Lisp Scheme Part39

Common Lisp、SchemeをはじめとするLisp族全般のスレです

■前スレ
Lisp Scheme Part38
http://peace.2ch.net/test/read.cgi/tech/1391252139/

■テンプレ
ttp://wiki.fdiary.net/lisp/

■関連スレ
【入門】Common Lisp その10【質問よろず】
ttp://toro.2ch.net/test/read.cgi/tech/1361341876/
【Scheme】Schemeインタプリタ Mosh Part1【Lisp】
ttp://toro.2ch.net/test/read.cgi/tech/1272469779/
【Lisp】プログラミング言語 Clojure #3【JVM】
http://toro.2ch.net/test/read.cgi/tech/1380333808/
【魔法】リリカル☆Lisp【言語】
ttp://toro.2ch.net/test/read.cgi/tech/1183396621/

長門ってどっちだスレ立て乙

前スレ>>989
> 日本語訳がおかしい気がする

>そして第二に、最良の事例（もしくは標準的な事例でさえも）は、タスクによって左右される
>ものではないと考えられていることです。つまり、ワープロのコードを記述するために最良の方法は、
>宇宙探査機の制御システムのコードを記述する上でも最良の方法だという憶測です。しかし、そうではありません。

practiceは「事例」では少しおかしく、「方法」でいい。
「つまり」以降に出てくるwayも「方法」になるので違いを出したいならば「実践」かな。
「やり方」としてもいいと思う。

>>1乙

>>1乙
ApacheをHunchentootに置換する権利をあげよう

http://www.buzzword.jp/img/face10.png

伊倉辰雄のウザさ半端ないな

lambda式のままでシンボルにバインドせずに再帰させる方法がピンときた。
要するに自身へのポインタを引数に渡して、そのポインタに再帰させるんだな
適用順Yコンビネーター(という関数)を作らなくてもいいんだな


