Hatena::Groupcadr

わだばLisperになる このページをアンテナに追加 RSSフィード

2004 | 12 |
2005 | 01 | 02 | 07 | 10 | 11 |
2006 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2011 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 11 |

2011-07-17

DO&

| 16:16 | DO& - わだばLisperになる を含むブックマーク はてなブックマーク - DO& - わだばLisperになる

いつものごとく古い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

| 19:02 | CLでSRFI-30 - わだばLisperになる を含むブックマーク はてなブックマーク - CLでSRFI-30 - わだばLisperになる

CLでSRFIな日々ですが、今回は、SRFI-30 ネスト可能な複数行コメントです。

ずばりのCLの、#| #| ...|# |# と同じなので、CLはSRFI-30対応済なのです。

とりあえず、レポジトリを作成してからソースを読んだりしているため、意味のないリポジトリを作成してしまいました。まあ良いかなと。

2011-07-09

LET*の星はRMSが考えた?

| 19:51 | LET*の星はRMSが考えた? - わだばLisperになる を含むブックマーク はてなブックマーク - LET*の星はRMSが考えた? - わだばLisperになる

古い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

| 23:09 | CLでSRFI-71 - わだばLisperになる を含むブックマーク はてなブックマーク - CLでSRFI-71 - わだばLisperになる

昨日の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に参加してきました!

| 02:32 | Smiley Hackathon #10に参加してきました! - わだばLisperになる を含むブックマーク はてなブックマーク - Smiley Hackathon #10に参加してきました! - わだばLisperになる

7/2(土)にSmiley Hackathon #10またまた参加させて頂きました!

今回も主催の d:id:acotie さん #10会場提供のGaiaXさんありがとうございました。

自分は、#4、#5、#6、#7、#9と参加しているので、今回で6回目。

やってたこと

SRFIの文字列ライブラリ srfi-13をこのハッカソンで仕上げようと思っていましたが、思いの外手強いのと実装にあたりchar-setというものが定義されているのが前提なところがあり中途半端な感じに。

時間があまったので、別のSRFIで手頃なものはないかと探してみたところ、no titleがあったので、これをCLに移植することに挑戦。

こっちは比較的楽勝なものを選んだ筈でしたが、マクロの展開が上手くいかず展開のデバッグにも行き詰まり頓挫。define-syntaxのデバッグの勘が全然浅いためなかなか展開の遷移が追い掛けられません。何か簡単に追い掛けられる方法を模索したいところ。

交流

前回に引き続きArc@mgikenさんと@inuzini_jiroさんを交えつつArcネタで盛り上がりました。

Arc素晴らしいですね!!

是非また参加したいです!