##; ss-< ... car shared lists
(define (ss-< shared-car left-cdr right-cdr)
(values
(rlet1 x (cons #f left-cdr) (set-car! x shared-car) )
(rlet1 x (cons #f right-cdr) (set-car! x shared-car) ) ) )
; ss>- ... cdr shared lists
(define (ss>- shared-cdr left-car right-car)
(values
(rlet1 x (cons left-car #f) (set-cdr! x shared-cdr) )
(rlet1 x (cons right-car #f) (set-cdr! x shared-cdr) ) ) )#共有構造を作る手続きを書いたんですが，もっと簡単(簡潔)に書けます？
#gosh> (ss-< 1 2 3)
(1 . 2)
(1 . 3)
gosh> (ss>- 1 2 3)
(2 . 1)
(3 . 1)
gosh>
#(values (cons shared-car left-cdr) (cons shared-car right-cdr)) で良いような。なおshared-carが1とかの単純な値では共有してるかどうかわからんです。何らかの構造を渡さないと。
#あ，循環リストの部分を読んでこれを使ったら共有構造が表せるなーと思ったんですが，言われてみれば，そんなのことしなくてもいいのでありました。。。。
#循環リストの作成は，set-cdr!でやる方法しかないんですか？
#eagerな言語では、循環構造はどこかで破壊的変更をしないと無理じゃないかなあと思います。暗黙の遅延評価があればset!無しで可能です。例えば
#gosh> (define z (lcons* 1 2 3 z))
z
gosh> (take z 10)
(1 2 3 1 2 3 1 2 3 1)
#ただこれはzを読みにゆく時に次々に新たにコンスセルが作られるから、#1=(1 2 3 . #1#) の意味の循環構造とは違うかな。
#'(#0=(11 22) (#0# 2 3) (#0# 4 5) )
これを自動化するマクロを書けばいいのかしらん。
#ただ，#0#という新たな道具をどう使えばいいか考えてたのでした・・・・
#循環構造というか，共有構造をコンパクトに生成できないかなとかと。（
#生成するところはメモリ上の話なんで、例えば (let ((x '(11 22)) `(,x (,x 2 3) (,x 4 5))) でも何でもできると思うんですが、そういうことではなくて?
#あ、括弧がひとつ足りないや
#letつかわずにできるかなーとか。
#; ss-< ... car shared lists
(define (ss-< shared-car left-cdr right-cdr)
`( (#0=,shared-car . ,left-cdr) (#0# . ,right-cdr) ) )
; ss>- ... cdr shared lists
(define (ss>- shared-cdr left-car right-car)
`( (,left-car . #0=,shared-cdr) (,right-car . #0#) ) )
#返り値をリストにしてみました。よく考えてみると，リストでまとめて扱ってたので。
#gosh> (ss-< '(999 999 999) 2 3)
(((999 999 999) . 2) ((999 999 999) . 3))
gosh> (ss>- '(999 999 999) 2 3)
((2 999 999 999) (3 999 999 999))
#`((,shared-car . ,left-cdr) (,shared-car . ,right-cdr)) にしたくない理由は?
#コードゴルフで#n#を使って縮めるってテクニックはあったけど。
#変数参照を最小にできるかなーと。
#このほうが，共有してる感がつよまる。（個人の印象です。
#もともと、同じ変数参照してたら共有ですからねえ。意味があるとすればリテラルに#n#ラベル付加、かな。
#なんでしょうか？ ＞ ラベル付加 （#n#のマニュアルエントリをみつけられない
#いや、たとえば(list '(1 . #0=(2 . #1=(3))) #0# #1#)) みたいな話です。((1 2 3) (2 3) (3))が帰ってきますが、リスト末尾がそれぞれ共有されてます。そういう構造を一気に書きたい場合は#n#ラベルが使えるよね、という話。
#尤もリテラルは変更不可であり、変更不可構造ではそれが同一なのか同値なのかを区別する必要はあまり無いので、やっぱり使いどころは限られそう。
#えーと，この#n#のマニュアルでの章はどこでしょうか・・・・
#今見たけどちゃんとしたエントリはないですね。入出力のところで軽く説明してるだけです。
#字句構造のところで説明しといてもいいかな。
#SRFI-38を見ればいいわけですね？
#リテラルに関していえば、GaucheのAOTコンパイラはリテラルの部分構造が共通なら元の表記がどうだろうと共有するようにコンパイルするので、ますます意味がない
#あ、仕様についてはそうです＞srfi-38
#インデクスで#リテラルも引ければいいですね。
##リテラルって?
#えーと，#で始まる記号群のことを表現していました・・・・
#IndexのJump toのリンク集に#があればと。
##あ、そこに@findexはっとけばいいのか。
#インデクスにないとグーグル先生に聞く習慣がついていまして・・・・
#でも手続きとは違うからなあ、別の章にしないとだめかな。
#何が手続きなのかわからないひとには，総索引が必要なのです。
#今でも総索引はないんですが、どうしましょう。
#つまり、手続きと構文 / 変数 / クラス / モジュール、で分かれている。
#理想はインクリメンタルサーチで候補が入力文字に反応してでてくるやつですね。（贅沢
##n#については，字句構造を見るというステップに気づかなかったので，グーグル先生経由でした・・・・・
#特殊構文インデクスという章があればいいのかも。
#Gaucheでしか使われない構文の索引。とか拡張構文の索引。
##お馴染みになりつつありますが09661ec158835d18fdbf299f51cb64a4157133fcでmake testにてTesting system ...でハングアップするので報告まで。Ubuntu 14.04.1 x86_64
#vmubuntu:maru% tail -f src/test.log [~/var/tmp/Gauche]
test sys-fdset-clear!, expects () ==> ok
test select, expects (0 #f #f #f #f 1 #t #f #f #t #\x) ==> ok
<signal handling>--------------------------------------------------------------
test sigalrm1, expects 14 ==> ok
test sigalrm2, expects 0 ==> ok
test sigalrm3, expects #<error> ==> ok
test sigalrm4 (interrupting syscall), expects 14 ==> ok
test sigalrm5 (interrupting syscall - restart), expects (a) ==> ok
test sigalrm6 (interrupting syscall - restart), expects (#t 0) ==> ok
test fork & sigint, expects #t ==>
#ここで停止中
#あ，SchemeCrossReferenceというのがありましたね。ありがとうございます。
#gosh> ($ ss-< '("head" "neck") $* ss>- '("body" "foot") "left hand" "right hand")
((("head" "neck") "left hand" "body" "foot") (("head" "neck") "right hand" "body" "foot"))#てな具合でss-<,ss>-をつないで共有構造をつくるみたいなイメージを受信していたのでした。理想は(ss '("head" "neck") -< "left hand" "right hand" >- '("body" "foot") )のようなマクロ。
#で，こういう演算子がどれくらいあれば，共有構造が表現できるんかなーと。（受信
Gauche > Archives > 2014/11/17