例 リストのメンバーか？
(((lambda (self-ptr)
(lambda (a l)
(cond
((null? l) #f
((eq? (car l) a) #t
(#t ((self-ptr self-ptr) a (cdr l))))))
(lambda (self-ptr)
(lambda (a l)
(cond
((null? l) #f
((eq? (car l) a) #t
(#t ((self-ptr self-ptr) a (cdr l))))))) 2 ’(1 2 3))

そうか。

括弧足んないよ

https://encrypted-tbn1.gstatic.com/images?q=tbn:ANd9GcQljebB_qGHv6_3JSjCi6jbKmmvLXQKmXrIEq5ENOG11_YWlPxl

これnaoiwata？
もしそうなら、かわいいからWishリストの本でも贈ろうかな＾＾

Wishリスト
http://www.amazon.co.jp/registry/wishlist/3FSK478U0FBC/ref=cm_wl_sb_o?reveal=unpurchased&filter=all&sort=priority

一個人の話題をここに書くのやめない？
この界隈の人間がこういうの許容するやつばっかりだと思われるのも嫌

俺のチンポは四国一
可愛いSchemeも
継続よ、継続よ
と泣いて喜ぶ
>>12
しね早漏包茎ついでに短小

NGNG

>>13
あらごめんなさい。11についてかいたのですけれど何か問題でも？

下品なのはやめれ。

つまり、やっぱり俺のチンポが町内一ということやな
婦人会もメロメロやで
俺はニボシくってチンポ固くしたで
おまえ等も見習えや

非表示非表示

事情があってAndroid上のエディタを使った。対応（）のチェック機能がない．
書いたものが動かない！（）の対応チェックでとんでもなく時間かかった．
俺はまだまだだな。リスプと取り組んで半年

SICP の日本語訳が無料で公開されているというありがたい話を聞いて見に行ったら、
「関数と手続の間の対称性は事物の属性の説明と行いの説明との間の一般的区別に関する反映です。」
みたいなすばらしい日本語ですごいありがたみがあった

The Little Lisper昨日やり終えた
8章までは簡単だったが無名再帰は感覚化するのに何度もやり直した。
最終章でのインタープリター作りは快調に終わったが、これ、終わり方中途半端で「後は自分で完成させなさいね」って感じ？
最後の一ページでのcons/car/cdrの定義
はじめなにやってんるんだが意図がわからんかった
最後の一ページにきてはじめて
「えへへ、内部のデータ構造としてはリストは幻影、実体はセルやで」
とささやいたんやな

で
「だからよぉ、もうconsもcarもcdrも
primitiveとしなくてもええんやで」
とか言ってるくせに
primitiveの適用関数はそのままでおえてるし。後は自分でやれってかあ。

参考資料テキストから

(define cons
(lambda (u v)
(lambda (b)
(cond
(b u) (t v)))))

(define car
(lambda (l)
(l t)))

(define cdr
(lambda (l)
(l nil)))

The Little Schemer 手習い
The Seasoned Schemer 修行
The Reasoned Schemer (論理プログラミング)
やったことないけど、2冊目に繋がってたんだっけ？それとも別トピック？

>>21
そんなこと最後のページに書いてんのか
文学的想像力の豊かすぎる人にはちょっとアレな本だね

gaucheでリストに入ってる演算子を使って演算したいんですけど、たとえば、

( (car '(+ -)) 1 2)

で 1 + 2 は計算できないんですけど、どうすればいいでしょうか

((car (list + -)) 1 2)

gauche で演算子をリストにしたいんですけど、
これ↓

(define oplist (list f1 f2))
(define (f1 v) (+ 0 v))
(define (f2 v) (- 0 v))

を reple で load で読み込むとエラーになるけど
これ↓

(define (f1 v) (+ 0 v))
(define (f2 v) (- 0 v))
(define oplist (list f1 f2))

はエラーになりません

もしかしてgucheも関数を定義する順番を考えないといけないということでしょうか

定義する順番というか評価する順番は考えなきゃいけない。

いわゆる純粋な関数型言語と勘違いしてる？

>>26
> もしかしてgucheも関数を定義する順番を考えないといけないということでしょうか

oplist自体は関数じゃないので、その定義の際には
定義式の (list f1 f2) が評価されねばならない。
しかし最初のだと、この式の評価の時点で f1, f2 は未定義だからエラーになる。

関数ならば定義の時点で本体式は評価されず、その中で参照している識別子が
定義済か否かは問わないので、次の２つはどちらもエラーにならず同じ結果になる。

(define (app-pair v) (list (f1 v) (f2 v))
(define (f1 v) (+ 0 v))
(define (f2 v) (- 0 v))

または

(define (f1 v) (+ 0 v))
(define (f2 v) (- 0 v))
(define (app-pair v) (list (f1 v) (f2 v))

>>29
なるほどぉ、勉強になった

>>26
Cとから手続き型言語から入るとこういう疑問を余り抱かないと思うけど、
最近は一番最初にプログミングを覚えた言語がhaskellですとかあるんか？

初めての言語はLispです

初めての彼はネパール人です

Lisp系言語以外でSCHEMEに一番近い言語って何だと思う？

pythonかjsだわな

ISWIM
Dylan
OCaml

C言語

>>36
dylan近いか？
dylan自体がselfとかjsに近いからjsが近い言うた僕が言うのもなんだけど。

DylanはS式でないCLOS
名前空間管理やSLOTアクセス管理に無頓着

lua

DylanてS式でもうごくんじゃないっけ？

C言語の正規表現マッチャのコードとか見るとschemeの臭いがするのは私だけでしょうか

てかC言語って割とLispの影響が見える

カンマ演算子とか三項演算子とかfor文とか

>>43
異論は多いみたいだが私もそう感じる http://peace.2ch.net/test/read.cgi/tech/1313183984/594

SICP の日本語LaTeX版を提供してくれているのはすごくありがたいけれど、読めば読むほど翻訳が（ありがたさから以下略）

>>43
> てかC言語って割とLispの影響が見える
>
> カンマ演算子とか三項演算子とかfor文とか

それらはAlgol 68からの継承だよ。
いわゆるAlgolはAlgol 60を指しAlgol 60は通常の文言語だが
Algol 68は手続き的（書き換え可能な記憶域を書き換えることで計算を表す）な式言語で
Cでの代入操作が文でなく式の演算子になっているのはAlgol 68が源流。
カンマ演算子や3項演算子もAlgol 68が元祖でそれから受け継いだもの。
for文の各パーツがオプション的になってるのもAlgol 68のループ構文からの流れだ。
Algol 68を少し真面目に調べてごらん。Cがどれだけ影響を受けたか良くわかる。

http://ja.m.wikipedia.org/wiki/ALGOL
http://ja.m.wikipedia.org/wiki/LISP
http://ja.m.wikipedia.org/wiki/ジョン・マッカーシー

マッカーシーは60年の時点でALGOL設計委員会の委員やって、ALGOLに触発されたともあるので
LISPとALGOL68の構文の関係は60-68年当時のLISPを調べないと分からないかも。

構文には影響ないだろw

LispでAlgolの影響とか言われるのは、SchemeとかCommon Lispとかの
近代的なLispの静的スコープ。あれはAlgol（68じゃなくて60も）で関数定義を
ネストさせた場合の意味論と同じ。これはマッカーシー先生は関係しない
んじゃないかなぁ。

>>47
McCarthyはAlgol 68には全くタッチしていない。
そもそもAlgol 60の設計をやった連中はWijngaardenのチームが出してきたAlgol 68の提案を見て
ほぼ例外なくあきれ返って愛想をつかしたのだから。
Algol 60とAlgol 68とは言語の中身や基本コンセプトも設計したメンバも全く別だよ。
Algolという単一の言語の年代別バージョンの違いじゃないんだ。
Algol 60とAlgol 68とは、CとAlgol 68との違い以上に違う言語。

Algol 60とAlgol 68とを明確に区別せず単なるバージョンの違いのようにみなして議論するのは全くのナンセンス。

どうして「そんなに違う」のに同じ名前（Algol）を継承したの？

よーするに「委員会言語」。

あとCの起源にまつわる伝説のあやしさと、Algol68からの影響については、
このページがよくまとまってる。 ttp://nanyanen.jp/comp/corigin.html

>>50
> どうして「そんなに違う」のに同じ名前（Algol）を継承したの？

IFIPという情報処理に関する国際組織のWG2.1（だったと思う）が中心になって、みんなが共通に使える（つまり特定企業の持ち物でない）
アルゴリズム記述言語(algorithmic language)を作ろうということになって作られたのがALGOL 60。AlgolはALGOrithmic Languageの略。
で、さらに強力な記述力を持つものにしようと1968年を目途につくることになって、提案を募った結果、オランダのWijngaardenらのチームが
選ばれて設計を任された。それで作られたのがALGOL 68。

つまりALGOLという名前は普通のプログラミング言語の名前のように純然たる固有名詞じゃなくて
ALGOrithmic Languageという一般用語の省略形という側面をも含んでいるんだよ。

だから文法的にも言語設計哲学的にも全く異なった言語や両者以外のいくつもの言語案がALGOLの名前をもっているんだ。
例えばALGOL 68の提案に危機感を覚えた一人にHoareさんがいる。で、彼が中心になって作った代替案はALGOL Wという言語。
これは実際に処理系も作られたし、これによるプログラミングの教科書も少なくとも１冊はちゃんと出版された（もちろん英語ね）。

日本でもALGOL 60の後継案（つまり後のALGOL 68になる提案と争った候補の一つ）を提案しており、ALGOL N（NはNipponの意）と
呼ばれている。これも１冊だけその言語設計哲学・コンセプト面を扱った本が日本語で出版された。

>>52への補足

連投ごめんね。
Knuthさんの作った文書整形言語＆プログラムであるTeXの一番最初の処理系は
SAIL（確か Stanford AI Languageの略じゃなかったっけ？不確かでスマン）で書かれたが、
私の勘違いでなければ、SAILはHoareさんたちのALGOL Wから発展した言語だったはず。

WはWirthのW.
彼の方がメインだったはず。
ALGOL 68と60の後継を競った。

>>54
そのWrith は pascal の人？であればかなり納得の系譜だね

WはWirthの意だったか。
Nは島内剛一先生だったよね確か。

>>54
Algol WのWはWirthさんのWだったのか。
なるほど、それをHoareさんらと共同でまとめて対抗案として提案したという延長として、
さらにPascalをWirthさんが作ったときに
HoareさんはFloydさんのアプローチを発展させた公理的意味論を編み出して
Pascalに対して具体的に定義したわけだ。

Pascalの主目的の一つが言語の簡略化だったから、
公理的意味論も構築しやすかった。

あんなにたくさんタイプしなきゃいけないのに簡略化なの？

簡略化された結果タイプすることが増えたんじゃね

Lispも言語の元データを簡略化した結果カッコが増えたじゃないか

skiコンビネータ−めっちゃ簡素やん

>>59
教育のための言語だから

意味論と構文論を切り離して考えられない奴はこれだから

pascal は素敵な言語だと思うよ delphi も結構広まっていたと思うよ
あーたしかに end の後ろになにもかかないか、セミコロンか、コンマか、とか今でも間違えるけど‥
http://ideone.com/uVYgb
http://ideone.com/ogrDn

>>64
どう違うの？

>>66
構文論はプログラムの形式を議論する
意味論はプログラムが表現するモデルを議論する
わかりやすく言うと理論的には、構文論が扱うエラーはコンパイラだけですべてを自動検出できるが、意味論が扱うエラーは自動的にはすべてを検出できない

意味論でのエラーを構文論からは検出できない、つまりコンパイラーでは検出できない具体的な例はありますか

>>68

(define (factorial n) (* n (factorial (- n 1))))

>>69
横からでスマン
その例って静的型付き言語ならエラーにできるかな？

>>70
>>69がエラーは、factorialが一般的に何をやる計算かとか、整数が無限にあるというドメインやモデルの知識があってはじめて分かる

なので、コンパイラがエラーを出すのは間違っている
「factorial」が「wait-ever」や「make-overflow」という名前だった場合や、*や-を文字列演算子で上書きしてた場合を考えれば分かる

>>71
なるほど、その例で構文論と意味論のイメージがつかめました
サンキュー

やっぱりボードゲームはCで書くべきなのかな
common lispで型宣言つけて(safety 0) (speed 3)でマクロで包んでいくのと
どっちがいいんだろう

>>73
どんなのか知らないけど、イマドキC使うのは特殊な要件があるの？
CLじゃなくてもPythonとかrubyじゃダメなの？

ボードゲームって将棋とかのことを言ってるんだけど
そういうののaiは探索関数で一ミリ秒でも速くしたほうがいいから
PythonやRubyは遅すぎてダメなの

探索ルーチンだけアセンブラで書けばいいと思うの。
探索ルーチンは「ボードゲーム」のプログラミングのごくごく一部なの。

そういう初歩的なこともわかってないのがバレバレなの。

「アセンブラで書く」とか言ってる時点でお察し

えっ・・・

本人がお察しだったようだ

なんだ、「アセンブリ言語で書く」が正しい、という意味かw

探索ルーチンは確かにボードゲーム全体のコード量と比べたら小さいけど
その関数とそれが呼び出される関数で見たら影響は大きい
初歩的なこともわからないとか言ってる時点でただ煽りたいだけなんだろうけど

> ただ煽りたいだけなんだろうけど

このスレで「一ミリ秒でも速く」と言ってるおまえがな。

一ミリでも遠くに飛ばしたい
男の甲斐性
ﾄﾋﾟｭﾝﾄﾋﾟｭﾝ

Lispで書いてみてどうしても速度が気に入らないなら
Cなりアセンブラなりで書き直せば？

斡旋フリー？
ｴﾍﾍ、本番できる？

少しでも速くするために先攻と後攻のルーチンを別に定義する部分やループを展開した書き方をする部分は
柔軟なマクロのあるlispが有利だと思った

やねうらおが昔そんな話書いてた
http://labs.yaneu.com/20090905/

今日schemeの実装終えた
勉強になった

scheme→Cのトランスレータを作れば敵がいなくなる

敵はそこまで弱くない

チキンなので敵前逃亡

彼の敵はもっと高いところに居るんだろう。
目標高いって素晴らしいやん。

俺もこういう俺様言語作りたい。基本Schemeとのこと。プリプロセッサにかけるだけ。


209 デフォルトの名無しさん sage 2014/10/05(日) 15:35:13.47 ID:37iiGiPw
>>164

define seq(n){
　　define seq1(m,n1,n2,n3,n4){
　　　　if(m = n)
　　　　　　(n1 + n2 + n3 + n4)
　　　　else
　　　　　　seq1(m + 1,n1 + n2 + n3 + n4,n1,n2,n3)
}
　　seq1(6,3,2,1,0)
}
seq(10000)
1455650563828306671891266930369....

元発言はどのスレ？

まぁ、そこまで意欲的なものをいきなり作るのは大変だろうから、まずは
「構文がS式のPascal」みたいなものを作ってみたら？

>>93
簡単だよ。資料はここ。
http://homepage1.nifty.com/~skz/Scheme/sapphire.html

Gaucheでもリードマクロを使えば割と簡単にできると思う。

>>94
プログラミングのお題スレ Part5
http://peace.2ch.net/test/read.cgi/tech/1411227287/

>>96
サンクス、勉強してみる

>>95
いろいろやってみる。
まだ、Scheme上でSchemeインタープリター実装の勉強段階だけど

>>93
rubyの処理系のコードをいじった方がはやいと思う

>>93
Lispで普通に書いた方がよくね？
なんでわざわざ対応したエディタも無い言語にしたがるのかマジでわからん

世間一般ではS式は迫害されるらしいよ

C 風の表記が欲しいならそういう言語使えやって話になる。
Lisp に C 風の外観を与えるのは悪いわけじゃないけど、
それで Lisp らしさを捨ててしまうのなら Ruby や JavaScript と比べて勝るところは何があるっていうんだ？

自分が欲しい俺俺言語を簡単に定義できる例としてなら有用だけど、
それを仕様として固めて広く使ってくださいってことになると、
Ruby では駄目なんですか、 JavaScript で駄目な理由は何ですかってことになる。
そこらへんのポリシーがうまく説明できてない感じ。

うまく説明できてないだけにも見えるので、
何をしようとしているのかをもちっと踏み込んだ説明が欲しいな。

>>102
携帯やエミュレータ用のコンパイラを作らされたことなら何度か

>>102
意義を議論する以前に、恐らくはまだ作った本人でさえまだほとんど使ってないんじゃないか。
良くも悪くもまだ単なるオモチャだと思う。普通に考えればデバッグは複雑になるはずだけどどうやってるの、とか気になる、

>>102
あほか

>>104
仕様がこなれてないのは使い込み不足だろうからこれからに期待ってことでいいけど、理念については説明が下手なのと視野狭窄だと思う。

Lispを学ぼうとする人にとっつきやすい文法を提供できるというのはよいと思うよ。
でも、そこには暗黙の想定があって、「Lispを学ぼうとしている」という大前提があるわけ。
そういう想定がなくて、言語に選択肢がある状況で「とっつきやすい (しかし、少し制限された) Lisp から始めて最終的には Lisp を使えるようになりましょう」と
「Ruby を学びましょう」ならあえて前者を選ぶかは疑問。
Lispを使う動機がない人にとってはアピールにならない。

書いてる人にとってはLispを使うのがあまりにも当然の大前提という感じになっちゃってて説明するまでもないと無意識に思っちゃったのかな。

>>106
メタなものに興味があってLispを覗いてみたらカッコだらけで、
「ゲッ！やめた、おれRubyにする」ってヤツもいるんじゃないの。
あと、Lisperに得意そうにへんちくりんなマクロを見せつけられて、
「だめだわ、オレ、Rubyがいい」なんてのもいそうだけど。

カッコなしで同相性(データとプログラムの形が同じ)を維持するのも難しいと思う

>>108
確かにその通りなんだが、Lispの売りってそれだけか？

>>109
というか、「同相性があればそれはLispだ」と強弁してもいいかと

>>107
そうだよ。 そういう色んな状況が想定できるんだよ。
で、目線が違うと「それはメリットじゃないよね」っていう疑問になっちゃうこともあるから、
立場をきちんと表明しなきゃね、前提を共有できるような記述が欲しいねっていうことを言いたいわけ。

>>111
前提は確定的なものではないだろう。人間の考えは変化する。
将来、メタなものに興味を持つ可能性のあるものも含めて広い間口を持たせるということでいいのではないかね。

>>112
いいよ。 悪いなんて思ってないよ。
だけど、その場合には別目線で見ている人には意義が伝わらないというデメリットが残るってだけ。
俺自身はある程度さっすることは出来てるけど、もやっとした気持が残るくらいには伝わってない。
伝わらなくてもいいという決断もひとつの決断だし、それはそれでもいい。
でも、たぶんだけど、これはそういう決断の結果じゃなくて言葉足らずなんじゃないかなという風に見えたんだよ。

俺低学歴なんだけど
Scheme使ってもいいかな？

いいよ
どんどんいけ

おｋ
漏れ逝ッキマース

きてぇ



　　　　　　　　　　　　　　　　　　　　　　　　　 ,. --ヾ- ,,.. ._
　　　　　　　　　　　　　　　　　　　　　　　　.´ｽ;/;::;:::::::::::::::::ヽ
　　　　　　　　　　　　　　　　　　　　　　　　　ﾚ|. |A:::,::::,::::::::::::ヽ、
　　　　　　　　　　　　　　　　　　　　　　　　　r'´　ﾚ|::/::::::::::::::ﾞiﾞiヽ
　　　　　　　　　　　　　　　　　　　　　は　　└.、″|r.y::::::::::::::| ﾞ!|
　　　　　　　　　　　　　　　　　　　　　あ　　 ｀┘　,.-"::::::::::::::::::/W　
　　　　　　　　　　　　　　　　　　　　　　　　　 ｀￣| /ﾙ::::::::;／ﾚ
　　　　　　　　　　　は　　　　　　　　　　　　　/￣｀ﾞ　　　Ｙ
　　　　　　　　　　　あ　　　　　　　,.- 、　　　 !　　 r　 , 、|
　　　　　　　　　　　　　 ／￣ヽ　/ 　　ヽ　　　ﾞ!　 .|　ノ | .|
　　　　　　　　　　　　／　　　　＼　.i.　　ヽ 　 |ﾞi　 i　　' ./　　　
　　　　　　　　　　 ／　　 入.　　　＼ﾞi　 　＼/ |　ﾞi 　 /|　　　 は
　　　　　　　　　／　　,.-'　 ∧. 　 　 ＼　　/　　| ｀ |　/ |　　　あ
　　n、　　　 .／　 ,._'´｀-.、/　入 　　　 ｀-"　　ﾞi　 .|/"´
　 ミ　｀ - ノ　　／　｀' .、 ,　/ 　 ＼　　　　　　、|　 |
　　^ー-、 , ／　　　　　ヽ_.」'　　　　＼　　　　,　|　.|
　　　　　.ー´　　　　　　　　　　　　　　｀ 、__.ノ_r'"　ヽ
　　　　　　　　　　　　　　　　　　　　　　　　　ゝ!_'uu_/

>>113
ご忠告に感謝。さようなら。

マクロもS式も結局は同図像性に帰結するし

LISPの谷のうたにあるもの
「構文木を書き下し　Ｓ式と共に生きよう
マクロと共に展開器を越え　括弧と共に抽象を謳おう」
どんなに強力な構文を持っても、
たくさんのかわいそうな構文解析器を操っても、
Ｓ式から離れては生きられないのよ。

糖衣構文は人類の夢なのに

>>121
そんなものに頼ってるから言語が太るんじゃねぇの？

SCHEMEは機能を積み重ねるのではなく、ユーザがしたいことを邪魔しないという目標がある。
言語が構文糖を持つんじゃなくて、構文糖が欲しいと思ったときにそれが出来るようになってるのがSCHEME的な解決方法で、
つまり、処理系としてはリーダをカスタマイズする方法を用意するべき。
もちろん誰もが納得できるような便利な構文糖は仕様に入れることを検討してもいいし、
誰もが納得とは言わなくても十分に便利なものは処理系の裁量で使えるようにすればいい。

それぞれのプロジェクトに合わせて勝手にマクロ書いてねってことか

糖衣構文はむしろ言語が不必要に太るのを防ぐものだが？
見た目だけのためにコア言語を拡張しないで済むのが糖衣構文なんだから。

マクロと特殊構文って違うものなの？

while(1)とfor(;;)くらいの違いはあるかも

マクロの限界を超えたのが構文

全部lambdaで実装できるからといって、全部マクロでやってるわけじゃないのね

Lisp 全般ではどうだか知らないけど Scheme の場合は特殊構文といういう言葉はない。
実装上は区別があるから無いわけではないんだけど、
仕様上は機能が特殊構文であるべきかマクロであるべきか明確な記述はなくて、
全部一緒くたに「構文 (syntax)」となってる。
do や let みたいにマクロで実装可能なものであっても処理系が特殊構文として持ってもいい。
let を特殊構文にして lambda をマクロで提供したって仕様には適合する。

lambdaで実装できるならマクロでなくて関数じゃないか。

基本的にマクロや特殊形式は関数にはできないもの（ifとか）。
>>130 が説明しているように、言語組込みの特殊形式にするか、
あらかじめ定義されているマクロにするかは、どっちでも良いことも多い。
（ifとcondの、どっちが組込みでどっちがマクロかは、使う側からすればどちらでも良い）

どうしても組込みでないと困るのはdefmacroとかw

defmacro って伝統的マクロのことかな。
explicit renaming などを組込で用意してそれを使って伝統的マクロの API を作ることは出来るので、
defmacro が組込でないといけないということもないんじゃないの。

SRFI49のI式やSRFI110のT式を使えば、
Lisp、S式を全く知らない人に知らず知らずのうちに使わせることが可能・・・？

それは微妙かも。 要はS式の風味を消しきれてないんだよ。
S式に慣れたベテランにとっては変換を間に挟むのは余計だし、
初心者にとってもそれほどやさしくない気がする。
S式を完全に置き換えられるように設計されてるせいで、
言語としては不自然さがある。
S式をわかった上で少し読みやすい (書きやすくはない) 記法って感じじゃないかなぁ。

一方で、>>96 はそういうこと考えないで言語として自然になることを目指してるみたい。
それと引き換えにちょっと制限が出来てしまってるけど、
S式を意識しないで済むのでT式やI式よりは初心者向けかな。

どこかで妥協は必要だと思う。

そんでもってT式は妥協点がまずいと思う。

I式はS式の表現力そのままでちょっと括弧を削減できますって感じなわけで
見かけはあまり変わらないけどS式通りの表現力を持つことに寄った妥協点。
sapphaireはC風の見かけに寄った妥協点。

T式は両方取りで無茶しすぎ。

C++がlispのマクロを取り入れるって話がある気がするけどどうなんだろ

#define と lisp が入り乱れる悪夢しか見えないのだが…

これ以上に魔界言語化させる気か

>>136
なにその鼻から悪魔
むしろLisp界隈がC++が培ったコンパイラ最適化技術を取り込む方がよくね？

そんな明らかに地獄を見るC++なんかより、静的型と必要呼びを取り入れよう。

ネット上の記事でREPL開発が便利という言葉が結構出てきますが
その内容は大抵併記されてないしどういうものかあんまりわかってないんですけど
要はREPLを内部データの完全読み書き可能なデバッグコンソールとして使うっていうだけのことであってますか？

>>141
REPL が無いと関数を書いて確認するまでの負荷が高過ぎと感じるね。
大きな関数を書いて苦労してデバッグするより、小さな関数を沢山書いて組み合わせる方が自分は好きだ。そういうスタイルで開発するとき、REPL は必須だと思う。

REPL は思いつきを次々とチェックしていくのに便利よ

lispに限らずpythonとかrubyとかforthとかjavascriptにもあるだろ

REPL とそうでないときの動作が微妙に違う言語が最悪。

ROOTのことかー！

今日自分用repl作り終わった
勉強になったな

今日自分用repl作り終わった
勉強になったな

>>148
そういう日記帳みたいなことを書くんじゃなくて、どんな学びがあったのか概要だけでも書いて欲しい。

うーん
チンコは朝が元気いい！
とかかなあ

任意のS式をC言語の関数に変換できれば、高速のlisp実行系ができると思ってやってみたら吹いた

最初にできたcommon lisp処理系がそのやり方だったんじゃ

うーん
The Little Lisperを終えて
適用順Ｙコンビネータは感動した
第２版の
The Little Schemerも初版とちゃうあたりからやるかとやっていたら
8 lambda the ultimete
で、いきなりわけわからんものが出てきた。その後を読んで環境を保持したclosureの伏線だと分かったが
テキストではふれてないが、いわゆる
末尾再帰の方法の１つでもあるなと思った
末尾再帰させる？どうなるの？
わからないままきていたが分かって勉強になった
試しにフィボナッチを計算させると
もう非while記述と同じように速い！
（あたりまえだけど）
感動！
Lisp/Schemeっておもしろいね

続き
ただ、引数に値を蓄積していく方法ではなく、引数関数の拡張テーブルに値を渡していく方法だった。
主眼は末尾再帰ではなくclosure・閉包
にあるからだろう

(define foo
(lambda (l func)
(if (null? l) (func 0)
(foo (cdr l)
(lambda (x)
(func (+ x 1)))))))

> (foo '( a b c d e f g) + )
> 7

とこんな具合の再帰が出ていた。
（テキストではmultiremberEco)

フィボナッチとフィボノッチ

>>151
何がどう吹いたの

>>154
継続渡しって訳か

>>157
まだ継続は勉強してないから俺には継続渡しかどうかわからない
もうすぐ継続やるらしいけど
the little schemer

GCは失敗スレについてここの人はどう思う？(今なんか荒らされてるけど)
おれは失敗だと思う
今でこそ普通に動かす環境が存在するけど富豪的環境を想定しすぎていた
あといずれシステムやランタイムがGCでプログラムを勝手に止めるのが我慢ならない
GCの無いLISP作れると思いますか

> あといずれシステムやランタイムがGCでプログラムを勝手に止めるのが我慢ならない
世代別GCのアルゴリズムではそんなに長い時間止まらないのでは
> GCの無いLISP作れると思いますか
作れるんじゃないですか
今でもGCをオンオフして好きなように出きるはず

そもそもおまえらが成功とか失敗を決めてなんか良いことあるの？
GCの無いLISPはLinear Lispでググれよ

良いことはあるでしょ
それを使っていいのかの判断基準にできる
GCを動かさないように「気を付けて」組むことはできるけど
そんなものは最初から無いに越したことないから
Linear Lispは平たく言えば参照カウンタ方式ってことね
参考になったよ

広く採用されて使われてるんだから成功なんじゃないの
あとは問題に対して使うか使わないかという選択があるだけでは

参照カウンタってGCの一種やろ？

いや、逆に広く採用されてしまったのは失敗だよ
リソース確保しまくってまともに開放されずにシステムを糞重くする原因だし
メモリ管理はこうせなあかん的な思想の頑固一徹に
ちまちま組ませてた方が良質なソフトを期待できたのでは
ちゃんとメモリ管理してれば1GBもあってまだ足りないなんて状況にはならなかったと思うよ

>参照カウンタってGCの一種やろ？
ちゃんと理解できてないからこういう人も出てくる

なんだ病人か

糞を作る糞はたとえGCがなくたって糞を作ると思うけど
まあそんなの確かめようがないんで、あとはGCスレでやって

念のために書いとくと
参照カウンタはプログラマが自分で開放タイミングを制御できるからGCではない
GCってのは自分で参照切ったりして手放したつもりでも
GC側の都合でそれがいつ開放されるかは判らず
プログラムがGC発動によって強制停止されるか判らない中
戦々恐々しながら使うやつのことね

解放タイミングが自明なら参照カウンタ自体使う必要がないんですがね。
お前参照カウンタを使ったこと無いだろ。
ていうかLISPのコードを書いたこともないだろ。

レッテル貼りレスばかりしてて虚しくないかね
参照カウンタの理解も足りてないし
GCと共存するしかないLISPスレだとこれが限界なのか

GCは参照カウント式とトレーシング式に大別される
参照カウントもGCだ

GCの定義が独自すぎて話が通じないぞ・・・

もしかして用語が気に入らないの？
用語の定義なんて今更ここて議論したくないから
参照カウンタとLISPとかで使う停止を伴なうGCの区別だけでいいよ

ここで話すこともあまりないんだけど
あっちがなぜか荒らされ始めてるっぽんで避難というか
まともっぽい話ができぞうなスレにちょっとお邪魔してもいいかなと
付き合ってくれてありがとね

GCないとCでfree忘れるだけで大惨事だし

解放し忘れはまだマシな方
誤って解放済みの領域にアクセスしてセキュリティ上の問題が発生するなどということが現実に起きてる以上
その危険を避けられるだけで一定の価値があると思う

参照カウンタはGCテクニックの一つだぞ、古い物で最も有名なのはSmalltalkの実装で使われてるじゃねぇか
まさかと思うがC++のshared_ptrの事しか知らないとか言うんじゃないだろうな？>>170

> あっちがなぜか荒らされ始めてるっぽんで避難というか
> まともっぽい話ができぞうなスレにちょっとお邪魔してもいいかなと

荒らされ方では互角だと思うけどなｗ
サンプルはお前

人の意見は聞かず自分の言いたいこと言うだけ言って満足して去っていったな

「○○が嫌なら○○のないlispを作ればいいじゃん」　と断言できるのがlispのよいところ

○○にS式を入れたらどうなんの

>>96みたいなことになるんじゃね？

家に怖いエイリアンがきてS式が出てくるまで無限にmacro-expandされる

http://route477.net/d/?date=20071112
>「コンピュータプログラムの世界において M式 (meta-expressions) は、 Lisp言語の一部として、S式の人間が読むことの出来る
>形態となることを目的に考えられた。 M式はLispの初期の論文において理論的な言語として使われていたが、実際に実装されることはなかった。 」
>
>S式は人間が読むもんじゃないのかよｗとツッコミたくなりますね。

>(M式のほうが)だいぶ「普通」なんだけど、LispプログラマはすぐにS式に慣れてしまったので M式は普及しなかったみたいです。
>S式はプログラムとデータが同じ構造をしている(ので、マクロが使いやすい)けど、M式はそうじゃないですからね。

>>184
文とメタ文が同じ記号と構造を持ってると読みにくいという意味だと思っていたが、もしかしてS式も読みにくいモノだったの？

参照カウンタがGCではないという解釈は非常識だけど、
解放のタイミングがコンパイル時に確定できる場合とそうでない場合を自動で検出して最適化するとか、
言語に制限を加えて常に確定できるようにするとかいった方向でなら面白いことが出来そうな気もする。

そもそも、プログラマには、メモリ回りをいじらせない方がいいという結論だったはずだが…

可能な限り自動化するに越したことはない。
でも、トレードオフのある話だから一概に言えないんじゃない？
結論ってどこの結論？

オレオレ

GCは失敗という意見を持ってる人は
GCをよく理解してないように見えるんだけど気のせいかな

いなくなった悪魔を再召喚する儀式はやめよう（提案）

lispに失敗はない
○○を失敗したなら、○○を失敗しないlispを作ればいいのだから

○○にlispを入れたらどうなんの

>>193
schemeになる

>>193-194
ﾜﾗﾀ

>>190
だよなぁ。
メリットもデメリットもあって状況によって使いわけるという当たり前の判断が出来てない。

そもそもGCが動くタイミングさえ熟知してれば古来からのメモリ管理法とほぼ同等の管理もできるんだよなあ・・

(GCってガベージコレクターなんだな、ググってわかった)

lispでもメモリを自分で管理するのが一番だね。あんまり情報がないから自分で調べる必要があるけど。
個人的には任意精度の数値が扱える機能がむしろオプションだったら良かったと思う。そしたらCっぽい計算が楽なのに。

コンスプールってどれくらい効果的なんだろう

>>190
最近のスマホはメモリ空間が狭いのにアプリがたくさん動きかつアプリの生存期間が長くなってしまっている‥
メモリコンパクションも、そもそもOSのメモリ管理すらも、いうほどにはあまりうまくいっていないなという感想を持つ人間が多くなったんじゃないかな

>>186
こちらの人はそう考えるのか‥参照カウンタは循環参照を扱えないからね‥

昨日の荒らし君が再召喚されたの？

>>202
参照カウンタとMarkSweepを世代別にすることで併用するとか最近のGC事情はイロイロあるのだが？

>>203
まあ参照するからGCされないんだろうねえー

>>204
Mark&Sweep と世代別管理が併用されることがあっても、参照カウンタが世代別管理と併用というのはあまり考えられないのでは‥
循環参照が発生した！とランタイムで検出することは可能なの？

そうなの？

循環参照の検出はそんなに難しくない。 定番の練習問題だろ。
だけど、実行コストはそれなりに大きいから走査のたびにやるのは性能的に厳しいと思う。
何度かに一度だけとかいった形にする必要があるんで、それを世代ごとに区分するのはいいアイデアな気がする。

>>207
＞実行コストはそれなりに大きい
そう、つまりMark&Sweep そのものだよね
となると、参照カウンタの世界と、Mark&Sweep とかコピーGC とかの世界とは相容れないとおもっているんですが‥

incremental(real time)GC採用しているschemeなりlispの処理系ある?

BoehmGCを使っていたらなんでもそうなるかと‥

>>206
参照カウンタが通常世代まで（edenは別）のGCで使って、Old　Space巻き込むFullGCの時にはMark & Sweepって実装は有るよ。
Mark&Sweepなら参照カウンタで循環したオブジェクトも除去される

って言葉で書くと簡単なのに実際に世代別かつ複数検出使うと効率的なGCを行おうとすると死ねる、つか一回死んだ(タグ付きメモリのハード欲しい!!!)、JavaとかSqueak作ってる連中はすげぇと思う。

君たちには明示的にGCすると良いことがあるかも知れないでしょうが、君たちの指示でプログラミングする人達にとっては百害あって一利なしですよ

>>211
なんだかよくわかりませんが、なんだか面白そうだ‥
どこぞのスレでは GC ネガキャンをやっているようですが、GC のためにハードウェアからの支援があると、なにか幸せが待っていそうですね‥

この機会にlispマシンを。。。

>>213
タグ付きメモリとかLispマシンだけじゃ無くて結構ハードウェア実装あるからACMの論文以外にもGC関係追いかけてみると良いかもね
;;;実売したプロセッサだとLispMachine以外無いのに(主観)
;;;論文やベンチャー企業のJavaVMの実装には出てきたりする。

http://www.shuwasystem.co.jp/products/7980html/2562.html
>ガベージコレクションのアルゴリズムと実装
>本書は絶版となりました。

・ﾟ・(つД｀)・ﾟ・

懐かしい。
大学の課題でガベコレ実装しなきゃならなくて
日本語の本で探して見つけたほとんど唯一の (実際、私が見つけられた唯一の) 本だった

>>216
良本だから書店に在庫があるうちに購入するといいよ

>>217
見付からないのは当然。 実際にこれ一冊しか出版されたことがないから。
言語処理系の本とかにGCの話題が含まれることはもちろんあるけど、
GCを体系的にまとめるってことを誰もしなかったんだなー。

>>216
達人出版会でPDF版が買えるぞ

lisp の実装本も和書では2冊だったか‥いや出たのが奇跡か？

大学の演習でしょっちゅうやらされるイメージ

lispのわかりやすい実装はネットにちょくちょくあるからな

lispを使うような大学で講義を受けてみたかった

哲学や記号処理系の人工知能の講義で使うプログラミング言語はlispかprologの二択だと思ってたが、最近はhaskellも使われているらしい

どの大学でもLisp教えてるだろ
教授のオナニーがメインだが

単位落とされたバカはいつまで頑張るのかなw

やめだやめだSchemeなんてやめだ
現実に役に立たない言語なんて何の意味もない
残念だがここからはCommon Lispだ

今三年だけど学部の講義・実験で主に使うのはCとJava
紹介程度にHaskellの話はあった

>>228
ん？継続で断念？

>>228
おちつけ、実用的なlispなんてない

Clojureとか

お前らの実用って何だよ。

xyzzyを好きに改造できること

LISP処理系が作れること

実用できてるじゃん。

30分でプロトタイプを作るなら、圧倒的にlisp
一方、製品版の実装は、いまだにCがメインです

そのまま製品にすりゃいいじゃん。

>>221
遅いけどこれ知りたい

多分1冊はCプログラムブック3のことかな
実装つっても所詮インタプリタレベルだし今読んでも参考にならないよ

3impがあれば必要なことは大体わかるよ。
日本語訳があれば実装してみる人もだいぶん増える気がする。

どんな実装にもいえるけど
ライブラリが無いと残念処理系にしかならないよね
他所様のライブラリを半端に使う手段をくっ付けて完成

実用的な処理系は既存の物使う方が良いし
作ることが目的だからそういうのはどうでもいいかな

実用を考えるなら、Schemeの場合は後付けで色々拡張することが前提の仕様だから、仕様に完全準拠するだけではまだスタート地点って感じだよな。
未定義が多いのは単に議論が続いているってのもあるけど、処理系実装の裁量範囲を広くとるために意図的にやってる箇所もある。
多様な実装が出現することを期待してのことだと思う。
その中でやっぱりこうするべきだっていうのがわかることがあれば将来の仕様に反映されるかもしれない。
だからまぁ色々やってみようぜっていう感じ。

だけどschemeが細部をちまちま議論しているうちに、世の中はどんどん先に行ってないか？
例えばHaskellは圏論を武器に新しい概念が沢山出てきている。テキストもある。言語仕様もちゃんと更新していってる。なんつーか、すごく活発なんだよ。
scheme が目指す言語仕様は本当に素晴らしいのかも知れないけど、動きが遅すぎる…

Haskell はピュアで制限きついから、従来の表現度を得るために新しい道具が必要とされただけ

他で新しい道具が出来たならパクればいいじゃない（ゲス顔）

俺の女、サイトウにパクられた
おのれ、ｻｲﾄｳ！

むしろどんどんパクって欲しい。閉じこもってるよりはマシ。

>>245
機能を追加するのではなく邪魔なものは何かを検討して排除するのがSchemeの仕様の方針と書いてあるだろ。
だからといって処理系の実装に機能を追加するなとかライブラリは不要とか言ってるわけじゃなくて、
むしろ積極的に色々やるために仕様で縛りを付けないというスタンスだよ。
それでもやっぱり統一しとかなきゃならない基盤だと皆が合意した部分だけが仕様になってる。

決まってない部分はお前も含めた皆が自由にしていいところ。
仕様に不足があるならお前が足していいところだ。

「○○が邪魔」　⇒　「○○のないschemeを作ればいいじゃん」
「○○が欲しい」　⇒　「○○入れればいいじゃん」

やればできるけどやらないのはやれないのと同じだと思うの

実用性考えるととたんに継続の存在が邪魔に思えてくる
OSのフックやイベントとかコールバックとして渡す場合どうすんの

structureをコピーして、その一部のスロットを更新したstructureを返す関数を作りたいんだけど
setfでアップデートするところでエラーが出るんだ...
誰か助けて

こんな感じに使いたい。
(update-structure player :name "hoge")
(update-structure pos :x 3)

; 以下はコード
(defun update-struct (structure key value)
(let* ((head (type-of structure))
(copy-fn (symbol-function (symb "COPY-" head)))
(copy (funcall copy-fn structure))
(update-fn (symbol-function (symb head "-" key)))
)
; コピーしたstructureをアップデート
(setf (funcall update-fn copy)
value)
copy))

(setq a (make-pos :x 0 :y 0))
(update-struct a :x 3)

>>254
どうしてこんなことしてるのかさっぱり分からないコードだ
#'(setf function)は規格に存在しないよ

構造体にslot-valueが使えるのも処理系の拡張だけど

(defun update-struct (struct key value)
(setf (slot-value struct key) value)
struct)

(update-struct a 'x 3)
--> #S(POS :X 3 :Y 0)


何がしたいのか説明がないとわからん
slot-valueは使えないって前提?

slot-value は盲点だったは、ありがとう。
環境の状態を、関数の引数に渡していく方法でゲームを作ってて、
毎回コピーしてから値の更新するのが面倒だったんだよね

大体こんな感じ↓
(defun battle (player enemy)
(battle (move player 1 2)
(attack player enemy)))
(defun attack (a b)
(update-struct b
:hp (- (player-hp b)
(player-attack a))))
(defun move (s x y)
(let ((pos-x (pos-x (player-pos s)))
(pos-y (pos-y (player-pos s))))
(update-struct s
:pos (make-pos :x (+ pos-x x)
:y (+ pos-y y)))))

; update-struct を使用しない場合
(defun attack (a b)
(let ((copy-b (copy-player b)))
(setf (player-hp b)
(- (player-hp b)
(player-attack a)))))

>>256
update-structみたいなのは
・予めスロットの名前しか分かってない上存在しないスロットにもアクセスする可能性はある
・実行時にならないとどんな構造体が来るか分からない
こんな場合に必要になるものだと思うよ
この条件だと、規格の範囲では構造体じゃなくてクラスで作るものになる
attackのように決め打ちで(- (player-hp b) (player-attack a))を参照してるなら、使用しない例のように#'(setf player-hp)で良いような気がするんだけど
どうしてもメタプログラミングしたいんならマクロでコード生成とか
単に書くのが面倒だからってことだけど
(defattack player (a b) ...)
(defbattle player (a b) ...)
(defmove enemy (a b) ...)

>>252
ちがうだろ
やればできる->子供が作れる
やれるけどやらない->彼女がいる
やれない->彼女は居ない

>>257

色々考えた結果
(setf player-hp)で更新するのが無難っぽいですね。


プレイヤーがスタミナをもっていて、
攻撃するときに自分のスタミナを減らして、相手のHPを減らすような場合とかもあるし

2つ以上のユニットを同時に更新とかが入る可能性があるな

>>252
そうかんがえるのが健康的だな

やればできるなんてのは、大概は
性格的にできない、継続できないアホの言い訳


>>258
ｵﾏｴは、馬鹿すぎる

見た目が同じものは本質的に同じ
従って>>252>>258>>260は同一人物

ということは>>251と>>261は同一人物か

>>261
うわ、精神病！！
レスするな気持ち悪い

計算メインの時ってどうしてる？S式だと見通し悪いだろ？
中置マクロとかなのかな。

見通し悪いと思わない。 それが真の Lisper

マジか。Lisperになりたいけど難しそうだな。

見通し悪いという意見も結構あるよ
でも中置マクロ定義すれば解決する問題でも無いみたい

逆ポーランド記法が一番

見通し悪いって具体的にどういう式がさ？

(define (f x)
(+ (* 3 (expt x 2)) (* 2 x) 1))

def f(x) :
3 * expt(x, 2) + 2 * x + 1

やっぱり中置記法必要なんじゃないかな（うらぎり）
インデント揃えたらもっと見やすいでしょとも思うが

あんまり気になったことがないけどなぁ

(define (f x)
(+ (* 3 (expt x 2))
(* 2 x)
1))

これならなんとか

def f(x):
return ((x**2)*3)+(x*2+1)

やっぱり数式は余計な空白が邪魔になる

>>264
見通しが悪いと感じる理由は、小学生のときから中置だったから
逆に、普通の式は、優先順位が複雑なときに見通しが悪くなる

なので、普段からS式で計算を行なえば問題ない
問題ない

emacsを電卓代わりに使ってると、S式で書き始めるんだけど、
途中いつの間にか中置になっててあれ？となる事がわりとある。

>>274
何で２回言ったし。最小二乗とか実際書いてみると不満になるときあってさ。

むしろ電卓でも逆ポーランド記法。

負号が式中に出てくるとイラっとするかな

(+ n (f x) (g x) (- x))

こういうときは便利
(* a b c d)

>>279
電卓代わりに使うときはそれ便利だよね。
でも、不定個数引数に適用したい場合はapplyでなくreduceを使わざるを得ないし、
最適化まで含めて考えると

(declaim (ftype (function (integer integer) integer) integer-binary-add))
(defun integer-binary-add (x y)
(declare (type integer x y) (optimize (safety 0) (speed 0) (debug 0)))
(the integer (+ x y)) )

みたいなのを型別に用意しなきゃ色々気持ち悪いので、既存の+, *みたいなのとは別に
自動coerceありの2項演算子と自動coerceなしの2項演算子を網羅的に規格で用意してほしいな、とは思う。
で、fixnum用の2項演算子の結果が溢れたらどうする？とかもoptimizeのsafetyとかで間接的に調整じゃなくて、
規格で明確化してほしい。

で、その場合、+, * は自動coerceありの2項演算子の方が良いと思うんだ。‘

>>280
最適化というのは処理系に特化するということで，規格で縛るのは矛盾してると思うけど．
それと上で書いてる程度のことは処理系のコード読めばわかるがコンパイラがやってるので人が直に書く必要はないと思う．
applyも同様だけど渡す引数の数による．処理系依存だが条件を満す処理系を使えば良いだけで規格で横並びにする必要性は感じないな．

そういう「処理系のソース読まなきゃわからない」のは馬鹿馬鹿しいの。
アプリケーションプログラマなら特定の処理系上で動作させることを想定してもいいけど
ライブラリプログラマとしては処理系非依存で書けるところは処理系非依存で書きたい。
そういうときの武器が規格なんだよ。

処理系非依存で書きたいなんて当たり前のことでそ
最適化部分を規格として含むことが妥当かどうかの話してるんじゃないの

それはものによるな。
どういうふうに最適化されるべきか、という話であれば規格はあまり関係ない。
しいて言えばCLにTCO義務化が入っていなかったのが残念ということくらい。

が、挙動そのものが最適化パラメータ次第で変わることがあり、それが処理系依存ってのはおかしいと思う。
fixnum同士の計算が最適化のパラメータ次第で変わることがある、なんてのは
そもそも最適化の文脈で語られるべきことじゃないと思うんだ。
だから、そういう部分は規格で明確化してほしいという話。

何十年も前の規格なのになあ
なんでそのとき参加しなかったの

というか、

　嫌　な　ら　作　り　直　し　て　い　い　の　よ

未定義であると明確に規格化されたらどうよ。

チンコいじりながら読んてます

下品なのはやめろ

マンコ舐めながら書いてます

今更だけどtaolispが気になってる

そうか。

(define make-counter
(let ((count 0))
(lambda () (set! count (+ count 1)) count))

という手続きで、
(make-counter)を実行するたびに数がカウント出来るのはなぜでしょう？毎回letが評価されてcountは0にならないのでしょうか。

letは無名関数の適用の構文糖衣なんだよ
(let((count 0))〜) = ((lambda(count)〜) 0)
わかるね？

変数は箱だというが，letで作られる変数はletが実行されるたび新しく作られて，
countという名前のラベルが貼られる．letから外れるとcountというラベルは剥がされ，
別の箱に再利用されるが，箱は使ってる限り奪われない．
箱が復数作られ，それぞれ勝手に中身を入れ替えることも起こる．

有限スコープ無限エクステントの理解ってそういうことでいいんだよな？

その define で make-counter として定義されるのは、

(let ((count 0)) (lambda () (set! count (+ count 1)) count)) という式を
評価した結果の値だ、って所まではOK？

んで、その let 式の評価は、その define の時の 1 回だけしか起きない...
ということがわかってないようだから、OKでもなさそうだがとにかく次へ行く。

count に 0 を束縛した状態で、
(lambda () (set! count (+ count 1)) count) を評価したものが make-counter になるわけだけど、
その lambda を評価すると「count を束縛した状態」というものを抱え込んだもの（閉包）に
なって、それを毎回実行するので、カウントが増えていくわけ。

let 式の評価は、その define の時の 1 回だけしか起きない... ってのはlisp全部の仕様でしょうか
いまさらながら、ちょっと怖い

sicp読もう（ゲス顔）
と言いたいところだけど、まあクロージャ、環境モデルなどの語句でググれば大体わかる

そのコードで肝なのはletで包んだlambdaである点ね
lambdaってのは外側の環境を含んだ関数を返すの
この環境というのは大雑把にいえば、レキシカルスコープ上でどんな変数が参照できてどういう束縛なのかの情報みたいなものね
だから(make-counter)を評価したらletで作られた環境付きの関数が返ってくる

(define make-counter2 (lambda () (let ((count 0)) (set! count (+ count 1)) count)))として

(define counter1 (make-counter))
(define counter2 (make-counter2))

としてcounter1とcounter2の挙動を比較してみたり、二つの環境モデルを実際に図で書いてみたりすると理解できる、かも

他の言語でもそうだよ

let(v e)が(lambda(v) (...) e)だというのは知識としては知っているのですが、それがletが1回しか評価されないというのがどう関係するのかよく分からないです

>>296
>んで、その let 式の評価は、その define の時の 1 回だけしか起きない...
ということがわかってないようだから、OKでもなさそうだがとにかく次へ行く。

そうですそこが分からないです・・・

(define (make-counter)
(let ((count 0))
(lambda () (set! count (+ count 1)) count))

こうでもしないと思ってるような動きはしないような...

あ、いつもCommon Lispばっか書くから間違えてた
(define make-counter2 (lambda () (let ((count 0)) (set! count (+ count 1)) count)))

で、
(make-counter)
(make-counter2)

の挙動を比較してみたらってことですね、ごめん

ということは、関数の中のlet式の変数の参照はガーベッジコレクトされないってことか…

letの中で定義された関数はずっと定義された時のままletの中にいるんだよ

>>298の表現も間違ってるな
> (make-counter)を評価したら
は
> make-counterはletで作られた環境付きの関数に束縛されてる
と読み替えてね

>>303
まともな処理系ならクロージャ自身の束縛がなくなった時点でまとめてGCされると思う

Schemeでしょ。順番に説明するから。

まず、
(define (f x y) (+ x y)) みたいな記法は簡便だから多用されるけど、実は、
(define f (lambda (x y) (+ x y))) の略記法だという点に注意。

で、
(define ver expr) みたいに書くと、exprを評価した値をverの値にする、と。

上のような普通の関数定義は、下の略してない記法を見れば分かるけど、
一番上に剥き出しで lambda があるわけだ。

んで、近代以降のLisp（Common LispとかScheme）は、lambda を評価すると、
手続きだけじゃなくて、その時の環境（変数名→値、という束縛の集まり）も
抱え込んだ「閉包」というものになる。

つまり、letの中にあるlambdaは、そのletによる束縛ごと、手続きになるわけ。
（let over lambdaというそのものズバリのタイトルの本があるが、まだ今読むのは
難しすぎると思う）。

(define foo (let ((x 0)) (cons (lambda () (set! x (+ x 1)) x)
　　(lambda () (set! x (- x 1)) x) )))
foo
gosh> (car foo)
#<closure foo>
gosh> (cdr foo)
#<closure foo>
これで
((car foo)) とか ((cdr foo)) とかを評価して観察してみる

処理が走るタイミングがわからないなら
カウンター関数とかじゃなくてdisplayとかもっと初心者にわかりやすいやつ使ったらいいのに

(define robot
　(let ((s 'jiro))
　　(lambda (c)
　　　(cond ((eq? c 'fight) (set! s 'kikaider))
　　　　　　((eq? c 'normal) (set! s 'jiro))
　　　　　　((eq? c 'state) (display s))))))

(define robot
((lambda(s)
(lambda (c)
(cond ((eq? c 'fight) (set! s 'kikaider))
((eq? c 'normal) (set! s 'jiro))
((eq? c 'state) (display s)))))
'jiro))

これと等価で、最初のlambdaがsをもつ環境を作り、2番目のlambdaはクロージャとして
その環境を保持している。

クロージャの「環境を保持する」とはそういうことだったんですね
皆さんありがとうございます、なんとなく使い方が分かりました

(make-counter)、lisp(sbcl)で書いてみたんだが、こんなんでええの？

(setf (symbol-function 'counter)
(let ((count 0))
(lambda () (incf count))))

sbcl には fset が無いみたいなのでマクロ？を使ってみたのがこれ↓

(defmacro fset (sym clj)
`(setf (symbol-function ',sym) ,clj))

(fset counter
(let ((count 0))
(lambda () (incf count))))

lisp は初めてなんで、よーワカらん…

counterの定義はdefun使えばいいのに
(defun counter () (let ((count 0)) (lambda () (incf count))))
counterが返すクロージャをfset使うのは便利だけど
(fset 'f (counter))
(f) => 1
(f) => 2

defunをどう読む?
デフン?

デファン

>>312
なるほど、どうもありがとう
ところでカウンタの値をリセットしたり、インクリメントさせずに
クロージャ内部のcountの値を取ってくるにはどうしたらいいだろう？

(f) => 2
(reset-counter 'f)
(f) => 1

(f) => 2
(get-count 'f) => 2
(f) => 3

一例としては、メッセージパッシング

(defun counter ()
(let ((c 0))
(lambda (&optional message)
(ecase message
((nil) (incf c))
(:reset (setf c 0))
(:get c)))))

(setf (symbol-function 'f) (counter))

(f)
(f :reset)
(f :get)

>>316
�d、素晴らしい

let over lambdaのパンドリックマクロも面白いよ

Mパッシングの発想は嫌いでもないんだけど
処理系でジャンプテーブルに変換でもしてくれないと遅くて使ってられん

変換されないの？

どっちが好き?
(define 1mycons (lambda (a d)
(lambda (mes) (case mes
((car) a)
((cdr) d)
((scar) (lambda (v) (set! a v)))
((scdr) (lambda (v) (set! d v)))
((type) 'pair)))))
(define 1mycar (lambda (rec) (rec 'car)))
(define 1mycdr (lambda (rec) (rec 'cdr)))
(define 1myset-car! (lambda (rec arg) ((rec 'scar) arg)))
(define 1myset-cdr! (lambda (rec arg) ((rec 'scdr) arg)))
(define 1mypair? (lambda (rec) (eq? (rec 'type) 'pair)))

(define 2mycons (lambda (a d)
(lambda (mes)
(mes a d (lambda (v) (set! a v)) (lambda (v) (set! d v)) 'pair))))
(define 2mycar (lambda (rec) (rec (lambda (ar dr aw dw ty) ar))))
(define 2mycdr (lambda (rec) (rec (lambda (ar dr aw dw ty) dr))))
(define 2myset-car! (lambda (rec v) (rec (lambda (ar dr aw ty) (aw v)))))
(define 2myset-cdr! (lambda (rec v) (rec (lambda (ar dr aw ty) (dw v)))))
(define 2mypair? (lambda (rec) (rec (lambda (ar dr aw dw ty) (eq? ty 'pair)))))

Lisperの人が普段何書いてるのか興味ある。スクリプト用途には向かないよね？

俺はスクリプトにも使ってる。
replでボトムアップスタイルが楽。

対話環境は他の言語にもあるけど、文法部分で一工夫必要になったり、上から下への手続き的コードになりがちで、
いまいち部品の部品から育ててる感触にならない。

Lispはまだ問題がまだよく定義できていない、あるいは、解法の定番がないものについて
試行錯誤しながら整理することに利用している。REPLによる対話環境はその点で便利。

普通にスクリプト書くなあ、向いてないとも思わんし

lispといってもgaucheは向いてるけどsbclとかはイマイチ
一応出来るんだけどなんかしっくりこない

スクリプトにはElispじゃね？

起動が遅いけど自分はclojureよく使うな>>スクリプト
事前準備がjvmとleinスクリプトだけで済むからどこでもたいてい使える。
出先の会社でインストール厳しいところでもjvmまではアリだったりするから。jarベースで起動できるスクリプトまでは通るし、clojure込みでjarに固めてあればrepl起動していろいろできるから。
インストール厳しいところでexe申請だともうどうもならん様なところとかでもなんとかなる。

シェルスクリプトでいいんじゃないかな

>>330
自分が一番つらかったのはpowershell無しのwindows環境ですcmdはきつい
unix系OSを開発に使ってるところだとjvm無しはなかったです。

なおエディタがnotepad.exeだけってところもありましたよ(二度と仕事したくない)

あ、windows以前だとedlinだけってところありました、財閥系の会社だから名前出さないけど

Javaの場合、単純ソートでも Comparator のサブクラスを実装しなきゃ
いけないトコが面倒臭かったなぁ…まぁ、Java 8 で lambda 式がやっと
入ったんで sort に限らず色々と楽になったからいいけど

>>325
昔はそう思ってたけど、もっと広く自分が仕様を固められてないぐらいから使える
内側のS式を常に動かて、試行錯誤しつつ、仕様が徐々に固まっていく方法が取れる
頭だけで事前に計画するより、ずっと早く適切に書ける
グレアムが画家のキャンバスや思考の道具発言の意味がやっと理解できた
考えてから書くのでなく、考える時にいじりまわしてる道具
高い表現力も、余計な事を分離して、思考の邪魔にならないように

仕様を固めちゃったら、大学の演習で「lisp作れ」が出来なくなっちゃう

へ？

俺Guile

>>337
日本限定駄洒落系処理系作りたくなるからやめれwwww

お前ザンキエフ

cl-glfw3をmacで動かしたことある人いますか？
サンプルを動かしてみてもフリーズしてしまいます
試しに他言語からGLFW3を叩いたところ問題なく動いたのでcl-glfw3固有の問題だと思うのですが

家のmac (10.9.5)、 sbcl 1.2.5 で試してみた。
まずうちでは macports を使ってるのでライブラリをsudo port install glfw として入れた。
sbclを起動して (ql:quickload 'cl-glfw3) とやったら、
ライブラリが認識されずにデバッガが起動したので、
USE-VALUE → ("/opt/local/lib/libglfw.dylib") としてやった。
で(ql:quickload 'cl-glfw3-examples) して
(cl-glfw3-examples:basic-window-example) と
(cl-glfw3-examples:events-example) を試してみた。どちらも動いているように見える。

多分、ccl を使ってるんじゃなかろうか。うちの環境でも ccl だとフリーズした。
確か opengl系の他のライブラリとか、あと lispbuilder-sdl というライブラリでも似たような問題があったはず。
ccl が中で使ってる Cocoa のスレッド安全性の問題がどうとかでうまく動かないらしい。

なんとか ccl を使いたい場合は lispbuilder-sdl の本家
https://code.google.com/p/lispbuilder/wiki/DownloadInstallationIntro
にもちょっと書いてあるように、 ccl の single-threaded-build を使う必要がある。
これは quicklisp にもある single-threaded-ccl というパッケージで作れるが、
もしIDEにslimeを使ってるなら相性が良くないのでおすすめしない(sbclを使えば良いと思う)。

あ、hを抜くのを忘れてしまった…

書き忘れていましたがお察しの通りcclを使っていました
sbclを入れて使ってみたところ上手く動いてそうだったのでこっちで試してみようと思います
ありがとうございました

Liserはこの世のゴミ

>>344
「この世のゴミ」というのはあまりにも失礼だろう。
浮世離れした人たちなのは確かだろうけど

いや、liserの奴らはヤバイ
おれはlisperだから関係ないけど

>>344
ｴﾍﾍ

リサちゃあァァん！
カワイィよおゥ！

ｴﾍﾍ

この世にGCが無くてよかった

もしあってもオブジェクトからしたら気付かないだろ

孤独死とかGCなんじゃね

でもそれを見つけたら参照されてることになるんじゃね

もしどこからも参照されなくなってGCされるなら
死じゃなくて存在自体消されてるはず

参照されてないのを処理系が発見して回収して遺品とか処分したり部屋とかリサイクルしたり。

発見するのは人で処理系じゃないからな

おにぎりたべたい…

>>356
発見現場で?

ああ、知らないのか

餓死した人の言葉だよ、それ

おじぎり、ひとつだけちょうだい…

おにぎりの人？

日記に書くほどおにぎり食べたかった人

参照されてないおにぎりうめぇ

「なに勝手に部屋ん中片付けてんだよ！！」
「あんたがいつまでも弱参照にしてるからでしょうが！」

不法入国の癖に参照されまくりの某国人「歴史的経緯ガー」

巣に帰れ

コンスコンスとか言ってると思ったらやっぱり居るのか。
このスレは監視対象だな。

キチガイが湧いてんね

毛根がＧＣされる

弱参照のビオレ

>>364
そもそも彼らが不法入国した日本列島はアメリカだしな…

>>369
メモリに優しいですー

Lisperはこの世のゴミ

どんどん回収しちゃおうね

GCしちゃうおじさん

どんどんGCされちゃうんだ…

過去の栄光にしがみつくだけならGCされてもしかたないかもな

Lisp嫌いそうな奴はにおいでわかる

>>377
本当か？じゃ、俺はどうだ？

　　　　ぅぉぇっぷ
　　／⌒ヽフ
　 /　 rノ
　ＯＯ＿)


***うﾞぉぉぉぉぉえ!!
ゲロゲロゲェ――!!!!
￣￣￣￣∨￣￣￣￣￣
　　　　 ぅぉぇっぷ
　　／⌒ヽフ
　 /　　rノ
　ＯＯ＿);ﾟ｡o;,


　　　　ぅﾞぉぇぇぇ
　　∧＿∧
〃 (|i´r`)
　/ つ　ｨ;ﾟ;δﾟ,
⊂こ＿)_);:ﾟ｡o;:ﾟ｡
　　　 ,;;｡:;ﾟ｡o,
ﾋﾞﾁｮﾋﾞﾁｮ

aaかわいい

lighttableいいなぁ
なんでCL仲間はずれにするのん？

lispを低水準なものにコンパイルする処理系作ってみたいんだけど
変換後のコードをCにするかllvmにするか迷ってるんだけどなにか大きな違いある？
主に学習目的で

>>382
Cにすると変換系を作り手や関係者が視認しやすいけど
LLVMまで落としちゃうと関われる人が減るってだけな感じ。

作者がLLVMでも問題無いって感じるならCにする意味無いはず。

まあ、 C の方が移植性が高い可能性はあるな。
LLVM がサポートしてないアーキテクチャへの移植が楽ということは有り得るかも。

>>382
いまなら断然llvmだと思う。
前に数理システムの人がレポート書いてたけど、今時のlispでも共通部分式の除去すらやってない。早いlisp書いてくれ。

意見が分かれてて余計に悩むわ
とりあえずGC本消化してドラゴンブック舐めてから考える

>>385
仮に最新のコンパイラ技術が投入できたとしてナンボほど速くなるのかだが，
劇的に速くなるようには思えない ．
具体的にどれだけ速くなるのよ．

取り合えず数理システムの人が、「こう書いたら、コンパイラはここまで最適化すべき」
ということを書いてるので、それ読んでみればだいたい見積もれる。

数理システムのレポートってこれのこと？
cl-www.msi.co.jp/solutions/knowledge/lisp-world/tutorial/compiler-eval.pdf

もしかしてcかllvmで悩んでたのはリターゲッタブルコンパイラを作ることで
どっちにするか決めるのを先送りに出来るのか

そもそもlispが低水準だと思ってた俺は異端か…

気楽に書いてもC並みに早いのが希望だなぁ。

REPL があるとグローバルな最適化があまり出来ないだろ。
Lisp 的な開発手順とのトレードオフがある話なんだよな。

JavaのJITみたいに最適化の前提が破られた時点でdeoptimizeするとかだめなの？

駄目かどうかで言えばダメじゃない。
ただ、そのためのコストと最適化の効果を天秤にかけたとき割に合うのがどこかっていうのは繊細な微調整が必要だし状況によるので、
かなりややこしくなると思う。

別にStalinみたいに最適化してもいいのだし

stalinの最適化ってどうなってんの？

粛清、かな……つまりはベクトル化

schemeの場合ルート環境を巨大letrecと解釈してコンパイルしてもうまくなかった思い出

Lisp関連の書籍は
まず冒頭でLispへの深い愛が語られますが
世の中の多くのエンジニアは不細工なゲテモノとして扱いします
ｳﾝﾁｯﾁ！

緑の宇宙人として描いてる本まであるからな

あの本は良いキチガイっぷりだった

>>402
でもあの本のCMビデオ結構すき

俺も立派なキチガイになれるように来春にはミドリの宇宙人にご挨拶する

久々に見てしまった
ttps://www.youtube.com/watch?v=HM1Zb3xmvMc

緑の宇宙人普通にかわいいんだよなぁ…

いくら生物シリーズで統一しているとはいえ、あれはないよな‥笑ってしまった‥

関数定義でfunction-name-1みたいな最後に-nを付けるような書き方見たことある気がするんだけど
あれどういう時に使うのか気になってモヤモヤしてる
知ってる人いない？

別に特に決まりがあるわけじゃないけど。

まあ一般的にはなんかの下請け関数とかで名前が重要じゃないときとかにそんな風にするかね。

prog1 や prog2 みたいな例もあるぞ。
そうやって事例を挙げることはできるけど、明確に共通する規則はないと思う。

>>407
オライリーは、毎回、表紙の生物の解説が裏の方に書いてあるけど、land of lisp には書いてなかった
オライリーは笑いが分かってない

本文で解説されてるからじゃないか？

-1
つまりマイナスいち
わかった？
※マジです

>>413
マジで？
いまいち信じられないからソース欲しい

schemeはデータ記述方法とプログラム記述方法が同じで
継続もファーストクラスオブジェクトだと聞いて
「継続もシリアライズして渡せるのかすげーな」と思ってたおじさんです
よろしくお願いします

なんですげえのかわからないけれど継続とやらを使うと末尾再帰表現できて遅くならないのは分かった初心者です。On Scheme
（collectorとして学んだけどcontinuationともいうと書いてあったな）

あれこれしたあとで、あれこれしてきたあとで、これをやれよ

という意味で継続なのかなあ

あれこれして集めまくってから、それから、こらやれろ

はコレクターだなぁ
両方共同じだな

すると
(define foo
(lambda l)
(if (null? l) '()
(cons (last l) (foo (butlast l))))))
のコンスも似たようなものにならないのか？

あれこれやってきてから(last l)にそれをコンスしろよ
コラコラ、キスするんじゃない

ここはお前の日記帳じゃねえんだって言えばいいの

いや末尾再帰の最適化やらCPSやらと
自分が言ってる継続は別の話だからね
継続はcall/ccで取り出せるやつのことな

さまざまな言語の不自由さから来るストレスで
痛めつけられ心が弱っているコーダに
救いの手を差し延べるのがLispなのです
故に初学者は糖質そのものですが
lispほたくさんの))))))))で優しく包み込んでくれます

糖衣構文がなんだって？

>>415
コンピュータの電源をブツ切りしたときに、継続がどうなってるのかモヤモヤする

>>422
シリアライズできるのならそれは丸ごとシリアライズされるだろうから電源切っても平気だと思うyo!
読み出せば参照してる環境もレキシカル変数も手続きも中身全部芋づる式に復元されるはずda!
ファイルとかオープンしてたらどうなってるかはわからないけど

未だに Scheme レベル5 くらいから上へ行けねー。3imp のおかげで継続はわかってきたが。
日常的には他のスクリプトを使ってしまうんだよね

>>424
そのレベルってどういう基準なの？

>>425
私家版、Schemeプログラマのレベル10
じゃないの？
ttp://practical-scheme.net/wiliki/wiliki.cgi?Scheme%3ASchemeプログラマのレベル10

>>426
サンクス

俺はレベル1だな

俺はレベル0 ‥信者がいるらしいので‥

>>429
あまり難しく考えないで楽しんだらいいと思う。
信者はマクロや継続のことに拘るかもしれないが、とりあえず受け流しておいていいと思う。

>>423
その継続を呼ぶと電源がブツ切りになるんじゃない？
ブツ切りされる原因は変わっても結局そうなる
世界線が収束してしまうんよ

継続については便利な小道具くらいに思っておいた方がいい
http://cl-www.msi.co.jp/solutions/knowledge/lisp-world/articles/three-dogmas-of-scheme

あるいは、頭はいいっぽいけど向いてなさそうな人を釣る餌

>>432
これ書いた人は頭良くないだろ
可能的推論をそれでしかありえない必然として扱いすぎている

論調なんかどうでもよいが再帰と繰り返しと束縛の話がおかしいのが気になるな

フルの継続の問題って決局何が問題なのかよく分からない…。Haskell のIOモナドの説明に出てくるWorld変数と関係ありますか？

>>435
君も頭悪そうだなあ
論調ととらえるか
あらあら

>>436
条件付きのcall/ccの方が実装は軽快になると思う。
しかし、多くのSchemerは反対するだろう。

call/ccの前に call-with-escape-continuationってなかったっけ？、r3rsだったかな

>>439
R3RSでも既に(call-with-current-continuation proc) essential procedure となってるね。

>>440
WinCEのschemeでcall/ec使ってる実装(call/cc無し)があってそれがr3rs準拠だった模様
もうだいぶ前の事なんでうろ覚えですまぬ

>>441
Racketには今でもcall/ecがあるんだね。驚いた。
そういう選択もあったと思うな。

lisp処理系でマクロ展開をコンパイルの前段階の最適化やらの部分でするとき
マクロ展開にevalを使わないと実装できない気がするんだけどどうしたらいい？

(defmacro nil! (x) (list 'setq x nil))
というマクロがあって
(nil! foo)という式を展開するときに
(list 'setq foo nil)これは本当は
(setq foo nil)になってほしい

ここら変でおかしい事に気付いた

どうしたらいいもなにも素直にevalしてください
マクロってのはそういうもんです

じゃあコンパイラを書く場合はevalと両方書かないと駄目なのか

evalもなにも、nil!っていう（マクロ展開用の）関数にコード生成させて、それを(nil! ...)の現れた場所に埋め込むのがマクロ展開器の仕事でしょう

>>443
ちょっとなにいってるかわかんない

前処理としてチューリング完全な手続きが使えたらいろいろできるよね、てのが Lisp のマクロ。
で、そのマクロ用の言語として Lisp をそのまま流用するのが伝統的マクロのアプローチだけど、
一方で R5RS Scheme みたいにマクロ用の独自言語を用意するというアプローチもある。

>>445
別にマクロ手続きをコンパイルして実行してもいいのよ？

read 時にも結局evalが必要なんだっけ

>>448
やっぱり伝統的な方法でやるならevalかインタラクティブなコンパイル処理を用意しないとだめか
副作用の無い関数は展開したいからevalが妥当かな

R5RS のマクロはある種の独自言語なのは確かだけど、
低水準マクロにどういう方式を採用すべきかで合意できなかったから
不本意ながらとりあえず合意できる範囲でインターフェイスを決めたものであって、
あれが Scheme 的なアプローチってわけじゃないんだよ。

ありゃ仕方なくやったって感じだな
Cのプリプロセッサマクロの豪華版

健全性は理念としてはわかるが、その実現のために
展開器がコンパイラ並みの大きさになっていくのはいかがなものか？
バグのない完全な展開器は現存するのか？

R7RSにはmacroexpandが無い。
どうやってマクロをデバッグするんだ？

http://practical-scheme.net/wiliki/wiliki.cgi?Gauche%3A%E5%BE%AA%E7%92%B0%E3%83%AA%E3%82%B9%E3%83%88%E3%81%AE%E8%AA%AD%E3%81%BF%E6%9B%B8%E3%81%8D
にある
(#0=(a . b) . #0#)
は循環リストではないのでは？

そうですよ。

> 循環や共有構造を持つS式

#n# #n=の話をしてるだけで循環かどうかは重要じゃないんじゃ

トップページに循環リンクを張っとくとロボ避け用になるね

lisp advent calendar
投稿しないなら予約するなよお

寄稿者の集まりも悪いしそんな楽しみにしてるやつがいるようなカレンダーでもなかったと思うが

殺伐とするのはgoの役目だから

括弧打つときの左shiftキーで小指が痛い
ctrlは変換無変換に割り当ててるから大丈夫だけどみんなは小指痛くならないの？

脱力が重要、ピアノ弾きにきいてごらんよ

>>463
emacs使ってるならPCの変換とかMacのかなキーを開き括弧にすると良いんじゃ無いの
閉じるのはparedit任せ
つかキーボードの最下段ってなんであんなに不便な割り当てなんだろね？

>>463
ギターとピアノで鍛えてるからか、痛くなったことがない

小指が痛くなるもやしっこは自分だけだったのか
shiftキーを親指で押せる位置にするのが一番早いかな
paredit便利っぽいけど小指の件とはあまり関係無さそう

>>467
コントロール+8にすれば？

>>463
俺は親指で押してるが根本的な解決とは言いがたい

日常的にキーボードを打っていれば必要な筋肉はつくと思うけど。

なんならギタリストみたいに指の筋トレでもすれば？

個人の指の長さ、筋肉の使い方、キーボードの高さや配置、いろいろ関係があるからなぁ。
どうすればうまく使えるか、微調整していくのがいいと思う。enjoy!

ハノンやろうか
てかピアノ弾き多いな

俺は津軽三味線だけどな
なんで左手の小指は使わん！

キーボードを押すときそこまでキッチリ押し込むとtyping injuryに成りやすい。
キーのスイッチが押し初めの方に有るキーボードを使って底付きしないように、
指の腹で押す。英語だとtyping injuryでぐぐると一杯情報有るのに
日本語だとこの手の情報あんまりないよね。。。。俺の探し方が悪いのか？？

まあ、マジレスすると左シフトでなんたらって
底づきさせてるんじゃないのか？
癖を直すのとクソキーボード変えるべきじゃないのか

>>474
あっちはタイプライターが結構前から普及してたけど、日本だとその頃は習字が該当するから。
文字書くときの姿勢関係だとペンクラブとかでも話題があるから文化的違いじゃないの？
PC普及でこれから事例が増えるといっぱい出てくる希ガス

にほんじんは意外なやつまでブラインドできんやつ多いしな
俺が教えた学生は全員ブラインド訓練からやらせた
文句言う男子はタコ部屋で俺のために稼がせる
文句言う女子学生は文句言えないようにおれの云々棒で口を塞ぐ
という硬い決意で望んだが、みんな真面目でな
金は入らんし棒は入れられんし
悲しかったなぁ

タッチタイプという語を知らないという老害自慢しかできないなら黙ってくださいね

ダッチワイフに見えた

このひと病気かな ID:0m+CPJzh

>>478
わはははは
瑣末君の無駄な書き込み乙

>>478
たかが表現に拘泥するあたり才能のなさを告白してるな
ろくな研究できてないだろ

さてと
ブラインドでカチャカチャやるか

ｺﾗｺﾗ、そこの、低能
ｸﾁｭｸﾁｭじゃないからな、ほらほら、中指立てるな

その飲み会でうざがられてるおっさんのようなセンスの18禁ネタはわざとなの

下品さを装って強がるのがせいぜい

瑣末で才能のカケラも無い、今すぐ回線切って首吊って、
氏ねじゃなくて死ねよゴミカス >>481

R7RS-large が規定されたとして、それでいったい何を作るのだ？
CLの仕様より大きくなるらしいが。

そんなの好きなもん作れよ

やっぱCommon Lispだよな
てかISLisp改良して欲しい

お前がやれよ。 仕様なんて言い張ったもん勝ちだぞ。

CLにはとくに不満は思いつかない
処理系にはどんどん頑張ってほしいけど
あえて言うなら処理系依存の所を減らしてくれたらいいけど

>>488
実装がともなってないと相手にされないことも多い。
（だから実装作れ、超がんがれ、という話になるわけだが）

大学でlisp処理系を作らされる学生の数、それがlispの仕様の数である

簡単な処理系の三つや四つ

C-cC-kしようとしたらC-cC-cしてしまった
まあみんなそれくらい作ってるよな

わはは君ってあちこちに出てくるけど総じてキチガイで笑う

初心者の俺にはどこらへんが基地外なのかさっぱりわからない

>>472
ハノンとかチェルニーとか人生の時間の無駄だから‥インベンションやシンフォニアがおすすめだ

誰か教えてくれ。
このマクロは (i (f)) => #f , (i f) => #t でいいのか？

(define-syntax i
(syntax-rules ()
((_ c)
(letrec-syntax ((f (syntax-rules () ((_) #t)))
(t (syntax-rules ()
((_ c) (f))
((_ x) #f))))
(t f)))))

>>497
いいよ。

>>497
これ、定義の3行目のcと6行目のcは別ものとして扱われるはずだから、
(i Y)でYになにをもってきても7行目の((_ x) #f)は適用されんだろ。
結局、常に(i Y) => #t になる。

　
　
　　　　　Gun = Kata

>>499
別物にはならないよ。 同じだよ。

>>491
俺も作ったわ w
専用命令込みで

>>501
R5RSのsyntax-rulesの説明を見る限り、
cはパターン変数として扱われるから
7行目のcは3行目のcを参照しないでしょ。

このへん、R6RS及びR7RSで変更されたの?

>>503
自分はMoshとGaucheを信用しているのだが、それぞれ結果が異なる。
mosh> (i f)
#t

gosh> (i f)
*** ERROR: unbound variable: f
Stack Trace:
______________

>>504
gaucheのdefine-syntaxってdefine-syntaxを含むマクロが定義できないバグが
あったんやけど、letrec-syntaxでも同じなんじゃないかな。

>>503
パターン変数だが、それによって 7 行目の c が 3 行目の c に対応しないとする理由になると考える理由がわかんないな。

>>506
ごめんなさい、勘違いしてました。

>>507
自分もcについて同様に考えていた。それぞれのスコープがあるんじゃないか？って。

schemeの純潔マクロは時間の無駄だよね

>>509
まったくだ。それでなくても開発者人口が極めて少なく、マンパワーが
不足しているのに、貴重なリソースを健全マクロに注いでいる。

潔癖症って健全じゃないよね
融通が効かないし、純潔でないものは無条件に悪と決めつけてるから、実務では汚染源になる

>>511のidで思いだしたけどTAOで引数にクォートを付けて
事前に評価されないようにする定義方法あったよな
ああいうのを取り入れたlisp-2が欲しい

貴重なリソースっていっても開発者が好きでやってることでしょ
勝手に開発者のモチベーションを共有リソースにするやつがいるんだな

>>513
気に障ったんなら許してくれ。開発者が完全な衛生的マクロを望み、
ユーザーが渇望しているのなら、それでいいと思う。孤高の人、scheme

>>511
既に >>451 で指摘されているけど、 syntax-rules は現時点での妥協でしかないのでこれだけで「衛生的マクロ」を評価すんなよ。

>>515
syntax-case ってのも妥協の産物なのかい？

衛生的マクロの利点は一応分かってる積もりだけど、CLのgensym+パッケージに比べて素晴らしいもの、とは思えないんだよなぁ。
シロウト意見だけど、これだけ何十年も決まらない、って衛生的マクロのアイディアに何処かに根本的な無理があるんじゃないの？
第1級の継続より限定継続の方が現実的、なみたいにさ。
それとも議論を尽くせばそのうち決まるものなのかな。

>>516
Yes。
底レベルで何をやってるかを隠していきなり高水準な機能を与えてる。
底レベルでの処理にどんなモデルを採用するかをうやむやにした結果。

>>517
マクロに限らずまだまだまだまだ決まってないことだらけじゃないか。
そんでもって、そもそも決めなきゃならないのかっていう議論さえときどき出てくる。
仕様にしてしまうことで実装を縛るのを嫌がってるんだよ。
それでも、どうしても決まってしまったものが仕様になる。
Schemeってそういうものだろ。 単に方針の違い。

黒板言語は伊達じゃない

>>517
フルの継続は実装としては興味深いが、ユーザーとしては使いにくいな。
仕様を限定して実装を軽くしてやった方が使い道があるだろうと思う。

>>473
左腕がサイコガンか何かなのか？

>>521
そりゃ逆だろう。 実装は面倒くさいがユーザーとしてはフルの方がわかりやすいよ。
継続が一回しか呼出されないとか、範囲が限定されているとかいうのはプログラムから読み取って処理系が最適化を頑張って欲しい。
ユーザーには制限が見えない方がいい。

メモリとCPUというどの実装にも明記されない確実な制限があるし

>>523
昔のcall/ec程度で十分だと思うがなぁ。
CLの黒田さんにもフルの継続の問題点が指摘されている。

誰が継続に永続性を持たせるべきだって言いだしたんだい？
Dybvig先生？

>>525
「十分」って誰基準よー。
そういう考え方やめろよ。
制限を排除していくのがSchemeの大綱だろ。

>>527
大綱？　それ、どこに書いてあるんだ？

>>528
Introduction

>>527
そこまでは書いてないと思うが。
でもそう考えているschemerは多いんだろうな。

制限を排除するのか、制限を追加するのか、どっちともとれるな

Programming languages should be designed not by piling feature on top of feature,
but by removing the weaknesses and restrictions that make additional features appear necessary.

必要な機能を追加するのではなく、その機能が必要になるような弱点や制限を取り除くべき

フルの継続って、むしろ高速化するための弱点になってるような気がしなくもない

call/ec のある Racket は流石だと言うことだ

Schemeには高速化よりも、表現の正しさを求めたい

>>532
明記はされていないものの、Scheme的には表現力を重視していると思う。
だからといって遅すぎてもよいというわけでもないのでそこらへんはバランスを取りながらということで。

教えてくれ。このコードって(import cxr) を落としてるんじゃね？
https://gist.github.com/SaitoAtsushi/8784203
動かない。

直したら動いた。これだけ変態的なマクロだと処理系のテスト用にいいな。
効率、めっちゃ悪そうだけど。

>>536-537
car や cdr を使ってるからか？
(scheme base) に car や cdr は含まれてるので、 (scheme cxr) を import しなけりゃ動かないというのなら処理系 (が持つライブラリ) の方が間違ってると思う。

>>536
それはちょっと古いやつ。
こっちの方が本格的になってる。
https://github.com/SaitoAtsushi/pattern-match-lambda

>>538
ああ、そうなのか。妙な構成にしておくんだな。

>>539
実用性はともかくマクロ展開期のテストにはいいな。
動かない処理系、けっこうあるんじゃないか？

>>539
GaucheのR7RSモードで試してみたが、全然、動かないぞ。

>>542
known issue。
マクロでマクロを生成する系のマクロはR5RSの頃からGaucheでは動かないことがあったよ。
今のheadではexplicit renamingが実装されていて、それを元に展開器がSchemeで書き直される予定があるよ。
次のリリースで修正されるか、間に合わなければその次のリリースになるとのこと。

>>543
了解

CLerの素朴な疑問だけど、schemeのマクロ展開器、なんでそんなに難しいんだろ。
仕様が難しいの？それとも曖昧なの？

>>545
オレの理解では仕様がダメダメ。Gaucheでさえバグがなくならないんだぜ。

>>545
リソース不足。
たまにコントリビュートありつつもひとりでやってることが多いから細かなミスが残る。
そして有名どころの展開器を使わずにあえて自分で一から書いたりするのでなおさらそうなる。
比較的大きなコミュニティを持っているguile、racket、chickenではそれほど問題ない。

さすがにR6RSでは自前でマクロ展開器を書いてない方が多かったみたいだけど。

>>546-547
thx。マクロの仕様がかなり複雑で乏しいリソースじゃなかなか作りきれない、と理解した。
CLから見てると、なんでマクロ展開なんてとっくに実用になってることを、
そんな難しい問題にしてるかイマイチ、理解できないんだけど…。
自分で実装しなきゃ分からないんだろうなぁ。

>>539これをコテン的マクロに書き換えるとどうなるの
ていうか何するマクロなのか読んでもさっぱり

>>548
CLのマクロ(いわゆる伝統的マクロ)は
　・健全性の確保をユーザにゆだねている (gensymを使うという規約をユーザが守らなければいけない)
　・完全に健全にならない部分がある
　・フェイズ(リード時とマクロ展開時とコンパイル時と実行時)がごちゃまぜでよくわからん
という問題があって、しかし「それを注意さえすれば特に問題にならないからいいや」というスタンス。

Schemeとしては「いやいや、そういうわけにいかんし」という感じ。
どちらもメリットとデメリットはあるからどっちを取るかというのは文化の違いとしか言い様がないな。

lisp-1はシンボルが関数と変数に分かれていなくて名前が衝突しやすくなった
そのせいで伝統的な方法のマクロだとlisp-2以上に気を付けなくならなくなった
だから衛生的マクロが必要になったけど複雑さとリソース不足のせいで何十年もかけてるのにまだちゃんと決まってない

最大の原因はlisp-1だろ

>>551
仕様そのものがどうこうよりも単にScheme業界の気質だと思うぞ。
一旦決めてもそもそも論が出てきて覆るし。

>>548
そうなんだよ。さっさとマクロの問題を片付けて他のことをやればいいと思うんだが。
教条主義的なところがあって自縄自縛になってるかもな。
それと開発者自身がそれを楽しんでいるという雰囲気もある。

キューみたいなデータ構造とかネットワーク関係とか、そういうのは語彙を追加すりゃいいだけの話でそもそも言語仕様に含める必要さえ疑問視されてるくらいなんだよな。
要はいくらでも後付けできる話なので、そうじゃない「言語のコア」として議論すべきこととしてはもうそんなにないんだよ。
強いて言えばリードマクロとかの話になるが…、それはそれでマクロ以上に決まらないだろうしな。

>>550
CLのマクロはマクロ展開時に展開される。
展開時に必要な手続が動かなければ展開に失敗するというだけのこと。
マクロに固有の問題じゃない。よくわからんのは単にフェイズがわからんってこと。

schemeって簡単そうに見えたけど、マクロはわけわかめだな

Common Lisp はオブジェクトシステムがよくわからんけど。

そもそもschemeはS式の基本データ構造としてのリストも否定材料にしてると思うよ
健全マクロはリスト操作を避ける仕組みそのものだし
S式を捨てたいって思想が透けて見えるよ

>>558
何度も同じことを書いてるけど、
現在の syntax-rules の仕組は下層でどのようなモデルを使うかを隠した高水準のものだから、
それを衛生的マクロ一般と混同するな。 するな。 するな。
大事なことなので三度言いました。

なるほどつまり伝統的マクロにタダで健全性を持たせることができれば大勝利なのか

>>560
それが実現できたらACMチューリング賞ものだと思う。がんばってくれ。

同一時間であればシンボルの唯一性が保証されている。健全マクロの問題は
定義時と実行時という時間が異なる空間でシンボルの唯一性を保証せよという
問題と考えられる。

explicit renaming なんかだと扱ってるのはあくまでS式で、
シンボルをリネームするという形なのでS式の世界だけで考えることは出来る…
…んだけど、マクロ使用箇所の「外側」もリネームする必要がある場合もあって、
文脈を理解した変換が必要なのでマクロ展開器をコンパイラと上手く分離するのは難しいかも。

コンパイラとマクロ展開器をどれくらい分離するかというのは色んなアプローチがあるってshiroさんが言ってた。

インターンする部分を一時的にフック出来れば
自動gensymがうまくいくと思うのは安直かな

やってみれば。

マクロ、そろそろやめませんか？

マクロとGCと数式は中置記法云々の話がループしてるな

ラムダ式の世界でさえ名前の衝突は議論されてたんだから、何かシンプルな方法があるはず、とも思うし、
一方でlisp-2にしてパッケージつけてCLみたくフェーズ分けすれば終わりだろ、とも思う。

>>566
マクロ止めるならS式は単なる風変わりな記法に過ぎなくなるけどいいの？

>>568
α変換？

文章や数式を考えるときは構造が頭の中でS式が浮かぶ

>>570
数式は再帰構造だからね。S式はマクロのためだけでもないと思うよ。

>>566
やめてどうすんの？
なんか話題があるならお前が出せよ。

マクロ、別にいいけどね
一般論としては続ける側が面白い話をすべきだと思うよ？

>>573
面白いと思って話をしてると思うんだが、お前が面白くないと思うならお前が面白くするのが筋だろ。

マクロは健全性とか無視すれば単に構文の置換ってだけだからなあ
それよりもその先のコンパイル段階でやるような項書き換えの方に興味ある
マクロ展開して((lambda (+ x y))1 2)みたいな無駄な適用式を(+ 1 2)に変換するみたいなやつね
この場合両方とも定数だから単なる畳み込みだけど

融合変換とか？
そういうのって適用できるパターンを大量に持っておくしかないんじゃないの。
置換えパターンをユーザが定義可能にするという方法もあるけど…。
それ Common Lisp のコンパイラマクロだし。
http://www.lispworks.com/documentation/HyperSpec/Body/m_define.htm

Haskell なんかだとそうとう豪快な変換をすると聞くけど、
動的型な Lisp ではどんな値を受取るか事前に何の保証もないので、
現実にはこういう泥臭い方法になってしまう。
理論家から見たらこれひどい仕組に見えるんじゃなかろうか。

コンパイラコンパイラとしてのマクロの価値はみとめるが、読みやすさ目的や単なるショートカットとしてのマクロの価値は認めない

はい次

>>555
展開のタイミングの話じゃなくて、そのときに見える「環境」について。
R6RS ではライブラリ単位でメタレベルという名の指定を与えてそれを元に分離された環境を作る。
マクロ展開時に見える環境と実行時に見える環境は別物。

でも R6RS 処理系の中でもいくつかのアプローチにわかれてる。
まずひとつは明確に分離せずうやむやにしているタイプ。 実装をあまり読んでないけど sagittarius はこのタイプだと思う。
ふたつめはユーザのメタレベル指定に厳密に従って環境を分離するタイプ。 Larceny などはこれ。
みっつめは環境は分離するがメタレベル指定によってではなくプログラムの内容を見て自動的に決定する方法 (implicit phasing) 。 Chez とかはこのタイプ。

R6RS はメタレベルの解釈について厳密な定義を与えているものの、
レベルの不整合を受入れるような実装があってもよいという逃げ道も書いてあるので、
どの方針を取るか迷いがあるんだと思う。
もしコンパイラマクロやリーダマクロを Scheme に導入するとしたら更なる混迷の渦がまきおこるに違いない。

一階述語論理のように制限を加えよう。高階のマクロは制限しよう
・・・なんてことをschemerが許容するはずないよなぁ。
制限は排除しなきゃいけないんだから。

>>579
CL上のCLのマクロについていってるんじゃなくて、CLのマクロをSchemeに持っていったら、という話か？
CL上の話じゃないなら、CLのマクロ、って書くんじゃなくて、Scheme上のCL方式とでも表現しろよ。

マクロは単なるメタプログラミングの道具なのに 580 のように実現方法が難しいからマクロ自体が悪と考えるやつが出てくる始末。
Schemeマクロ話のナンセンスなところ。

俺はマグロがいいな
ﾄﾛﾃﾞﾀﾉﾐﾏｽ

>>582
では、あなたが完璧な健全マクロの仕様と、その実装を作成して
世に問うたらどうかな？　それともテストするだけ？

>>584
Schemeマクロのユーザー目線の話をしている。
Schemeユーザーからするとマクロは重要なメタプログラミングの道具。
実現方法が難しいからマクロ自体が悪と考えるのは実装者目線であって、
なんもしらんユーザーも一緒に巻き込まれてそう考える、もしくは、
実装者がユーザーも同じように考えてると思ってるとしたら実にナンセンス。
文句があるなら作ってみせろ、ってのもまったく噛み合ってない。
ユーザー＝実装者って自虐劇も大概にして欲しいよな。

>>584
よこからだけど
どうして「では」とつなげるの？
頭おかしいの？
いやがらせなの？

カンペキな健全マクロなんてものを本当に欲しいと思っているのなら、もはや病気だよ
中でいくらunsafeなことをやってても、出来上がったマクロがあらゆる入力に対してsafeであればそれでいいじゃないの
プログラミングってのは、本質的にそういうもんでしょうに…

>>587
> 出来上がったマクロがあらゆる入力に対してsafeであれば

少なくとも Common Lisp におけるマクロはそれが不可能であることがわかっている。

しかし、現実的に100人規模でCommonLispを書いてる会社や、50万行から100万行規模のアプリケーションでも
それが問題になっているという話は耳にしたことがない。

航空ルート検索/予約システム 50万行から http://www.itasoftware.com/
鉄道運行システム http://www.siscog.eu/upload/GESTAO-DE-LISTAS/News/PDF/eclm-2013-siscog-a-story-written-in-lisp-20130602.pdf

昔から積み重ねた実績からして既に充分で新しいマクロ方式に対しての需要もないのだろう。
ずっと昔からCommonLispでは、マクロは実装方式を議論するものではなくて、当り前のように使う単なるツールなんだよ。

なるほど。
schemeも伝統的マクロ+gensymでもいいんじゃね？

>>590
伝統マクロ好きだけど、schemeで伝統的マクロ+gensymは駄目だと思うが。
しかしｓｃｈｅｍｅにとってマクロというのはこれから未来の話か？
現在主流の方式も、もう20年前には出尽してるし、メジャーな処理系もマクロのシステムは確立してるだろ。

運用で回避できると言えば出来るけど、だからこれで行けというのも違うだろ。

C/C++ では簡単にバッファオーバーランが起こるとかいうのと同じレベルの話だと思う。
C/C++ ってそういうもんだし、その分だけ出来ることもあると理解していても、
後続の言語ではマシにしようという方向に動いてるだろ。

>>591
>schemeで伝統的マクロ+gensymは駄目だと思うが。

なぜ？

lisp-1だからじゃないの
http://blog.practical-scheme.net/shiro?20100425-scheme-macro

あとCLerの立場としてはSchemeが頑張っていいもの作ってくれたらそれ貰えばいいだけなんだから、応援するところじゃないの

>>592
いっとくけど、CommonLispでのマクロに対するレスで、CommonLispでの話だからね。
危険性が0じゃなかったら何一つ実用的なものは書けないのかよってこと。
schemeで伝統的マクロ+gensymはそれこそ簡単にバッファオーバーランが起こるとかいうのと同じレベルだろ。

でもCommonLispでの問題点とそれを運用で回避する方法を具体的に知ってて言ってんの？
パッケージロックで何万行レベルのコードでも簡単にほぼ100%回避できるよ。マシにしようという方向に動いてるって話だな。
CommonLispトータルのシステムと、取ってつけたようなscheme＋伝統的マクロを同じ俎上に乗せないでくれよ。

arc もlisp-1だったのでは？

arcは核を小さくしたかったからシンボルに名前空間を付けるのを避けたんじゃないの？
lisp-2にするとfuncallとかfunctionとかsymbol-*が必要でどうしても大きくなってしまいそう

arcがlisp-1で伝統マクロを使ってるからと言って変数がシャドウされやすいという問題がなくなったわけではないでしょ
ちょっと検索するとarcにhygienic macroくっつけたコンパイラが公開されてたりするみたいだし
arcのtutorialに書いてあるように、grahamがhygienic macroに対し懐疑的なのでそういう実装になってるだけ
それに対して、変数のシャドウが問題だと考える人たちもいて、>>591というかschemeコミュニティはそっちの考えが主流なんでしょ

でいいのかな、あんま詳しくないけど

>>598
>arcがlisp-1で伝統マクロを使ってるからと言って変数がシャドウされやすいという問題がなくなったわけではないでしょ

grahamさんには変数シャドウの問題回避よりも優先させたいが利点が伝統的マクロにあったのではないの？

コンパイラコンパイラとしてのマクロと、ユーザのショートカットとしてのマクロは、議論を分けるべきだと思う

>>599
例えば？
君が調べてここに書いてくれるとみんなの役に立つと思うよ

>>601
さあ、本人に聞いてみないとわからん。

schemerは衛生的マクロ探求の道を選んだ。極めればよいと思う。
でも、それが唯一絶対の選択肢ではないだろうということだ。

本人に聞いてみないとわからんこと他人に聞いたわけ？
延々質問攻めしといて誰もが分かってるようなこと偉そうに呟いて終わりとか失礼すぎませんかね
なんか苛ついちゃった、ごめんね

>>603
それはすまなかったな。
衛生的マクロが絶対という論調に反発していたんだ。失礼した。

（来年の今頃にはマクロの話題に少しは参加できるようになりたい）

macroexpand やりまくって例外探していくだけの簡単なお仕事です

>>595
そんなこと言ってないだろうがよ。 むしろお前の主張と同じだ。
Common Lisp はノウハウまで全部含めて CL だから Scheme で後追いすんのアホくせって話。

横からですまん。ちょっと論点整理していい？素人なので違ってたらつっこんで欲しい。
Schemer も Lisper もとりあえず合意できることを列挙しておきたいんだ。

1. Common Lisp の伝統的マクロは健全(衛生的)でない。ので、危険性はゼロでない。
1.1 しかし、CL では大規模プロダクトでも何ら問題は生じておらず、実用的な
道具になっている。理由は、Lisp-2 であること、パッケージロックの機構(ただし処理系依存)の二つ。
2. Scheme は健全なマクロを目指している。
2.1 そもそもlisp-1 のため CL よりも健全性が問題になりやすい。
2.2 syntax-rules は高水準の仕組みで 衛生的マクロとイコールではない。

>>608
> Lisp-2 であること、パッケージロックの機構

言語機能に加えて問題を避けるノウハウとかプログラマの意識みたいなのもあるわな。

Common Lisp では、処理系は道具なんだからプログラマが間違えたら結果が間違ってるのは当たり前だろみたいな意識があるけど、
Scheme では「原理的に」どうだろうということを考えてしまうところがあると思う。

これは比較できる事実を提示しづらいので異論はあると思うけど、根本的な意識が違うところ向いてる感じはあるんじゃないかな。

>609
ありがとう、修正してみた。異論がありそうなところは?を付けといた。
まだ色々漏れてると思うんで、がりがり書き替えて欲しい。

1. Common Lisp の伝統的マクロは健全(衛生的)でない。
よって、危険性はゼロでない。
1.1 しかし、CL では大規模プロダクトでも何ら問題は生じておらず、
実用的な道具になっている。
1.1.1 言語の機能として CL は Lisp-2 なので
Scheme に比べて問題が生じにくい。
1.1.2 パッケージロックの機能(ただし処理系依存)が危険性を減らす。
1.1.3 危険を避けるノウハウが確立しており、問題が生じても
プログラマの責任と見做される(?)。

2. Scheme は健全なマクロを目指している。
2.1 Scheme は lisp-1 なので CL に比べて問題が生じやすい。
2.2 syntax-rules は高水準の仕組みで 衛生的マクロとイコールではない。
2.3 問題が生じないこと、を目指している(?)

自分用にすれば？
自分にとっての一般化の過程ではありえても、誰にとってもそうである状態としての一般化は試みるほうが変

>>608 Schemer も Lisper もとりあえず合意できることを列挙しておきたいんだ。

合意ということなら、マクロはlisｐにおいては有用と考えているから導入されている、ということ位だけだよ。

CLではだいたい上手く行ってるからはっきり言ってどうでも良いトピック。

マクロがツールとしてどういう物なのかという、Lispプログラマ的なバランス感覚が弱い奴は、
話の落とし所も分からんから、完璧な健全性とはぁ、とか、
それに反発してマクロ廃止論や制限論をぶち上げたりする。それがループしてるだけ。
話の内容からしてユーザー不在だし、そういうのはschemeの実装者者寄りの奴なんだろ。

lispプログラマとしては、完璧な健全性云々よりも、マクロを書くマクロが壊れてたら嫌って話はあるけどね。

ちょっと基本的なことなんだけどお
define-syntaxってなんでグダグダわけのわからんネストを強要するの？
伝統的が
(define-macro (swap! a b)`(let((tmp ,a))(set! ,a ,b)(set! ,b tmp)))
と書けるなら
(define-syntax (swap! a b)〜)となぜ書けないの？
なんで
(define-syntax swap!
(er-macro-transformer
(lambda (form rename compare)
とかダラダラ書かせたりするの？
(define-er-syntax (swap! a b)(rename-let(let set! tmp)〜))
みたいなものを自分で定義しろってことなの？
あと
(define-syntax swap!
(syntax-rules ()
このsyntax-rules ()の()は何なの？
無駄多すぎね？

ぐぐったらsyntax-rules ()の無意味な()は判ったよ
でもセンスは感じられないな
ユーザーはこんなの求めてないと思う
一見して何してるのかさっぱりじゃC++と変わらねーよ

>>613
> (define-syntax (swap! a b)〜)となぜ書けないの？

それだと一種類のパターンしか書けない。
パターン一個で受けて分解して数種類のパターンと比較して分岐するということをやってたら、結局はそこそこの分量になる。
パターンの分解はどちらにせよ必要であることを考えると最初から仕組として持っていた方が簡単だよ。
R7RS の派生式型の項にある事例 (let とか do とか) を syntax-rules なしで書いてみるといい。 絶対に長くなるから。

> (define-syntax swap!
> (er-macro-transformer
> (lambda (form rename compare)
> とかダラダラ書かせたりするの？

これについては余計と言えば余計ではある。
現時点ではどんな仕組みを底レベルマクロとして採用するのか確定してないので、 er を特別扱いすることが出来ないんだ。
er を底レベルマクロとして採用している処理系で er-macro-transformer を挟まずに使える処理系は存在する。

> (define-er-syntax (swap! a b)(rename-let(let set! tmp)〜))
> みたいなものを自分で定義しろってことなの？

そう。
ささいな見た目の違いは簡単に吸収できるので問題ではないという意識が存在するのは確か。

>>615
ありがとう
schemeの健全マクロコードが全く本スレに貼られない状況がわかった気がする

>>612
うーん、CLとSchemeっておれが想像してた以上に考え方が違うんだね。

>>611
了解。

マクロは地獄や

マクロは真っ黒だからな。

As a general rule, macros should not be used when a procedure will do.

so natural it is.

ISLISPでtheはあるのにdeclareやdeclaimが無いのがよくわからない
なんで無いの

他の言語はこういう話題で盛り上がってるけど、2015年はLispにとってどういう年になりますか？
ttp://gihyo.jp/dev/column/newyear/2015/pronama-lang-prospect

その答えは、Lisperの数だけあるだろう、、みたいな

おれがオレオレschemeをついに完成させる

今年こそ真面目にオレオレlispを完成させる

>>617
メゲずにまとめ続けてほしい
それぞれが今感じている空気を明文化しておかないと文化の継承が行われないので
無駄な争いが繰り返されるし、初学者にも分かり辛くて、ゆくゆくは衰退する気がする

そりゃ学級会の黒板になるな
意味なし

common lisp以前の古いlispの書籍を読んでみたい
だれか知らない？

初めての人のためのLISPは？

>>630
もってる
正確にはcommonlispが完成する前の古典がいいんだ

http://www.amazon.co.jp/dp/4871482006

>>632
買いたい
、が高い

>>629
日本で最初のLisper　中西先生の本
Ｌｉｓｐ入門（第３版） (コンピュータ　サイエンス 大学講座　１)

>>634
よこレスだが、中西正和氏が日本で最初のLisperという理由を詳しく教えて欲しい。
古くは、中西正和氏の他に、後藤英一、 和田英一、黒川利明、各氏がLISPを啓蒙していたと思う。
処理系であれば、和田英一氏の東大のLISP 1.5が1966年。
中西正和氏のKLISPが1967年。
翻訳でない日本最初の書籍は、1972年にLISPとその応用例 雨宮綾夫氏のようだが。

日本で最初にLispを紹介したのが中西先生だと思ったけどなぁ。
違ったかな。日本に処理系がない時代に自分でLisp処理系を作った方。
古いBitにご自身の述懐があったはず。


はちみつさんかい？

>>634
ok
注文した

>>636
正確に調べたわけじゃないってことね。
当人が知らなかったということがありえるので、
自分が最初だという自己申告じゃなくて、
いつどういう媒体で紹介したのか、
又はいつどういう媒体で紹介したという記述がどこにあるか
という情報が >>635 は欲しいんだと思う。

めんどくせえ

>>日本で最初のLisper
なんて言い方を安易にする人をあいてにしてもなあ

だよな。 最初に知った人か最初に紹介した人か最初に実用した人か最初に論文に引用した人かはっきりしないしな。
まあ初期の Lisper ってことをちょっと誇張して言っただけと理解するよ。

>>636
中西正和氏がKLISPを開発した1967年、1943年生れの中西氏は24歳。
コンピュータは計算機センターに鎮座するものだった当時、
新進気鋭のLisperだったことは確かで日本で最初のLisperであってもおかしくはないよ。
ただ最初のLisperという記述が存在するなら、掘り下げて知りたかっただけ。
和田英一氏の話をみつけたが、日本には1964年にIBMがLispを持ってきたのが最初みたいね。
https://www.youtube.com/watch?v=w8IxEQmtjSE
LISPというもの自体は1960年には日本でも知る人はいたらしい。

っ「情報処理シリーズ4 LISP」by ウィンストン＆ホーン

知らんけど学術論文にでたら読んでる人は沢山居るんじゃないの？

当時の日本の「業界」なんて狭いもんだろ。
もちろん業界の人は読んでた可能性はあるが、
絶対数が少なければ沢山の人が読んでたというわけじゃないだろ。

>>637
楽しんで。3版はわからないけど2版まではM式のことも書かれていたよ。
竹内先生の本でも引用されてるね。
初期の理論的、実験的なLispの雰囲気が感じられると思うよ。
パソコンの黎明期、その本で勉強してZ80や6502で自作した人が多かったんだ。

めんどくさいなぁ。じゃあこれならいいだろ。

中西先生
日本が世界に誇るLispの第一人者であり、日本のLisp黎明期に
大きな貢献のあったお方。
Apple-Lispで広くLispを普及させることに尽力された。

なんでそこまで固執するの？
精神病なの？
信者なの？
間抜けなの？

てす

Ltkってポータブルなプログラム作れる？
例えばwindowsで事前にtkが無くても動くバイナリを配布したい

ltkってwishを操作してるだろ
wish用意しないと動かないんじゃないかな

>>651
くーっありがと

インタプリタとREPLって違いますか？

インタプリタじゃなくて対話モードでした

Read-Eval-Print-Loop の略であることからもわかるように、 REPL は eval の概念を持つ LISP の用語。
LISP における対話モードのことを REPL というと理解していい。
今では拡大解釈されて対話モードのことを REPL と呼ぶ場面は多いので、
非公式な場面では違いは気にしなくていい。
公式なドキュメントの類では用語の意味を厳密に定義していることもある。

>>655
ありがとうございます

>>629
LISPの古典ならマッカーシーの書いたこれで間違いない
タダで読めるし
http://www.softwarepreservation.org/projects/LISP/book/LISP%201.5%20Programmers%20Manual.pdf

>>652
wishも入れて配布すればいいじゃん。
ライセンスがGPL系で良ければGTKでもいいし。

LISP × GUI × マルチプラットフォーム　で最善のツールキットを探す道
McClimがwindowsで使えたら良かったんだけど

scheme系だけどracketじゃ駄目？

Lispって、ネストのオンパレードで全体のコードが記述されるのが
きもくもふつくしい点であるという認識でおｋ？

>>661
お前のいう、ネストのオンパレードで全体のコードが記述されてるLispコードを教えてくれ
何いってるのかさっぱり分からん。
a(b(c(d(e(f(g())))))) か
x=g();x=f(x);x=e(x);x=d(x);x=c(x);x=b(x);x=a(x);return x; かってこと？
どちらでも書けるよ

>>661
ｴﾍﾍ
前から後ろから責められて
一組終わるとまた次の一組に前から後ろから責られて
朝まで寝かせてくれないの？
(sub1 (sub1 (sub1 (sub1 onna ))))

もういや！好きにして
ｴﾍﾍ
(((lambda (f)
( (f f)
(f (lambda (x) ((f f) x)))))
(lambda (r)
(lambda (n))
(if (=< n 0) 0
(r (sub1 n))))))
108)

煩悩よのう、108回も射精されちゃうんだぁ

こいつはひでぇ

よかったなお友だちができて

=< がつかえる処理系って何？

ｴﾍﾍ
スマホでうったから少し間違ってるけど、だって女だって彼女と思って入れちゃったら強姦罪でつかまっちゃうことよくあるだろ？
でも少し修正
誤 (lambda (n))
正 (lambda (n)

誤 =<
正 <=

男は黙って順番守って不動点前から後ろからコンビネーター

>>666
定義すればどの処理系でもつかえる、イミフだけど

>>666
ghci とか

厭味ったらしく疑問形で攻撃する奴って、人としてなんか嫌だわ

どちかというとLispの話題関係なしに人格がどうのとかいう奴の方がうざい
prologライクな処理系でも=<採用してるかもしれんだろが

最近Lisp以外でもメタプログラミングの話題を見かけるようになってきたけど、
パターンマッチで書けるマクロは別にS式でなくてもいいのか。

ポールグレアムのエッセイを読みかじった限りでは、本気でメタプログラミングしようとしたら必然的にS式みたいな見た目になるとあったが・・・

>>672
S式で構文組むのと、中置記法で構文組むので、どっちが楽だと思う？
中置記法は考えなくちゃならないことが沢山あるよ。やることは同じなのにね。
センスがない人が作った構文規則を読解する大変さもS式とは比べものにならないと思うよ。

逆ポーランド記法いいよ。

いやどうだろう
(+ 1 2 3 4 5)とかできないし(1 2 3 4 5 + + …て数える必要ある。1個足りずゲームオーバー)
制御文とか気持ち悪いし
S式も気持ち悪いかもしれないけど
頭のシンボルで何が起こるか一貫して判断できるのは楽だよ

LISPを学び始めた時に一番戸惑ったのは、
関数呼び出しとマクロ呼び出しの構文が同じということだった。
その関数またはマクロの定義を知らないと、
全部の引数が評価されるかどうかすらわからないという。

それはよく言われることだな。 括弧の意味が場合によって異なる。
可能な限りは、関数呼出しとマクロの区別を意識しなくても自然に書けるようにデザインすべきだけど、混乱してしまうことはあるわな。
結局はトレードオフの話で、 LISP は全部が括弧っていうことの利点の方が大きい方を取ったってことだから、
欠点の方が上回ると考える人は諦めるしかしゃーない。

評価モデルに興味がない俺は勝ち組だな…

>>674
逆ポーランドは、記法というより、入力として優れてるな。
つまり電卓にピコピコと打ち込んでいくとき。
エディタとかでソースを（行ったり来たりして）自由に編集できるような時には、また別だな。

スタック型言語ってやつだよね。postscriptとか

Postscript派生のPDFもね。

Forth

>>676
関数呼び出しとマクロ呼び出しの構文が同じで戸惑うやつって一定数いるよね。
ある程度の命名規約みたいなゆるいものはあることが周知されてないってことなのかな。
でも、戸惑った経験のある奴に話を詳しく聞くと中途半端なんだよね。
(set! x 3)のx、(if a b c)での、b c、(define (f x) )での、f、xなどの評価で悩んでる人はいないみたい。
不思議だよね。

(push stack 1)とかを関数で作ろうとしてはまるんじゃないかな
(define stack '())
(define(fpush stack o)(set! stack(cons o stack))stack)
(define(fpop stack)(if(null? stack)#f(prog1(car stack)(set! stack(cdr stack)))))
正しくは下のようなコードかマクロ
(define(make-stack)(list 'stack))
(define(fpush stack o)(set-cdr! stack(cons o(cdr stack)))stack)
(define(fpop stack)(if(null?(cdr stack))#f(prog1(cadr stack)(set-cdr! stack(cddr stack)))))

Lisperって世の中の何の役にも立たないのに態度だけでかくて嫌だわ

だって頭いいからね

Lisper(のふりをしたLisp齧っただけの選民思想持ち)
の声が大きいせいでlisp使ってると変な目で見られて迷惑

俺のそそり立つﾁﾝｺ見てもそう言えるか？ああん？

逆恨みアンチのいない言語ってないのかねえ

BASICならいそうにないなあ
ｲﾙﾉｶﾅ

Lisp使っている時点で馬鹿確定だわな

好きなCommon Lispで新しいWeb開発を〜京大中退、22歳のサムライトCTOが取り組んだシステム再構築
http://engineer.typemag.jp/article/somewrite_cto

Cより速いCommon Lisp
http://togetter.com/li/740107

サムライトはCommon Lispという最先端の技術を使う数少ないWeb企業です。
http://blog.8arrow.org/

3月5日 (木) に「Clack Meetup #1」というイベントをサムライト株式会社のオフィスにて開催します。
http://blog.8arrow.org/entries/2015/01/20

なぜなら、僕を理解するにはまずCommon Lispを理解しなければならないからです。Common Lispとその言語思想を理解することで、ようやく僕がこれまで生み出してきたものを理解するに至ります。
http://nitro-idiot.hatenablog.com/entry/2011/11/11/222814

>>691
劣等感滲み出る書き込みだね

Common Lispのコードは醜い

http://benchmarksgame.alioth.debian.org/u32/performance.php?test=nbody
LispがCより速いとかデマに騙されないように

↑だまされないように

Cより高速なCommon Lispコードを書く
http://blog.8arrow.org/entry/2014/10/23/063044
＞Cの「http-parser」より6.4倍高速です。
＞比較対象のCのhttp-parserはNode.jsで使われているものなので、
＞かなりの高速化が施されていると推測されますが、それを
＞Common Lispに移植したら少しだけ速くなりました。
＞処理系依存のハッキーなテクニックを使ってるわけでもなく
＞標準の機能だけで。

標準の機能だけでCより6.4倍高速ですが何か？

>かなりの高速化が施されていると推測されますが、
これは空想だし、
>>695
現実は殆どのケースでトリプルスコアで負けている
騙されてはいけない

Lisp:よくある誤解
http://practical-scheme.net/wiliki/wiliki.cgi?Lisp%3A%E3%82%88%E3%81%8F%E3%81%82%E3%82%8B%E8%AA%A4%E8%A7%A3

LISPは速い - 翡翠はコンピュータに卵を生むか
http://d.hatena.ne.jp/masatoi/20100118/1263741706

ろーてく - ブログ Common Lisp 早い!?
http://lowtech.oops.jp/modules/weblogD3/details.php?blog_id=84&cat_id=12

:: Lispって意外と速い？ | 世界の半分〜まじかる☆ちきんれーす ::
http://halfworld.jugem.jp/?eid=130

LISP ベースの「世界最速」 (と作者が信じる) ウェブサーバ - スラッシュドット・ジャパン
http://slashdot.jp/developers/article.pl?sid=09/05/28/0218247

リリカル☆Lisp開発日記 » Blog Archive » LispをCより速くする

Island Life - 「Cで書くコードの方がCommon Lispで書くより速いって人がいたら、それは彼のCの技量が高すぎるってことだね。」
http://blog.practical-scheme.net/shiro/20100620a-lisp-speed

Lisp は「C 言語並みに速い」「C 言語より速い場合がある」
http://valvallow.blogspot.jp/2010/06/lisp-c-c.html
http://blog.bugyo.tk/lyrical/archives/219

>>695
Cより速いのひとつもないのが現実

>>687
そういう構造ってどこにでも見るよね
権威主義的なやつがハクつけるために嗅ぎ付けて来ちゃう

最近馬鹿にされがちな意識高い系ってのもまるごと
そういう振る舞いに憧れて量産された馬鹿のことなんだよな

LispはCより速い、はざっくりしすぎてて誤解も生むけど、
CommonLispがRubyやPythonより大体100倍のオーダーで速くてCにも迫れる位の認識は広まったから良いんじゃね？ってところだな。
言われなければ、CommonLispはRuby位の速度だって思ってるんじゃないかな。

> 言われなければ、CommonLispはRuby位の速度だって思ってるんじゃないかな。
俺そういう認識だったｗ

直線を走る速度ならCの方が速いけど
ゴールまでの近道を見付けるのがLispの方が速くて
そこが勝因になることがあるってこと

体育系のCに頭脳派のLispだからな

勝利おめでとうw

>>699
発想・設計から保守まで含めた速度で考えればLispでも何とかCに対抗できるはず

>>704
断言するが、Cの方が頭を使う
実務的には、5月に、昔作ったCのコードを保守できる人がうちの会社から消える

頭を使わされる。では？

もっと言えばプログラムの本質でないところに頭を使わさせられる

>>707
それは頭を使うのいみが違う

そのくらいわからんのか

うちの会社は面接でいきなりLispの話するやつ採用しないから

魔除けになってお互いにWin-Winじゃん

(;´Д`)ﾉθ

>>711
いきなりだったら何の話でもどこの会社でもダメだ
バカじゃねーの

履歴書に書かないとな。
「リスプできます！」って。

面接の前に、参考に自分で作ったlispのコードを送ったことならあるわ

相手が読めなきゃしょうがないよね…相手によりけり。
で、採用されたんですか？

Lispの世界をこれから学ぼうと思ったら、SchemeとCommon Lispのどちらに入門すればいいの？

どっちも同じようなもん？

>>718
どっちも学べ
The little schemerと
Land od Lisp買っとけ

どっちもかぁ、そうしたいけど時間がないっす

wiki見るとschemeはミニマムを目指してるみたく書いてあったから、先にschemeトライするのが正解に思えてきた。
ま、入口で悩んでる時間ももったいないですしね

>>720
用途によるな
将来的にLispを使うのならCL
継続などを学びたいだけならscheme

Lisp系の最大の強みはマクロだから、CLを学ぶのがいいと思う。
Schemeはまともなマクロを標準化できてない。

schemeやるならhaskellの方がいいような気がする

>>718
Schemeで。
相性悪かったらこの世界とはおさらばで。

じゃあ、Little Schemerと鉛筆で。

ちょっと離れてる間にコメたくさん！
さわりだけならすぐ一回りできるらしいし、schemeの処理系入れたんで弄ってみます

>>722氏のコメントは頭に置いときます。アドバイスありがとうございます。

>>725
Theが抜けてます

>>726
>>722なんか意味ないよ
とりあえず初心者が学ぶ段階では

俺もThe Little Schemerをすすめるな
1章から7章までは多分を簡単
「バカにしてるのか？」と思うかもしれない。が、しかし……

ま、8と9章で向き不向きがわかるかな
そこで挫折する人は多いだろな、この前もここで「諦めた」って人いたし。
最後はインタープリターつくるんだが、前章までわかってりゃ楽ちんかな
ま、頑張ってくれ
俺もThe Little Schemerやったよ
あ、特徴をひとつ。セルには触れない。あくまで記号処理の枠でやる。

>>728
9章のお題YCをもういちどTheLittleSchemerの最初から追っていけば今度こそ理解できるかな‥これから本屋だ

マクロを触らないならlispやる意味無いよ
専用の構文がある言語の方が良い

木構造ならlispでしょ

木構造を弄ってlispのコードを生成するとかね
関数型プログラミングがしたいだけならlispよりもっと向いてる言語がある
the little schemerは読む価値あるけど

マクロは後回しで良い。

Lispなんて何やっても役に立たないから
好きなのやれ

「役に立つ」の意味が「企業の製品として稼働している」なら、役に立つのは圧倒的にアセンブラとCだしな…
Webアプリや携帯はjavaが多いけど、Webサーバまでみるとlispがいまだに幅を利かせているという現実

あえてClojureからとか

WebでLispとか
ごく少数の過去の遺物ですよ

>>728
丁寧に教えてくれて嬉しいです。little schemerはkindle版ないのが残念だけど、本屋で覗いて見ますわ。
実は上に書き込んでから「独習 Scheme 三週間 」ってサイトを見つけてのめりこんでましたよ。

重ね重ね、皆さんレスありがとうございます

>>737
allegroserve に Lispache、最近は >>692 かな

正気な人間はそんなもん使わないだろ

役に立つ・立たないにこれだけこだわるのは
正気じゃない役立たず

プログラマはみんなプログラミングに狂ってるはず。

>>729
わかると思うよ
自分自身へのポインターを確保するために引数をひとつとって無名再帰させる話でしょ？
それがわかば適用順Yコンビネーターは割りと単純は変形
要するに適用をラムダ化して引数化していく

躓いたところはここで聞けば？
わかる範囲でこたえる

>>743
thx

Lispマシンとかアプリケーションが落ちても編集途中のデータが生きてるから
アプリ立ち上げなおせば作業再開できるとかオーパーツレベルの過去の遺物
だよな。。。

>>720
Scheme がミニマムを目指してるってのはよくある誤解。
議論を徹底するので無闇に膨れたりはしないけど、議論した結果として機能を増やすことになれば増やす。
議論でまとまらなければ未定義になるので結果的に未定義だらけで今のところ仕様は小さいってだけ。

未定義の部分はそれぞれの処理系がそれぞれの作者の考え方で作るから、
そういうところも含めれば実態としてはそんなに小さくもない。

>>718
教養としてSchemeは学んでもよいとは思う。
けど、ある程度理解したら新しくてメジャーな言語にした方がいい。
経済的な問題もある。

Schemeに馴れた頭でCLみると
「確かにそうできるけど、なんかイケないんだぁ。先生、この子、なんかズルしてます！！」
って感じぃ
1. nilが意味し得るもの
2. (car nil), (cdr nil)がエラーにならないこと

ま、それに慣れてるとSchemeって
「おまえ、どんだけ融通効かないの？記述が冗長になるだろうが。これだから模範性は！！」
って感じぃ

>>748
ｔ先生とａ君かよ

>>745
> オーパーツレベルの過去の遺物

オーパーツの意味わかってないだろっｗｗｗ

オーパーツ的な何かであるというのは間違ってはないんじゃないか

>>750
オーパーツその殆どが現在の技術で作られた偽物って意味の方かｗ

アプリケーションが落ちても編集途中のデータが生きてるというのはある意味素朴な仕組みということであり、
それを紹介していた人もそのように紹介していると思ったがね。シングルユーザー的利用には利点ありということだと

>>745
すまん。あえて使い方が間違っているとすれば「過去の遺物」のほうだった。
もちろん「（過去の）遺物」のうち特殊なものが「オーパーツ」なので一概に間違いではないのだけれども
IT の文脈において「過去の遺物」って、たいがいネガティブな意味合いでの使い方
http://ejje.weblio.jp/sentence/content/%E9%81%8E%E5%8E%BB%E3%81%AE%E9%81%BA%E7%89%A9?catId=computer
が一般的だから、同じく IT の文脈における「オーパーツレベル」「オーパーツ的」の持つ
「そんなのが当時すでにあったのか！」というポジティブな印象と矛盾してたのでつい反応してしまった。
反省している。

スクリプトとして使うのに#!だけで足りるのと#!??!#のとはどっちかにしろと思う

>>748
そもそもLisp族は他言語の良さげな機能を容易に吸収できるようにできているのだから、清濁合わせ飲む度量が必要なんだよな。

>>756
意味わかりませーん
僕ってネトウヨじゃないからぁ

>>756
SchemeはLISPじゃないからな
>>757
障害者

Scheme is a statically scoped and properly tail recursive dialect of the Lisp programming language.
　　　　　　　　　　　　　　　　　　　　　　　-- Revised7 Report on the Algorithmic Language Scheme

Schemeで(car '()) -> '() な処理は簡単に実現できるしCommonLispで (car '()) をエラーにすることも簡単なので議論する価値がない

>>758
あたまわるすぎぃ！！

>>760
ば、ばかだぁぁぁぁぁ！！

>>760
(car '())はnilがいいなぁ

こんな感じか。

(import (except (scheme base) car)
(scheme write)
(prefix (only (scheme base) car) r7rs:))

(define (car p)
(if (null? p) '() (r7rs:car p)))

>>763
(car '()) -> '()はバグの温床だと個人的には思うが (fifth '(1)) -> '() のような挙動が便利というのも分からんでもない。使い所によるな。

c*rがnilでnilを返すのがバグになるってよく言われるけど自分はまだ遭遇したこと無いな

(f*ck '() '()) -> (())

個人的帰納主義かよ

>>766
そういう類のバグだからそうだろうな

乗り遅れたかもしれんが、
Lispでなにを選べばいいかわからんというなら
覚えるものが少ないSchemeの処理系がよくないか?

やっぱりなんだかんだ言ってSchemeはminimalでしょ

んで、日本で一番勢力のでかいGauche

CommonLispはSchemeが使えれば使えるでしょ。
本質的に変わるところはない

gaucheなんてマイナーなものよりsbclの方がいいよ
quicklispあるし

時代はCCL

>>770
今だとclojureが一番使い心地は良い
つか学習ならMinmalなLisp1を自前で実装してとかじゃないの？

lispにもlighttableみたいなエディタほしいです

>>774
schemeだと一部しか使えないけどemacs+swankでいいじゃない

>>771
便利だよねぇ。
アプリがインストール不可な職場のPCに入れてる。

他の言語のも欲しいがEmacsべったりなのはCommonLispだけなのか。
せめてSchemeのが欲しいよう。
(PortablePythonは入れてる)

>>773
Clojureどうなの?
末尾呼び出しの最適化がだめなのと、
List至上主義ではなくArrayとか使えとか読んでちょっと敬遠気味。
(うろおぼえなのですまん)

Swingが使える言語はすごい期待できるんだけどなぁ。

Scalaより関数型言語でしょ ?

SBCLはWindowsでスレッドがサポートされたら使いたい

Lisp Schemeだけでなくてすまんが、
Windows, MacOSX, FreeBSDでポータブルな
グラフィックライブラリと関数型言語の組み合わせを探してる。

OCaml + LablGTK
Haskell + wxHaskell
はけっこー環境構築が大変な気が

Clojure or Scala + Swingはなんとなく気が引ける。
末尾呼び出しやList至上主義はやめるべき ?

最近ではWindowsだけでいいよってなことで
F# + .Net
でいいやと思っています。

>>778
CCL and GTK

clojure良い言語だしtcoなくてもloop/recurあるしleiningen便利だし
ただエラーがjavaのそれなんで初心者には厳しそうな気がする

clojureは、安心して再帰最適化に頼れないのが難点

HaskellはGtk2hsがコンパクトだった記憶

Clojureはエラーメッセージがほとんど意味を成してないのが難点

日本語で責めてるのにスワヒリ語であえぐ女みたいだな
ｲﾐﾜｶﾗﾝ

Clojureのシーケンスは実際に何で実装されてるかは開けてのお楽しみという言いしれぬ気持ち悪さがある。

>>778
CommonQtもいいよ。今はGTKよりもQtの方がポータブルなんだな。
LGPL化されたことだし。

abclという選択もある

>>784
hashmap食わせてもシーケンスで[k v]受け取るとかのことかな？

今自分が感じるClojureの最大の魅力はリテラル表現が最初から多彩な事だったりするんだけどああいうのschemeとかclとかだとreader macroになっちゃうからめんどくさいんだよな
;; 逆にclojureはreader macroの自由度が無いんだけどね

Lisperは時代遅れのゴミカス
早く死滅しろ

みんな3月になったらどこ行くの？

Reddit以外無くね

navi2chスレはopen2chとかnext2chとか行くかも。
navi2chで書き込めるから。

redditなんてまじかとおもったが移民してるとこもあるんだな
http://www.reddit.com/r/newsokur/
やっぱopen2chとかじゃね

新月をCommon Lispで実装しようという猛者はいないのか

>>786
( ) と [ ] と { } が入り交じるコードはマクロ書きにくそうというか、プログラムをデータとして見たときに扱いづらそうなんだよな。

[] {} は, "" みたいなもんだからマクロで混ざったりしないだろ.
それとも文字列を'(#\h #\o #\g #\e)と書いた方が良いって話か.

文字列の中は文字しか入らないからいいけど
[] {}の中にはS式が入るからややこしくなるってことだろ
clojureしらんけど

>>793
え？マクロ書くときにリーダマクロでの評価とか気にするのならともかくマクロでList,Vector,Hashとかを表現として区別することなんてあるの？
渡されたリストの要素が何かって知る必要はあるけどリテラル表現とか気にしないよね？

>>796
(defmacro my-let [[var val] & body]
`((fn [~var] ~@body) ~val))

(defmacro my-let2 [[var val] & body]
(list (cons 'fn (cons (vector var) body)) val))

逆クォートじゃなくてリスト操作でプログラムを組み立てたいときとか

もう少し良い例はないのか. もはや自説を通したいだけに見えるが.
clojureに関しては
(['a] 0) -> a
({'a 0} 'a) -> 0
なところがマクロ定義で式操作場合でも都合良いなとしか思えんな.

>>787
心配するな。いずれLisp系は絶滅する。

EmacsとかD-Waveとか
まあEmacsはいい加減どうにかすべきだとは思う

そこに颯爽と xyzzy が

勉強始めたばっかなのにそれはないよ

>>802
安心するとよい、コンピュータのパラダイムが変わらない限りLispは滅びることはない。
絶滅しても同じ発想に至ればまた生まれる。(つか絶滅するまえに常になんかにょきにょき生えてくるし)

畳の下から生えるキノコみたいな言語だな。
COBOLやJavaのように産業界を支える日は来るのだろうか。

>>804
産業界の床下開けるとわかるんじゃねぇの？

まともな人はみんなredditに移ったのかね

ASTを直接書く、ってアイデアは偉大だ。だけどそれ以上が出てこないのはlispの停滞を意味している。
このままlispが無くなることはないけど、進歩はあるんだろうか？

>>807
AST (というか厳密に言えばそれに近しいリストだが) を直接書くのをやめたら、それ LISP って名乗れると思う？
LISP インスパイアな新しい言語じゃね？
そういう言語がどんどん現れてもいいけど、そういうのも LISP に含むってのは無理がある。

>>801
うーん
遅いしぃ

(´・ω・`)
M式…

最近OCaml触ってみたんだけど使い心地がSchemeに似ていて
M式が有れば、こういう感じだったのかなって思った

>>811
SMLの方がもっとSchemeっぽいよ。

>>811
M式はもっとちがうな。アレンの「Lispの構造」
を読んでみるといい。

昔はマクロ書きまくってたけど最近はバグの温床になりやすいから本当に必要な時か特定用途のマイクロ言語を入れる時しか書かなくなった
最近は gauche の pa$ や cut や $ .$ なんかを多用して関数合成で書くことにしてる
こっちのがモジュラリティ高くなる

デバッグしにくいってのはマクロの大きな課題だよね。
マクロ用のデバッガとかが必要なんだろうけど。

>>815
展開した先でエラーが起こったときに元のマクロを特定するための情報を残しておけばできるのかな。

カッコが重なった見づらさといったらない
大中小カッコ自由に使えるようにならんの？

特定のクラスとそのサブクラスについて、make-instanceの処理の前になんかしたい場合ってどんな方法がありますか？

(defmethod :around make-instance ((class 'standard-class) &rest initargs)
(if (subtypep class particular-class)
...
(call-next-method)))

こんなんしか思いつかないんですが、いろいろよくない感じがします

あ、:around変なとこに書いてるけど、closでの話です、すみません

>>817
>カッコが重なった見づらさといったらない

適切な字下げと慣れの問題では？
ASTに近いものを直に見せられることからくる見づらさは括弧の問題ではないし。

>大中小カッコ自由に使えるようにならんの？

lexerレベルで同じ括弧トークンとして扱うだけ。

>>814
まあ用意されてるマクロ使う方が安心な気はするよな。

ま〜、ロクなことにはならんよね
マクロだけに

Gauche や Racket くらいになると欲しいなと思ったものはだいたい揃ってるから、
実用的には良くてもなんだかつまらないかも。

LISP勉強はじめました。
ただ非常にもやもやしていることがあります。
LISPerってやっぱり大学でちゃんとコンピュータサイエンスを学んだ人が使っているイメージですが
自分は専門学生です。
後ろめたいというよりは、他のLISPerに笑われるのが怖いです。
自分のような低学歴がLISPを学ぶことは問題ですか？

そんなの聞いたことないわ

> LISP勉強はじめました。

ここだけで小便漏らして喜ぶ

>>824
昔はすごいLisperがいたけど。最近は大したことはない。
ざっくり学んだら新しいタイプの｢言語に移った方がよいと思う。

>>824
コンピューターサイエンスの人たちはHaskellやML系に移っていると思う。
PythonやRubyにも流出していると思う。

>>827
いま自分は、Perl, Java, C, C++がつかえます。
LISPは、将来仕事で使うためではなく
自分で何かを作るために学ぶはじめました。
本を読み始めて、LISPer（＝ハッカー）とはこういうものだ、
とういうような書かれていることについて、
自分は全くそういうものには程遠く、
そのギャップ？（自分でもよく分かっていない）に苦しんでいます。
問題は言語そのものではなく文化や哲学、思想などです。たぶん

数学も満足にできない自分が情けない

何も言わずにガウスの消去法を実装しなさい
実装できればLISPerを名乗り、このスレに参加しなさい

ふふ、かく言う私も低学歴でね…(´・ω・`)

>>829
とりあえず"SICP"を読んでみるといいよ

ttp://mitpress.mit.edu/sicp/
ttp://sicp.iijlab.net/

あとハッカーの文化や哲学、思想については
"how to become a hacker"を読むといいかもね

ttp://www.catb.org/esr/faqs/hacker-howto.html
ttp://cruel.org/freeware/hacker.html

自分で考えてきました。

SICPについてはもうすこしあとになりそうですがいずれ読みたいです。
how to become a hackerはいまから読みます。

みなさんありがとうございました。
はやくレスが来て助かりました。
みなさんのお蔭で前向きに考えることができました。

結論からいうとこれからも続けることにしました。
自分のやりたいことのためには自分の使いたい言語が必要です。
大卒にも笑われない一人前になりたいです。
では、ガウスの消去法を張り付けるまでROMになります。

>>818
stackoverflowで質問したら？
ここは思想とか自転車置き場の議論ばかりなので処理系に具体的な質問に返事はないよ．

色々良くないとか書かれても，察するのが面倒なので具体的に書いて欲しい．
副作用だけで良いなら:before，なんやかやするなら:aroundで良いんじゃね？
(defmethod make-instance :before ((class 特定のクラス) &rest initargs))
何が駄目なの？ subtypep 使ってる意味が分からんけど．

>>835
質問の仕方が悪くてすみません
ここでの特定のクラスというのはメタクラスのインスタンスとしてのクラス(つまり通常の文脈でのクラス)なので、
(defmethod make-instance :before ((class 特定のクラス) &rest initargs)
では引っかからないです

>>818で個人的に問題だと感じているのは、基本的にすべてのクラスはstandard-classのインスタンスとして作られてるので、

1. すべてのインスタンス生成時の処理に割り込んでしまうことと(大体６倍くらい遅くなる)、
2. 他にmake-instance :aroundを書き換えるようなライブラリなり何かと競合する点

だったのですが、とりあえず1.は適当なメタクラスを用意してcloser-mopでdefclassに介入することで解決できたので大丈夫です
今後はstackoverflowを検討することにします

> すべてのクラスはstandard-classの...

すべてのクラスは間違いです
普段使うようなクラスと読み替えてください、すんません

>>836
> とりあえず1.は適当なメタクラスを用意して
とりあえず，というかその方法が定石な気がするけれど．
2の競合については別途メタクラスを用意しているのであまり心配する必要もないと思うが．
逆にstandard-classと同じように書けないのが面倒だがマクロでごにょごにょするのが定番．
とりあえず，mopについて答えられる人間はここにはいない．
stackoverflowには居る(日本版でも可)．

>>838
metaclassでやるとdefclass時にいちいち指定しないといけないのが嫌だったので、>>818みたいなことになってました
c2mop:ensure-class-using-classをいじれば

> 逆にstandard-classと同じように書け

るようになったので、今度はこの部分の競合がちょっと心配ではあります
stackoverflowはいいところそうなのでそのうち移ろうと思います
どうもありがとうございました

the little schemer が届いた、gauche をインストールした、訳者文、序文、はじめにを読んだ
ガイドラインによれば「急いでこの本を読むな」ということだし、疲れたので続きは明日‥

redditに次スレが立ったようです
ttps://www.reddit.com/r/lisp_ja/comments/2x4v7k/lisp_scheme_part_40r/

>>840
おーい、「明日」が終わるぞぉ

明日は明日です

バカはレス禁止ね

昨日は gauche のインストールで疲れて寝た
今日は第二章の途中、lat? のインプリメントを読んだ
cond の括弧の使い方とか混乱する、というか括弧に気をつかっていないが、それでいいのだろうか？

おにぎりの人ありがとー

型つきLispで一番良いのってどれなのでしょうか
typed racketが一番将来性ありそうだけど妙なバグがまだある
shenは機能も使えるライブラリも少なすぎる

Common Lisp

>>840
gaucheって学習用じゃないからまともなデバッグ機能はないぞ。
トレースさえない。Racketの方がいいんじゃないか？

たかがThe Little Schemerやるのにデバッグ機能などまるで不要

デバッグ機能とかけてThe Little Schemerと解くと「たかが」となるのであって
The Little Schemerは良い本だ
続編のThe seasoned schemerも薦める

>>849
アドバイス感謝、racket のチュートリアルで赤黒縞々を書いて楽しんでいた、gauche にトレースはあった気がする、ダンプみたいなのが延々出てくるやつだったかな、が、ともかく忘れた
でも、実体はよくわからないが親切そうなので、当分racketでやってみる
racket チュートリアル半分で疲れたので、続きは明日‥

little schemerこそ黒板とチョークか、紙と鉛筆で読めるほんじゃまいか。

Racket は大分気の利いたデバッグ機能が付いてるよなあ

>>851
それとatom?は標準手続きに無いことに気づかずはまりやすい。
冒頭に説明があるが目立たないので注意が必要。
再帰を理解できたらもっと一般的なコンピューターサイエンスの本を
あたったらいいと思うよ。

>>851
最近になってRubyで説明されたやさしいコンピューターサイエンスの本が
でていたと思う。

　　　　　　　　　　　　　　　　　　　　　　 　　　　　 　　　
;;;;;;;;;;;ヽ　　　　　　　　 _,, -ｰ-､　 ,r
;;;;;;;;;;;;;;;|　　 　 　 ,,r';´;;;;､ﾐﾐﾐﾐﾐ∨;;_;;;;;;;;;;;;;;;;;｀ヽ,
;;;;;;;;;;;;;;;;|　　　 ／;;;;;;;;;;;_､､-''´ﾆﾆ ,__ ｀ヽ;;;;;;;;;;;;;/
;;;;;;;;;;;;;;;;;|　 .／;;;;;;;;;／_, -''´::::;:;::::´￣｀''' ';;;;;;;;/　　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
;;;;;;;;;;;;;;;;;;|／;;;;;;;;;;;/　´.＿::::::::::::::::::，-､ 　':;;;;/　　　　　／　　
;;;;;;;;;;;;;;;;;;|＼;;;;;;;;;;|　　‘ｰ''´ ,　　　､￣´　　V､　　　 ＜　　　 　ハァ？　　意味わかんねえよ
;;;;;;;;;;;;;;;;;;|　 ＼;;;;|　　　 　 ,( ● ●）､　　　 nヽ　　 　 ＼ 　　
;;;;;;;;;;;;;;;;;|　　　.>y　 　 　,'　　　　　　',　　　lﾞ) }　　　　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
;;;;;;;;;;;;;;;;|　　　lﾞ n　　　　l　 _,,．--､,　i 　　 |､ﾉ
;;;;;;;;;;;;;;;|.　　　', !〈　　　　',/r,二⌒ﾕヾ_　　 j
;;;;;;;;;;;;;;|　　　　ヽ_∧　　　 ''''´￣￣｀　　　ｲ　　　　　　　　 __　　　　(　　丿
;;;;;;;;;;;;;|___,, -'''⌒ ヽv＼　　　　　　　__,,ｨ　|　　　　　　　　/,ハ　　　　)　ﾉ　　 ﾄﾞｺﾏﾃﾞｸｽﾞﾔﾈﾝ
;;;;;;;;;;;;|ｰ- ､_ 　　 　 ｀ヽ`ヾ､ｰ''''´｀´　　;　j　　　　　 r(ZZyZZZZZZ■
;;;;;;;;;;/　　　_,＞､　　　 ｀ヽ, ｀丁`l　　　;　√`-､　　 ｀ヽ ｀"　//// 〉
;;;;;;;;;|　　　´　　 ｀ー､　　　 ＼|　 ゝ､　　,〈　　/ 　 　 　 ゝ､,,_｀´´ノ
;;;;;;;;ﾉ__　　　　　　 ｨ´｀ 7ｰ､　　　　ヽ＼ノノ） ﾊ　　　　 　 ﾉ　　 /
;;;;;;/::::::｀ｰ-､__　　 | ___,|　　ヽ　　　　　 ｀V／　'.,　　　　/`ｰｧ ｨｿ
;;ノ:::::::::::::::::::::::｀ー-Lユゝ,　　`i　　　　　　　　　 |　　　/　　 l//
:::::::::::::::::::::::::::::::::::::::::::::::::::ゝ,､､ l　　　　　　　　　 |　 ,r个 ｰ−ｲ
:::::::::::::::::::::::::::::::::::::::::::::::::::::lj |.|.l|　　　　　　　　　 |. /　�U　　 j
:::::::::::::::::::::::::::::::::::::::::::::::::::::´ lj.ﾘ　　　　　 　 　 　 |ﾉ 　　　　　|
.

　 .

>>855
http://www.oreilly.co.jp/books/9784873116976/

SICPじゃあかんのかぁぁぁぁぁ！

もう両方読めよ。
古いのは長い年月の淘汰を生き残ったんだから立派なもんだろうし、
新しいのは新しい知見が盛り込まれてるだろうし。

>847
What is Gradual Typing: 漸進的型付けとは何か
http://qiita.com/t2y/items/0a604384e18db0944398

"オプションの型アノテーションを持つ言語には Common LISP, Dylan, Cecil, Visual Basic.NET, Bigloo Scheme, Strongtalk があります。"

なにやらCLとbiglooが入ってる。
そこで型推論やら型検査やらしてくれるのかはよく分からない。

26. Bigloo A practical Scheme compiler User manual for version 4.0b
August 2013 -- Explicit typing
http://www-sop.inria.fr/mimosa/fp/Bigloo/doc/bigloo-27.html

asm.jsも含まれるのかな?

CMUCL User's Manual
Chapter 5 Advanced Compiler Use and Efficiency Hints
Type Inference
https://common-lisp.net/project/cmucl/doc/cmu-user/compiler-hint.html#toc154

asm.jsは、GC止めてunsafeに自前メモリ管理させて高速化するという技法だと思う。

あれも一応型指定だよ。
型アノテーションが|0とかだけどw

型しばりアリのLisp族だとTyped Clojureが凄い好き
最適化の為に型指定もできるならCommonLispが好き

学習用じゃないからデバッグ機能が貧弱なんじゃなく、単純にgaucheはまだ機能が足りないんだよ
開発リソースの問題だろうけど、どうにかならんかなぁ

今後専ブラ組はどうするの？
俺はnext行こうかなと思ってる http://next2 ch.net/tech/ <- NGワードなので空白入れ
もう書き込めなくなりつつあるらしいが

Readdit併用
そもそも専ブラでも読み書きできるものはあるしな

>>866
開発者にその気がないからでしょう。コンパイラ最適化には前向きだけど。
デバッグはプリントデバッグでいいだろうみたいな。
デバグ機能の貧弱さはかなり前から指摘されてるのにね。

実用主義だろうと学習用だろうとデバッグ機能はあるに越したことはないよ。
開発予定に入ってるし。
http://practical-scheme.net/gauche/devinfo-j.html

?

RnRSってなんでデバッガを規格化しないん？

抽象度が落ちるから

リスパーは自由の海でこそﾁﾝｺそそり立つから

俺がageてしまったばっかりにへんなのが来てしまってごめん

俺のそそり立つﾁﾝｺ見てもそう言えるか？ああん？

>>872
なくていいと思ってるわけじゃないよ。 皆が納得する方法が出てきてないだけ。
デバッガって動作モデルとのかかわりが密接だから今の段階で決めちゃうと色んなところに実装上の制約が付いてしまう。
優先順位からすると後回しにせざるを得ない。

継続とデバッグクッソ相性悪そう

>>872
評価モデルをもっと詳細に限定しないとデバッガの規格化は無理かと…

>>873,877,879
CLのSLIMEみたいな環境作りやすくするためにあれば良いのにって思ったけど複雑なんですね。

>>880
Schemeの委員会では永久に決まらないと思うよ。

どちらかと言うと開発環境の話で、言語の話とは違うかなという気もする。
だいたいデバッガを言語仕様に入れてる言語の方が少ないだろ。 つーか CL くらいじゃろげ。

>>878
むしろ継続はデバッグに役立ったりするものだと思ってた

>>882
Smalltalk「CLより話題にされない」

>>884
言語仕様あったっけ？

>>885
ANSIの規格があるよ

Schemeも実用面の規格を決めるワーキンググループ作ればいいのに

>>886
R7RS-large のこと、ときどきでいいから思い出してください

>>887
仕様を大きく実用的にするんならCommonLispと変わらないのでは？
Schemeの存在意義は何なのだろう？

>>888
正しさ

インストールしたままずっと使ってなかった PLTScheme がいつの間に…

PLTScheme とか懐かしすぎる。ナウなヤングを取り込むために Racket って改名したんだよね。

>>888
Schemeが目指すのは弱点や制約を取り除いていくこと。
実用面での不足があるという弱点を取り除こうとするのは当初からの存在意義通り。

例えばだよ、Lisp一般の話として、他のプログラミング言語では構文を追加できないという制約をマクロで取り払った。
これは制約からの解放ではあっても現実としてマクロ機能を追加してもいる。
でも、マクロを追加するのは、必要だからたくさんの構文を追加しましょうというのとは違うだろ。

ニュアンスを説明し難いけど、結論からすると全然違うよ。

Schemeは言語仕様としてはコンパクトで拡張性のあるものにしておいて、
実用的な機能はライブラリとして外部化しましょうという話だった。
しかしネットワーク周りなど、ライブラリ単体では対応しきれない部分が増えてきて仕様が拡大する方向になった。

Common Lispの場合はそういう機能は処理系ごとの独自拡張になっていて、それらの違いを吸収するライブラリがデファクトスタンダードになっている。
まさにカオス。

scheme の弱点は未定義の多さじゃないの
REPLも決めてないのに弱点を減らしてるとか言われても

REPLは開発環境に属することなので言語仕様の一部として決めるべきじゃないと思うな。
仮に決めるとしても今というのは早すぎる。
何が正しいのかわからない段階で決めるってのは足かせになるだけ。
つまり今のSCHEMEはまだまだ未完成な存在であると同時に、
急いで決めるとろくなことがないという思いによってそうなってる。
未定義の中で現れて現実の中で鍛えられた実装を元に仕様にフィードバックするという形
なので、ちょくちょく仕様改定するというスタンス。

>仮に決めるとしても今というのは早すぎる。
20年後も同じこと言ってそうだ

つまり今決めること自体が弱点ということですな

>>896
結果的に時間はかかるんだけど優先順位の問題だよ。

ダークコーナーだったトップレベルの挙動がR6RSで一旦決まったけど、
あれにREPLを持ち込むと破綻してしまうということははっきりしてる。
拙速ではあったけど正しいと思う形に (それまで決まってなかった部分の) 挙動を決めたら
REPLがはじき出されたんだよ。
REPLが絶対に必要でそこでの挙動が明確でなければならないとするなら、
正しいと思う形を曲げ (妥協し) なきゃいけない。

最終的には妥協するにしても優先順位がどちらかというと
REPLではないな。

慎重すぎて女を口説けない男のようだな

理想が高すぎて、一度も社会に出ぬまま引きこもってる中年ニートみたいなもん？

>>899
せめて「理想が高すぎて現実の女に興味をなくした」って言い換えようず

>>899
むむむ、今の俺だ

>>901
自分が失くすのは構わんが、今後新規に関わる人も皆当然興味を失くすのが前提になったらアウト
単純に「世の中の動きから取り残された」状況にならんことを祈るよ

Schemeは世の中の動きに左右されない「絶対」を求めてるんだよ。
出来るかどうかは別として。

いわゆる、大統一理論ですね

little schemerってなんだか読めてないようなモヤモヤの残る本だな。
前に戻って読み返せばモヤモヤ晴れるだろうか？

Seasoned SchemerかSICP読んでから読み返せば？

ふたりともtheはつけろよ
ま、それはさておき
the seasoned schemerとか
先に読むのはどうかねえ
ま、それがわかって
「なぁあるほどぉ、そういうことで
ああだってのね」
となることはあるだろうが
俺はもう一度、概念を把握する、作り上げで行くという姿勢で読み返したほうがいいと思うけどな

>>906
その本はコンピューター専攻ではない学生のためのに
易しく再帰を説明した本なのだけど、逆に素質のある人には回りくどい。
もっと簡潔明瞭に書かれた本を読んでみては？

素質のある人がthe little schemerよむと
モヤモヤするのかね！！

>>898
うーん、たかがREPLもきちんと定義できないなんて…。
上の方で話題に出てたデバッガもそうだ。
現実的に有効な機能をきちんと定義するのに問題がある仕様なんて、穴だらけ過ぎるだろ。

「気に入らなければ自分で作っていいのよ」

そのとおぉりぃぃ！

むしろ立ち位置的には好き勝手に自分専用の言語に拡張するための土台の言語だなSchemeは

Scheme処理系自作してちゃんと使ってる人にはそれで良いね
ヒトサマの作った処理系の上で俺様拡張風味の何かをしたい人には制限事項にしかならんけど

それだとポータビリティーないじゃんか

>>911
C++ に REPL がないのは穴か？
(厳密にはあるが本来の意味を大幅に外れないと成立しない。)
REPL を含めて厳密な意味論を定められる言語仕様の方が特異だろ。
ただ、 R6RS はひとつの完成系ではあっても急ぎすぎたと認識したから
R7RS では R6RS を踏まえつつもだいぶん後戻りした。

>>916
色んな可能性があって、色んな実装が出てきて、
それでもやっぱり決まってしまったものが仕様になっていく。
今のところポータビリティがないという弱点はあるけど、
急いで埋めてヤワな土台にしてしまうのはSCHEME的でない。

規格だと思わなけりゃいいんじゃ
あくまでも実装の目安的な

>>918
健全な認識だなぁ
賛成

>>919
実際少なくない人数がデファクトスタンダードの明文化だと思ってるよ

汚かろうが何だろうが、とにかくガチガチに決めてしまわない事には、
実務で使われる日なんか永遠にやって来ないよ

>>922
もとも教育用だしな
実用したいなら現状ではCL一択だろ

schemeを実務で使ってる俺は異端か…

>>922
言語には思想があるんだよ
実用重視ならCL使えば？
逆にCLがあるからScemeは下手な妥協や拙速を避けてﾁﾝｺじっくりいじりながらジリジリ歩めるんだし

実務で使うといっても個人環境で勝手にひっそり使うのと、チーム単位プロジェクト単位部署単位企業単位で使うのとでは意味が違うな
日常作業に使うのと製品に組み込むのもまた違う

>>924
俺もそれなりに使ってるよ
今のSchemeでは無理な実務ばかりじゃないもんね
異様に仕様で決めろいってる人が言葉の定義のなかで実用後どうたらといってるんだろ
「今のSchemeでは耐えられない実務にはSchemeは実用的でない。今の仕様に対する思想ではとても無理であろう実務にはSchemeはいつまでたっても実用的とはならない」
意味ないこと言ってますよね
あたかもCLの思想でSchemeの試用を決めろといってるがごとし
CLとSchemeの違いを
F-BASiCとN88-ｂａｓｉｃのような方言性とでも思ってるんじゃないかしらん

ゲゲ、例えが古すぎたぁん！

プロジェクトのマニュアルの自動更新がscheme

GNUとはCとLispの環境であり、スクリプトはschemeで書かれる。
というのがストールマンの描いた絵だったはずだが。

>>929
gmake 4.0 のアナウンス見たときは正直笑った
ストールマンはきっと諦めない

ああいう使い方はちょっとなぁ。
いっそS式で書けるmakeみたいなのなら
自動生成とかしやすくて使うかもしれんけど、
makeにSchemeのコードを埋め込めてもたいしてうれしくはないよな。
余計なお世話としか言い様が無い。
そんなことよりやることがあるだろうと小一時間問い詰めたい。

>>926
その通り。実務ったって、いろんなのがあって。実質個人で使ってるだけなら仕様がどうとかどうでもいい。

大きな規模で使おうとするときに、ポータビリティーはありません、言語仕様はまた変わるかもしれません、
この処理系はバージョン1.0ですらないしデバッガはまだありません、
なんて言えないよ。

またか

だから、そういうケースの実務には使わない

精神病なのかね

先週ぐらいにとある大規模学会をみてきたのだけど
ambがあったら自動でできることを
「アルゴリズムの効率化」
とか主張してるの２つぐらいあった
学生の発表なんてそんなものだよね

そのアルゴリズムの効率化の十分条件がambによる自動化可能性にあることを証明したのならたいしたものだ

来たぞ来たぞ来たぞーーーーーーーーーーーーーーーーーーーーーー
よっしゃいくぜーーーーーーーふぉおおおおおおおおおおおおおおおおおおおおおおおーーー

なぜキーボードクラッシャー君がここに？

当たり前のことを当たり前にギリシャ文字でこねくり回しただけの教授の博士論文も見たことあるし学生ならそんなもんじゃね

圏論ですら米田補題が出るまで当たり前すぎて意味なしと言われてたしな…

>>934
大会の質疑応答で言えよｗ