《 Lisp SETF Advent Calendar 2018 13日目 》

setf系構文の紹介ですが、今回は、define-modify-macroの紹介です。

define-modify-macroは、簡単に説明するなら、(setq x (fn x))のようなパターンを簡潔に(fnf x)と書けるようにする便利定義構文なのですが、このようなパターンが頻出する訳でもないので、普段はそんなに使うこともない印象があります。

define-modify-macroで何か定義してみる

(setq x (cdr x))

というパターンはそこそこ使いますが、define-modify-macroでcdrfでも定義してみましょう。

(define-modify-macro cdrf () cdr)
(let ((x (list 0 1 2)))
  (cdrf x)
  x)
→ (1 2) 

まあ、実質同じことをするビルトインマクロにpopがありますが……。
一応返り値が違います。

定義構文の注意点として、代入にされる場所となる変数が先頭に来て、さらにそれが定義構文中には現われない、という点です。
cdrの場合は1引数なので、0引数で記述します。

define-modify-macroを使えば役に立ちそうな立たなそうな構文を大量生産できます。

(define-modify-macro listf (&rest args) list)
(let ((x (list 0 1 2)))
  (list x 1 2))
→ ((0 1 2) 2 3 4) 
(define-modify-macro =f (&rest args) =)
(let ((x 0)
      (y 1))
  (=f x y )
  (list x y))
→ (nil 1) 

appendf、nconcf等々は定番アイテムで、色々なユーティリティライブラリに含まれています。
まあ、ライブラリを読み込むのが面倒な場合には、簡単なので定義してしまっても良いでしょう。

modify-macrolet

define-modify-macroは大域定義になるのですが、7年程前にローカル構文版を思い付いて作ったことがありました。

• GitHub: g000001/modify-macrolet

これを使うと、

(modify-macrolet ((nconcf (&rest args) nconc))
  (let ((x nil))
    (nconcf x (list 0 1 2 3))
    x))

のように大域の名前を汚染することなくローカルに書くことが可能になります。

ちなみに、個人的には定義してから7年間一度も使ったことはないですが、ご興味のある方は如何でしょうか。
また、modify-macroletを自作してみるのも一興かなと思います。

■

HTML generated by 3bmd in LispWorks 7.0.0

《 Lisp メソッドコンビネーション Advent Calendar 2018 13日目 》

前回に引き続き、メソッドコンビネーション元祖のFlavorsに標準装備されていたメソッドコンビネーションを眺めたり再現してみたりしようと思います。

メソッドの返り値を順繰りに次のメソッドに送っていく:pass-onの再現がしたくて苦戦していましたが、なんとか形にできました。

Flavorsの:pass-onの挙動を確認してみる

とりあえず、LMI Lambdaのエミュレータで挙動が確認できたのですが、こんな感じでした。

(defflavor a () ()
  (:method-combination (:pass-on (:base-flavor-last) :m)))
(defflavor b () (a))
(defmethod (a :m) (x y)
  (values (list :a x) (1+ y)))
(defmethod (b :m) (x y)
  (values (list :b x) y))
(send (make-instance 'b) :m 0 1)
→ (:a (:b 0))
   2

aを継承するbという2つのflavorに、それぞれmを:pass-onで定義し、bのインスタンスでmを呼び出すと、b.mの返り値をa.mが受け取るようになります。
:base-flavor-lastなのでb→aの順番ですが、:base-flavor-firstにすれば、逆にもできます。

:pass-onが多値で返す意味が分からなかったのですが、良く考えると、メソッドの引数が複数になる場合は、多値かリストにして対応するしかなく、リストだと受取側の引数のインターフェイスを変更しないといけないので、多値で返すしかないですね。なるほど。

Common Lispで再現してみる

MOPのmake-method-lambda、compute-effective-methodあたりでどうにかできないか検討しましたが、call-methodフォームを作成して、また分解して、という感じになってしまうので、call-methodをスルーして、メソッドの関数をmethod-functionで取り出して直接呼ぶことにしました。

(ql:quickload :closer-mop)
;; LispWorks/Allegro CL
(define-method-combination :pass-on ()
  ((ms ()))
  (:arguments &rest args)
  (let ((vs (gensym "vars-")))
    `(let* ((,vs ,args)
            ,@(loop :for m :in ms 
                    :collect `(,vs
                               (multiple-value-list
                                (apply ,(c2mop:method-function m)
                                       ,vs)))))
       (declare (dynamic-extent ,vs))
       (values-list ,vs))))

しかし、メソッドの引数情報が欲しいので、define-method-combinationの:argumentsを指定しているのですが、SBCLだと:argumentsがちゃんと実装されていないようなので&restが使えません。

また、method-functionが返す関数の引数は、args、next-methodsの筈なので、(funcall method-function vs nil)とするのが正しそうですが、LispWorksとAllegro CLでは、(apply method-function vs)でないと上手く動かない謎。

そんなこんなで、まともに動くものができているとは言い難いですが、こんな感じに書けます。

(defclass a () ())
(defclass b (a) ())
(defgeneric m (o x y)
  (:method-combination :pass-on))
(defmethod m ((o a) x y)
  (values o (list :a x) (1+ y)))
(defmethod m ((o b) x y)
  (values o (list :b x) y))
