左辺

プログラミング言語 SchemeLISP 系言語の一種である。 代入を行う構文も他の構文と同様に括弧を用いた形式である。 例えば (set! foo 1) といったように書く。

さて、 Scheme の規格である R6RS を読んでいて気づいたのだが、このときの foo の場所を left-hand side (日本語ではだいたい「左辺」と訳される) と呼んでいるのだ。

構文の名前である set! よりは右に現れるので左辺というのはいささか奇妙な印象を受ける。

この用語が出現するのは set! についてと let 系構文の束縛部についてだけのようなので、これらについてだけは特別扱いなのだろうか。 数学用語の延長なのかもしれない。

Document ID: 14b6d1f6c55c33723c60aa9c4a1bd08a

Wiki 記法

Wiki 記法は様々なものがあるが、書きたいものを短くマークアップできるようにするということが重要な目的であり、万能性を求めたあげくに複雑怪奇になってしまうようなら本末転倒だと思う。 充分に高い表現力が欲しいなら HTML で書けばよい。

とはいうものの、分野ごとに様々な記法が乱立するというのもそれはそれでつらいので、 Markdown (またはそれを基礎にして拡張した記法) が手頃なものとして重宝(ちょうほう)されるのもわかることではあるのだ。

だが、既存の Wiki 記法を見るかぎりどれもこれもパースしづらく、自分が作るプログラムでそれらの記法を採用するのは躊躇(ためら)う。

パースのしやすさと書き(やす)さを上手く両立できるような記法について考えている。

Document ID: 7de6730155b31b410f8b441850e51e48

こんな夢をみた「村上旅館」

こんな夢を見た。

子供の頃に遊び場にしていた廃墟の近くを通りかかると、廃墟に村上旅館という看板が付いていることに気づいた。

これだけの夢なのだが、私は実際にはそんな廃墟で遊んだことは無い。 夢の中で廃墟があった場所は、現実には、私の知る限りずっと田んぼである。

レンタルビデオショップ大手の「ゲオ」で以前にクーポンを貰った。 使う機会がないまま放置していたのであるが、あらためて見るとサービスの実施期間として年を書いていないことに気付いた。 月日と曜日だけによる記載なのである。

具体的には 1/1 SUN ▶ 1/31 TUE といったように記載されている。 クーポンを受取った日のことを考えると常識的には 2017 年の 1 月のことだというのはわかるのだが、当然ながらおおよそ 7 年毎に同じ曜日が巡ってくる。 たとえば 2023 年の 1 月の曜日もこの記載内容に当て嵌ってしまうのだ。

法的には機械的に発行されるクーポンは契約の一種とは見做されず、店側が応じなければそれ以上の要求はできないということのようだが、火種になりかねない要素だと思う。

日付を書くときは年も入れるに越したことはない。

Document ID: 56165c6c4711acbd54045d53b6cdab56

こんな夢をみた「四年七組」

こんな夢をみた。

私は小学校の校庭にいた。 夕方から夜になりかけるくらいの暗さだった。 見えないことはないが、不安な程度の暗さといったところである。 誰もいない。

私は内ポケットからリモコンを取り出してスイッチを押すと校庭の照明が付いた。 校庭の照明は野球場にあるようなすごく強力なもので、たちまち明るくなった。 照明のリモコンは、一般的な照明用のリモコンとして想像されるようなものではなく民家の壁に設置されているようなものをそのまま取り出してきたような形をしていた。

私が小学校にいたのは、小学校に関連する噂を確かめにきたのだった。 四年七組の教室には呪いがかかっているのだという。

私は小学校に入っていくと、何故か床や壁は剥き出しの木造で、一般的な校舎の意匠ではなかった。 校舎というよりも、寺を思わせる見た目であった。 ちなみに、外から見た校舎はごく一般的な学校の様式だった。 建物は校舎の様式にありがちな細長いものではなく、上から見ると真四角のような形になっていたはずだ。 その右奥が目的の四年七組だった。

寺の廊下のような廊下をそのまま進み、四年七組の教室の戸 (障子が貼られた和風の様式の戸である) をあけると、そこもまた畳敷きの和風の部屋だった。 だが、とりたてて怪奇現象に関するようなものもなく、廊下を通って入口に戻ろうとすると、曲がり角で和尚に鉢合わせた。

