ビスケットはいろいろと普通の言語とは違う変わった特徴があります．
書き換え型言語であるというのは，見た目には大きいですが，書き換え型言語のグループの中でも実は異質なのです．
ビスケットのプログラム（メガネ）には変数はありません．すべて実例です．もう少しちゃんというと，時間変化の実例です．ビスケットの特徴である柔らかい書き換えは，複数の時間変化の実例を与えることで，その実例に近い組み合わせを探して，その実例との近さに応じた結果に変化させる，という動き方をします．実例そのものだけではなく，その周辺もカバーしているので，それが変数的に振舞うということでもあります．
ところが，テトリスのプログラムに代表されるように，方眼紙をつかったプログラミングでは，その曖昧なマッチングはまったく使われていません．つまりビスケットの特徴がまったく生かされていません．では何が新しいのでしょうか．
ここからは架空の話ですが，ビスケット的な絵の書き換え言語で，柔軟性を導入しないで言語を進化させたとすると，当然入ってくるのがパターンの変数です．
メガネの左側と右側に同じ変数がきます．パターンマッチの際に，任意のパターンが右側の変数とマッチして，左側の変数にそのパターンが代入されて書き換えられます．
テトリスの場合だと任意の形のブロックを横に動かすというのを，ブロックがマッチする変数を導入することで，一つのメガネで表現することができるようになるわけです．
これは，もしかしたらあったかもしれないビスケットの拡張です．普通のコンピュータサイエンスのセンスであれば妥当な拡張だと思います．
現に，これまでもその部分的な機能として，実験的にワイルドカードの絵を導入したりしてました．任意の絵とマッチします．
しかし，この実験を通しても本格的な採用には至っていません．むしろ頑なに変数の導入を拒んでいます．
それによく考えるとテトリスのブロックが移動するメガネは変数でまとめてかけるほどは単純ではありません．
この二つのメガネをよく比べると，移動可能かどうかの空白のチェックの部分がそのブロックの形によって変わります．これを一般的に変数とマッチングで表現するような記述はやってやれないことはないでしょうけれど，そうとう難しそうです．
つまり，これを入れた瞬間にビスケットはとても難しい言語に変わってしまうのです．
この話の重要な点は，変数を導入しない表現形式にこだわる，ということなのだろうと思います．プログラムを元々あった発想である「変化の実例」の集合に止めておくということです．
普通のプログラミングは変数を導入して抽象化しますが，ビスケットはそれをやらない．しかし，大量の似たようなメガネはどうにかしたいです．そこで，メガネを自動的に生成するという方向を考えてみます．
パターン変数ですと，動き方を抽象化されたレイヤで考えなければなりませんが，自動生成ということにすれば，最終的には変化の実例のレイヤで考えられるということです．
パターン変数の場合は無限のパターンを表現できますが，展開する場合はどこかで有限に止める仕掛けが必要です．テトリスの場合はブロックの形があらかじめ決まっているということです．
実際，Javascript で書かれたテトリスを見ると，ブロックの回転を表現する部分で，どんな形のブロックも９０度回転することができるアルゴリズムが使われていました．これは７種類しかないブロックを回転させるには過剰な品質ですが，プログラム自身はその方が簡単になるので，過剰品質はプログラミングでよく見る光景ですね．
ここまで書いてて話は脱線しますが，プログラム上にいろんなセキュリティホールがありますが，その多くはプログラムの過剰品質から来ています．プログラムを書いたときには想定していなかった入力が来た時に誤動作するということです．それに対してメガネの自動生成のアプローチでは常に具体例にもどるというか，必要なことしか動かないのを考えて，それを簡単に作るという立場なので，この手のセキュリティホールを未然に防ぐ可能性もあります．
変数を使わないプログラムの表現レイヤーというのは面白そうです．