(m (make-instance 'b) 0 1)
→ #<b 40205BA353> 
   (:a (:b 0)) 
   2 

メソッドコンビネーションの展開はこんな感じで別段変なことはしていませんが、どの処理系も何かしらおかしい感じです。
まあ、LispWorksとAllegro CLで動くので良しとしましょう。

(mc-expand #'m :pass-on nil (make-instance 'b) 0 1)
→ 
(let* ((#:|vars-131621| args)
       (#:|vars-131621|
        (multiple-value-list (apply #<Function (method m (b t t)) 4140032074>
                                    #:|vars-131621|)))
       (#:|vars-131621|
        (multiple-value-list (apply #<Function (method m (a t t)) 41400320FC>
                                    #:|vars-131621|))))
  (declare (dynamic-extent #:|vars-131621|))
  (values-list #:|vars-131621|)) 

まとめ

HyperSpecによると、define-method-combinationの:argumentsでは、&restの他に&wholeも使えたりするみたいですが、メジャーな処理系を試してみたところ、まともに:argumentsの機能を実装しているものは無いように思えます。

• CLHS: define-method-combination

SBCLは、ソースを眺める限り&restを処理できていないのですが、今後修正されれば、今回の:pass-onも動くんじゃないかなと思います。

■

HTML generated by 3bmd in LispWorks 7.0.0

《 Lisp メソッドコンビネーション Advent Calendar 2018 12日目 》

前回に引き続き、メソッドコンビネーション元祖のFlavorsに標準装備されていたメソッドコンビネーションを眺めたり再現してみたりしようと思います。

本当は、:pass-onの再現がしたいのですが、色々間に合ってないので、:daemon-with-overrideの再現でお茶を濁したいと思います。

:daemon-with-overrideは、Common Lispでいうと、:aroundなしのstandardメソッドコンビネーションの前に門番のメソッドがいるような感じですが、こんな感じに定義できます。

(define-method-combination :daemon-with-override ()
  ((before (:before))
   (after (:after))
   (primary ())
   (override (:override)))
  `(or 
    ,@(and override `((call-method ,(car override))))
    (multiple-value-prog1 
        (progn
          ,@(loop :for m :in before :collect `(call-method ,m))
          (call-method ,(car primary) ,(cdr primary)))
      ,@(loop :for m :in (reverse after) :collect `(call-method ,m)))))

細かいオプションは詰めてないですが、これくらいの定義なら空で書けるようになりました。
難解だと思っていたdefine-method-combination構文ですが、10個位定義を書けば、そこそこ覚えられそうですね。

では、使ってみましょう。

(defgeneric foo (x)
  (:method-combination :daemon-with-override))
(defmethod foo ((x T)) x)
(defmethod foo :before ((x T)) (print :before))
(defmethod foo :after ((x T)) (print :after))
(defmethod foo ((x rational))
  `(rational ,(call-next-method)))
(defmethod foo ((x integer))
  `(integer ,(call-next-method)))
(defmethod foo :override ((x number))
  (evenp x))

(foo 8)
→ t 
(foo 9)
▻ :before 
▻ :after 
→ (integer (rational 9)) 

メソッドコンビネーションを展開してみるとこんな感じになります。

(mc-expand #'foo
           :daemon-with-override
           nil
           1)
→
(or (call-method #<standard-method foo (:override) (number) 40201044DB>)
    (multiple-value-prog1
        (progn
          (call-method #<standard-method foo (:before) (t) 402045306B>)
          (call-method
           #<standard-method foo nil (integer) 4130468943>
           (#<standard-method foo nil (rational) 413046892B>
            #<standard-method foo nil (t) 413046961B>)))
      (call-method #<standard-method foo (:after) (t) 4020462243>)))

まとめ

:daemonメソッドコンビネーションに門番がついているというパターンなので、Common Lispでは、:aroundを使えば実現できるパターンですね。

数あるパターンが、Common Lispでは、:aroundとして集約されたという流れが想像できます。

■

HTML generated by 3bmd in LispWorks 7.0.0

《 Lisp SETF Advent Calendar 2018 12日目 》

前回の(setf all)を定義していて気付いたのですが、incfや、push、popはvaluesと組み合わせると処理系によって異なる動作をします。

下記のような例は、SBCLやAllegro CLでは中途半端な動きをしますが、LispWorksではマクロ展開時にエラーになります。

(let ((x 0)
      (y 0))
  (incf (values x y))
  (list x y))
→ (1 nil) or error
(let ((x (list 0 1 2))
      (y (list 1 2 3)))
  (pop (values x y))
  (list x y))
→ ((1 2) nil) or error

もしや、setf以外はvaluesを取れないのかと思い、HyperSpecを確認してみましたが、5.1.2.3 VALUES Forms as Placesでもvaluesはsetf以外では機能しない、とは書いてありません。

間接的な定義がされている場合もあるので、それらしきものを探してみましたが、setfベースのマクロについての定義があります。

• 5.1.3 Treatment of Other Macros Based on SETF

decf、pop、pushnew、incf、push、remfはdefine-modify-macroで定義されているような挙動をする的な解釈が成立しそうな雰囲気もありますが、 define-modify-macroのAPIからすると、関数の引数として値を処理するので、多値は扱えません。
define-modify-macroで定義すれば、incfのようなものは、

(let ((x 0)
      (y 0))
  (setf (values x y)
        (values (1+ (values x y))))
  (list x y))
→ (1 nil) 

のように展開されると思われるので、中途半端な返り値になっている理由も合点はいきます。

多値を扱いたい

とりあえず、多値を扱えるフォームはどんな感じになるか定義して眺めてみます。

incfの多値版は、こんな感じに定義できるかなと思います。

(defmacro incf* (place &optional (delta 1) &environment env)
  (multiple-value-bind (dummies vals newval setter getter)
                       (get-setf-expansion place env)
    (declare (ignore dummies vals setter))
    (let ((deltas (loop :for () :on newval :collect (gensym))))
      `(multiple-value-bind ,newval
                            ,getter
         (setf (values ,@deltas) 
               ,(if (eql 1 delta)
                    `(values ,@(loop :for () :on deltas :collect 1))
                    delta))
         (setf ,getter
               (values ,@(mapcar (lambda (v d)
                                   `(incf ,v ,d))
                                 newval
                                 deltas)))))))
(let ((x 0)
      (y 1))
  (incf* (values x y) (values 1 10))
  (list x y))
→ (1 11) 

popの多値版はこんな感じ

(defmacro pop* (place &environment env)
  (multiple-value-bind (dummies vals newval setter getter)
                       (get-setf-expansion place env)
    (declare (ignore dummies vals setter))
    (let ((retvars (loop :for () :on newval :collect (gensym))))
      `(multiple-value-bind ,newval
                            ,getter
         (let (,@(mapcar (lambda (a d)
                           `(,a (car ,d)))
                         retvars
                         newval))
           (setf ,getter
                 (values ,@(mapcar (lambda (v)
                                     `(cdr ,v))
                                   newval)))
           (values ,@retvars))))))
(let ((x (list 0 1 2))
      (y (list 0 1 2)))
  (pop* (values x y))
  (list x y))
→ ((1 2) (1 2)) 

VALUES Forms as Placesを処理できるdefine-modify-macro*のようなものを定義してみても良いかもしれません。

まとめ

どうせコンパイル時に展開すると思うのでVALUES Forms as Placesを処理できても良いと思うのですが、何か事情があるのでしょうか。

これらのフォームは、ループ内で頻出しそうなので極力無駄のない定義になる必要があるような気はしますが、展開時に無駄は省けそうですし、さて真相やいかに……。

■

HTML generated by 3bmd in LispWorks 7.0.0

《 Lisp メソッドコンビネーション Advent Calendar 2018 11日目 》

前回に引き続き、メソッドコンビネーション元祖のFlavorsに標準装備されていたメソッドコンビネーションを眺めたり再現してみたりしようと思います。

前回いきなりcaseメソッドコンビネーションの再現に取り組んでみましたが、改めて、どんなメソッドコンビネーションがあるのか一覧にしてみたくなりました(ネタ切れだから)

調べてみたのは、後期Flavors〜New Flavorsあたりのメソッドコンビネーションです。

前知識

Flavorsのメソッドコンビネーションの標準構成は、Common Lisp版から:aroundを外したようなものです。
:aroundの部分は、defwrapperというメソッドを囲むマクロを定義する感じになります。

また、キーワードシンボルになっていますが、Lisp Machine Lispでは、userパッケージのシンボルの略記になります。
つまり、(eq :progn 'progn)です。
共用シンボルはuserパッケージに置かないで、keywordパッケージに纏めよう、と整理したのがCommon Lispです。

さて、では眺めてみましょう。

:daemon

Common Lispのstandardメソッドコンビネーションから:aroundを外したようなもの。
これを:darmonと呼びます。

:before / :after

Common Lispと同じです、:daemonメソッドコンビネーションの部品を単体で呼び出しているとも考えられます。

:and / :or / :progn

Common Lispから:aroundを外したようなもの。

:append / :nconc / :list

Common Lispから:aroundを外したようなもの。

:inverse-list

listが逆順になって返ってきます。
わざわざ用意しているからには使い道があるのでしょう……。

:max / :min / :sum

Common Lispと同じですが、:sumは、Common Lispでは+になっていますね。

:case

前回紹介した不思議メソッドコンビネーションです。

:daemon-with-and

:andの前後を:before、:afterで囲んだものです。
Common Lispではandに:daemonは付きません。

:daemon-with-or

:orの前後を:before、:afterで囲んだものです。

:daemon-with-override / :override

:overrideで定義したメソッドが:daemonメソッドコンビネーションの前に配置されていて、それがorで結合しています。
つまり、:overrideがnilを返した場合だけ、:daemonに進むという変ったものです。

:two-pass

プライマリ全部起動の後に:after全部を起動するものらしいです。
make-instanceで良く使うらしいですが、インスタンス初期値の設定とかでしょうか。

:pass-on

メソッドの返り値を次のメソッドに次々と渡していくメソッドコンビネーションのようです。
先日フィルターを作ろうとしていましたが、pass-onならできそうです。 しかし、返り値は何故か多値で返す様子。。
(a b c)という引数を持つメソッドを連鎖させるには、(values a b c)で値を渡さないといけないようですが、何故なのか。

ネタ切れなので、次回からCommon Lispで、Flavorsのメソッドコンビネーションを、`Symbolics Open Genera上のFlavorsの挙動を確認しつつ再現していきます。

■

HTML generated by 3bmd in LispWorks 7.0.0

《 Lisp SETF Advent Calendar 2018 11日目 》

setf関数、defsetfと紹介してきましたが、今回は一番汎用的なdefine-setf-expanderの紹介です。
実際、defsetfや、define-modify-macroも、define-setf-expanderの定義に展開している処理系も多いです。

define-setf-expanderを簡単に説明すると、

(setf (x y z) a b c)

のようなフォームのx、y、z、a、b、cという部品を好きなように配置することが可能です。

好きなように、といっても一応x、y、zは変数としての振舞い、a、b、cは値としての振舞いをする必要はありますので、作法に則る必要はあります。

CPLの代入構文のallを作ってみよう

左辺値について調べている際に、CPLが左辺値、右辺値を整理したとWikipediaに書いてあったので、ちょっと眺めてみましたが、Fortran、Algolに比較すれば、左辺値が拡張された感じはします。

• The main features of CPL

左辺値にリスト表現や配列をとって、変数を複数同時に代入できたり、リストを分解して変数に代入できたり、1963年の言語にしては先進的ですが、拡張のバリエーションとして、

all a, b, c := 0

という書法がありました。

上記の場合は、変数全部に0が代入されるわけですが、左辺と右辺で微妙に対称性がなく、イレギュラーなsetf定義の例に良さそうなので、ちょっと考えてみましょう。
まず、構文の見た目ですが、こんな感じになるかなと思います。

(setf (all a b c) 0)
(list a b c)
→ (0 0 0)

構文全体としては直感的なのですが、allというゲッターを考えるに、これは単独では存在できそうにないですが、どうなんでしょう。
それはさておきこんな感じに書いてみました。

(define-setf-expander all (&rest places &environment env)
  (loop :with store := (gensym "all-")
        :for p :in places
        :for (d v sv setter getter) := (multiple-value-list (get-setf-expansion p env))
        :append d :into ds
        :append v :into vs
        :append sv :into svs
        :collect setter :into setters
        :collect getter :into getters
        :finally (return 
                  (values ds
                          vs
                          `(,store)
                          `(let (,@(mapcar (lambda (v)
                                             `(,v ,store))
                                           svs))
                             (values ,@setters))
                          `(values ,@getters)))))

下記のフォームをマクロ展開してみると、

(let ((x 0)
      (y 0)
      (z 0))
  (incf (all x y z) 100)
  (list x y z))
→ (100 100 100)

こんな感じになります。

(let ((x 0) (y 0) (z 0))
  (let* ()
    (let* ()
      (let ((#:|all-128690| (+ (values x y z) 100)))
        (let ((#:|Store-Var-128691| #:|all-128690|)
              (#:|Store-Var-128692| #:|all-128690|)
              (#:|Store-Var-128693| #:|all-128690|))
          (values (setq x #:|Store-Var-128691|)
                  (setq y #:|Store-Var-128692|)
                  (setq z #:|Store-Var-128693|))))))
  (list x y z))

大体の場所でallは機能が成立するようです。

(let ((x (list 0 1 2))
      (y 0)
      (z 1))
  (setf (all (values (car x) (cadr x)) y z) 
        42)
  (list x y z))
→ ((42 42 2) 42 42) 
(let ((v (make-sequence 'vector 7)))
  (setf (all (elt v 1)
             (elt v 3)
             (elt v 5))
        '-
        (all (elt v 0)
             (elt v 2)
             (elt v 4)
             (elt v 6))
        '+)
  v)
→ #(+ - + - + - +)  

しかし、push、popの挙動は良く分かりません。
push/popした後のリストがallによって同値になるので、これであってるような間違っているような。

(let ((x (list 1 2 3))
      (y (list 0 0 0)))
  (push 'a (all x y))
  (list x y))
→ ((a 1 2 3) (a 1 2 3)) 
(let ((x (list 1 2 3))
      (y (list 0 0 0)))
  (pop (all x (cdr y)))
  (list x y))
→ ((2 3) (0 2 3)) 

まとめ

変った代入構文をみつけたら、また定義に挑戦してみようと思います。

■

HTML generated by 3bmd in LispWorks 7.0.0

《 Lisp メソッドコンビネーション Advent Calendar 2018 10日目 》

組み込みのメソッドコンビネーションの紹介も尽きてきたので、メソッドコンビネーション元祖のFlavorsに標準装備されていたメソッドコンビネーションの再現でもしてみましょう。

Flavorsのcaseメソッドコンビネーション(の真似のつもり)

Flavorsのcaseメソッドコンビネーションと題しつつオリジナルの挙動が確認できていないのですが、どうもFlavorsとNew Flavorsで挙動が違うようです。

再現したつもりなのは、New Flavorsの方ですが、もしかすると、第二修飾子がメソッドの引数に現れた場合のディスパッチにcaseを使うのかもしれません。

作成してみたものは、メソッドの引数を安直にcaseに展開するもので、第二修飾子がcaseのマッチ対象になります。

(define-method-combination case ()
  ((case-clauses (case . *)))
  (:arguments a)
  (loop :for c :in case-clauses
        :if (equal '(case otherwise) (method-qualifiers c))
        :collect c :into otherwise
        :else 
        :collect `(,(cadr (method-qualifiers c)) (call-method ,c nil)) :into clauses
        :finally 
        (return 
         `(case ,a
            ,@clauses
            ,@(and otherwise 
                   `((otherwise
                      ,(reduce (lambda (m ms)
                                 `(call-method ,m ,(and ms `((make-method ,ms)))))
                               otherwise
                               :initial-value nil
                               :from-end T))))))))

(defgeneric fib (n)
  (:method-combination case))
(defmethod fib case 0 (n) n)
(defmethod fib case 1 (n) n)
(defmethod fib case otherwise ((n number))
  (+ (fib (1- n)) (fib (- n 2))))
(defmethod fib case otherwise ((n integer))
  (call-next-method))
(fib 20)
→ 6765 

展開を確認してみるとこんな感じです

(mc-expand #'fib 
           'case
           nil
           20)
→
(case a
  (1 (call-method #<standard-method fib (case 1) (t) 41E00640EB> nil))
  (0 (call-method #<standard-method fib (case 0) (t) 41E00641C3> nil))
  (otherwise
   (call-method
    #<standard-method fib (case otherwise) (integer) 41E0061D63>
    ((make-method
      (call-method
       #<standard-method fib (case otherwise) (number) 41E0059333>
       nil)))))) 

eql特定子をメソッドコンビネーションで実装してしまっている感がありますが、汎用化を推し進めると、filtered-functionみたいなことになるのかなと思います。

今後、Flavors、New Flavorsのcaseメソッドコンビネーションの挙動が確認できたら、オリジナルに忠実なものも作成してみようと思います。

■

HTML generated by 3bmd in LispWorks 7.0.0

《 Lisp メソッドコンビネーション Advent Calendar 2018 9日目 》

前回メソッドコンビネーションのlistが:aroundと組み合わせることで結構汎用的に使えることが分かってしまいました。
+、min、max、append、nconcのメソッドコンビネーションを眺めると、どれも&restな引数の関数なので、listメソッドコンビネーションでできた結果を:aroundでapplyすれば良いだけです。

define-method-combinationの短形式は指定したシンボルのフォームで囲むメソッドコンビネーションを定義しますが、関数以外のオペレーターも指定することが可能です。

define-method-combinationの短形式の存在意義を確認するため、clパッケージ内のフォームを物色してみました。

define-method-combinationの短形式で定義できそうなものを探す

ということで、引数が&restか&bodyかで始まるフォームをclパッケージから探してみましたが、下記のようになりました。

(ql:quickload :trivial-arguments)
(loop :for s :being :the :external-symbols :of :cl
      :when (and (fboundp s)
                 (ignore-errors
                   (typep (trivial-arguments:arglist s)
                          '(cons (member &rest &body) *))))
      :collect s)
→ 
(rotatef shiftf cond ignore-errors
 append logeqv tagbody and
 locally logand lcm psetf
 trace vector in-package with-standard-io-syntax
 gcd psetq setq logior
 nconc or list progn
 make-broadcast-stream values untrace loop
 make-concatenated-stream declaim logxor +
 *)

なるほど、碌な応用が考えつかないものばかりです。
標準で提供されているメソッドコンビネーションは、このリストの中でも割合に有用なものが選ばれていたことも判ります。

とりあえず、幾つか定義を試してみましょう

ignore-errorsメソッドコンビネーション

define-method-combinationの短形式で順次実行のフォームを定義した場合、基本的にprognと同じようになります。

(define-method-combination ignore-errors)
(defgeneric foo (x y)
  (:method-combination ignore-errors))
(defmethod foo ignore-errors (x y)
  (+ x y))
(defmethod foo ignore-errors ((x list) (y list))
  (append x y))
(foo 1 2)
→ 3 
(foo '(0 1 2) '(a b c))
→ nil 
   #<conditions:arithmetic-type-error 40201FF25B> 

こんな感じに展開されるのですが、エラーが発生してもとにかく続行したいという時には使えるかもしれません。

ignore-errorsメソッドコンビネーションは、prognメソッドコンビネーションを`ignore-errorsで囲めば定義せずに済んでしまいそうです。
and、orメソッドコンビネーションと:aroundでignore-errors適用も良さそうです。

一応の展開形確認

(mc-expand #'foo 
           'ignore-errors
           nil
           '(0 1 2)
           '(a b c))
→
(ignore-errors (call-method
                #<standard-method foo (ignore-errors) (list list) 402014EFD3>
                nil)
               (call-method
                #<standard-method foo (ignore-errors) (t t) 40201FE2C3>
                nil)) 

valuesメソッドコンビネーション

listメソッドコンビネーションに:aroundでvalues-listすれば良いのですが、より直截的でしょうか。

(define-method-combination values)
(defgeneric foo (x y)
  (:method-combination values))
(defmethod foo values (x y)
  (list x y))
(defgeneric bar (x)
  (:method-combination values))
(defmethod bar values ((x number))
  (list x 'number))
(defmethod bar values ((x rational))
  (list x 'rational))
(defmethod bar values ((x float))
  (list x 'float))
(defmethod bar values ((x integer))
  (list x 'integer))
(bar 1.0)
→ (1.0 float) 
   (1.0 number) 

まあ、頭を捻れば応用例も見出せるかもしれません。

loopメソッドコンビネーション

loopで囲んでみましたが、メソッドコンビネーションスコープとループのスコープが微妙に噛み合いません。
長形式で工夫して定義するかMOPでメソッドコンビネーションの枠組み自体を書き換えるかしないと、あまり有用な定義はできなさそうです。

噛み合わない点ですが、loopのblockスコープが指定できない、等々です。
これもprognメソッドコンビネーションで、条件が成立するまでループさせるような:aroundを書いた方が有用かもしれません。

(define-method-combination loop)
(defgeneric baz (x)
  (:method-combination loop))
(defmethod baz loop (x)
  (print x)
  (throw 'baz x))
(defmethod baz loop ((x number))
  (print (list (incf x) 'number)))
(defmethod baz loop ((x rational))
  (print (list (incf x) 'rational)))
(defmethod baz loop ((x integer))
  (print (list (incf x) 'integer)))
(defmethod baz :around (x)
  (catch 'baz
    (call-next-method)))
(baz 8)
▻ (9 integer) 
▻ (9 rational) 
▻ (9 number) 
▻ 8 
→ 8

tagbodyメソッドコンビネーション

折角なので常軌を逸していそうなtagbodyについて考えてみましたが、blockや、tagbodyのタグのスコープはダイナミックエクステントなので、普通に書いたらメソッドを跨ぐことができません。
ということで、定義がtagbodyやblockの中に収まっている必要があります。

(define-method-combination tagbody)
(defgeneric fact (n)
  (:method-combination tagbody))
(block nil
  (let ((n 20)
        (ans 1))
    (tagbody 
      (defmethod fact tagbody ((n (eql 0)))
        (go X))
      (defmethod fact tagbody ((n integer))
        (setq ans (* n ans))
        (go L))
L     (decf n)
      (fact n)
X     (return ans))))
→ 121645100408832000 

まとめ

define-method-combinationの短形式を使って有用なものを定義できることは、ほぼなさそうです。
関数系であれば、listメソッドコンビネーション & :aroundの組み合わせで、順次実行フォーム系であれば、progn & :aroundの組み合わせを、非常に簡潔に書ける、ということがメリットですが、長形式だけ用意しておけば良かったのではないかナー、という結論です。

■

HTML generated by 3bmd in LispWorks 7.0.0

《 Lisp SETF Advent Calendar 2018 9日目 》

今回は、また毛色を変えて、setf系の面白構文を紹介したいと思います。

letf

letfは、Lisp Machine Lispに存在したletとsetfが合体したような構文です。
束縛系構文なので、代入系のsetfとはちょっと違うのですが、こんな感じで使えます。

(defstruct s x y z)
(let ((s (make-s :x 0 :y 1 :z 2)))
  (letf (((s-x s) 42))
    (print s)
    (list s 
          (s-x s)
          (s-y s)
          (s-z s))))
▻ #S(s :x 42 :y 1 :z 2) 
→ (#S(s :x 0 :y 1 :z 2) 
    42
    1
    2) 

letの変数部分が、setfでいう一般化変数になっていて、上記の場合は、letfのボディの中では構造体sのxスロットは42になっていますが、スコープを抜ければ復帰します。

Lisp Machine Lispでは、ロカティブという参照の仕組みがありますが、ロカティブをすげかえる仕組みがマシンのメモリ参照のレベルで実装されていて、この機能によってCommon Lispでいうスペシャル変数のような感じで色々なものの参照を扱えるのですが、letfはこれを活用しています。

Common LispでもLispWorksのような一部の処理系には、letfがユーティリティとして含まれていますが、代入して元に戻すフォームをunwind-protectで囲んだ実装です。

Emacs Lispのcl.elにも何故かletfがありますが、こちらも代入して復帰となっています。
※註: Common Lispにはletfはありません。

なお、代入して元に戻す方式と、スペシャル変数のようなバインディング方式の違いですが、マルチプロセス時等に挙動が変ってきます。

また、letfで扱えるのは、ロカティブのみです。
setfでは読み出しと書き込みで整合性がなかったり非対称なものを定義できますが、こういうものはletfでは扱えません。

参考

• comp.lang.lisp: Does LETF lead to an identity crisis?
• comp.lang.lisp: PLACE-LET

■

HTML generated by 3bmd in LispWorks 7.0.0

《 Lisp メソッドコンビネーション Advent Calendar 2018 8日目 》

今回はCommon Lispの組み込みメソッドコンビネーションのlistを紹介していきます。

listメソッドコンビネーション

listは、メソッドの集合をlistで囲んだように実行するもので、全体の結果がリストとして返ってきます。

(defgeneric foo (x)
  (:method-combination list))
(defmethod foo list ((x number))
  (cons x 'number))
(defmethod foo list ((x rational))
  (cons x 'rational))
(defmethod foo list ((x float))
  (cons x 'float))
(defmethod foo list ((x integer))
  (cons x 'integer))
(foo 1)
→ ((1 integer) (1 rational) (1 number)) 

こんなのどこで使うんだと思ってしまいますが、あれこれ考える中で、返り値がリストということは、:aroundで色々変形してやれば、結構汎用的な使い方もできることに気付きました。

多値で返す

(defmethod foo :around (x)
  (values-list (call-next-method)))
(foo 1)
→ (1 integer) 
   (1 rational) 
   (1 number) 

任意の集約

(defmethod foo :around (x)
  (reduce (lambda (x ans)
            `(,(+ (car x) (car ans))
              ,(cons (cadr x) (cadr ans))))
          (call-next-method)
          :initial-value '(0 nil)
          :from-end T))
(foo 1)
→ (3 (integer rational number)) 

標準の組み込みメソッドコンビネーションで結果を集約する関数系のものに、+、min、max、append、nconcがありますが、これ等は、list+:aroundで集約で実現できてしまいそうです。

自ら今後紹介するメソッドコンビネーションのネタを潰してしまった感もありますが、次回も、標準組み込みのメソッドコンビネーションを紹介したりしようかなと思います。

■

HTML generated by 3bmd in LispWorks 7.0.0

《 Lisp SETF Advent Calendar 2018 8日目 》

実践編今回は、defsetfの長形式篇です。

前回、defsetfの短形式を紹介しましたが、短形式では、引数の順番等の条件がうまく嵌ればとても簡潔に書けます。
しかし、そうはいかない場合もあるのと、仮引数で&optional、&key等々と指定したい場合にdefsetfの長形式を使うことになります。

短形式と同じ例ですが、こんなゲッターとセッターの対があった場合、

(defun kar (list)
  (car list))
(defun set-kar (list val)
  (rplaca list val))
(let ((u (list 0 1 2)))
  (set-kar u 42)
  (list u (kar u)))
→ ((42 1 2) 42) 

(defsetf kar (list) (val)
  `(set-kar ,list ,val))

のように、普通のマクロ定義のような感じで書けます。

(let ((u (list 0 1 2)))
  (setf (kar u) 42)
  (list u (kar u)))
→ ((42 1 2) 42) 

引数宣言の順番も、setfが使われる場合の引数の順番と同じなので迷うこともないでしょう。

短形式では、非常に簡潔に書けました、

(defsetf kar set-kar)

しかし、長形式で明示的に書かれていた方が判り易いですね。

defsetfで定義できるものは基本的にセッターとゲッターが存在し、それが対称に動作しているものになります。

defsetfで扱えないようなイレギュラーなものは、最も汎用的なsetf定義オペレーターである、define-setf-expanderとget-setf-expansionを駆使することになります。

アドベントカレンダーの後半ではイレギュラーなsetf定義でも紹介していこうかなと思います。

■

HTML generated by 3bmd in LispWorks 7.0.0

《 Lisp メソッドコンビネーション Advent Calendar 2018 7日目 》

今回はCommon Lispの組み込みメソッドコンビネーションのprognを紹介していきます。

prognメソッドコンビネーション

prognは、メソッドの集合をprognで囲んだように実行するものです。

メソッドコンビネーションアドベントカレンダー 5日目で、フィルターのパターンをメソッドコンビネーションですっきり書けないか考えていましたが、アイテムの一時置き場を用意して更新していくことが可能であれば、prognで書けそうだと思ったので試してみました。

メニューにはアイテム置き場とフィルター適用済アイテムを持たせて、初期化とソートを:aroundで、他各種フィルターの適用は、prognメソッドコンビネーションで実行してみています。

(defclass menu ()
  ((items :initform '() :initarg :items :accessor items)
   (filtered-items :initform '() :initarg :items :accessor filtered-items)))
(defclass fizz-filtered-menu (menu) ())
(defclass buzz-filtered-menu (menu) ())
(defclass *-filtered-menu (fizz-filtered-menu buzz-filtered-menu) ())
(defgeneric filter (menu)
  (:method-combination progn))
(defmethod filter :around ((menu *-filtered-menu))
  (setf (filtered-items menu) ;filtered-items初期化
        (items menu)) 
  (call-next-method) ;フィルタリング
  (setf (filtered-items menu) ;昇順にソート
        (sort (filtered-items menu) #'<))
  menu)
(defmethod filter progn ((menu fizz-filtered-menu))
  (setf (filtered-items menu)
        (remove-if-not (lambda (x) (zerop (mod x 3)))
                       (filtered-items menu)))
  menu)
(defmethod filter progn ((menu buzz-filtered-menu))
  (setf (filtered-items menu)
        (remove-if-not (lambda (x) (zerop (mod x 5)))
                       (filtered-items menu)))
  menu)

フィルターを掛けるためだけに、mixin的なクラスを定義するのが、微妙な気がしますが、まあ良しとしましょう。
実行してみましょう。

(let ((menu (make-instance '*-filtered-menu 
                           :items (loop :repeat 100 :collect (random 100)))))
  (filtered-items (filter menu)))
→ (0 15 30 45 45 60 60 60 75) 

先日定義してみたmc-expandで展開形を確認してみると、:aroundで囲まれたprognということが判ります。

(mc-expand #'filter 'progn nil (make-instance '*-filtered-menu))
→
(call-method 
 #<standard-method filter (:around) (*-filtered-menu) 41C008E0CB>
 ((make-method
   (progn
     (call-method #<standard-method filter (progn) (fizz-filtered-menu) 402003E7FB> nil)
     (call-method #<standard-method filter (progn) (buzz-filtered-menu) 4020052C8B> nil))))) 

:around修飾子の謎 その二

:aroundは、メソッド単体を囲んで実行するというよりは、コンビネーション全体を取り囲うものなのでは? Flavorsのdefwrapperのような使い方をするのではないか? と昨日書きましたが、改めてSonya Keene氏 のObject-Oriented Programming in Common Lisp(邦訳:Common Lispオブジェクト指向)を確認したところ、「5. Controlling the Generic Dispatch」の章でちゃんとそんな風に説明してました。
前に読んでた筈でしたが、すっかり忘れていたようです……。

Object-Oriented Programming in Common Lisp(邦訳:Common Lispオブジェクト指向)は、Common Lispにオブジェクトシステムを導入するのにあたって貢献した人達(主にSymbolics)が執筆に協力している本なので、割合に説明が細かいです。

また、多くの書籍では、Common Lispと他の言語のオブジェクトシステムとの対比でオブジェクトシステムに変な機能があるとか無いとかで説明されることも多いですが、この本は、Common Lispネイティブな視点で書かれている所もお勧めです(ANSI CL成立前の仕様だったりするのが若干残念)

次回も、標準組み込みのメソッドコンビネーションを紹介したりしようかなと思います。

■

HTML generated by 3bmd in LispWorks 7.0.0

《 Lisp メソッドコンビネーション Advent Calendar 2018 6日目 》

今回はCommon Lispの組み込みメソッドコンビネーションのandを紹介していきます。

andメソッドコンビネーション

standardはパターンに分類するなら呼び出しのフックの実現でしたが、andは、メソッドの集合をandで実行するものです。

二次元座標2dと、それを継承した3d、ついでに何故か2dのスーパークラスである1dがある場合を考えてみましょう。

(defclass 1d ()
  ((x :initarg :x :accessor x)))
(defclass 2d (1d)
  ((y :initarg :y :accessor y)))
(defclass 3d (2d)
  ((z :initarg :z :accessor z)))

これらの等価を判定する==を考えてみると、andを使えば、

(defgeneric == (x y)
  (:method-combination and))
(defmethod == and ((a 1d) (b 1d))
  (= (x a) (x b)))
(defmethod == and ((a 2d) (b 2d))
  (= (y a) (y b)))
(defmethod == and ((a 3d) (b 3d))
  (= (z a) (z b)))

こんな風にすっきり書けます。

(== (make-instance '1d :x 10)
    (make-instance '1d :x 10))
→ t 
(== (make-instance '2d :x 10 :y 20)
    (make-instance '2d :x 10 :y 25))
→ nil 
(== (make-instance '3d :x 100 :y 50 :z 80)
    (make-instance '3d :x 100 :y 50 :z 80))
→ t 
(== (make-instance '3d :x 100 :y 50 :z 80)
    (make-instance '3d :x 100 :y 50 :z 8))
→ nil 

前回定義してみたmc-expandで展開形を確認してみると、こんな感じに、実際にandでメソッドが囲まれています。
※なお展開形は実装依存です。LispWorksでは実際は、sys::blocked-andが使われています。

(mc-expand #'== 
           'and
           nil 
           (make-instance '3d :x 100 :y 50 :z 80)
           (make-instance '3d :x 100 :y 50 :z 8))
→ 
(and (call-method #<standard-method == (and) (3d 3d) 41D052D4A3>
                  nil)
     (call-method #<standard-method == (and) (2d 2d) 41D052D48B>
                  nil)
     (call-method #<standard-method == (and) (1d 1d) 41D04E5EE3>
                  nil))

さらに、andは、:around修飾子も持っているので、実行の全体を何かの処理で包みたい場合に使えます。

(defvar *debug* nil)
(defgeneric == (x y)
  (:method-combination and))
(defmethod == and ((a 1d) (b 1d))
  (when *debug* (print (list (x a) (x b))))
  (= (x a) (x b)))
(defmethod == and ((a 2d) (b 2d))
  (when *debug* (print (list (y a) (y b))))
  (= (y a) (y b)))
(defmethod == and ((a 3d) (b 3d))
  (when *debug* (print (list (z a) (z b))))
  (= (z a) (z b)))
(defmethod == :around (x y)
  (let ((*debug* T))
    (call-next-method)))
(== (make-instance '3d :x 100 :y 50 :z 80)
    (make-instance '3d :x 1 :y 50 :z 80))
▻ (80 80) 
▻ (50 50) 
▻ (100 1) 
→ nil

:around修飾子の謎

メソッドコンビネーションアドベントカレンダーを書き始める前は、and等でも:aroundが使えるのを知りませんでした。
使えることを知ってからも一体何に使うのか謎でしたが、Flavorsにあった、defwrapperのようなパターンを記述するためなのかもしれません。
そう考えると:aroundが最外周に配置されることもなんとなく分かる気がしますが、 上記の例は、ちょっとわざとらしい例ながらもdefwrapperの使い方に近いです。

次回も、標準組み込みのメソッドコンビネーションを紹介したりしようかなと思います。

■

HTML generated by 3bmd in LispWorks 7.0.0

《 Lisp SETF Advent Calendar 2018 6日目 》

実践編今回は、defsetfの短形式篇です。ネタは刻んでいきます。

defsetfや、define-method-combinationでは、良く使いそうなものを短く書ける短形式と、詳細にパラメータを記述できる長形式がありますが、そんなに頻繁に使うわけでもないので、短形式があることで逆に混乱を招いている気がします……。

そんな短形式ですが、既存のゲッターとセッターが違う名前で存在する場合に、ゲッターの名前に統一するような場合に使えます。

具体例としては、こんな対があった場合、

(defun kar (list)
  (car list))
(defun set-kar (list val)
  (rplaca list val))
(let ((u (list 0 1 2)))
  (set-kar u 42)
  (list u (kar u)))
→ ((42 1 2) 42) 

defsetf一発で(setf kar)に纏められます。

(defsetf kar set-kar)

しかし、セッター側の引数の順番に注意。
うまくはまるには、変数→値の順である必要があります。

(let ((u (list 0 1 2)))
  (setf (kar u) 42)
  (list u (kar u)))
→ ((42 1 2) 42) 

処理系の基本関数などの定義では、結構使われているようですが、ユーザーが書くプログラムで、バラバラの名前のゲッター、セッターをsetfのもとに統一する、ということはあまりなさそうです。
長形式だけを用意しておいて、パターンが頻出する場合には、ユーザにマクロを書かせる、という方針でも良かったのでは……。

次回は、defsetfの長形式を解説してみます。

■

HTML generated by 3bmd in LispWorks 7.0.0

《 Lisp メソッドコンビネーション Advent Calendar 2018 5日目 》

組み込みのメソッドコンビネーションのパターンを淡々と紹介していこうかなと思いましたが、eshamsterさんの記事が面白かったので、自分も簡単なものを考えて定義してみることにしました。

• 小ネタ: define-method-combinationで遊ぶ

フィルターでメソッドコンビネーションが使えないか

たまたま今日GUIの一覧メニューのフィルターを作成していて、フィルターってメソッドコンビネーションで上手く書けるのでは?と思ったので試してみます。
とりあえず、リスト対して絞り込みの関数を順にandな感じで適用していく、という感じです。
通常なら、下記のようにでも書くのかなという所です。

(flet ((filter-integerp (list)
         (remove-if-not #'integerp list))
       (filter-evenp (list)
         (remove-if-not #'evenp list))
       (filter-flatten (list)
         (flatten list)))
  (defparameter *fns* (list #'filter-flatten
                            #'filter-integerp
                            #'filter-evenp)))
(reduce (lambda (res f)
          (funcall f res))        
        *fns*
        :initial-value 
        '((1 2 3 4 (1 2 3 4 nil t 8) t 8) (1 2 3 4 (1 2 3 4 nil t 8) t 8)))
→ (2 4 2 4 8 8 2 4 2 4 8 8) 

フィルターをメソッドコンビネーションで書いてみよう

下準備

メソッドコンビネーションを定義するにあたって、コンビネーションがどう展開されるかを確認しつつ書きたいので展開ユーティリティを定義すると良いかなと思います。

(ql:quickload :closer-mop)
(defun mc-expand (gf mc mcopts &rest args)
  (c2mop:compute-effective-method gf
                                  (c2mop:find-method-combination gf mc mcopts)
                                  (compute-applicable-methods gf args)))

これでこんな感じに展開できます。

(mc-expand #'foo 
           'chain
           '()
           '(1 2 3 4 nil t 8))
→
(progn
  (call-method
   #<standard-method foo (chain evenp-filter) (list) 4020328873>
   ((make-method
     (call-method
      #<standard-method foo (chain integerp-filter) (list) 4020231D53>
      nil)))))  

展開を確認しながら書けるのであれば、謎のdefine-method-combinationも使いこなせる気がしてきます。

書いてみる

さて、とりあえずは、フィルター適用の順序不定で良しとして、こんな感じに書いてみました。
標準のメソッドコンビネーションでは、:before、:after等、修飾子の指定は一つですが、実際はこの部分はリストになっていて、equalで等価判定されます。
定義されるメソッドが違う名前であれば、クラス関係に関係なく増やすことが可能です。

(define-method-combination chain ()
  ((methods (chain . *)))
  `(progn 
     ,(reduce (lambda (m ms)
                `(call-method ,m ,(and ms `((make-method ,ms)))))
              methods
              :initial-value nil
              :from-end T)))
(defgeneric foo (x)
  (:method-combination chain))
(defmethod foo chain integerp-filter ((u list))
  (remove-if-not #'integerp (call-next-method)))
(defmethod foo chain evenp-filter ((u list))
  (remove-if-not #'evenp (call-next-method)))
(defmethod no-next-method ((gf (eql #'foo)) method &rest args)
  (apply #'identity args))

(foo '(1 2 3 4 nil t 8))
→ (2 4 8) 

call-next-methodで次を呼ばないといけないのがめんどうな気がしますが、処理結果を次に渡す安直で良い方法が分かりません(メソッドを分解して関数を取り出しても良いのですが……)
順不同で登録/呼びだしをするのでno-next-methodでデフォルト値を返すようにしています。

やっぱり順番を指定したい

やっぱり適用順によってはエラーになるようなフィルター構成もあるので、順番は指定しても良いかなと思ったので、優先順位を指定してみることにしました。

(defun ordered-chain-qualifier-p (method-qualifiers)
  (typep method-qualifiers
         '(cons (eql ordered-chain) (cons integer (cons T null)))))
(define-method-combination ordered-chain ()
  ((methods ordered-chain-qualifier-p))
  (let ((methods (remove-duplicates methods 
                                    :key (lambda (method)
                                           (third (method-qualifiers method)))
                                    :from-end T)))
    `(progn
       ,(reduce (lambda (m ms)
                    `(call-method ,m ,(and ms `((make-method ,ms)))))
                  (stable-sort methods #'>
                               :key (lambda (method)
                                      (second (method-qualifiers method))))
                  :initial-value nil
                  :from-end T))))

(defgeneric bar (x)
  (:method-combination ordered-chain)))
(defmethod bar ordered-chain 0 identity ((u list))
  u)
(defmethod bar ordered-chain 100 integerp-filter ((u list))
  (remove-if-not #'integerp (call-next-method)))
(defmethod bar ordered-chain 200 evenp-filter ((u list))
  (remove-if-not #'evenp (call-next-method)))
(defmethod bar ordered-chain 1 flatten-filter ((u list))
  (flatten (call-next-method)))

展開はこんな感じです。

(mc-expand #'bar
           'ordered-chain
           '()
           '(1 2 3 4 nil t 8)) 
→
(progn
  (call-method
   #<standard-method bar (ordered-chain 200 evenp-filter) (list) 4020447F83>
   ((make-method
     (call-method
      #<standard-method bar (ordered-chain
                             100
                             integerp-filter) (list) 402031D65B>
      ((make-method
        (call-method
         #<standard-method bar (ordered-chain
                                1
                                flatten-filter) (list) 4020458C5B>
         ((make-method
           (call-method
            #<standard-method bar (ordered-chain 0 identity) (list) 4020467533>
            nil)))))))))))

メソッドコンビネーション修飾子の二番目に整数で優先度を付けてみました。
パターンマッチでも行けると思いますが、ordered-chain-qualifier-pを定義して選別しています。

メソッドコンビネーション修飾子はequalで判定されると上述しましたが、優先度を変更して再定義するとメソッドがどんどん増えてしまうので、重複も削除しています。
また、デフォルトメソッドを最優先として定義すればno-next-methodの定義も不要になります。

さて実行してみると、

(bar '((1 2 3 4 (1 2 3 4 nil t 8) t 8) (1 2 3 4 (1 2 3 4 nil t 8) t 8)))
→ (2 4 2 4 8 8 2 4 2 4 8 8)  

とりあえずは、3つのフィルターが順に適用されているようです。

問題点

しかし、優先度を付けてみると、今度は、call-next-methodと優先番号の組み合わせが直感的でない気がします。

具体的には、優先番号が低い順から呼ばれるのに、引数の適用は優先度の高い方からされる、ということで、call-next-methodで呼ばない場合、連鎖は優先度が低い方から途切れてしまいます。

call-methodの入れ子にしないで、平坦に優先順に並べ、適用結果を次々に受け渡すことができれば、整合性は取れる筈ですが……。

メソッドコンビネーションアドベントカレンダー終了まで良い解決策が思い付けば記事のネタにしたいと思います。

■

HTML generated by 3bmd in LispWorks 7.0.0

《 Lisp SETF Advent Calendar 2018 5日目 》

今回は、TAO/ELISの!、!!についてです。

実の所、TAO/ELISの!、!!は、setfとは挙動は似ているものの実現方法が異なったもので、Common Lispのようにマクロに展開されるものではなく、(!という特別な括弧が作る代入フォームです。

詳しくは、1986年のbit誌のマルチパラダイム言語 TAO 連載で解説されていますので興味のある方は参照してみると良いかと思います。

• マルチパラダイム言語 TAO - 第4回 代入，関数，catch

この!記法は、setfが!になった感じですが、上述のように特殊な括弧です。

(!(car x) 42) ≡ (setf (car x) 42) 

このフォームは読み書きの場所を返すようになっている(マシンの支援あり)ので、

(!(if pred (car x) x) 42)

のようなものもsetfのような事前のマクロ定義なしに書くことが可能です。

!!の方は自己代入式といって、これも面白くて便利なのですが、フォームの結果を代入する場所を!で指定して書き込むというものです。

これを使うと(setq x (+ x 42))のような良くある代入が、

(!!+ !x 42)

のように書けます。

(!!cdr !x) ≡ (pop x)
(!!nconc !(car x) y) ≡ (setf (car x) (nconc (car x) y))
(!!delete 'a !x) ≡ (setq x (delete 'a x))

等々入り組んだ表現になる程シンプルに書けたりします。

ちなみに、このアイデアは、1979のTAO/60にはあったようで、PDP-11上に実装された初期のTAO/60について書かれた、TAO LISP についての5. 複値形式 (Double valued form)の段落で説明があります。

これによると、

複値形式の概念に思い至ったのは, ALGOL68 や Pascal のプログラムを Lisp に移し替えようとしたとき, どうしてもスムーズにいかなかった悔しい経験があったからである.

とのことなので、やはりAlgol系言語の左辺値の書法が念頭にあったようです。

記法は、TAO/ELISの!ではなく、:を使っています。
TAO/ELISでは、Common Lispに接近したため、キーワードシンボルと記法がぶつかってしまうために!になったようです。 (TAO/ELIS復活祭(2010)で竹内先生が軽く説明していました)

インタプリタの軽快な動作に力を入れていたTAO/ELISでしたが、setfのようにコンパイル前提のマクロでの実現ではない方向で工夫を凝らした代入機構の紹介でした。

ちなみにCommon Lispでも、リーダーマクロで(を再定義すれば、そこそこ似た感じに記述することは可能です。
興味のある方は挑戦されてみてはいかがでしょうか。

• #:g1: ()の再定義

■

HTML generated by 3bmd in LispWorks 7.0.0

《 Lisp SETF Advent Calendar 2018 4日目 》

どうもsetf機構についてどんどんマイナーな方向に進んでしまいそうなので、実践的なものも挟んでいきたいと思います。

Common Lispでのsetfの定義方法と定義構文ですが、やたらと数が多いです。
しかも、省略形式と、詳細形式に分かれていたりして、一体何を使ったら良いのかと思うこともままあります。

ざっと一覧にすると、

• 自動アクセサ生成系(defclass、defstruct)
• Macro Forms as Places/Symbol Macros as Places で自動で定義される系
• (defun/defmethod (setf ...))
• defsetf
• define-setf-expander
• define-modify-macro

加えて、定義時に使う補助関数として、get-setf-expansionがあります。

今回は、上記から、(defun/defmethod (setf ...)) を解説したいと思います。

(defun/defmethod (setf ...))

(defun/defmethod (setf ...)) の形式は、CLtL1には存在しておらず、ANSI CLになってから追加されたものです。

追加の目的ですが、メソッドのアクセサをdefmethodで定義させたいためです。

(defclass foo ()
  (a b c))
(defmethod (setf foo-a) (val (obj foo))
  (setf (slot-value obj 'a) val))

こんな感じのことがしたいという訳ですが、ANSI CLでは、この為に関数名を拡張して、(setf foo)というような名前も使えるようにしました。
なお、この形式の関数名はsymbol-functionでは扱えないのでfdefinitionを利用します。(専らfdefinitionを使っておけば良いのですが)

(funcall #'(setf foo-a) 42 (make-instance 'foo))
→ 42
(setf (foo-a (make-instance 'foo)) 42)
→ 42
(fdefinition '(setf foo-a))
→ #<standard-generic-function (setf foo-a) 40E01CBF4C> 

単なる関数/メソッドなので、setfとは関係ないこともできてしまいますが、当然ながら、これはスタイル上良くないこと、とされています。

(defun (setf foo) (val var)
  (list var val))
(setf (foo 'var) 'val)
→ (var val) 

なお、処理系が標準関数のsetfの実装をマクロにするか関数にするかは任意なので、関数で書けるからといって、

(funcall #'(setf car)...)

のような書き方をしても可搬性は期待できません。
個人的には良くやってしまうミスなのですが、統一して欲しい……。

アドベントカレンダーもまだまだ残りの日数がありますので、今後もsetfの定義のバリエーションについて書いていきます。

■

HTML generated by 3bmd in LispWorks 7.0.0

《 Lisp SETF Advent Calendar 2018 3日目 》

探す旅とか書いてますが、LispでSETFのようなものが初めて導入されたのは、結論からいうとLISP 2(1965)だと思います。
しかし、Lispの歴史の文献については、The Evolution of Lispが決定版で良く知られているものなのですが、LISP 2についての記述は何故か殆どありません。
EoLに拠り所にするならば、1973年のL Peter Deutsch氏のByte Lisp(setfq)が最初となるでしょう。

さて、LISP 2ですが、LISP 2は、後世のLispの試行錯誤を先取りしている所が多々ありますが、それはAlgolとの接近による所が多いです。
その後のLispがAlgol化していったから、とも言えますが、具体的には、

• Algol構文の採用(Algolとコード共用できるレベルを目指す)
• 型宣言の導入
• 静的スコープの採用
• 拡張された左辺値

あたりがあります。

1975年にSchemeがAlgolの影響でLispに静的スコープを取り入れたのが、Lisp史の一つの大きな転換点とされますが、Schemeに10年先行して、LISPをまんまAlgol化しようとしたLISP 2が完全に忘却されているのは不思議ではあります。

なお、LISP 2の発掘については、Paul McJones先生が熱心に取り組まれているようです。

• Dusty Decks: Preserving historic software

LISP 2は構想のみで実装はなかった、とされていましたが、先日実装も発見されたようです。後世で発掘されるというのも面白い。

• GTL is a LISP 2 implementation

さて、この記事ではsetfがメインテーマなので、上記3項目の中では、拡張された左辺値について詳しくみて行くのですが、setf関連については、 LISP II Internal Language(1965) 3.1 ASSIGNMENT-EXPRESSION, LOCATIVES に纏められています。

これによると、(SET locative expression)という形式になっていて、locativeというのがCommon Lispのsetfでいうplaceという感じになっています。
locativeには、ビットやリスト、配列があり、下記のように書けたようです。

(set (car x) b)
(set (cdr x) b)
(set (bit 2 2 a) (bit 2 2 15))
(block ((a real array) (m integer))
  (set (a m) 42))
(set (prop (quote x)) (quote (p 42)))

S式は中間言語なので、表層言語でも書いてみると、

car x ← b;
cdr x ← b;
bit (2, 2, a) ← bit (2, 2, 15);
begin real array a; integer m;
  a[m] ← 42;
end;
prop 'x ← '(p 42);

となります。
これらは、Common Lispで書くと、それぞれ、

(setf (car x) b)
(setf (cdr x) b)
(setf (ldb (byte 2 2) a) (ldb (byte 2 2) 15))
(setf (aref a m) 42)
(setf (symbol-plist 'x) '(p 42))

となります。
LISP 2では型宣言するので、配列のsetでは、(配列名 インデックス)という形式でOKのようです。

読み出しと書き込みの記法の二重性について

左辺値について、1960年代初頭のFORTRAN、Algol、CPLあたりの扱いを眺めてみましたが、左辺に配列の記法が来るものは、添字付き変数という概念のようで、配列のアクセサが介在するものではないようです。
LISP 2の記法でもその辺りを踏襲しているように見えますが、locativeという概念で左辺にアクセサの記法が出てくるのは、当時の他の言語と比べてもそれなりに先進的だったのかもしれません。

参考

• LISP 2 - Software Preservation Project
• #:g1: LISP 2の先進性について

■

HTML generated by 3bmd in LispWorks 7.0.0

《 Lisp メソッドコンビネーション Advent Calendar 2018 2日目 》

ほぼ無計画なので、内容が続き物だったりそうではなかったりします。
とりあえず、定番というか、Common Lispに標準で用意されているメソッドコンビネーションの紹介でもしていこうかなと思います。

standardメソッドコンビネーション

Common Lispのdefmethodで定義したものは、標準でこのタイプになります。
主な登場人物は、:before、:after、:around、call-next-methodです。
:before、:after、:aroundは、指定したコンビネーションでのメソッドの追加で利用し、call-next-methodは、優先順位リストに従って次のメソッドを起動します。
他のOOP言語では、superに相当しますが、Common Lispでは、必ずしも継承順位で上位ものを呼び出すわけではないので、call-nextなのでしょう。

とりあえず、実際に:before、:after、:around、call-next-method全部盛りのメソッドを定義して動作を確認してみましょう。

(progn
  (defclass c1 () ())
  (defclass c2 (c1) ())
  (defclass c3 (c2) ()))
(progn
  (defmethod foo ((o c1))
    (format T "~16T~A~%" '(foo c1)))
  (defmethod foo ((o c2))
    (format T "~16T~A~%" '(foo c2))
    (call-next-method))
  (defmethod foo ((o c3))
    (format T "~16T~A~%" '(foo c3))
    (call-next-method))
  ;;
  (defmethod foo :before ((o c1))
    (format T "~8T~A~%" '(foo c1 :before)))
  (defmethod foo :before ((o c2))
    (format T "~8T~A~%" '(foo c2 :before)))
  (defmethod foo :before ((o c3))
    (format T "~8T~A~%" '(foo c3 :before)))
  ;;
  (defmethod foo :after ((o c1))
    (format T "~24T~A~%" '(foo c1 :after)))
  (defmethod foo :after ((o c2))
    (format T "~24T~A~%" '(foo c2 :after)))
  (defmethod foo :after ((o c3))
    (format T "~24T~A~%" '(foo c3 :after)))
  ;;
  (defmethod foo :around ((o c1))
    (format T "~A~%" '(foo c1 :around))
    (call-next-method))
  (defmethod foo :around ((o c2))
    (format T "~A~%" '(foo c2 :around))
    (call-next-method))
  (defmethod foo :around ((o c3))
    (format T "~A~%" '(foo c3 :around))
    (call-next-method)))

とりあえず、実行してみるとこんな感じになります。

(foo (make-instance 'c3))
▻ (foo c3 around)
▻ (foo c2 around)
▻ (foo c1 around)
▻         (foo c3 before)
▻         (foo c2 before)
▻         (foo c1 before)
▻                 (foo c3)
▻                 (foo c2)
▻                 (foo c1)
▻                         (foo c1 after)
▻                         (foo c2 after)
▻                         (foo c3 after)
→ nil

大元のメソッドは、プライマリメソッドと呼びますが、call-next-methodで次のメソッドを呼ぶことが可能です。
上記では、(foo c3)、(foo c2)で明示的に呼び出していますが、もちろん無ければ呼ばれません。

:beforeは、プライマリメソッド起動の前に起動されますが、クラス優先順位リストの順に該当するものは全て呼び出されます。
:afterは、:beforeと対称の動作です。 なお、:before、:afterの中では、call-next-methodは使用できません。

:aroundが割合に複雑ですが、:aroundがあれば、それが最初に起動されます。
その:aroundの中で、call-next-methodが起動されれば、クラス優先順位リスト順に、次の:aroundを起動、:aroundがなければプライマリメソッドを起動します。
call-next-methodを呼べば、その返り値が利用できるので、このデフォルト値を加工するような使い方が殆どです。

:before、:afterではcall-next-methodが使えないので、スロットの値を設定する等、副作用目的での利用となります。 GoFのObserverパターンのようなものは、呼び出しイベント時に起動したいフックのようなものが多いので、:before、:afterで賄うことが可能かなと思います。

メソッドの中身を覗いてみる

compute-effective-methodで確認すると、call-methodの連鎖が直接見えて判り易いので確認してみると下記のようになります。

call-methodは第一引数に起動するメソッド、第二引数にそれ以降で起動するメソッドのリストを取りますが、入れ子にしていけば、所謂、継続渡しに似た記述になります。
起動リストが空か、メソッドのボディにcall-next-methodの記述がなければ、以降のメソッドは起動されず、そこで処理はストップします。

(c2mop:compute-effective-method #'foo
                                (c2mop:find-method-combination #'foo 'standard nil)
                                (compute-applicable-methods #'foo (list (make-instance 'c3))))
→ (call-method
    #<standard-method foo (:around) (c3) 4190211F13>
    (#<standard-method foo (:around) (c2) 4190211F2B>
     #<standard-method foo (:around) (c1) 4190211C93>
     (make-method
      (progn
        (call-method #<standard-method foo (:before) (c3) 419021266B> '())
        (call-method #<standard-method foo (:before) (c2) 4190212683> '())
        (call-method #<standard-method foo (:before) (c1) 419021258B> '())
        (multiple-value-prog1
            (call-method
             #<standard-method foo nil (c3) 4190212753>
             (#<standard-method foo nil (c2) 419021276B>
              #<standard-method foo nil (c1) 419021269B>))
          (call-method #<standard-method foo (:after) (c1) 4190211F43> '())
          (call-method #<standard-method foo (:after) (c2) 4190212573> '())
          (call-method #<standard-method foo (:after) (c3) 419021255B> '())))))) 

元祖Flavorsのデフォルトコンビネーション

元祖Flavorsでは、当初デフォルトのメソッドコンビネーションとして、:daemonコンビネーションが用意されていましたが、登場したのは大体1981年頃のようです。
これは、:before、プライマリ、:afterの組み合わせで、Common Lispのstandardからcall-next-methodと:aroundを削ったような挙動ですが、1984年あたりになると、:aroundも追加された様子。
call-next-methodのようなものはなく、#'(:method flavor method-name)のような形式で直接呼び出したり、:around専用の継続メソッドを呼び出す構文を使ったようです。

次回は、andコンビネーションあたりを紹介しようと思います。

■

HTML generated by 3bmd in LispWorks 7.0.0

《 Lisp メソッドコンビネーション Advent Calendar 2018 1日目 》

Lisp メソッドコンビネーション Advent Calendar 2018始まりました。
開始初日にして既につらい。
setfネタともう一品と思ってテーマにメソッドコンビネーションを選んでみましたが、setf以上にニッチでした。

メソッドコンビネーションってなに?

さて、メソッドコンビネーションについての説明ですが、読んでそのまま、メソッドのコンビネーションのことです。
どういう面の組み合わせかというと、ざっくりメソッドの起動とその順番についてと考えて良いでしょう。

(defclass k0 () ())
(defclass k1 (k0) ())
(defclass k2 (k1) ())
(defmethod m ((obj k2)) 'k2)
(defmethod m ((obj k1)) 'k1)
(defmethod m ((obj k0)) 'k0)

こんな感じの定義があったとすると、

Common Lispでは、compute-applicable-methodsで起動するメソッドを確認することが可能です。

(compute-applicable-methods #'m (list (make-instance 'k2)))
(#<standard-method m nil (k2) 40E011D08B>
 #<standard-method m nil (k1) 40E004A153>
 #<standard-method m nil (k0) 40E006B64B>) 

上記の定義では、k0 < k1 < k2 という継承順のクラスに対し、それぞれmを定義しています。

k2についてmを起動してみると、

(m (make-instance 'k2))
→ k2 

となりますが、Common Lispの標準では、compute-applicable-methodsで求めたリストのメソッドが呼ばれていきます。
この例では他2つのメソッドは、呼ばれませんが、明示的な操作と相対的な名前で呼ぶことも可能です。

3つのメソッドのコンビネーションについて説明しましたが、Common Lispでは上記はstandardという名前が付いています。

なんとなく想像が付くかと思いますが、Common Lispでは任意のメソッドの束を任意の構成で呼んだり呼ばなかったりが可能です。

Advice機構とメソッドコンビネーション

メソッドコンビネーションというとbefore、after等の修飾子を付けてフックを掛ける使い方の印象が強いと思います。

具体的な例でいうと、上記のコードにbefore、afterを追加定義してmを起動すると、

(defmethod m :before ((obj k2)) (print "before k2"))
(defmethod m :after ((obj k2)) (print "after k2"))

(m (make-instance 'k2))
▻ "before k2"
→ k2
▻ "after k2" 

となります。

さて、compute-applicable-methodsで確認してみると、メソッドが増えているのが分かります。

(compute-applicable-methods #'m (list (make-instance 'k2)))
→ (#<standard-method m (:after) (k2) 40E0868EF3>
    #<standard-method m (:before) (k2) 40E086956B>
    #<standard-method m nil (k2) 40E011D08B>
    #<standard-method m nil (k1) 40E004A153>
    #<standard-method m nil (k0) 40E006B64B>)

起動のされ方については、Common LispのMOPで定義されているcompute-effective-methodで起動コードを確認することが可能です。

(c2mop:compute-effective-method #'m
                                (c2mop:find-method-combination #'m 'standard nil)
                                (compute-applicable-methods #'m (list (make-instance 'k2))))
→ (progn
    (call-method #<standard-method m (:before) (k2) 40204EB4DB> nil)
    (multiple-value-prog1
        (call-method #<standard-method m nil (k2) 40E011D08B>
                     (#<standard-method m nil (k1) 40E004A153>
                      #<standard-method m nil (k0) 40E006B64B>))
      (call-method #<standard-method m (:after) (k2) 40204E84E3> nil))) 

上記はLispWorksの例ですが、起動するコードを直接確認できるので、何か良く分からなくなってきたら実際にどんなものが生成されるか確認してみるのも良いでしょう。

このように生成されたコードを眺めてみると、メソッドコンビネーションのコンビネーションの一つとして、フック/Advice機構が実現されていることが分かります。

本体メソッドの前後に副メソッドを配置するコンビネーションは、GoFデザインパターンでもObserverパターンとして良く知られていますが、古えのLisp畑(Flavors等)では、フレーム理論の影響からか、配置されるメソッドをdaemonと呼び、この標準パターンもdaemonと呼んでいます(ややこしい)
伝統を受け継いでいるCommon Lispでもこのコンビネーションが標準となっていて、standardという名前が付いている、という訳です。

フレームワークの代表的な使われ方と、フレームワークそのものが混同されるのは常ですが、メソッドコンビネーションもフックとしての使われ方だけではないことに留意する必要はあるでしょう。

今後は、メソッドコンビネーションの歴史、Common Lispや、Lisp Machine Lisp等でのメソッドコンビネーションの定義方法の解説etcを書いていく予定です(一体書けるのか)

■

HTML generated by 3bmd in LispWorks 7.0.0

《 Lisp SETF Advent Calendar 2018 1日目 》

Lisp SETF Advent Calendar始まりました。
数年に一度Lisp系でニッチなAdvent Calendarを催したりしていますが、最近あまりニッチなことはしていませんでした。
その反動なのかLisp SETF Advent Calendarですが、ニッチすぎたかもしれません。
ちなみに、過去のニッチなAdvent Calendarには下記のようなものがあります。

• Lisp Reader Macro Advent Calendar 2012
• Metaobject Protocol(MOP) Advent Calendar 2013
• レトロLisp Advent Calendar 2016

SETFってなに?

さて、setfについての簡単な説明です。
プログラミング言語の代入構文にも様々ありますが、左辺に変数名だけでなく、配列の場所であったり、リストであったりが記述できるものがあります。

x := x + 1
a[x] := y + 1
a, b, c := list(0, 1, 2)
...

右側にはどんな値でも置けるのですが、左側に置いて意味を成すものを考えると、値を代入できる場所の指定/参照、となることが多いようです。
Lispのsetfとは、値の読み書きの場所について一般化し、値の読み出しのフォームと同じ見た目のフォームで書き込みも表現しようというものです。

setfは、

(setf 場所 値)

という形式ですが、「場所」には、変数名や値をアクセスする記述を使用できます。
一番身近なリスト操作のcarで説明すると、

リストのcar読み出しフォーム

(setq x (list 0 1 2 3)
(car x)
→ 0

リストのcar書き込み

(setq x (list 0 1 2 3))
→ (0 1 2 3)
(setf (car x) 42)
→ 42
x
→ (42 1 2 3)

となります、Algol風に書けば、

car(x) := list(0, 1, 2, 3)

となるでしょうか。
carで読み出して来た場所に、値を代入するという意図が表現できているかと思います。
リストの場合は、配列アクセスの表現にかなり近いので自然な拡張に思えます。

SETFのFが気になる問題

長い歴史を持つLispでは、名前の由来を最早誰もはっきり説明できない関数が結構あります。
実は、setfもそんな名前の一つです。 代入だからsetは良しとして、fはなんだろう、というのはFAQでもありますが、Common Lispのsetfの由来は、L Peter Deutsch氏の論文A LISP machine with very compact programsまで遡ることができます。

代入関数であるsetが変数名だけでなく関数フォームを取れるようにしよう、というのがアイデアの骨子ですが、

setを拡張して、

(set '(fn arg1 ... argn) 42)

と書けるようにし、次に同様にsetq版も考えて、
※setqは、set+quoteが由来

(setq (fn arg1 ... argn) 42)

と書けるように拡張。しかし、これでは関数フォーム全体をクォートしてしまい引数が評価されないのが実用上不便ということで、関数名だけクォートするものを考案。

(setfq (fn arg1 ... argn) 42)

この当時のLISP(INTERLISP系)にバッククォートがあれば、

これがCommon Lispでいうsetfと同じもので、(SETFQ (fn argl ... argn) newvalue) which quotes the function name and evaluates everything else.と表現されています。
ということは、setを使えば、

(set (list 'fn arg1 ... argn) 42)

と書けるということでしょうか。
それはさておき、つまりFはfunctionを意図していたようですが、一番流布しているのはFはField説、次にForm説あたりかなと思います。

ちなみに、やたらとクォートの扱いについて細かいと思う人もいるかと思いますが、L Peter Deutsch氏のバックグラウンドであるINTERLISPでは引数が評価されるものと、されないもの二種(q付きとqなし)が大抵用意されているので、引数評価について敏感だったのでしょう。
Common Lispでは、setとsetqの関係ですが、qがquoteを意味しているものとしてはsetqが唯一の生き残りです。
なお、setfqのqはどっかに飛んでいってしまったようです。

• #:g1: SETFのFって結局なんなの

今後は、setfのアイデアが最初に登場したと思われるLISP 2の解説、Lisp Machine Lispでの発展あたりについて書いたり、数あるsetfの定義構文を全部解説してみようかなと思います。

■

HTML generated by 3bmd in LispWorks 7.0.0

2018-11-23の祝日に開催されたEgison Workshop 2018に参加してきました。

Egisonの現状と今後の展望 - 江木聡志 (楽天技術研究所)

まずは、Egison開発の歴史についての発表でした。
開発動機に始まり現在注力している数式処理機能、テンソルの添字記法等まで解説がありました。
EgisonはあくまでProof of conceptとのことで、今後Haskellへの組み込み機能としても展開していったりするようです。

先日開催されたML Day #2でのEgisonの発表資料

• パターンマッチ指向プログラミング言語 Egison と その上に実装された数式処理システム

Egison入門+論文紹介 - 西脇友一 (東京大学)

Egisonの入門解説と、来たる12月に開催されるAPLAS 2018で発表予定の Non-linear Pattern Matching with Backtracking for Non-free Data Types の解説でした。
まずは、Egisonに慣れてもらうということで、Egisonのパターンマッチの解説が大目で、論文の内容はざっと、という感じでした。

Egisonパターンマッチのアルゴリズムとマッチャー定義 - 江木聡志 (楽天技術研究所)

Egisonのマッチャーのアルゴリズム解説に始まり、無限の大きさの探索空間に対して適切にマッチさせるための工夫のについて解説されました。

こちらも先日開催されたML Day #2でのEgisonの発表資料に詳しいです。

• パターンマッチ指向プログラミング言語 Egison と その上に実装された数式処理システム

Egisonプログラミングコンテスト

出題をEgisonで解くという内容でした。

• Egison Programming Contest 2018の問題集

member?、reverse、というリスト処理では初等的な内容でしたが、Egison流の書法に慣れていない参加者が大半だったため意外と苦戦(私も)しているようでした。

問題集を眺めると、「ポーカーの役判定」までありましたが、そこまでは辿り着かず。
ちゃんと予習していけば良かった……。

Egisonの型システムとその型推論器の実装 - 河田旺 (京都大学)

Egisonに型推論器etcを実装したTyped Egisonを開発している中でのあれこれについてが解説されました。

• Typed Egison
• Egison Workshop 2018: Egisonの型付け規則一覧
• Egisonの型システムとその型推論器の実装(発表資料)

新機能で知るEgison - 郡茉友子 (東京大学)

テンソルの添字記法に代表される数式処理用の記法を実装するにあたってのあれこれ、EgisonをJupyterで使うためのegison_kernelの紹介、S式がつらいということで、EgisonのHaskell風の構文拡張の紹介でした。

• egison_kernel

Haskell風のシンタックスについては、egison 4.0に向けての計画の一つなのかもしれませんが、発表内容のものと同一のものなのか、それとは独立の実装なのかメモするのを忘れてしまいました。

• Egison: Issue New Syntax

現在、対話的に使った際のエラー処理は手厚くないとのことで、新構文で記述→ファイルを読み込み、というフローで使ってみて欲しい、とのことでした。

Lispをやっていて、S式アレルギーの人が一定数いる(大多数)のは十二分に把握しているので、EgisonがS式を採用した理由とメリットについて質問してみましたが、江木さんより、別段にS式に対するこだわりはないという回答でした。
それをうけて私が「S式に対する熱い思いがあるのかと思いました」と発言したところで妙に会場のウケをとってしまい、もしかしたら、Haskell風の構文について質問/紹介するタイミングをつぶしてしまったかもしれません(すいません)

Egisonで微分幾何 - 江木聡志 (楽天技術研究所)

こちらも先日開催されたML Day #2でのEgisonの発表資料に詳しいという感じでした。

• パターンマッチ指向プログラミング言語 Egison と その上に実装された数式処理システム

懇親会

希望者で懇親会が開催されましたが、参加者間で濃い議論が行なわれていたようです。
私はLisp/S式推しで喋っていましたが、ちょっとウザかったかもしれません(正直すいません)

まとめ

S式構文、パターンマッチ、数式処理、と揃ったので、勝手にREDUCE、MACSYMA/Maximaの系譜に続くEgisonキタコレと思ってしまったのですが、主軸はそこではなく、パターンマッチの可能性と記法を追求する途上でたまたまS式、ということのようです。
……ついでにおまけで良いからS式の可能性も追求して欲しい!

全般的にEgison Workshop 2018は、色々な要素のバランスが良く楽しいワークショップでした。

また、参加者にはもれなくEgison Tシャツが配布されました。
Egison Tシャツ欲しかったのでうれしい!

次回のワークショップも期待しています。

■

HTML generated by 3bmd in LispWorks 7.0.0

前回、多値についてCommon Lisp以前のLisp Machine Lispから眺めてみました。

色々な資料を眺めている中で、GLS(Guy L. Steel Jr.氏)の多値についてのスタンスが、使い勝手の方に舵を切ったCommon Lispと美しさを取ったSchemeを象徴するように見えたので、GLSと多値について書いてみたいと思います。

タイトルに継続と多値と入っていますが、GLSが多値と継続について語っているのを見付けただけです。継続に興味ある方々には、釣りタイトルみたいになってしまってすいません :)

初期のLisp Machine Lispの多値とGLS

初期のLisp Machine Lispの多値の高レベルAPIにはmultiple-value-listとmultiple-value、があり、returnは多値を返せました。
multiple-valueはCommon Lispでは、命名が良くないということで、multiple-value-setqと改名されましたが、当初は代入フォームがメインだったようです。

multiple-value-bindのような束縛構文はというと、調べた限りでは、GLSが提案したものが最初で1977-03-07のメールに詳細が書いてあります。
名前は、Common Lispと同じmultiple-value-bindです。

GLSが提案した形式は、

(MULTIPLE-VALUE-BIND <function call>
                     <bindings>
                     <body>)

というもので、現在のものとは、変数と多値を返すフォームの位置が反対になっています。

この提案では、束縛部ではオプショナル引数や残余引数の指定ができることが示唆されています。

(MULTIPLE-VALUE-BIND (FOO A B C)
        (VAL1 VAL2 &OPTIONAL VAL3) ...)
or
(MULTIPLE-VALUE-BIND (FOO A B C D E)
        (VAL1 VAL2 &REST VAL3) ...)

さらに、入出力の多値の数をしっかり合せたい場合、

(MULTIPLE-VALUE-BIND (BAR B C)
        (G0001 &REST G0002)
        (FOO A G0001 D E))

と書けることを挙げて、

This idea lends a nice symmetry to the passing of arguments and
the returning of values.  Finally, one might note that this also
allows the possibility of specifying that NO values are expected back.
PROG could evaluate statements in this mode, while evaluation
of subforms should require at least one return value.
This lends itself to a better theory of statements vs. forms.

と締めています。
多値の入出力の対称性を実現でき、さらに発展して値を返すフォームを式、返さないフォームを文とできる、ということみたいです。

この提案に反応があったのか無かったのか記録には残っていないのですが、結局この仕様はそのままは取り入れられず、Common Lispでもお馴染の形式のものが1979年に導入されています。

初期のCommon Lisp仕様策定と多値とGLS

時は流れて1981年。初期Common Lispの仕様の議論ですが、当時のmultiple-value-bindの仕様(=現在のCommon Lispの仕様)を少し変更して変数部をlambdaと同じにしたらどうか(つまり上述の1977の仕様と同じ)と提案しています。

• Re: Proposed mildly incompatible change to MULTIPLE-VALUE(-BIND)

I propose that the list of variables be completely identical in syntax
to a LAMBDA-list.  This includes the use of &OPTIONAL and &REST.  One
can get precisely the current functionality by inserting &OPTIONAL at
the front of the variables list.  In addition, one would be able to get
non-NIL default values; a list of some of the values, using &REST;
and better error checking, because one can *require* that certain values
be delivered.

現在のmultiple-value-bindと何が違うかというと、GLSのものは多値の数をきっちり合せることが前提のインターフェイスになっていて、合わなければエラーになるというところです。

(defmacro gls-multiple-value-bind (args mv-form &body body)
  `(multiple-value-call (lambda ,args ,@body) ,mv-form))
(gls-multiple-value-bind (a b)
                         (values 0 1 2)
  (list a b))
;error> got 3 args, wanted 2.

(gls-multiple-value-bind (a b &optional c)
                         (values 0 1)
  (list a b c))
→ (0 1 nil) 

この提案に対してのDavid Moon氏からの回答が「実用指向のCommon Lisp™」という感じなのですが、実際の所、多値を返す殆どの関数は、それを使う側がいらない多値は捨てるものという前提で運用されていて、理論的に考えられるような対称性はみられない、として切り捨てています。

• Re: Proposed mildly incompatible change to MULTIPLE-VALUE(-BIND)

This sounds superficially plausible and has been proposed many times before.
The reason it has never been accepted is that in practice most functions 
which return multiple values rely on the feature that extra values the
caller does not want are thrown away.  Calling and returning aren't really
as symmetric in practice as they are in theory.  It probably would be useful
to have a way of requiring at least a certain number of values to be
returned.  Of course, then all the functions which rely on extra values
being supplied NIL would have to be fixed.  This is pretty common practice
when you have code like (and <condition> (values <val1> <val2>)).

Schemeと多値と継続とGLS

また時は流れて、1988年、Schemeメーリングリストでのことですが、GLSがSchemeの会合で継続を踏まえた多値の扱いについて話をするつもり、という旨のメールを書いています。

• Continuations and multiple values,

このメールでは、数あるLisp方言で、それぞれ多値の返却/受取で数が合わない場合の対処も違うけれど、継続と多値の問題と見做せるとしています。
また、継続は返却/受取の数は一致していることを基本とし、その上で継続に多値の数が一致しているかを問合せるaccepts?というものを提案しています。

accepts?と使うとCommon Lispの多値のような挙動は下記のように書けるようです。

;;; cwcc = call-with-current-continuation
(define (values . r)
  (define (ignore-excess-values k z)
    (if (accepts? k (length z))
    (apply k z)
    (if (null z)
        (supply-default-falses k r)
        (ignore-excess-values k (cdr z)))))
  (define (supply-default-falses k z)
    (if (accepts? k (length z))
    (apply k z)
    (supply-default-falses k (cons '#f z))))
  (cwcc (lambda (k) (ignore-excess-values k r))))

さらに、beginやset!は0個の値を返すのはどうかという話もでてきますが、これも上述の1977年のアイデアですね。

まとめ

多値の返却/受取の個数合せについて、使い勝手の良い挙動でまとめたCommon Lispと、あるべき挙動を選択したScheme、そして時代と方言を越えて一貫した主張をしていたGLSを眺めてみました。

Schemeで多値と継続についての議論がどの辺りからあるのかは調べていないのですが、発表する内容として考えられていたことからしても1988年のGLSの提案が割と初期のものなのではないでしょうか。
ちなみにR7RSでもaccepts?のようなものは仕様には取り入れられていないようです。

Common Lispでは、失敗/成功のフラグをアドホックに多値の二値目で表現するようなことをします。
まさに、多値が導入された当初の目的で使っている感じですが、数合わせしないといけなくなるとすると、ちょっと面倒ですね。

■

HTML generated by 3bmd in LispWorks 7.0.0

Goの多値についての記事が人気のようで、この数日Twitterで多値の話題が賑わっています。

• 多値について本気で考えてみた

多値が話題になることなど、そうそうないですが、多値といえばやっぱりCommon Lispでしょう!、ということでLispと多値について書いてみます。

Lispと多値の歴史

多値といえばCommon Lispですが、最初の仕様のCommon Lisp(1984)でも標準の言語機能になっています。
Common Lispの人達は、普段から普通に便利に使っていますが、多値周りはシンプルなデザインなので使い方で混乱する、ということも特にないでしょう。

典型的な使われ方には下記のようなものがあります。

• 逆引きCommon Lisp: 多値

しかし、その多値機能ですが、Common Lispで初導入という訳ではなく、直接の祖先であるLisp Machine Lispにから輸入したものです。

ということで、Lisp Machine Lispの歴史を遡ってみましたが、私が調べた限りでは、多値が導入されたのは、1976年辺りのMIT LispマシンのCONSのようです。
LISP Machine Progress Report(1977)では、

        A traditional weakness of Lisp has been that functions have to
take a fixed number of arguments.  Various implementations have added
kludges to allow variable numbers of arguments; these, however, tend
either to slow down the function-calling mechanism, even when the
feature is not used, or to force peculiar programming styles. 
Lisp-machine Lisp allows functions to have optional parameters with
automatic user-controlled defaulting to an arbitrary expression in the
case where a corresponding argument is not supplied.  It is also
possible to have a "rest" parameter, which is bound to a list of the
arguments not bound to previous parameters.  This is frequently
important to simplify system programs and their interfaces. 
        A similar problem with Lisp function calling occurs when one
wants to return more than one value.  Traditionally one either returns
a list or stores some of the values into global variables.  In Lisp
machine Lisp, there is a multiple-value-return feature which allows
multiple values to be returned without going through either of the
above subterfuges.

という風に、入力側のオプショナル引数と、出力側の多値の対で語られています。

複数の値を返したい、というニーズがそんなにあったのかは不明ですが、リストで返したり、大域変数経由で渡すところを多値機構として、すっきり纏めたという話は、それはそれで説得力があるという所でしょうか。

MIT LispマシンはSECDマシンに非常に近い構成らしいので、専用マシンは多値をハードウェア支援で高速に実現できますよ!的な記述も探してみましたが、そういう話はみつけられませんでした。残念。

興味のある方向にCONS時代のLispのマニュアルを置いておきます。

• LISP MACHINE SOFTWARE MANUAL(1977)

このマニュアルでは、%CALL-MULT-VALUEや、%RETURN-N等のプリミティブが定義されていることが判ります。

ちなみに、Scheme方面では、恐らく1980年代前半にTが最初に導入し、その後紆余曲折を経てR5RSで仕様化されたようです。
Schemeも元を辿れば、Lisp Machine Lisp由来かなと思います。

Common Lispでの多値の扱い

多値の扱いを考える場合、N個の値を返す場合と、受けとる場合にどうなるかを考慮する必要がありますが、Common Lispでは下記のようになります。

値を返す

1. フォームは0個以上の値を返す

値を受け取る

1. 関数は単値のみ受けとる
2. 関数は二つ目以降は無視する
3. 0個の場合、nilを受け取る
4. 関数以外のスペシャルオペレーター/標準マクロには個別に規定がある

詳細は、Common Lispの仕様を参照してください。

• CLHS: 3.1.7 Return Values

スペシャルオペレーター/標準マクロの個別の規定ですが、過剰であれば無視され、足りなければ、nilが補われる動作と考えて問題ないと思います(multiple-value-call以外は)。

ただこの挙動をもって、Common Lispの多値機構の挙動と見做せるかというと、そうではなく、そういう風にフォーム構成されているだけという点に注意が必要かなと思います。

受取り側が期待した個数より少なければnilで補填され、敷衍して0個の場合はnilとなるのがCommon Lispの多値機構、という訳ではありません。

例えば、multiple-value-bindは足りない場所はnilを補い、過剰な場合は捨てますが、

(multiple-value-bind (q r s)
                     (floor 1 2)
  (list q r s))
;=> (0 1 nil) 

それは、多値を引数リストにする時にオプショナル引数のように処理しているからで、入出力の多値の個数が一致していなければ、エラーにすることも可能です。
また、nil以外のデフォルト値を設定することも可能でしょう。

(defmacro strict-multiple-value-bind ((&rest vars) mv-form &body body)
  `(multiple-value-call (lambda (,@vars) ,@body) ,mv-form))
(strict-multiple-value-bind (q r s)
                            (floor 1 2)
  (list q r))
;error> got 2 args, wanted at least 3.

まとめ

以上ですが、Common Lispでは、継続と多値があまり連続した議論になっていないのがお判りでしょうか。

このまま書き進んで行こうと思いましたが、長くなったので、続きは別の回にしたいと思います。

次回: 対称性にこだわるGLSと継続と多値

■

HTML generated by 3bmd in LispWorks 7.0.0

先日 @hatsugai さんからLisp関係の記事があるということで1986年のInformation(インフォメーションサイエンス社)というコンピューター月刊誌をお借りしました。
このInformationですが、1986年は第二次AIブームのまっさなかということで、面白い記事が多かったです。

AIワークステーション花盛りという感じで興味深い広告も多いのですが、その中でも目にとまったのが、裏表紙のMicroVAX IIの広告です。

MicroVAX IIもAI対応してますよ!という広告なのですが、用意されているAI言語として、当時かなりシェアが高かったFranz LispとNILの名があります。
……NIL! NILが商用化されていたとは!
広告の文言をそのまま引用すると、

■NIL
MIT AI Lab. で開発されたCommon LISP
米国Impediment(製)

とのことで、Impediment社があつかっているということですが、LispはSpeech Impedimentみたいなので、そんな洒落を社名にするならLisp関係の会社でしょうか。
早速ネットを検索してみたりしていたのですが、Impediment inc という検索ワードで、それらしき情報が出てきました。

• Expert Systems, October 1985: Impedimet's NIL

この記事によると、マシンスペック 5-16メガRAMのVAXで稼動し、Fravorsによるウィンドウシステム、Emacs系エディタが開発環境として用意されていますようです。

Fravorsによるウィンドウシステムは、ウィンドウシステムまるごとなのかVAXのものにのっかったものなのか知りたいところです(当時だと丸ごと作っていそう)が、Lispマシンのものを移植したりしていそうです。

Emacs系エディタについては、NILのマニュアルではSteveというものが標準エディタとして解説されていますので、多分Steveが動いたのではないでしょうか。 ちなみに、Steveの他にNileというものがあったとWikipediaに記載がありますが、実在したのかは未詳。

Impediment社は90年代からウェブサイトを所有しているようで、現在もドメインは活きているようですが、ウェブサイト自体は落ちているようです。 会社の住所は1985年の記事のものと同じようなので同一の会社かと思われます。

whoisで所有者情報を確認してみたところ、Alexander Sunguroff氏が管理者の様子。過去のAI関係の記事に社名と一緒に紹介されているようなので経営者のようにみえます。

Sunguroff氏は、1970年代初頭にはProject MACに関わっていたようで、主に初期のMultics MACLISPの開発にDavid Moon、….氏と共に携わっていたようです。

また、MACLISPマニュアルの定番である1974年版はDavid Moon氏とSunguroff誌が一緒にまとめたようです。

NILは、MITでのLisp Machineプロジェクトと同じく、MACLISPの後継ですが、後にCommon Lispの礎となり、自らもCommon Lispのスーパーセットとなりました。 Common Lispがレキシカルスコープを採用したのは直接的にはNILの影響だといわれています(当事者達曰く)

この辺りの経緯を鑑みるに、筋金入りのLisperであるSunguroff氏が1984年あたりに宙ぶらりんになっていたNILを商用化するために会社を興してもおかしくはないなと推理しているのですが、真相やいかに。

当時のLisp環境の最高峰といえば、Lispマシンでしたが、汎用機上のライバル達もLispマシンに追い付け追い越せで、Lisp OS、ウィンドウシステム完備のGUI、Lisp向けエディタ(Emacs etc)を一式揃えて勝負していましたので、NILもOSこそLisp OSではないものの、そんな感じだったのではないかと思います。

NILはMIT内で利用されていたのみと思っていたのですが、製品として世に流通していたとすれば、そのうち誰かが発掘してbitsaversにでも置いてくれるかもしれません。
いつかNILを起動してみたい……。

■

HTML generated by 3bmd in LispWorks 7.0.0

今月も月末にSBCLの新バージョンがリリースされましたが、リリースノートに、

• SBCL All News: 1.4.12
  enhancement: identical code (at the machine instruction level) can now be shared between functions, if explicitly requested.

とあり、どんな機能か気になったので調べてみました。

fold-identical-code

ちょっと調べても説明もなく良く分からなかったので、githubのコミットログを眺めましたが、fold-identical-codeとかいうのが、その機能のようです。

• Don't call sb-ext:fold-identical-code just yet. · sbcl/sbcl@a7d27f6 · GitHub

fold-identical-code を使ってみる

どう使うのかは、良く分かりませんが、

fold-identical-codeが定義されているsrc/code/icf.lispに

;;;; Identical Code Folding (similar to what might be done by a C linker)

とあるのでコードサイズの縮小あたりが狙いなのかもしれません。

とりあえず、下記のような同じ内容の関数を定義してみてからfold-identical-codeを実行してみると、

(progn
  (defun foo (x) (+ 42 x))
  (defun bar (x) (+ 42 x))
  (defun baz (x) (+ 42 x)))
(fold-identical-code :aggressive t :print t)

以下のようにずらっと結果が表示されますが、

#<code id=154F2 [1] baz {53FD93CF}> = #<code id=154F0 [1] foo {53FD92AF}>
#<code id=154F1 [1] bar {53FD933F}> = #<code id=154F0 [1] foo {53FD92AF}>

barとbazはfooにまとめられているようです。

使用メモリの削減具合を確認するためにイメージをダンプしてみましたが、135MiBのイメージが、ダンプ時にfold-identical-codeを実行してからダンプすると、134MiBに縮みました。

1%も縮まっていない感じですが、C++等のリンカの最適化を解説しているページによると、重複の削除によって1〜2%縮むと書いてあるものが多いようなので、そんなものなのでしょう。

むすび

今の所ドキュメントは整備されておらず、src/code/icf.lispsrc/code/icf.lispを読むしかない感じですが、今後整備されていくと思うので期待して待ちたいです。

ちなみに当初自分が期待していたのは、disassembleした時のインストラクションが同一になるかどうか確かめるユーティリティだったのですが、下記のようにfold-identical-codeの部品であるsb-vm::code-equivalent-pを使って判定できるようです。

(defun fun-code-equivalent-p (f g)
  (sb-vm::code-equivalent-p (list (sb-c::fun-code-header f))
                            (list (sb-c::fun-code-header g))))
(fun-code-equivalent-p #'foo #'bar)
;=>  t

ごくたまに欲しい時があって、disassemble関数の中身を使って自作していましたが、sb-vm::code-equivalent-pを使った方が正確に判定できるようなので、今後はこちらを使おうかなと思っています。

■

HTML generated by 3bmd in LispWorks 7.0.0

いきなりですが……、Shibuya.lisp 発足は十年前の2008-09-18だと思っていましたが、2008-09-08でした……。
日付間違えて覚えてて10周年過ぎてました。なんてこったい。

• 2008-09-08 Lisp系言語 コミュニティ Shibuya.lisp 発足 - higepon blog

自分は、発足当初のスタッフで途中で交代した人間ですが、10年も続いているのは素晴しいなと思います。

ざっとこの十年を振り返ってみると、テクニカルトークと、Lisp Meet Upがあります。
最近は、もくもく会というものあるようです。

• 2008-10-18 Shibuya.lisp テクニカルトーク#1
• 2009-02-28 Shibuya.lisp テクニカルトーク#2
• 2009-07-04 Shibuya.lisp テクニカルトーク#3
• 2009-11-07 Shibuya.lisp テクニカルトーク#4
• 2010-03-20 Shibuya.lisp テクニカルトーク#5
• 2010-11-27 Shibuya.lisp テクニカルトーク#6
• 2011-09-26 Shibuya.lisp テクニカルトーク#7
• 2014-08-30 Shibuya.lisp テクニカルトーク#8
• 2013-01-22/2018-09-27 Lisp Meet Up presented by Shibuya.lisp #1/#68

Lisp Meet Upの方は、今月開催分で実に68回目。
Lisp Meet Upは、なわたさんを中心として企画され始まったと記憶していますが、Meet Upがなければ2012年あたりで実質消滅していたかもしれないなと思います。

テクニカルトークの方は、大体50から100人程度の参加者で開催していたものですが、開催の負担が大きかったこともあり、2014年以降は開催されていません。
まあでも最近だと100名程度の参加者であれば手軽に開催できるイベント会場があるようなので、発表さえ揃えられれば開催できるのかもしれません。

この十年の傾向

2008年頃は、勉強会ブームがあり、また言語を学ぼうというブームがありました。
Lisp系言語では日本のSchemeの代表格であるGaucheが圧倒的だったと記憶しています。
一方、Common Lispグループは割と草の根的に活動していき、地味にネットワークを広げていったようです。

言語学習ブームが去りつつあった2011年あたりから、Schemeでなにか発表しようという人は少なくなる一方で、Clojureが擡頭してきて、Lisp Meet Upは、Common LispとClojureを中心にして今に至るようです。
Schemeは端から眺める限りでは、Schemer＝処理系開発者という感じなのでユーザーが集まって何かするより、開発者間で議論して個人間で盛り上がるという感じに見えたので、言語がコミュニティを形成させる上での形質の違いのようなものがあるのかもしれません。

現在では、業務でCommon Lisp、Clojureを書く人材/職場の交流もShibuya.lispをきっかけにして、ということも多々あるようです。

まとめ

次の十年の継続と発展を期待しています!

■

HTML generated by 3bmd in LispWorks 7.0.0

Common Lisp仕様策定のメーリングリストで、RMSが()とNILは区別すべき、という主張をしていて、そうした場合の御利益について説明しているのをみつけたので眺めていました。

• () and T.

NILと()を区別すべきという主張はさておき、文末の方にCommon LispでいうGeneralized Booleanのアイデアが紹介されています。

RMS:
The general principle is: if a predicate FOO-P is true if given falsehood as an argument, FOO-P should always return an object of which FOO-P is true. If, on the other hand, FOO-P is false when given falsehood as an argument, then FOO-P should always return its argument to indicate truth.

foo-pが真の時は、述語の与えられたオブジェクトを返すということの一般化ですが、Common LispでのGeneralized Booleanは、ざっとHyperSpecを数えたところ99個あるようです。

next-method-p remf slot-exists-p random-state-p simple-string-p
wild-pathname-p compiled-function-p slot-boundp graphic-char-p arrayp
string= string-equal simple-bit-vector-p array-in-bounds-p functionp
fboundp hash-table-p tree-equal symbolp listen input-stream-p
output-stream-p listp readtablep = /= < > <= >= pathname-match-p atom
streamp delete-package eq boundp keywordp logtest remprop characterp
open-stream-p every notevery notany unintern pathnamep complexp
alphanumericp realp simple-vector-p y-or-n-p yes-or-no-p eql vectorp
endp equal stringp remhash interactive-stream-p packagep evenp oddp
bit-vector-p subsetp alpha-char-p load minusp plusp numberp typep
adjustable-array-p zerop standard-char-p logbitp constantp tailp
special-operator-p rationalp array-has-fill-pointer-p char= char/=
char< char> char<= char>= char-equal char-not-equal char-lessp
char-greaterp char-not-greaterp char-not-lessp upper-case-p
lower-case-p both-case-p ldb-test fresh-line integerp equalp consp

boundpの謎

Generalized Booleanとして機能した場合に返す値が謎なものは結構ありますが、中でも、boundpが気になります。

cl:nilは偽値であるcl:nilに束縛されているので、(boundp 'cl:nil) => Tと真値を返すわけですが、これをGeneralized Boolean化した場合、(boundp 'foo)がfooシンボルを返すのは良いとして、cl:nilシンボルでcl:nilを返したら偽になってしまいます。

上記のRMSのメールでは、こういう場合は、Tを返すようなことを書いていますが、Generalized Booleanとしての機能は果すものの、今度は、(boundp 'cl:NIL)と(boundp 'cl:T)を区別できなくなります。

まとめ

Generalized Booleanを返しても良いもののうち、実際の利用例については首をひねるものは、boundp以外にも結構ありますので、暇潰しに考察するのも一興かなと思います。

■

HTML generated by 3bmd in LispWorks 7.0.0

色々な言語でCommon Lispのコードを書いてみたら、どうかなと思い試してみました。
だからなんなの、というような試みです。

コード例はお馴染みのfibにします。

Common Lisp

大元のCommon Lispです。
quoteを付ければデータになりますが、一応listでリストを生成するものも書いてみます。

'(defun fib (n)
   (if (< n 2)
       n
       (+ (fib (1- n))
          (fib (- n 2)))))

(list 'defun
      'fib
      (list 'n)
      (list 'if
            (list '< 'n '2)
            'n
            (list '+ 
                  (list 'fib (list '1- 'n))
                  (list 'fib (list '- 'n 2)))))

当然ながらevalすれば、コードとして実行できます。

Racket

まあ、RacketもCommon Lispもそのまんまですね。
1-というシンボルは関数名としては不可だった気もします。

'(defun fib (n) (if (< n 2) n (+ (fib (1- n)) (fib (- n 2)))))

defun等々の関数を定義すれば、そのまま動かせると思います。

Python

PythonではCLのリストに相当するものは配列になるでしょう。
ASTやシンボルへのアクセスもできるようですが、とりあえず、面倒なのでシンボルは文字列としておきます。

['defun',
 'fib',
 ['n'],
 ['if',
  ['<', 'n', 2],
  'n',
  ['+', ['fib', ['1-', 'n']], ['fib', ['-', 'n', 2]]]]]

上のコードを動かすにはインタプリタを作成する感じなんでしょうか。

Ruby

RubyもPythonと似た感じですが、シンボルがあるので使ってみました。

[:defun,
 :fib,
 [:n],
 [:if, [:<, :n, 2], :n, [:+, [:fib, [:"1-", :n]], [:fib, [:-, :n, 2]]]]]

Erlang

何故Erlangという気もしますが、Prologっぽいので試してみました。
やはりシンボルがあるので扱いが楽です。

[defun,fib,[n],['if',['<',n,2],n,['+',[fib,['1-',n]],[fib,['-',n,2]]]]]

Prolog

Prologは、Lispと同様、基本のデータ型がリストです。Lispのシンボルはアトムに相当するでしょうか。

[defun,fib,[n],[if,[<,n,2],n,[+,[fib,[1-,n]],[fib,[-,n,2]]]]]

Julia

最近ブレイクしつつあるような気がするJuliaですが、シンボルがあるので、そこそこ素直に書けます。

[:defun, :fib, [:n], [:if, [:<, :n, 2], :n, [:+, [:fib, [Symbol("1-"), :n]], [:fib, [:-, :n, 2]]]]]

データをコードにする仕組みが割と身近に存在するようで、文字列をパーズしてExpr型というコードに変換することが可能です。

julia> xpr="function fib(n)
         if n < 2
            n
          else
            fib(n - 1) + fib(n - 2)
         end
       end"
julia> Meta.parse(xpr)
:(function fib(n)
      #= none:2 =#
      if n < 2
          #= none:3 =#
          n
      else
          #= none:5 =#
          fib(n - 1) + fib(n - 2)
      end
  end)
julia> Meta.show_sexpr(Meta.parse(xpr))
(:function, (:call, :fib, :n), (:block,
    :(#= none:2 =#),
    (:if, (:call, :<, :n, 2), (:block,
        :(#= none:3 =#),
        :n
      ), (:block,
        :(#= none:5 =#),
        (:call, :+, (:call, :fib, (:call, :-, :n, 1)), (:call, :fib, (:call, :-, :n, 2)))
      ))
  ))

コードをExprで直接記述することもできるようで、この辺りは、まんまLispの前置記法ですね。

Expr(:function, Expr(:call, :fib, :n), 
     Expr(:if, Expr(:call, :<, :n, 2), 
             :n,
             Expr(:call, :+, 
                    Expr(:call, :fib, Expr(:call, :-, :n, 1)), 
                    Expr(:call, :fib, Expr(:call, :-, :n, 2)))))

(追記) Squeak/Pharo Smalltalk

ブログの内容が謎コンテンツでしたが、意外にもSmalltalk方面から反応を頂きました。
ありがとうございます🙇

「色々な言語でCommon Lispのコードを書いてみよう」https://t.co/AlI5lmFhvd をSqueak/Pharo Smalltalkで。

#(defun fib (n) (if (< n 2) n (+ (fib (#'1-' n)) (fib (- n 2)))))

多くのSmalltalkの処理系ではリテラル配列表現の要素となるシンボルは#を省略できるので少しLispっぽく書けます。

— sumim (@sumim) 2018年8月28日

シンボルがあるSmalltalkもかなりLispっぽく書けますね。しかも丸括弧。

まとめ

Common Lispは、プログラムを文字のつづりというよりは、言語処理系のリスト型とシンボルで記述しますが、他の言語のデータ型を使ってCommon Lispのコードを書いてみたら面白いかなと思って試してみました。

当然ながら、やっぱり、Lisp、Prologあたりは、この辺りの処理はしやすいですね。

Juliaは数値計算にフォーカスしているものと思っていましたが、案外Lisp的なコード=データな文化も継承しているようで、なかなか面白いと思いました。

■

HTML generated by 3bmd in LispWorks 7.0.0

三年以上寝かせたアイデアですが、まったく有用なケースを見出せていません。

(defconstant ? :test)
(member "a" '("b" "c" "a") ? #'string=)
→ ("a") 

何か活用法あるでしょうか。

ちなみに、いまのところ有用なケースは見出せていませんが、マクロやコンパイラマクロの引数定義をめんどくさくしたりコンパイラの最適化を阻害する欠点はあるなとは思いました。

■

HTML generated by 3bmd in LispWorks 7.0.0

最近、過去のブログ記事を眺めかえしたりしているのですが、shiroさんのブログに、アラビア数字・ローマ数字変換ネタがあり、

• アラビア数字・ローマ数字変換 ─ Island Life

  formatの~@Rに対称な機能がparse-integerに無いのは美しく無いよなあ。

とありました。

私は、MACLISPは対称の筈だ!と思いMACLISP用のコードを書き始めましたが、どうも昔に書いたことがあると思いローカルのファイルを検索してみると、どうやら記事を読んだ当時に書いていたようで、ついでにGitHubにコードもアップしてました。

これが可能なのはMACLISPは基数にローマ数字を指定できるからなのですが、詳細は関連記事の動画を参照してください。
どうして当時記事にしなかったのだろう。マニアックすぎたからだろうか……。

関連記事

• roman.pltの紹介
• MacLISPでは表示と入力の基数にローマ数字が設定できた

■

HTML generated by 3bmd in LispWorks 7.0.0

表題の通りで、だからなんだよといわれればそうなのですが、以前、C++ STLにCommon Lispの影響はあるのかを探る旅に出ていました。

• #:g1: C++ STLにCommon Lispの影響はあるのかを探る旅(1)
• #:g1: C++ STLにCommon Lispの影響はあるのかを探る旅(2)

この記事の結論としては、明言はされていないものの、Common Lispのシークエンス関数をごっそり取り入れているようにしか見えないので、Common Lispが元ネタはじゃないだろうか、という感じでしたが、先日Stepanov先生の「その数式、プログラムできますか？」を読んでいたところ、find_ifの注釈として脚注に、

"find it if it's there"(あれば検出する)の意。この名前の起源はCommon Lispプログラミング言語にある。
                                                         ─第10章 プログラミングの基礎概念 P216

と明言されていました。
まあ名前どころじゃなくて、シークエンス系ユーティリティの概念とか挙動は、結構な数が取り込まれていると思いますので、興味のある方はチェックしてみてください。

■

HTML generated by 3bmd in LispWorks 7.0.0

私の身近にLispWorksを使う人がちらほら増えてきているのですが、バグやパッチの情報だったり、便利な使い方だったりの情報共有をもっと活発にしたいなと思い、Google Groupsで勝手に「日本LispWorksユーザー会(非公式)」というのを作成しました。

• 日本LispWorksユーザー会(非公式)

主な用途・ターゲットユーザー

1. LispWorksのパッチやバグの情報共有
2. LispWorks全般、特に日本語処理周りについての情報共有

が主な目的で、その辺りに興味がある方々がターゲットユーザーです

まあ、Lisp Hugメーリングリストで尋ねてみたら?というアドバイスが殆どになってしまうかもしれませんが、それはそれで良いかなと思っています😃

■

HTML generated by 3bmd in LispWorks 7.0.0

小学館ランダムハウス英和大辞典のオンライン版で、“obscure”の用例に何故かMACLISPが出てきているのを発見しました。

goo 英和・和英辞書 「an obscure feature of MacLISP」の意味

an obscure feature of MacLISP
説明書に書かれていない MacLISP (コンピュータ言語)の一特徴.

ちゃんとMITっぽい言い回しですが、一体どこから紛れ込んだのでしょう……。

■

HTML generated by 3bmd in LispWorks 7.0.0

turingcomplete.fm #17 を聴いていたら、Lispと有理数について、またそれはいつ頃導入されたのかという話題がでてきました。
そういえばLispが有理数をサポートしたのっていつ頃なのか私も知らないな、ということでちょっと調べてみましたが、1981年あたりが境ではないかと推測できたものの、結局あまりはっきりしたことは分からず。
とはいえ、折角調べたのでまとめて記事にしてみることにしました。

Common Lisp

しかし、とりあえず「Lispは数値計算周りの仕様が充実している」という評判はCommon Lisp(1984)辺りが始まりのようです。
次にSchemeが、RRRS(1985)でCommon Lisp(1984)の成果を評価し、それを取り入れたようですが、その際にCommon Lispでは定義されていない正確数と非正確数の概念ができたようです。
当時の背景があまり想像できませんが、移植性のある正確数とそうでないものに分けたのでしょうか。
RRRSではCommon Lispより前には体系的に数値計算をまとめたLispはなかったと述べられているので、Common Lispが一つの境なのでしょう。

S-1 Lisp

では、そのCommon Lispは、どこから有理数を取り入れたかというと、当時の科学計算用スーパーコンピュータ用LispであるS-1 Lisp(S-1 NIL)からのようで、取り入れる方針が決まったのは1981年位のことのようです。

• The Evolution of Lisp:

  Fancy floating point numbers, including complex and rational numbers (this was the primary influence of S-1 Lisp)

S-1 LispはS-1 NILとも呼ばれるように、方言としてはNILであり、Common Lispが制定された頃にはNILはCommon Lispになってしまっているので、どこからNILでどこからCommon Lispかは分かりませんが、数値計算回りでのS-1 Lispの影響は、かなり大きそうです。
S-1 Lispでは、数値計算回りでハードウェアの支援が手厚く、有理数のサポートでもハードウェアの支援を受けることができていたようです。

• S-1 Common Lisp Implementation(PDF)

Lisp Machine Lisp

また、同時期の1981年後半には、S-1 Lispとは独立してLisp Machine Lisp(Zetalisp)(CADR System 74)にも導入されていますが、製品として世の中に出たLispとしては最初のものではないでしょうか(Symbolics/LMIから製品化)。
ちなみに、Lisp Machine Lispの方の有理数は、当初は、エスケープ文字が/なので、3\10のように記述されていましたが後のCommon Lisp化で3/10のように表記されるようになったようです。
また、Lisp Machine Lispでは、Common Lispのように整数との統合はされていないようで1\1と1は別物になるようです。

1981年のLispコミュニティ

Lispコミュニティでは、1981年辺りで有理数の議論がよくされていたようで、1981年あたりに何らかの機運があったのかなと思います。

Lisp、Smalltalkの双方で活躍していたL Peter Deutsch氏がSmalltalk-80には有理数サポートがあるという投稿をしていますが、こういう発言があるということはやはり1981年辺りで有理数をサポートしたメジャーなLisp処理系はなかったのではないかと思います。

• LISP-FORUM: rational arithmetic
• LISP-FORUM: Re: implementation of rational numbers
• LISP-FORUM: Re: Division in Smalltalk

■

HTML generated by 3bmd in LispWorks 7.0.0

すっかり忘れてしまっていましたが、「百年の言語」を体現するarcが公開されたのは、十年前の2008-01-29のことでした。
本当は、今年の01-29に何か書こうと思っていましたが、それさえ忘れて早二ヶ月半……。

arcのソースコードが公開されたのは2008年でしたが、arcで構築されたサイトのHacker Newsは、2007年から稼動しています。
また、名前と構想が発表されたのは、2001年のことなので、かれこれ十八年ともいえなくもないです。

最近のarc

arcの近況を眺めてみましたが、オフィシャルなリリースは、2009-08の3.1から9年間動きなしです。
Hacker Newsを動かしていたのはarcでしたが、2014年にpg氏がY Combinatorの日常業務から引退し、今ではまだarcで動いているのかは良く分からないようです。

軒並動きはないのかと思いましたが、arcのコミュニティが開発しているAnarkiの方は最近も更新があるようです。
Racketに#lang anarkiを作成するなど、なかなか面白そう。

早速、試してみましたが、Racketがインストールされた環境であれば、

raco pkg install anarki

とするだけで導入されます。

あとは、こんな感じで記述しRacketから使えます。 (無理にarcっぽさを出してみました。)

#lang anarki
;;; fib.rkt
(:provide fib)
(def fib (n)
  (if (< n 2)
      n
      (+ (fib:- n 2)
         (fib:- n 1))))

;; Racket
(require "fib.rtk")
(fib 40)
;→ 102334155

むすび

もっと色々書こうと思いましたが、昔の文献を読んでいたらお腹一杯になって満足しました。

参考

• (2012) さあ、Arcをはじめよう | 松村技研
• (2008) Arc's Out
• (2003) 百年の言語
• (2002) なぜArcはとりたててオブジェクト指向でないのか
• (2001) 人気の言語を作るには
• (2001) Arc at 3 Weeks

このブログのarc関係の記事

• https://g000001.cddddr.org/?TAGS=arc

■

HTML generated by 3bmd in LispWorks 7.0.0

defvarには値が設定されている場合には再設定をしないという利点がありますが、開発中などはdefvarの値を再設定したい場合がままあります。

こんな時の為に便利マクロを定義するという記事を読みました。

• defvar で再定義

目立たない機能なのであまり知られていないですが、Emacs系のLispエディタ上ではdefvarのフォームを評価したら値が再設定される、という機能があります。
どうやらdefvarが誕生した(1979年頃)からある機能の様子。
(多分、defvar誕生の頃から扱いがめんどくさいという認識があったのでしょう……)

Zmacs(ZWEI)だと、COM-EVALUATE-REGION-HACKというのがあって、defvarをsetqに置き換えて評価するようです。

slimeだとslime-eval-defunで評価すれば、defvarを認識して下請けのslime-re-evaluate-defvarで値を再設定します。
再設定の方法は、一度makunboundしています。

LispWorksだと、“Evaluate Defun”が“Reevaluate Defvar”を呼んで再設定します。slimeと同じくmakunboundするようです。
エディタ変数editor::evaluate-defvar-actionの値が、:reevaluate-and-warnか:reevaluateの場合だけこの動作になるので好みで入切可能です(デフォルトは有効)

Hemlockだと、“Re-evaluate Defvar” コマンドのみで、“Evaluate Defun”とは連動しないようです。こちらもmakunboundして再設定。

新しい値でsetqするものかと思っていましたが、案外makunboundで処理する方式の方が多いみたいですね。

むすび

“Reevaluate Defvar”は、リージョンを評価した時などにも発動していることがあります。
大抵の開発時は、再評価してもらった方が嬉しいですが、defvarの値設定まわりがどうも不思議な挙動だなと思ったら、確認してみるのも良いかと思います。

関連

• #:g1: SLIMEばつ牛ン (1) slime-eval-defun
• #:g1: Slimy hackathon #1終了!!

■

HTML generated by 3bmd in LispWorks 7.0.0

MIT Lispマシンのソースディレクトリを漁っていたら、MITの最初のLispマシンであるCONS時代のLisp Machine Lispのマニュアルらしきものをみつけたので、html化してみました。

• lmdoc;csoft 20

日付は、1977-06-08ですが、CONS時代のドキュメントであるAIM-444: LISP Machine Progress Reportと照らし合わせてもCONS時代で間違いないようです。

AIM-444の最後に書いてあるように、プロトタイプであるCONSは、1977年に一応の完成となり、1978年あたりから実用を目的としたCADRの開発が始まります。

CONS時代のLisp Machine Lispで興味深い所

EVERYやSOMEはINTERLISPから輸入してきたものであることが書かれていたりします。

また、CONS時代にはまだ、パッケージがないのですが、どうやら接頭辞で管理していたようです。
雰囲気としては今のEmacs Lispに近いですが、これらは、PREFIX REGISTRYのまとまりとして何らかのお作法があった様子。

現在のCommon Lispにも存在するread-from-stringが既にありますが、read-は接頭辞だったようなので、当初は、Common Lispでいうとread:from-stringみたいな感じだったのかもしれません。
しかし、これらの接頭辞は、その後パッケージができても名前はそのまま変更されることもなく後の慣習と混ざり、なんとなく命名規約が二重になった感じを残したようです。

また、現在のLispでは単語を-で繋ぎますが、一部_で繋いだものも存在したようです。これらは後に-で統一されます。

%は現在の命名慣習でも公でない内部関数を表わしたりしますが、初期のLisp Machine Lispでもそのようです。
この後、CADR時代になってくると、マイクロコードで書かれた低レイヤーのサブプリミティブで値を返すことが前提になっていないものに%が付くという慣習になって行ったようです。

%が重なる%%の命名規約は謎です。安直に考えると、さらに内部の関数という感じですが、どうもそうでもない雰囲気があります。

面白いのが、下請けを意味する*と併用されたりすることで、例えば、%*NCONCは、可変長のNCONCの二引数版でかつ公でない関数、という感じになります。また、%*GENSYM-COUNTERのように変数に適用されることもあるようです。

• 7.x PREFIX REGISTRY

TRACE-
GRIND-
TV-
PC-PPR-
KBD-
FILE-
PRINT-
READ-
FASL-
ED-
ED-COM-
%
%%
*
%*
DTP-
%%Q-
CDR-
%%AREA-MODE-
FSM-
%SYS-COM-
ADI-
%%ADI-
LP-
%%LP-
%%ARG-DESC-
%FEF-
%%FEF-
FEF-
%%ARRAY-
%ARRAY-
ARRAY-
ART-
FEFH-
%FEFH-
%%FEFH-
FEFHI-
%%FEFHI-
%%PHT1-
%%PHT2-
%PHT-
SG-
%%SG-
MESA-
%%MESA-

むすび

CONS時代のLispがどのようなものだったかの資料は少なく、AIM-444: LISP Machine Progress Reportに書いてあることも謎が多かったのですが、このマニュアルで若干謎が解明されました。
また、Lisp Machine LispはCADRから始まるような印象がありましたが、初期のものを含めると1975、6年あたりから存在するといえそうです。

■

HTML generated by 3bmd in LispWorks 7.0.0

Lispな人でマストドンを利用している人がどれだけいるのかは分からないのですが、ボットを作成するのが簡単だったので、Twitterボットが投稿するついでにマストドンにも投稿するようにしてみました。

r/lisp_jaと、その他英語Lisp系サブレディットの詰め合わせ版の二種があります。

• r/lisp_ja (@reddit_lisp_ja) - mstdn.jp
• r/lisp (@reddit_lisp) - mstdn.jp

TLのお供にどうぞ。