2011-11-09LISPブログ
こちらのブログに加えて新しいLISPブログ始めました!
このブログと同じくLISPのことしか書かないブログになる予定です。
2011-07-17
DO&
Lispマシン |
いつものごとく古いLispマシンのメーリングリストを漁っていたところDO&というものの提案メールを発見しました。
Date: Wednesday, 21 April 1982, 20:15-EST From: levitt at MIT-AI, zvona at MIT-AI Sender: Zvona at MIT-AI Subject: LMLIB;DO& To: info-lispm at MIT-AI DO& is an interation macro with many of the features of LOOP and a LISPy syntax similar to DO*. User-definable keywords allow common iterative constructs -- like CDRing down a list, CONSing a new list, or counting -- to be implemented more simply and readably. Automatic generation of end tests makes the DO/DO* end-test form unnecessary. The programs below, equivalent to common LISP functions, give a feel for DO& style: (defun length (list) (do& ((i &count0) (l &pop list &return i)))) (defun reverse (list) (do& ((elt &pop list &return accum) (accum &push elt)))) (defun listarray (array) (do& ((elt &aref array &return (nreverse list)) (list &push elt)))) (defun remq (item list) (do& ((a &pop list &return (nreverse out)) (out &push a &only-if (neq a item))))) DO& allows most relevant information to appear within the variable specifications, improving program clarity, and doing away with the need for formulaic and complex bodies. DO& has evolved over more than two years and reimplemented many times. The rough corners have been worn off, and we now believe the current implementation is clean enough for general release. DO& is documented in detail in LMLIB;DO&DOC. Bugs to BUG-DO&@AI; users may wish to add themselves to INFO-DO&. Here is a partial comparison of features of DO& and LOOP. It is perhaps not perfectly impartial. Also, many of the features of LOOP which DO& lacks could be added if there were demand for them. DO& syntax is a natural extension of DO*. LOOP is a non-LISPy sublanguage. Partly as a consequence, it is easier to determine the scope of DO& keywords than that of LOOP keywords. Since keywords all begin with ``&'' it is easy to separate them from non-keywords. The simplicity of DO& syntax makes it trivial to learn and often immediately understandably by non-users. Also it indents better than LOOP in Zmacs. LOOP and DO& have roughly comparable numbers predefined iteration keywords. The sets are not identical; LOOP has a package mapping keyword, and DO& has one for mapping over plists. In any case, both make it relatively easy to define your own keywords, so exactly which keywords are defined by default is not very important. LOOP supports parallel binding; DO& does not. Of course you can always use an extra variable to get the same effect. DO& guarantees that variables have sensible values at all times; LOOP does not. In particular, in a LOOP epilogue, the values of iteration variables may be undefined, whereas in a DO& &RETURN form, they are always defined and take on the obvious value. Both LOOP and DO& achieve package independence by using pname equality in looking for keywords. LOOP supports destructuring; DO& does not. DO& generates automatic dummy variables when none is supplied in a variable specification; LOOP does not. LOOP does more code optimization than DO& does. DO& has many other features that are described in detail in DO&DOC.
LOOPマクロに対する対抗馬としては、最初期のものではないかと思いますが、LOOPで良く言われている問題点が既に述べられています。
面白そうなのでDO&のソースがどこかに落ちてないか探してみたのですが、残念ながらみつけることはできませんでした。
ということで、適当にサンプルコードが動く程度のものを作ってみました。
適当に考えながら作成していましたが、途中で面倒になったので、fare-matcherでやっつけることに。
しかし、サンプルコードの範囲だけではどういう動作なのかはちょっと分からないなという感じです…。
■
2011-07-12
CLでSRFI-30
SRFI, Common Lisp |
CLでSRFIな日々ですが、今回は、SRFI-30 ネスト可能な複数行コメントです。
ずばりのCLの、#| #| ...|# |# と同じなので、CLはSRFI-30対応済なのです。
とりあえず、レポジトリを作成してからソースを読んだりしているため、意味のないリポジトリを作成してしまいました。まあ良いかなと。
■
2011-07-09
LET*の星はRMSが考えた?
古いLispMのメーリングリスト(info-lispm@mit-ai)を眺めていて発見した、新機能の告知メッセージ
Date: 15 JUN 1980 0023-EDT From: RMS at MIT-AI (Richard M. Stallman) Subject: Incompatible change to PROG To: INFO-LISPM at MIT-AI Soon PROG will bind all the variables in parallel instead of sequentially. This only makes a difference if you have initializations which depend on other variables bound by the same PROG. If you want to bind variables sequentially, use PROG*, which is presently the same as PROG and will not change. Old QFASL files will continue to work as before. The change takes effect only when the program is recompiled. I plan to create LET* and DO*, which will both do sequential binding like PROG*, at some time in the future.
これだけでは、PROGの変数が直列に束縛されるものをPROG*にしたのがRMSかどうかははっきりしませんが、LET*はRMSの創案かもしれないですね。
おおー、RMSかー、などと思ってしまいました。こんなことに関心がある人も少ないかと思いますが。
■
2011-07-03
CLでSRFI-71
SRFI, Common Lisp |
昨日のSmiley Hackathon #10でちょっと手をつけて挫折していたSRFI-71ですがパターンマッチが上手く行かない理由が分かって動くようになりました。
その原因ですが、Schemeの場合は変数としてtが使われていることは普通なのですが、あまり注意していなかったのでCL:Tが紛れ込んでいて、パターンマッチが意図しない方向にマッチしていたというオチでした (CL:Tは定数なので変数とは違ったマッチになる) 。
さてそのSRFI-71ですが、多値を受けるLET構文の拡張です。
自分が移植したSRFIでも多値があつかえる束縛構文はこれで4つ目な気がするんですが、SRFIでは思いの外同じ分野の提案が繰り返し提案される傾向があるように思います。
■
また、SRFI-71では、unconsや、unlistも一緒に定義されていたりするのですが、ネーミングがなかなか良いなと思いました。
SRFI-11のlet-valuesと違うところといえば、値を受けるところにも (values v ...)という表記を使うことと、values省略して値を並べて書くこともできる、というところでしょうか。
(in-package :srfi-71-internal) (let (((values x1 x2 . x2+) (values 1 2 3))) (cons x1 (cons x2 x2+))) ;=> (1 2 3) (let ((car cdr (uncons '(1 2)))) (cons car cdr)) ;=> (1 2) (let (((values car cdr) (uncons '(1 2)))) (cons car cdr)) ;=> (1 2) (let (((values . args) (unlist '(1 2 3 4 5)))) args) ;=> (1 2 3 4 5)
ちなみに我等がSRFI-86でも同じような構文がサポートされています
(alet (((values . args) (values-list '(1 2 3 4 5)))) args) ;=> (1 2 3 4 5) (alet (((values x1 x2 . x2+) (values 1 2 3))) (cons x1 (cons x2 x2+))) ;=> (1 2 3)
■
Smiley Hackathon #10に参加してきました!
7/2(土)にSmiley Hackathon #10またまた参加させて頂きました!
今回も主催の d:id:acotie さん #10会場提供のGaiaXさんありがとうございました。
自分は、#4、#5、#6、#7、#9と参加しているので、今回で6回目。
やってたこと
SRFIの文字列ライブラリ srfi-13をこのハッカソンで仕上げようと思っていましたが、思いの外手強いのと実装にあたりchar-setというものが定義されているのが前提なところがあり中途半端な感じに。
時間があまったので、別のSRFIで手頃なものはないかと探してみたところ、SRFI 71: Extended LET-syntax for multiple valuesがあったので、これをCLに移植することに挑戦。
こっちは比較的楽勝なものを選んだ筈でしたが、マクロの展開が上手くいかず展開のデバッグにも行き詰まり頓挫。define-syntaxのデバッグの勘が全然浅いためなかなか展開の遷移が追い掛けられません。何か簡単に追い掛けられる方法を模索したいところ。
交流
前回に引き続きArcの@mgikenさんと@inuzini_jiroさんを交えつつArcネタで盛り上がりました。
Arc素晴らしいですね!!
是非また参加したいです!
■