以上。

夢の中の私はこれらを当然のものと受け止めていたが、実際にはこんな場面を体験したことは一度もない。

この夢に登場した小学校の外観は私が通っていた小学校とは全く異なるものであったし、私の通っていた小学校は各学年に二組しかないので七組などといったものは存在するはずもない。 当然に、教室が和風だったりもしない。 どこかの教室の呪いなどといった噂も記憶にない。

こういったよくわからない夢が、いったいどういった記憶から合成されたものなのか、自分の内面に想いをはせてみるのもまた一興である。

こんな夢をみた「ゆがんだ景色」

こんな夢を見た。

私は自動車にのっていた。 自動車は高度に自動制御されていて運転の必要はないが、見た目には現代の普通の自動車のようにハンドルもあり、ペダルもついていた。 窓はガラスではなくディスプレイになっていて、外の様子に情報を付け加えて表示する、いわゆる強化現実 (AR) を実装したものだった。

その自動車は山道を走っていた。 遠くに山城が見えた。 自動車には誰だかよくわからない同乗者がいた。 同乗者の説明によれば、城を中心にした観光地なのだという。

しばらくすると、 (窓に模した) ディスプレイの景色がゆがみ、まるで空中を走っているかのような状態になった。 観光地として城を強調するあまり、どこからでも城が見えるようにデータが補正されて、結果として無理のある映像になっているのだと同乗者が説明してくれた。

私はリセットスイッチ (通常の自動車ならばワイパーを動かすスイッチであるが、夢の中の私はなぜかそれをリセットスイッチと認識していた) を押したが、映像はゆがんだままだった。 与えられるデータがゆがんでいるので、やりなおしたところでゆがみは解消されないのだった。

Document ID: 2942e23018114c8c9f1bee809e2eceac

メモリストリーム

プログラミング言語 C における文字列というのはメモリの塊そのものです。 見えているままのデータがメモリ上のどこかに配置されています。 余計なことをしない単純さは機械の性能を引き出しやすい一方で、ちょっとしたことでもプログラマが手間をかけなければいけません。 もちろん、文字列を扱うライブラリを導入したり作ったりすればいくらでも複雑なことは出来るのですが、凝ったデータ構造は標準ライブラリとの組合せがやり難くなります。 そのあたりを考慮して使い勝手がよく汎用性が高い仕組みが作れないものかと私は考えていました。 そして、思い出したのは以前に作ったメモリをストリームとして読みだす仕組みのことです。

パイプでメモリをストリームにする - 主題のない日記

これと同様にメモリへの書き込みをストリームを通して出来る仕組みがあれば便利でしょう。 Scheme の文字列ポートによって、ファイル操作と同じ要領で文字列を構築できる便利さを私は知っています。

結果として出来たライブラリに memstream と名付けて Github に置きました。

GitHub - SaitoAtsushi/memstream: The library for access memory via stream.

例えば数をストリームに出力する関数があったとして、関数 open_output_memstream がオープンしたストリームを出力先にすればそのまま文字列を構築することが出来ます。 以下のように使えます。

#include <stdio.h>
#include <stdlib.h>
#include "memstream.h"

int count_three(FILE* fp) {
  int total=0;
  for(int i=3; i>0; i--)
    total += fprintf(fp, "%d\n", i);
  return total;
}

char* count_three_string(void) {
  FILE* fp=open_output_memstream();
  count_three(fp);
  fputc('\0', fp);
  size_t len;
  char* str = mclose(fp, &len);
  return str;
}

int main(void) {
  count_three(stdout);
  char* str=count_three_string();
  printf("%s\n", str);
  free(str);
  return 0;
}

ライブラリ memstream は Windows のパイプの機能を利用しています。 パイプの読書きのハンドルに対しては、シークを除いてはファイルに対しての読書きとほぼ同じ操作が可能なので、パイプのもう一旦で受取った情報を文字列として構築するという考え方です。

POSIX に有る open_memstream という機能とよく似ています。 インターフェイスも合わせることも考えたのですが、別スレッドで動いている都合上、タイミングを待つ必要があって現在の形に落ち着きました。

Document ID: 7f7c141b7a1c51ba27bf73ac15996653