TOP カテ一覧 スレ一覧 100～終まで 2ch元 削除依頼
NetBeans Part7
【GPGPU】くだすれCUDAスレ part8【NVIDIA】
.Net Core / Net ASP Core
コメント研究すれ。
家計簿ソフトを作る
数学者が技術者にプログラムを書いてもらうスレ
■WindowsCEプログラミング（EVC PB3含む）Ver2.2■
Borland Developer Studio 2006 No.13
表計算ソフトは人類の生産性を大きく下げている
UWSC初心者用スレ

Lisp Scheme Part40


1 ：2015/03/16 ～ 最終レス ：2018/07/14
Common Lisp、SchemeをはじめとするLisp族全般のスレです

■前スレ
Lisp Scheme Part39
http://peace.2ch.sc/test/read.cgi/tech/1408017352/

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

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

2 ：
>1乙

3 ：
>>1
乙

4 ：
ho

5 ：
もー前スレおちたぁ

6 ：
こっそり。

7 ：
そりゃ980超えたら落ちるって

8 ：
ﾁﾝｺそそり立ちましたぁ！！

9 ：
OnLisp難しい
みんなどれぐらいで読めた？

10 ：
読むだけなら三〇分だったなぁ(速読なんで)
理解するのは３月以上かかった orz

11 ：
OnLisp を読んで、ユーザー定義のマクロは害悪だと、あらためて認識しました

12 ：
極端なマクロを作るべきではないし実際にそれほど使われないけど、
マクロを使いたいときというのは汚いコードを隠蔽したいときだったりするので、
マクロを定義できないとたぶんもっとひどいことになる。

13 ：
On Lisp読んでmacroを害悪って感じるのが不思議だわ
使いどころを間違えると確かに非道いものになるが、使うべき所で使わないのも非道い事になるって明確に述べられているじゃん

14 ：
マクロのおかげでいちいちクオートせずに済むのが吉

15 ：
マクロあってこそ唯一無二のLisp族なのに、マクロを否定したら読み辛いだけの欠陥言語やないか～い！

16 ：
マクロなくても読みやすくね？
コードが視覚的に構造化されてるし

17 ：
>>13
OnLispの内容を、隣の同僚に説明することまで想像してください

18 ：
>>15-16
構造化と言えば構造化だけどどの構造も同じように括弧で表されるのは微妙。
慣れれば読み難いとは思わないけど、読み易いというほどでもないんじゃないか。
読み易いかどうかと言うよりも許容可能かどうかという話だと思う。

どの構文にも名前 (記号によって表される名前のこともあるけど) が付いているから検索しやすいとか、
本物のマクロを使えるとか、そういうのは利点としてカウントできるから見難さを上回る利点になるけど、
簡単に覚えられる程度の決まりきった構文しか使わないという人には利点がないわけで、欠点が上回ってしまうということは考えられる。

>>11
そんなわけで、マクロを否定しつつそれでもLISPを使いたいというのは何が嬉しいのかよくわからない。
それともLISP自体が駄目と言いたいのかな？
わからないというのは言葉通りの意味で、批判とかではないよ。
わかるように是非とも説明して欲しい。

19 ：
カッコいいから

20 ：
理系女を引っ掛ける時の武器になるじゃない

俺「つまり、リスプで無名再帰をランダムでYコンビネーターするわけさ。実際見てみたい？」
女「うん」
俺「(*´σｰ｀)ｴﾍﾍ、そそり立ったマクロをランダムに君のYにプス。ニップルにもプス、さあさあ、リスプリスプ」
女「リスプ・スゴー！ズコーってスゴー」

21 ：
ラテン語みたいなものだろう
知ってると箔が付く

22 ：
>>21
ラテン語はEUの大学出のインテリだったらほぼ必須と思って良かったはず
エゲレスはラテン語圏じゃないからしらん

23 ：
はっきり言ってマクロなしでもLISPを使いたい

24 ：
ﾁﾝｺそそり立つ奴うぜえと思ってｇｇったら個人特定できてﾜﾛﾀｗ

25 ：
ふふふ、俺に嫉妬してるな
よし、中国五千年の秘法、少漏多接でおまえもﾁﾝｺ鍛えろ

26 ：
>>16
むしろ Lisp 使うときのモチベーションがマクロ
専用エディタがなくても使う人はいるのかどうか

27 ：
OnLispにてベジエ曲線とかで詰んだ

28 ：
ショートリフの医薬品エキスパートシステムではマクロは使われてたんかいなぁ？

29 ：
>>28
使われてたというか、無しだと難しいでしょう
プロンプトとのインターフェイスだけはマクロの方が読みやすいのは、さすがの私でも認める

30 ：
積み木の世界は？

31 ：
記号処理ベースのAIは絶滅したのだろうか。

32 ：
巷で話題のDeep Learningとは対極だしね

33 ：
>>23
S式単位の編集、評価が便利すぎるんだよな

34 ：
最近はCommon LispとSchemeの人口はどっちが多いんだろう？

35 ：
githubとかの活動状況みて、人口数だとclojureがうなぎ登りな感じする
schemeって何かするときに処理系に依存するのが多いのが厭
clって何かするときに過去のしがらみが厭
みたいな理由でclojureに流れた人なので余計にそう感じるのかも<<俺

;;;ちなみにjvmと.net(clojure cli)の狭間で同じように嫌いになりかけてる orz

36 ：
Javaが嫌いなのでClojureは使いたくない

37 ：
>>34
ttp://redmonk.com/sogrady/2015/01/14/language-rankings-1-15/

しっかし改めてみて見ると、Lisp方言の中ではClojureが抜きん出てるな

38 ：
clojure は Lisp の皮をかぶせた Java って感じだから、
伝統的 Lisp が好きな人はイマイチに感じるかもね。
それでも Clojure がそれだけ伸びたってことは
「伝統」が Lisp 人口を抑制する理由になってたってことだ。
具体的にどれというわけでもないけど、文法的にもコミュニティ的にも。

39 ：
ここに詭弁がある

それでも Clojure がそれだけ伸びたってことは
「伝統」が Lisp 人口を抑制する理由になってたってことだ。

40 ：
Paas上にサービス作ろうと思うとたいていJVM上になるからClojureになっちゃう
ホストしてくれるところがあるならCommon Lispで書いてもいいんだけど

41 ：
clojure は repl のあるjavaです
だんじてlispではない

42 ：
PaulGrahamの言う大理石みたいな言語ってやっぱりHaskellのこと？

43 ：
>>41
え、どうみても Lisp じゃんか？何が嫌なの

44 ：
ベクタが嫌

45 ：
馬鹿丸出しだな

46 ：
俺も一々 java が顔出してくるので嫌になって clojure 辞めた

47 ：
Dot 対が無いのが嫌って人が居たな>>clojure

48 ：
しばらく前に触った時は、時々エラーメッセージがまんまjavaで出てきて、デバッグし辛くて嫌になった。
今は改善されてるかな？

49 ：
car/cdrがないなんて
オッパイとﾁﾝｺがない人類みたいじゃないか

50 ：
凸と凹が無いレゴブロックだよ

51 ：
確かにエラーメッセージが意味をなしてないことは多々ある
REPLでNullPointerExceptionとか言われても困るし

52 ：
>>49がうまいこと言ったな

53 ：
car,cdrに相当するものは有るじゃん

54 ：
car: 吾が身は、成り成りて成り合はざる処一処あり
adr: 我が身は、成り成りて成り余れる処一処あり
cons: 此の吾が身の成り余れる処を以ちて汝が身の成り合はざる処に刺し塞ぎて国土を生み成さむ

55 ：
list: しか善けむ

56 ：
ﾁﾝｺそそり立ちましたぁ！！

57 ：
そっかー。

58 ：
ﾁﾝｺたたない (´･ω･`)

59 ：
Common Lisp には ed あるからな。

60 ：
ﾁﾝｺ萎えましたぁ！

61 ：
>>42
なんだろう？C/C++ のことかな？

62 ：
特定の言語を指して言ってるようにも読みとれないし、
指していないものとして読んでも意味は通じると思うのだが。

63 ：
でもポール・グラハムの価値観というか美的センスは知りたいよね

64 ：
Lisper捕まえて価値化とか美的センス問いただすってどうなの

65 ：
PGの経歴考えれば、氏の美的センスに興味持つのは別におかしいことじゃないだろ

66 ：
元の文読んだら出てこない質問じゃないのかな。

67 ：
教祖が思いつきで適当こいたことを信者が一生懸命意味づけしてるみたい

68 ：
PGはセンスないと思う

69 ：
PGは経済的な感覚はするどいと思う
プログラマとして、言語設計者としてはどうかと思う

70 ：
グレアムは現実寄りの感覚を持っていると思う。
言語設計者が陥りがちな罠として一貫性とか対称性とかを過度に重視してしまうことがあるんだけど、
グレアムの場合は逆に「汚くてもこの方が効率的だ」と言えちゃうところがある。
それはそれでプログラマ、言語設計者に必要な資質だと思う。

71 ：
>>68
典型的に恥ずかしいやつだな

72 ：
>>71
教祖様べったりか。おまえ、自分の頭で考えたか？

73 ：
意味わからんだろうから少しだけ説明してやるか

おまえの評価は彼の主張内容への批判にまるでなっていない。彼という人物そのものの評価をしているだけだ。

比較して
>>70は、彼の考え方なり特性についての評価であるから問題はない

>>68
これでも恥じ入らないなら終わってるから底辺でウジウジしてろ

74 ：
だからLisperは・・・

75 ：
グラハム師は絵かきでもあるんだが？
尊師、いやセンスも抜群であるぞよ？

76 ：
グレアムですとりとり

77 ：
ちょっと見ないうちに発展してるんだな
ChickenなんてPython並みにライブラリ充実してるやん

78 ：
☆ 日本の核武装は絶対に必須ですわ。☆
http://www.soumu.go.jp/senkyo/kokumin_touhyou/index.html

☆ 日本国民の皆様方、2016年7月の『第２４回 参議院選挙』で、改憲の参議院議員が
3分の2以上を超えると日本国憲法の改正です。皆様方、必ず投票に自ら足を運んでください。
私たちの日本国憲法を絶対に改正しましょう。☆

79 ：
最初の一発をアメリカに落とすなら賛成

80 ：
>>78
某大統領はツーマンルールの束縛をも離れ自由に核を行使することができるようになるのですね

81 ：
pythonのdoctestに相当するものって
schemeの実装でもってる処理系ってありますか？

82 ：
SICPは糞訳だから難しいだけで
普通の入門書やで

83 ：
学生がはじめて触るプログラミング言語としてschemを想定している時点で普通ではない

84 ：
学生がはじめてさわる言語として？
は？

85 ：
LispWorksメジャーバージョンアップしてたよ～
http://www.lispworks.com/news/news34.html
Release of LispWorks 7.0
Cambridge, England, 05 May 2015

ARM版がでたり、EE版でなくても64bit版使えるようになってますね。
ただとても高いです(>_<)
64bitだと、
Hobbyist Edtion $750
HobbyistHV Edtion $1,500
Professional Edition $3,000
Enterprise Edition $4,500

Lisp生誕50周年の時に、記念価格で頑張って10万円以下で32bit Pro版買いましたが
もうムリポ

86 ：
>>85
以前お試し版でどうにもならなかったので価格に見合わんと思って捨て置いたのだけど
LispWorksのIDE日本語まともに動くようになりました？(UIで使うのよ)

87 ：
>>86
Windows版しかわからないけど、LispWorks 6.1あたりから日本語は問題なくなってるよ。
インライン入力、日本語フォントの表示など。
ただ、Shell Panelについては相変わらず文字化けするね。
（前から要望は出してたけど結局対応されてない。）

88 ：
https://github.com/pedropramos/PyonR
Racketとpythonの混合できるって聞いて動かそうとしてるんだけど
Gentoo Linuxだと動いてくれない
ひょっとしてWindowsでしか動かなかったりします？

89 ：
>>87
>ただ、Shell Panelについては相変わらず文字化けするね
まだ多国語対応未対応な箇所あるのか orz
LispWorksはVSと値段かわらんから購入候補になるんで頑張って欲しいんだが。(DB必須なので必要なのはEnterprize版)
Franzは良いとは見聞きして知ってるけど零細企業で買うのは開発に必要なライセンスは2か３でなんとかなっても再配布ライセンスがちょっと躊躇する(値段が見えないので銀座の寿司屋な気分だ)

90 ：
きちんとしたサポート込みで、個別の相談にもかなり乗ってくれるらしいからなぁ。
処理系の値段つーより、ある種のコンサルみたいなもんなんじゃね。
用途を説明して概算を聞いてみてもいいと思うよ。

91 ：
issueとpull reqみると、osxは分からんってかいてあるけど、
作者がどの環境で動かしてるかよくわからないね。

92 ：
>>88
Gentoo Linuxだけど動いたよ
動かないってのは具体的にどんな状況?

93 ：
>>92
cd PyonR/examples/numpy_arrays
$ racket sum_arrays.py

sum_arrays.py:2:0: cpyimport: The 'cpyimport' statement is disabled.
To enable it, require the module 'python/config' from Racket and run (enable-cpyimport!)
in: (cpy-import "numpy" as :np)
context...:
/home/niitsumalocal/.racket/6.0.1/pkgs/python/cpy-importing.rkt:65:2
/usr/share/racket/collects/syntax/wrap-modbeg.rkt:46:4
standard-module-name-resolver

94 ：
>>93
そのエラーメッセージに解決法書いてあるよ

> sum_arrays.py:2:0: cpyimport: 'cpyimport' 文は無効になっている。
> これを有効にするには、Racket で 'python/config' モジュールを require し (enable-cpyimport!) を実行せよ。

というわけでこう

$ racket --eval '(require python/config) (enable-cpyimport!)'
The 'cpyimport' statement is now enabled.

$ racket PyonR/examples/numpy_arrays/sum_arrays.py
cpu time: 2197 real time: 2194 gc time: 12
[[ 5.05084018e+08 4.99867603e+08 5.02311555e+08 ..., 4.97975418e+08
以下略

95 ：
最近流行のdeep learningだけどlispと組み合わせて何かやった研究とかないのでしょうか

96 ：
型つきschemeで一番まともなのはbiglooぽいけど
ライブラリが一番充実してるのはracketぽい

Racketのパッケージをbiglooで動かせないものか

97 ：
::okey::

98 ：
sssp://img.2ch.sc/emoji/2ch-okay.gif

99 ：
他人の作ったJavaプログラムのバグをとりつつ
自分の使いたい機能を追加したりするなら

Scala
Clojure

どっちがおすすめ？
Javaとの融合はScalaが上っぽいけどLispになれてるのでLispの方がいい

100 ：
>>99
後者

101 ：
>>99
Lisp慣れしてない自分でもClojureに楽しくはまったのでClojureを押してみるなり
JVM用言語で最も短いコードで最良の結果だす言語の一つだと感じる

102 ：
>>99
後者。
Leiningen の checkout dependency が便利すぎてはげる

103 ：
モナドのちゃんとした定義ってあるの？
言語ごとに定義が違う気がするんだけど

104 ：
モナド則はモナド則だよ。

105 ：
関数型言語「Racket 6.2」リリース
http://osdn.jp/magazine/15/06/23/063900

　RacketはShemeから派生した関数型言語。旧名称はPLT Schemeで、バージョン5より
Racketに名称を変更した。強力なマクロシステムが特徴で、マクロを使って言語機能
を拡張でき、プロジェクト固有の新しい「方言」を作成できるという。また、Web
サーバーやデータベース、GUI、チャートなどのアプリケーションをサポートする
ライブラリも提供される。ライセンスはLGPL。プロジェクトは米国立科学財団（NSF）、
国防高等研究計画局（DARPA）、米教育省、Exxon Foundation、Microsoft、Mozilla、
Googleなどの支援を受けている。

106 ：
Racket 最強伝説

107 ：
>>105
記事読んだけど、マルチパラダイム言語って誰が言い始めたんだろ
そもそもシングルパラダイム（原理主義）な言語なんて非実用的なものの対義語なんか冠にしても意味ないと思う

108 ：
typed-racketが変なバグ起こさなくなったの？
安心して使えるようになったのなら使ってみようかな

109 ：
Clojureと同じ文法でC++もwrapしようとしてるプロジェクトを
２つぐらいみつけたんだが2年ぐらい更新がない
JavaからC++の変換はそんな難しくないはずなんだけど
何か違う理由で頓挫してるんだろうか

110 ：
>>109
(その人達に必要な機能は)完成したからではなかろうか

111 ：
試しに実装してみたぐらいの気がする。
継続して使うのに作ったかは分からない。


型付きといえばshenも、18.1で型チェックが速くなったらしい。
ソースみたら、該当箇所の型が総称型に変わってた。
http://www.shenlanguage.org

112 ：
相互運用テストのためにakamaiがhttp2のコードをCLで書いてて、少し話題になってたね。
https://github.com/akamai/cl-http2-protocol
https://github.com/http2/http2-spec/wiki/Implementations

113 ：
cl-llvmってなんだろう。
https://github.com/sellout/CL-LLVM
llvmを吐く？FFI？

http://blog.cnu.jp/2012/12/11/android-gdk/
それとも、androidのjava/llvmみたいな話と同じなのかな？

114 ：
これ3年ぶりのコミットがあったのか。
https://github.com/sellout/CL-LLVM/commits/master

115 ：
CL (というより動的型の言語) は LLVM の抽象度では上手く扱えないしたいして最適化できないという話もある。
GC の性能にも強く左右されるし、 LLVM よりも JVM の方が CL とは相性よさそうな気がする。

116 ：
ABCLの性能ってどうなの?

117 ：
昔，kawaからJavaを使おうとして非常に苦労した記憶が
ABCLならだいぶ楽にJavaが使えるのだろうか
Clojureは最初は楽だけどJavaのパッケージマネージャで苦労するね

118 ：
>>117
Java のパッケージマネージャって Clojure 書くのに Maven とか Gradle でも使ってるの？

119 ：
一時期Clojureが過剰に持ち上げられていたけど
まったく流行らずに終わったな

120 ：
ブラジャーに対抗しようとしても無駄なことだし

121 ：
clojure は、lispの対抗馬とか思ってると、 repl 起動するまでにブチ切れると思う

122 ：
普通に流行ってるじゃん

123 ：
やもえずJavaのウンコなプログラムのメンテしないといけない場合に
Clojureは便利だった

そういう制約ないならRacketが一番

124 ：
>>123
Racketの良さを教えて

125 ：
srfiがみんな使える上に
pythonとも連携できる
jythonみたいにnumpyが動かないとかもない

126 ：
>>125
ありがとう
pythonライブラリを透過的に使えるなら便利そうだね

127 ：
えっ？Clojure って流行ってるの？

128 ：
少なくともメーリングリストは相当活発だよ

129 ：
自前でサーバー立てるなら何でもありだけど、実際PaaSのほとんどがJVM前提だからね

130 ：
Javaでプログラム書く人達はユニットテストという概念がないらしく
csvに結果を書き出してエクセルで手作業テストを行うという謎慣習があるようだ

こういう人達の書いたJavaコードと付き合わざる得ない環境ではClojureは便利

131 ：
JUnit…

132 ：
eclipseからJUnit使ってみるとわかるけど
エクセルの方が楽

133 ：
>>130
むしろ、java以外のユニットテストツールを使ったことがない

134 ：
>強力なマクロシステムが特徴で、マクロを使って言語機能を拡張でき
このLISP系でよく言われる「言語機能の拡張」って全然的を射てねーなと思う
例えばschemeのファーストクラスオブジェクト(FCO)としての継続って
言語プリミティブとしてFSO継続相当を始めから持ってない限りはどうやっても
拡張で得ることはできないし
FCOとしての継続の無い言語から有る言語へ言語機能を拡張するってことは
つまり新規にFCO継続付き言語を作るって事に他ならない
できることは結局言語に既にある機能の延長上の事だけで
言語拡張なんて大それた事は他の言語同様できやしない
「子供騙しですけど強力なマクロシステムで俺構文糖衣が簡単に作れますんで・・・」
とちゃんと書き直した方がいいね！
「プラグインモジュールを使うと言語機能を拡張できます」とかで売った方がまだ納得できると
思わないかね君たち

135 ：
長くて読めないから3文字にまとめてくれ！

136 ：
おかしなひとには
かかわらない
しらんぷり

137 ：
お
　か
　　ん

138 ：
>>134
思わない

139 ：
>>134
ていうか頭悪いと思います
「言語拡張」の俺的意味からの演繹をしてるだけ

140 ：
マクロ展開時になんでもできるのに何で制限があると思うんだ？

141 ：
>>134 みたいな勉強不足の人に黒板先生は本当に便利だ

http://cl-www.msi.co.jp/solutions/knowledge/lisp-world/articles/scheme

> 端的に言ってしまえば Scheme は Lisp ではないです。 この2つを混同するのは味噌糞いっしょ、ってやつで、つつしむべきです。

http://cl-www.msi.co.jp/solutions/knowledge/lisp-world/articles/script-lang

> Lisp の不幸の1つに、
> Lisp を使わない奴に限って Lisp について語りたがる
> というのがあるんですが、今回もう1つ加わったのは、
> Lisp を知らない奴に限って Lisp を他のもの、なかでも自分の自慰行為の結果と比べたがる
> Lisp の評論をとうとうとやるわけです。

142 ：
>>134
マクロは任意の構文木から任意の構文木への変換であって
どんなプリミティブが用意されるかは言語の戦略で決まること
レイヤーの違うことを関連付けて語るのはやめてちょうだい

143 ：
>>141
その理屈でいくなら、CommonLisp も Lisp ではありませんね

144 ：
>>143
それと >>134 とどんな関係が？

145 ：
>>144
Lisp と CommonLisp を混同しながら、Scheme はLisp ではないと主張ている人の意見はほどほどにして聞きましょう

146 ：
>>145
自身のLispの定義を明らかにせずにCommon Lispは違うって言われましてもｗ
でもCommon LispがLispでないんなら、なおさらSchemeでLispを代表させるような論が成立しないのは同意できるんでないの

147 ：
>>146
まず、Lisp は CommonLisp ではない
Lisp は Scheme ではない

次に
ttp://www.softwarepreservation.org/projects/LISP/book/LISP%201.5%20Programmers%20Manual.pdf
この↑Lisp1.5 は Lisp であるとする　(おそらく、誰も異議をはさまないでしょう)

その上で、CommonLisp は Lisp であると仮定する (つまり、Lisp1.5 と CommonLisp程度の差があっても Lisp の一部であると仮定する)
当然、SchemeはLispである

逆に、SchemeはLispではないと仮定する (つまり、SchemeにもLisp1.5にもないモノがあればLispではないとする)
package にintern できる symbol がある CommonLisp は Lispではない

CommonLisp 側の言い分としては、CommonLisp はSchmeと同じくLisp系の新言語です
(Common Lisp is the modern, multi-paradigm, high-performance, compiled, ANSI-standardized, most prominent (along with Scheme) descendant of the long-running family of Lisp programming languages. )

Confusing Lisp and Common Lisp is permissible once in a human life. です

個人的には、マクロやシンボルが無くてもLispと呼ぶべきだと思います

148 ：
>>141
このKURODA Hisaoって人が書いてる他のページも見たが
Abstract Syntaxの概念やこれを設定する意義を理解できない人がSemanticsについて語っても全く説得力がないね
それにSchemeの単一name space批判を自然言語での文脈依存性を持ち出してるが
自然言語の柔軟さというかいい加減さを至上の価値とするのならば所詮は知性ゼロ・常識ゼロのコンパイラやインタプリタですら処理できちゃう
普通のプログラミング言語なんてどれも失格、もちろんCommon Lispもね
理論や論理学について良く判っていない人間ほどFregeみたいな「計算機と深い関係があると世間で言われている」哲学者の名前を出したがる

149 ：
　わりと
　　　どうでもいいよね～　　　　　　　　　　　　　　　　　　　ね～♪
　　　　　　　　　　　　　　　　　　　　　　　　 _　‐..:: ￣￣ ::::... 、
　　　　　　　　 　 　　 . ｨ　　 　　 　 　 　 r'::/ ::ィ:::::::::::ｊ:::::::ヽ::::＼
,._.._ .......､._　　　 _　／:/l!　　 　　 　 　 　 | ::|::/ |::::::::∧:::ﾚ::l:::| :::::rﾍ
ヽ　:~""''.>ﾞ' "~　,､､''‐'､|　　　　　　　　　 l ::仏_ノﾍ:/ ー- ﾊ:::!::::::|::::i
　ﾞ､'､::::::ﾉ:::::::_,.-=.　 _～:、　　 　　 　 　 /::::ﾘy=ﾐ　'　ｨ=ﾐ /:::::!::::/:::::!
　　``､/:::::::::__....,._ `ﾞ'Y' _.ｪ-､..._　　　 　 |::::｛xx 　　　 xx/::::::｢）'|:::::::|
　　,.--l‐''"~..-_'.x-='"ﾞｰ ､`'-､ 　　　　　lﾊ:仆 ..._ヽフ　/:::: /´　|:::::::|
　"　　 .!-'",／　 `'-‐'') /＼　`　　　　　　Ⅵ::::ソ勺　７イV_　　!:::::::!
　　.-''~　>'ﾞ::　　　 ‐'"ﾞ./　　ヽ.　　　　＿_　 |::/ 爻___ん'´ｯ'⌒ヽ! :::::!
　　　 ／/:::::　　　　 　 ',　 　　　　　 (__,、＼/ /‐―一弋{、　 / ￣_)
　　　'　/:::::　　　　　　 .:';　　　　　 　 　 ＼ '　{　　　　　 :::＼ 　 /~::!

150 ：
ﾁﾝｺも関係ないもんねぇ

151 ：
これで133も満足だね

152 ：
確かに言語拡張でarduinoと連携してドローンを自動航行できますとか言えた方がかっこいいよな
方言作れるとか書かれてもLisp界隈の事情知らん人間にゃ意味不明だし

153 ：
>>152
バインディング書けば言語に関係なく出来るだろ。
その手のライブラリがたくさんあるとか、
コマンドひとつで導入できるエコシステムがあるとかならアピールポイントになるとは思うけど。

154 ：
言語は大きい会社や団体が開発してることがほとんど。なので妙な政治意図で故意に機能が削られたりが良くある。マクロありとこういうのは無視出来る。だいたいは誰かが便利なマクロを公開してくれる

155 ：
なんで誰もcl-contを持ち出さないんだ

156 ：
だって、>134の言い掛かりと言語レベルでの継続の必要性とは、まるで関係がないんだものw

157 ：
フル継続の後付けが難しいのは事実だろ。
cl-cont も Scheme に比べればモドキに過ぎないしな。

そんでもって >>134 は継続は例に出しただけで、
マクロによる拡張が容易であっても言語が持つべきプリミティブの選択が重要だってことじゃないのか？

158 ：
長々書いてるけどマクロでシンタックスを拡張できてもセマンティクスは変えられないってこと？
そりゃそうなんじゃない？この手の話の根はチューリング完全話と一緒だよね
機能拡張という言葉はセマンティクス拡張と同義ではないよなあ

159 ：
それはもう見ているものがLispのマクロによる拡張性ではなくなっている

160 ：
特殊形式以外のマクロを使わないという選択

161 ：
言語の意味論とシンタクス拡張はレイヤが違う話だよ。
DSL は言語の意味論を変えはしないけど系を作ることは出来る。

物理法則は変えられないけど、物理法則の範囲内でサッカーのルールを定義したとして、それが無意味って言えるか？

162 ：
上の方の人と偶然被ってるけど、質問。
schemeのdefine-syntaxって何ですか?
defineじゃダメなの?

163 ：
Scheme のマクロは式の評価の前に展開される。
ものすごく単純化して説明すると処理されるタイミングが違うの。

164 ：
>>162
マクロなら可能だがdefineでは定義不可能なケースを上げておく

defineで定義された関数(procedure)の適用では、まず全ての引数が評価されてからその結果が関数bodyに渡されて関数の結果が決まる。
もし、全ての関数を評価せずに前から必要な分だけ評価する関数を書きたい場合、defineでは無理。その場合はdefineは-syntaxなどをつかってマクロを定義することになる。

マクロは
>>163が述べているように第一段階としてSchemeのS式を生成し、第二段階でその生成されたS式を評価するわけだが、第一段階ではマクロの引数は評価されない点が重要。
それによって、defieとは異なり一部の引数をのみ評価することが可能となる。

or関数はその一例だな
もしdefineでmy_orを定義しようとすると全ての引数を評価するという無駄な関数となるわけだ。
もしaがtrueなら
(or a b c d e)でb以下は評価不要
が(define my_or ……)とすると
aからeまでを必ず評価してしまう

165 ：
>>164
補足
だからmy_orはマクロで定義するというわけな
どうだ？
ﾁﾝｺそそり立つほどわかったか？

166 ：
>>164
訂正
もし、全ての関数を評価せずに
もし、全ての引数を評価せずに

167 ：
>>163でスゲーわかった気になったのに、>>164-165で全然わからなくなりました。
defineでも問題なさそうだけど。

(define my_or1
(syntax-rules ()
((_ a b) (or a b))))

(define-syntax my_or2
(syntax-rules ()
((_ a b) (or a b))))

(my_or1 #t (begin (print "!") #f)) ===> #t
(my_or2 #t (begin (print "!") #f)) ===> #t

168 ：
>>167
試した処理系は何？ それは仕様上未定義だよ。
期待した動作をするように見えてもただの偶然。

169 ：
全部(lambda()～)で囲って遅延評価すればなんでもできるよ
SICPでマクロが無くても問題なかったのはこのおかげ

170 ：
>>168
gaucheっす。r[567]rsによると、my_or1はこう呼ぶべしと理解したけど、あってます?
(define my_or1 (syntax-rules () ((_ a b) (or a b))))
(let-syntax ((my_or1 my_or1)) (my_or1 #t (error "!!")))

変数と構文キーワードを区別しなきゃならない理由が、いまいちピンときません。
フォームの先頭が(lambda)を評価したものと(syntax-rules)を評価したもので
区別出来そうな気がします。(実際Gaucheはそうしてるから>>167で動いてる?)

171 ：
>>170
構文は第一級ではない。 (実行時に値として扱える存在ではない。)
「マクロ展開フェイズ」が完了してから「式の評価」を開始するので、実行時に束縛するのでは遅すぎるんだよ。

式ひとつごとに「展開」「評価」をする処理系でフェイズの分離を有耶無耶にしている処理系だと区別を曖昧にしてもなんとかなるのかもしれないが……
それは実装方針のひとつとしてそういうのもありえる、可能というだけ。

172 ：
>>171
>構文は第一級ではない。 (実行時に値として扱える存在ではない。)
なるほど、疑問氷解です。

173 ：
.oO( The Little Prover を読んだ香具師がスレの流れを作ってくれる予感 )

174 ：
なぜ自由なlispより不自由なjavascriptが流行ったのか

175 ：
自由度なんてマニアしか求めてないから

176 ：
ウェブブラウザから使えるのが lisp だったら流行ったんじゃないの？
とはいえそこに lisp が採用されない理由も結局は一緒か。

177 ：
IE4やNN4で実装されたスクリプト言語がLISP系だったら…

少なくともfirefoxのnoscriptアドオンは不要だったろうな

178 ：
逆に考えるんだ、
「lisp でWebブラウザを作ればいいや」
と考えるんだ

179 ：
WebAssembly が一般的になれば Lisp にもワンチャンあるで

180 ：
Javaがダメ言語とあの時点で判明してればなあ。
当初の予定通りschemeが組み込まれてたに違いない。

181 ：
emacs で Webブラウジングが出来るんじゃ無かったか。

182 ：
技術系のドキュメントとかあまり凝った事してないものしかまともに見れんよ。

183 ：
Emacs に Webkit 載せたりしてるのもあったぞ。
Emacs 側から Webkit をどれくらい操作できるのかは知らんけど。

184 ：
ブラウザ競争っていかにCSSに意図通り対応してるかの勝負だし
サーバサイドならemacsでもjavaでも変わらん

185 ：
いや javascript が動かないと。

ああ、其処を lisp にするって話だったか。

186 ：
いまだに、javascript が scheme だということについて納得できない

187 ：
第一級の継続も末尾呼び出しの最適化もないしねぇ

手続きが無条件でクロージャになるってのがまあ当時としては特徴的ではあったけども

188 ：
CLみたいな余計な装飾子が無いところはschemeと考え方が近い
末尾最適化が標準のluaのがよりschemeに近い
継続は第一級にする必要ってあんのかな
使い所が難しいし言語に例外機構が備わってればいらないし
jsはライブラリ覚えるだけでもしんどい

189 ：
今JSがコールバック地獄になってるからこそ継続がほしいんじゃん。フル継続じゃなくて限定継続でもいいから。

190 ：
javascriptのように通信が頻繁に行われる環境で継続なんか入れたときに、例えば途中でブラウザを切ったときの継続がどうなってるのか考えるとワケ分からなくなる
schemeの継続ですら、資源を使いまくってるサーバが落ちたときにリソースのclose操作とかきちんと行われるのか不安になる

191 ：
>>189
jsはクロージャがあるからCPS方式で継続もどきは作れるんじゃないの
インスタンスが途切れちゃうなら継続使っても同じだし

192 ：
>>191
CSP？

193 ：
継続渡しはCPS
セントラル警備保障はCSP

194 ：
JavaScript 処理系の Rhino は第一級継続を持ってる。 実在する以上、言語処理系レベルでは可能ってことだろ。
だけど、 Scheme 処理系でも外部のライブラリ (バインディングとか) を通過したところで継続が途切れてしまう制限を持っているものがあることからもわかるように、
継続が処理系の外の世界をまたぐのは難しいんだわ。
(※参考 Gauche のドキュメント http://practical-scheme.net/gauche/man/?l=jp&p=call/cc )

JavaScript はアプリケーションに組込んで使うタイプの言語だから、当然、外の世界とのやり取りはあたりまえで、
そこに第一級継続を持ち込んでも途切れまくりであんまり役に立たんのじゃないか？

Gauche のドキュメントには限定継続の利用を勧めるようなことも書いてあるけど、
フル継続で途切れてしまうところを越えられるって意味ではなくて、
継続の範囲を明確に書けるから変なところをまたがないように注意しやすいって意味だと思う。

195 ：
プログラミングGauche第2版ﾏﾀﾞｰ

196 ：
そういやGNU標準言語？だかのはずのguileって使われてるんだろうか

197 ：
待ちguile

198 ：
GNU自体微妙な団体だし
そんな団体の標準になられても気持ち悪い

199 ：
などとにわかschemerが申しております

200 ：
guile って死んでると思ったけど、
結構頑張ってんよ

201 ：
unicodeサポートが微妙だったのはもう昔の話なのかな？なんかそれで使うのやめた事がある

202 ：
アプリケーションに組込むなら小さい実装の方がいいよな。 Guile は豪華すぎると思う。
かといってリッチな実装というカテゴリだと Racket が強いから Guile は微妙ということに……。
Guile の強みって何？

203 ：
javascriptでscheme組もうと思う
クロージャあるし継続なしで末尾再帰ぐらいなら結構楽勝かな

204 ：
https://reptilian79.wordpress.com/2015/01/16/muhammad-invents-lisp-lisp-is-the-enemy-of-democracy/
こんなの見つけた

205 ：
>>204
ワラタ

206 ：
racket で raco を使って exe 化したらやたらサイズがデカいのが出来たんだけど、
もっと小さくできないものなん？

207 ：
自作処理系だと4KBセクタに収まるようにできる
512バイトブロック単位だが
けどschemeコアも含めたりすると結局数十KBにはなる
イメージまるごとexeにするタイプなら
参照切りまくれば小さくなるんじゃないの

208 ：
Biglooの生成するcコードは恐ろしくシンプル

209 ：
そっかー。

210 ：
初めまして。
早速ですが教えて下さい。
下のcall/ccの定義を解説できますか？

(define call/cc
(lambda (k f)
(f k (lambda (dummy-k result)
(k result)))))

211 ：
例えば RnRS の call/cc を使ってこういうのを書いたとする。

(define (foo x)
(+ 3
(call/cc
(lambda(cc)
(if (> x 3) (cc (+ x 1)) x)))))

(display (foo 1)) (display (foo 5))

継続とは何かというのを綺麗に説明するのは難しいけど、
「残りの計算」という言葉で説明するのが一般的だね。
この例でいえば call/cc を呼出された後にするはずの計算、
すなわち「 (+ 3 」が変数 cc に入っている継続。
call/cc を呼出している外側全てと言い換えてもいいかもしれない。
(字句上の外側ではなくて実行時の外側。)
で、 >>210 の言うところの call/cc (名前がまぎらわしいから
ここでは call/cc* と変える) は残りの計算を陽に引数として
渡すバージョンということだと思う。
最初の例を call/cc* で書き直すと

(define (foo* x)
(call/cc*
(lambda(x)(+ 3 x))
(lambda(cc f)
(if (> x 3) (cc (+ x 1)) (f cc x)))))

(display (foo* 1)) (display (foo* 5))

となる。
「(+ 3」の計算を (lambda(x)(+ 3 x)) というクロージャにして渡しているのが
わかるかな。

212 ：
>(+ 3 (call/ccc
式中の副作用(call/cc)は評価順序不定の罠が
判ってると思うけど一応

213 ：
ついでにこの式の評価順序ってR6RS以降で何か変わったのかなーと思って調べたら変わってないっぽいね
式を多用するlisp族ではついつい書いてしまうからどっちかに決めた方がいいと思うんだけどな
継続は一見副作用に見えなかったりするからややこしい
そういや評価順の問題ってトップレベルにもあったなあ

214 ：
横から初心者が何だけど、
>>210の定義のdummy-kって別に無くてもよさそうなんだけど、何か必要な理由って有るのかな？

215 ：
>>211
その例だと継続使っても使わなくても結果が変わらないので微妙。
fを適用する先も間違ってるし。

こんな感じでどうでしょう。

(define (foo x)
(call/cc
(lambda(cc)
(+ 3
(if (> x 3) (cc (+ x 1)) x)))))

(define (foo* x)
(call/cc*
(lambda (x) x)
(lambda (cc f)
(let ((ncc (lambda (x) (cc (+ 3 x)))))
(if (> x 3) (f ncc (+ x 1)) (ncc x))))))

216 ：
連投すまぬ。
引数の名前がきちんと対応していなかったのでfoo*を書きなおした。

(define (foo* x)
(call/cc*
(lambda (x) x)
(lambda (f cc)
(let ((g (lambda (x) (f (+ 3 x)))))
(if (> x 3) (cc g (+ x 1)) (g x))))))

217 ：
>>216なら素直に理解できた
要するに、これは継続渡しのスタイルの中で使えるcall/ccってことか

あと、さっきの例をちょっといじって
(define (foo& x k)
(call/cc*
k
(lambda (f cc)
(let ((g (lambda (x) (f (+ 3 x)))))
(if (> x 3) (cc g x) (g x))))))

(foo& 1 (lambda (x) (display x)))
としたほうがわかりやすいかもしれない

218 ：
LFE(lisp flavor erlang)使ったことあるかたいますか？
どの辺が問題なんでしょうか。
バックエンドがerlangというのは大きいメリットだと考えるんですが。

219 ：
>>218
使われない理由っていうことでいうと、↓のような感じかな。
読み直したら全面的にdisってるが、おもちゃとしては面白いと思ってる

・開発リソースが少ないのでおもちゃの域を出ない
特に、Common LispもしくはClojureを置き換えるほどのライブラリ・
成熟度・勢いは無い。

・そんなに速くない

・Erlang／BEAM自体の需要が少ない
Erlangスレでも書いたことがあるんだが、開発の現場でErlangを本当に必要とする
場面というのは少ない。良くも悪くもフォーカスを絞った言語だから。
エラー処理が楽とかいう人も多いが、乗り換えるほど大きなメリットでは無い
また、現実問題として、システム全部をBEAM上に載せる必要は無い。
一部だけErlangで書けば良いし、そのために
微妙な成熟度の微妙なLisp方言を入れる必要性ってあんまり感じられない

なお、Elixirで騒いでいる人たちも、Erlang系だからってよりはRubyっぽい
関数型言語っていう表面的な特徴で一時的に騒いでいる人の方が多い

・名前がダサい。これは馬鹿にできない

220 ：
>・そんなに速くない
これはBEAM特有の問題なんだよね、数値計算がちょっとでもはいるととても遅い
非同期IO処理だけさせるような所だとElixir含めてErlang系はものすごく便利だけど読める人が少ないし

221 ：
>>219 さん、
>>220 さん、
ありがとうございました。

Common Lispのライブラリが使えれば状況良くなるのかなぁ
※Lispはこれから勉強するのでどの程度違うものかは判っていなくて言っています。

222 ：
haskellのlhs2texみたいなのって
LispやSchemeにはないの？

223 ：
あかんなぁ
俺、馬鹿になってきた
年ってやつかなぁ
Common Lisp始めたけど、あれこれの関数名をすぐ忘れる。
駿馬も老いては駄馬なんとかか

224 ：
因みにことし還暦な

225 ：
>>224
不惑や知命でもぼける人はぼけちゃうからねぇ

226 ：
Schemeでsyntax-case使うとき、マッチングの第一要素にkって名前をよく見るし使うけどこのネーミングになんか由来とか理由とかあります？
なんで？って聞かれて答えられないんですが

227 ：
ソースがあるわけじゃないが自分は keyword の k だと思ってた。
仕様の中にある例でも k 使ってるからほとんどの人はそれに倣ってるだけだろうけど。

228 ：
i と j じゃ整数の印象が強いんで、次の k を使ってるだけかと思った

229 ：
このあたりの例で使ってる i はたぶん identifier の i じゃないかと思う。
http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-13.html#node_sec_12.7

t は疑問の余地なく temporary だな。 p は pattern で e は expression ってところか。

230 ：
>>229
scheme限定のイディオムなんかね
clojureだと
(defn hoge [coll] (brabrabra))
coll(collection)をわたすんだぞーってイディオムになってるみたいな？

231 ：
パターン変数には全部頭に ? を付けるとかいう流儀もあるし、
そんなに確立したものではないと思うけどね。

232 ：
マクロの空をつらぬいて

233 ：
継続にkを使う人達もいる

234 ：
>>233
constantな値にkFoo,kBarってつける習慣もあるからcontinuationにkプレフィックスはそんなに違和感持たないなぁ
class指向な処理系で classって名前使えないからClass klass = someObject.class って書くようなものかと思うのであるよ。

;;; 実は歌の続き？としばらく悩んだ

235 ：
理解重視でオレオレlisp処理系をhaskellで書いててこれを改良しようとしてます
環境は[(名前,値)]というわかりやすい実装でラムダ式本体部を引用するとこんなのです
let env' = (zip param args) ++ closure ++ env in
last $ map (eval env') body
これって開発言語のスタックを使った実装になりますよね?
このコードはapplyの一部で、evalとapplyの相互再起の中の1コマなのですが
よく末尾再帰とかいいますがああいうのはどうやって判定するのですか？

236 ：
そろそろ何か書き込みないとスレが落ちる？

237 ：
それは大変だ

238 ：
SICPの新訳が出た
http://d.hatena.ne.jp/takeda25/20151030/1446174031

239 ：
schemeはいい線行ってたと思う
不幸なのはほとんどの機能がjavascriptで足りてしまったこと
大多数の人は末尾再帰すらないjavascriptでいいと言う
繰り返し処理と言えばループしか脳から出てこないんだから
再帰はおろか末尾再帰なんか知らないだろう
再帰処理もスタック構造のコンテナとループで同じことができるんだから
実際知らなくても困らない

240 ：
JavaScriptの末尾再帰はもうすぐ実装されるし高階関数もずいぶん前からあるが

241 ：
WebAssembly が一般的になったら JavaScript の勢力は (クライアントサイドでは) 過去の資産を除いてフェードアウトしそう。
そのときこそ Scheme の復権が狙えるかもしれないぞ。

242 ：
>>235
末尾コンテキストを判定する
末尾コンテキストの実行時はフレームで確保したスタックは使われない
よってその直前で削除してしまえるから関数呼び出し等でもループに置き換えられる
(define a (lambda (x y) (b x y) (a x y)))
の最後の(a x y)は末尾コンテキスト
最後のa呼び出し前のx yの引数の積み上げが完了した時点でaのフレームは削除できる
削除した後aを呼び出すとまた同じフレームレベルでaの処理が開始する

243 ：
末尾コンテキストの伝播
tを末尾コンテキストとする
(lambda ()・・・t)
(if test t t)
(begin ・・・t)
(lambda()・・・・t))
組み合わせると次のように末尾コンテキストが伝播する
(lambda ()・・(begin ・・・×)・・・(begin ・・・(if test t t)))
×は親が末尾コンテキストでの実行でなければ子も末尾コンテキストにはならない事を示す

244 ：
関数適用の末尾コンテキスト
上で(a x y)を末尾コンテキストと書いたが
より正確にはtの呼び出し時点が末尾コンテキストとなる
表記的には(t 引数)となるがt自身がいつ評価されるかはschemeでは規定されていない
よって処理系の都合順にt x yを評価した後、tの呼び出し前に末尾コンテキスト処理(フレーム削除等)が発生する

245 ：
末尾コンテキストが移動する構文
(set! var exp)
(while test body)
set!はvarがフレーム内変数ならexpの評価、フレーム外変数ならvarをexpの結果で破壊した時点が末尾コンテキストになる
whileはtestで偽になった時点かbody内からbreak等で抜けた時点だが、
そもそもschemeでのループ構文は末尾再帰の構文糖衣として定義されることが多く、この限りではない

継続呼び出しの末尾コンテキスト
継続呼び出しは継続を保存した位置に移動すると共に環境も入れ替わるため
末尾コンテキストの対象外となる(考慮しなくて良い)

246 ：
http://tech.grammarly.com/blog/posts/Running-Lisp-in-Production.html
割と知られている英文法チェッカーがCommon Lispだった

247 ：
ドクじゃん

248 ：
>>242-245 素晴らしいIDですね
末尾コンテキストの伝播については理解できたと思います
ifは末尾コンテキストが2つに増えるので
もしif文が末尾に連なってたら末尾コンテキストがたくさんになるわけですね
これを使って末尾コンテキスト判定をするis-tailrecみたいなのを作れば
考え方として、関数fの定義でもしis-tailrecが真となる箇所以外でfが
呼ばれていれば末尾再帰でないと判定すればいいですよね
set!の部分がちょっとまだ理解できてませんが考えてみます

249 ：
>>238
紹介サンクス
かなり読みやすくなってる気がする

250 ：
Haskellのclassとinstanceに相当する型演算をSchemeで擬似的に作る方法ないのだろうか

251 ：
Picrin にはそんな感じのオブジェクトシステムが入ってるよ。
作者による紹介記事がある。

http://wasabiz.hatenablog.com/entry/2015/01/12/170025

クラスじゃなくてプロトコルという名前になってるけど、やってることはほぼ同じ。

実装はこのあたり。 意外に小さい。

https://github.com/picrin-scheme/picrin/blob/master/contrib/50.class/piclib/picrin/class.scm
https://github.com/picrin-scheme/picrin/blob/master/contrib/80.protocol/piclib/picrin/protocol.scm

252 ：
ピクミンかと思ったらピクリン

253 ：
https://twitter.com/illmnt_SICP_ja

254 ：
うーん、、、、

255 ：
>>253
何だこれ。晒してるつもりなのか？
こんなことすべきじゃない。

256 ：
>>253
これ読んでいるだけでも、すごく勉強になるよな

257 ：
なるよな？
同意を求めないで欲しい
気持ち悪いbot作ったなーとしか…

258 ：
SICP は専門書なわけで、どこの 140 文字を抜き出したって勉強になるってほどの情報量ないよ。

259 ：
情報量うんぬん以前に
何言ってんのかわからない
日本語なのか
これは

260 ：
ワードサラダにしか見えん

261 ：
変な翻訳を抜き出して笑うためのbotだと思うんですけど
SICPで翻訳と言えば例の翻訳炎上のはてブ勢の気持ち悪いこと気持ち悪いこと

262 ：
アスぺの人、和田訳を執拗に擁護するのはなんなんだろうな
専門知識で足りない英語力を補っているから、minghai訳よりはマシって程度なのに

263 ：
>>261
笑うためってのは言い過ぎだと思うけど、まあ、余興だよな。

264 ：
和田訳こそ英文が読めなくて、日本語を適当にでっちあげた
真鍋のいうところの腐臭のする糞訳なのに、
どういうわけか擁護するんだよな

265 ：
擁護とか一体何と戦ってるんだこのおっさん

266 ：
照り輝くbotはもともと糞訳をまとめたおもしろbotだろ
そもそも照り輝く自体相当前からネタにされてるし

267 ：
糞約とはいえ他人の著作物云々の問題はクリアしてるのか？

268 ：
SICPを糞訳と言うと、おかしな連中が絡んできて面倒だったけど
これからはこれ貼るだけですむから楽でいいわ
https://twitter.com/illmnt_SICP_ja

269 ：
>>261
はてブ気持ち悪いのだけ一貫してて主張がコロコロ変わってて面白い
主張は変わってないのに同じ人が擁護したと思ったら次の記事には叩いてんのな

270 ：
推奨NGワード: illmnt

271 ：
機械翻訳みたいな変な訳ばっかり
こういうのダメ出しするのも出版社の仕事だろ
アメリカの教科書はリーダブルじゃなきゃならないと聞くが
悪文で書いた教科書なんてのはそれこそ日本の悪文化だよ
ましてMITの教科書を改悪、悪文化するのはおかしいゾ

272 ：
まして、はおかしいか。俺も悪文化。

273 ：
http://peace.2ch.sc/test/read.cgi/tech/1333015632/

274 ：
プログラミングGauche尼で売り切れてオライリーが入荷待ちなんだけど
絶版？第2版？

275 ：
>>214
ラムダ式返したい

276 ：
本当はLisp使いたいのに急ぎだとpythonとかbashで使い捨てスクリプトを書いてしまう

277 ：
そうか。

278 ：
それで良い。

279 ：
(定義 (長さ リスト)
　(もし (空? リスト)
　　0
　　(加算 1 (長さ (残余 リスト)))))

280 ：
(定義 (右から畳み込み リスト 乗算 単位元)
(もし (空？ リスト) 単位元
(乗算 (車 リスト) (右から畳み込み (残余 リスト) 乗算 単位元))))

281 ：
「車」…w

282 ：
(管 リスト)

283 ：
Schemeを勉強しだす→「なんてシンプルかつエレガントなんだ！これさえあれば何でもできそうだ！」
Schemeで何か作ろうとしだす→「なんて面倒なんだ！CommonLispみたいに統一してくれよ！」

「R{5,6,7}RS準拠だぞ」
「けどここは各実装で好きにしていいぞ」
「皆自分でSchemeを作るんだぞ」

284 ：
Scheme は「俺自身が Scheme になる事だ」が奥義だから

285 ：
(もしもし？ もしもし？ ただいま留守にしております お掛けになった電話番号は)

286 ：
> 俺自身がscheme
それは違うが

287 ：
真の Scheme は世界で俺だけだもの

288 ：
「俺の母語はschemeだぞい」とかいうなら分かるんだけど。
俺がschemeってどういうことよ？もっと具体的に。

289 ：
俺がガンダムだ！ 的な。

290 ：
今度生まれる時は側溝に生まれたい的な

291 ：
マジレスするとオサレマンガの台詞

292 ：
> 俺自身がscheme
これは自分にはかなり納得がいく言い方だった。
自分はC++が主なんだけど、schemeを学んでから、その知見を取り入れて、
C++のスキルが顕著に上がったと思う。
自分の書くコードの質も、先輩の書いたコードに対する読解力も。
なんというか、schemeで考えてC++で書くようになったというか。

293 ：
lispの入門書って何がおすすめなん？Land of Lisp？The little schemer(scheme手習い)？

294 ：
>>293
(質問スレに書くべきだったけど許して)

295 ：
Realm of Racketの翻訳って誰かやってんのかな？shiroさん？

296 ：
>>293
漠然とした本なんかより処理系のソースコード
かといってgcc級の糞でかいの読めっても無理だろうから規模がちっこいやつね
ついでにその処理系で動作確認もできるし

297 ：
>>296
ありがとうございます

298 ：
>>293
プログラミングGauche

299 ：
>>293
前者は読んでておもしろい、後者はまじめに勉強にはなる
お金あるならどっちも読むと良いよ

あとは上の方に書かれてるけどソースコードはとっても勉強になるけどこれは結構しんどいと思うな(割と時間かかるから)。

300 ：
基本的な考え方くらいはおさえとかないとソースから意図を読むのは難しいと思うよ。

301 ：
>>299
>>300
ありがとうございます、やはりソースをそのまま読むのは辛いですよね…

302 ：
ttp://www.amazon.co.jp/dp/B018KXY55Y/
「ＬＩＳＰでわかる！プログラミング・自由に生きるための英語学習法」
何この…何これ?
kindleでサンプル見たんだけど、これで理解できる初学者いるの?

303 ：
一人称が予な著者らしい
https://twitter.com/tadachika_j

304 ：
個人出版のデジタル本で1200円は高いな。
50円なら買ったかもしれないのに。

305 ：
>>302
Kindle出版のオナニー書籍にしか見えないんだけど内容どうだった？(prime会員だからタダでよめるんだけどなんか触るのイヤな感じ)

306 ：
miniKanrenの日本語解説本
誰も書かないなら個人出版で出しちゃうぞ

307 ：
>>305
サンプルの範囲では
「○○が出来ます」＋コードサンプル
で１㌻
それが延々続いてた
目次見るとそこそこ解説もコードも書かなきゃいけなさそうなことも取り扱っているはずなんだが

308 ：
自分もサンプル版を読んでみたけど、言語の解説という雰囲気ではなく、自分の勉強した内容を箇条書きっぽく書いてあるように感じた。
サンプルは最初の方しか読めないから、LISPそのものの説明のところだけしか読めてないけど、後半の応用部分は面白くなる可能性はあるかもしれないな。

英語学習法の部分については、
http://primitive-lisp.blog.so-net.ne.jp
独学でこのくらい書けるようになるのであればスゴイと思うし、ブログを日本から発信するのには十分かと。
でもネイティブの人はカタコトのように感じるレベル。

309 ：
英語学習法の部分はサンプルに入ってないので、自分テキトーなことを言ってるぜ！？

310 ：
Lispの別スレ出来てる

311 ：
キチガイコテスレじゃん

312 ：
Deep Learningの人達はpythonフレームワークを乱立させてるけどlispのマクロ下位互換マクロ作ってるだけなのにいつ気がつくんだろ。lisp使えばフレームワークとかそもそも必要ないのに

313 ：
フレームワークを乱立させやすい言語は流行る
Lispもそうだった

314 ：
え、あ、うん

315 ：
Theanoとかlispで書き直したらかなりスッキリするのに
ごちゃごちゃしすぎ

316 ：
他人の書いたpythonコードを解析しないといけなくなって
「めんどくさい
何でLispで書かないんだ
解析させられる俺の身にもなれ
Lispなら長さが半分以下の読みやすいコードになるのに」
という感情がとても高まってきている

317 ：
お前が書いたlispのコードの方がもっとひどいんだがｗ

318 ：
windows内蔵言語のvbscriptでschemeモドキを作ろうと目論んでる
つってもちゃんとやるのはマクロと末尾再帰だけでね
variant型使ったリスト処理がどんだけ遅くなるか見ものだ

319 ：
100Gぐらいのメモリーに入りきらないデータを扱う時にpythonではジェネレター式というのを使うけどschemeやlispではどういうふうにするの？

320 ：
典型的なのはストリーム (srfi-41)
http://srfi.schemers.org/srfi-41/srfi-41.html

ジェネレータの形にする場合もある。
http://practical-scheme.net/gauche/man/?l=jp&p=gauche.generator

Gauche だと遅延シーケンスがある。
でも、これは処理系自体に組み込みじゃないと後付けでは難しいので遅延リストに依存したコードは移植性に難があるかもしれない。
http://practical-scheme.net/gauche/man/?l=jp&p=%E9%81%85%E5%BB%B6%E3%82%B7%E3%83%BC%E3%82%B1%E3%83%B3%E3%82%B9

単なるバイト列やテキストであればカスタムポートも使いやすいと思う。

321 ：
https://github.com/dherman/c.rkt
これでC言語のプログラムを自由に加工したりできるっぽいのだけど
ドキュメントらしきものがない
誰かexample usageみたいなものどこかにないか知りませんか？
使えればかなり便利そうなんだけど

322 ：
Racket はなんだか独自の世界で生きてるよね

323 ：
>>321
拡張子が scrbl のファイルはドキュメントだぞ。
Scribble で html などに変換できるはず。

324 ：
Edi Weitzの新著の書評誰かplz.

325 ：
http://cl21.org/

326 ：
>>325
いや違うと思う。CLって多分思考（若しくは試行）ツールなんだと思うよ
俺が使いこなせないのは普段から抽象を扱ったりしてないから

327 ：
>>324
http://clfreaks.org/post/137885712779/12-common-lisp-recipes-plus

328 ：
schmeme 手習いを反復してやってます
(cond ((eq? a (car lat)) ....
で eq? が真を返すときの実行文の文法がわかりません

教科書では
(cond ((eq? a (car lat))(cdr lat))
となっていますが
(cond ((eq? a (car lat))(print "abc")(cdr lat))
と真の時の従属節に関数実行のS式を追加することはOKでしょうか？

目的はデバッグのため
処理系はgauche です，プログラミングgaucheを手元に置いていますがよく読めてません
よろしくお願いいたします

329 ：
beginすればいいんじゃね

330 ：
>>329
if のときじゃなくて cond のときはどうでしょうか？

331 ：
>>330
condはifとbeginに置き換えられる
condをマクロとして実装してる処理系は多い
まず処理系のソースを見てごらんよ
(cond (test1 body1) (test2 body2) (else bodyn))は
(if test1 (begin body1) (if test2 (begin body2) (begin bodye)))
に一旦展開された後で項書き換えとかコンパイルとかされる
要するにcondのbody節は複文相当で最後の式の値が全体の式の値になる
構文が判らないレベルなら教科書は一旦捨てて処理系のソース読んだ方が早い

332 ：
ちなみにschemeはマクロを除いて基本構文は5つしか必要ない
define lambda set! if beginだったかな？
でも厳密にはquote関係も数に入れると10個ぐらいかもしれない
それ以外は全て上の5構文を組み合わせたマクロとして定義できる
つまり上の5構文だけマスターしとけばよい

例えばletがマクロなら(let((var value)) ～)は((lambda(var) ～)value)
のように意味を全く違えずに置き換えられる
残りのマクロも同様に基本構文への展開形を連想できるようになれば
schemeの基本はマスターしたと思ってよい

ただし肝心のschemeのマクロの定義は手段が沢山あってカオスなので
schemeマクロの闇については自分で調べて下さい
gaucheなら大きく分けて2つだろうけど

333 ：
最近の Gauche には explicit renaming マクロ変換器が入ってるよ。

334 ：
ノートぱちょこん買い替える非業界人なんだけど、最近話題沸騰中の
LispとSchemeにちょっと興味があって。やっぱりマックにしたほうが
幸せになれるんでせうか？それとも、今までのぱちょこんをLinixに
したほうがいいのかな？

335 ：
割とどうでもいい

336 ：
マックにArchLinux入れろ

337 ：
>>334
LispとSchemeで遊びたいならWindowsでもMacでも好きな方買って大丈夫
WindowsならWindowsに適したものが、MacだとUnix処理系から普通にって感じで入れられるよ。

338 ：
最近どこで話題沸騰中なんだ？

339 ：
Windowsでコーディングとか正気か

340 ：
Gauche で OpenGL 使うときは Windows の方がよい

341 ：
メモリを多めに積んだやつに VMware なり Virtual PC なりの仮想化ソフトを入れて使い分ければいいよ。

342 ：
レスありがとうございます。質問者です。
やっぱりマックがいいという意見が多いみたいですね。
そろそろ新型出るという噂もあるようなので様子見て買ってみたいです。
LinuxはArchってのがいいんですかね？
昔のスラックウェアみたいなかんじなのかな。古いPCでも遊べそうですね。

343 ：
・・・！？

344 ：
Lispで書かれた対話botか？！

345 ：
はじめてのLisp関数型プログラミング――ラムダ計算からリファクタリングまで一気にわかる (Software Design plus) 五味 弘
ていう本が出てるけど、これはISLispなの？CL？

346 ：
>>345に限らず本スレの皆様への質問とお願い

> これはISLispなの？CL？

そもそもISLispを主たる対象とした日本語で書かれた本（言語仕様の詳解中心でもプログラミング中心でもどちらでも可）って
（個人や大学・研究所などのWebサイトにPDFファイル等の形でアップされているとかでなく印刷され商業的に通常の書店で
購入可能な形で販売されているという意味で）出版されているのですか？

日本語でLispの本というとSchemeかCLかしか存在しない（英語圏でも状況は変わらない）と個人的には思っていたのですが？
日本語に限らず英語でも構わないのでISLispを主題とした書籍をご存知でしたら教えて下さい

347 ：
ISLisp は、Lisp言語のISO標準であり、1997年にISO規格が制定されました。
ISLispは、業界標準となっていたCommon Lisp の言語仕様の巨大さに対して、
処理系の効率と学習・利用の容易さを向上するために, Common Lispを継承
しつつ EuLisp, Le Lisp, Scheme を参考としてコンパクトで一貫性のある
言語を目標に 開発されました。


とあるけど、そういえばISLispの本って見たことないかも。

348 ：
ISLisp、惹句はいいんだど、いかんせんまともな実装が無いのがな。

349 ：
著者「関数型おしえます！」(お？どれどれ)
著者「Lisp最高です！」(あ、うん)
著者「…islispﾃﾞｽ…」(は？！なにそれ？伊豆lisp?)

ブロガーA「良著なのでコードをschemeで書きなおしました」(いいねえ)
ブロガーB「haskellでかきました」(うおおおおおおお！！！！！)

という反応になるよね。一般的には。
common lispかschemeで書き直したものをHPにアップすべきだと思う。

350 ：
せめて伊豆用slimeぐらい用意しないと女子高生には読んでもらえないと思うんだ

351 ：
はじめてのLisp関数型プログラミング、昨日買ったばかりなんだけど
ハズレ感が半端ない

352 ：
で、ISLispなんですか？

353 ：
ISLisp でggrと「ISLISPを使うべきでないたった1つの理由」がトップに並ぶ哀しさよ

354 ：
サンプルプログラムダウンロードしてみればわかるのでは。

355 ：
ちなみに本の最初の方ではclisp導入してた。

356 ：
最近は、RHがclojureでうまく整理して、関数型含めてjsに広まる概念もあったりする。

逆の流れでいうとtransducerをhaskellで説明しようとしたけどちょっと足りない話。
https://reddit.com/r/haskell/comments/2cv6l4/clojures_transducers_are_perverse_lenses/

いまだとshapeless使えば静的な型検査通る可変な型扱うコレクションつくれるらしいので、上のやつみたいなのも着実に減っててるとは思う。
https://github.com/mandubian/scaledn

結局のところC#などにもそうやって取り込まれてるんじゃないかなと。
react(.js)もphpのテンプレートエンジンの置き換えからだそうで。

357 ：
clojure が lisp方言として紹介されてると違和感がある

358 ：
>>357
すまぬが理由がわからないのでkwsk解説を求む

359 ：
>>358
・特に [ ] のあたりの文法が違うのでLispの資産を移行できないから
・Lisp の　( ) の対応に慣れた人には、罠のようにはりめくらされた文法不一致があるから
・S式だけで構成できないから
・再帰末尾最適化に制限があるから

360 ：
>>359
1の[]に関しちゃ大昔のスーパー閉じ括弧の存在を忘れてもらっては困ると思うしschemeの一部処理系も括弧の代わりに表現力の強調で括弧と同等に扱う等に導入してるからそこまで嫌わんでもと思う
2の部分は許容してもらうしかないんじゃないのかなぁ、まぁ否定はしない
3は1と2の事だよね？
4はLispというよりscheme好きの人なら反発するのとてもよくわかる。(jvm側の問題でもあるけど)

[]に関しちゃむしろ良く出来てると思うのだよね、3が許せないとどうしようもないけど。

リーダーマクロが普通に扱えないって言う意味で怒ってるのかと思ったのでちょっとびっくりしました。>>359

361 ：
>>359
> ・再帰末尾最適化に制限があるから

「再帰末尾」じゃなくて「末尾再帰」
元の英語は "tail recursion"

362 ：
> ISLisp でggrと「ISLISPを使うべきでないたった1つの理由」がトップに並ぶ哀しさよ
これ根本的に間違えてんね．ユーザーいないし訂正する人もいないからこのページが消滅するとよいね

363 ：
算法表現論ゲット
読みやすそうで少し安心

364 ：
>>362
ちょうど、昨日、そのページ読んだばかりだった。
どこらへんが間違ってるの？

365 ：
> 「実行時情報」が使えないということは，つまり，自分で定義した関数によるマクロの展開は行えない，ということです．
ココ。つまりこのページの主張全部

366 ：
自分で定義した関数ってコンパイル時情報だよな？

367 ：
仕様から関連しそうな箇所を抜き出してみた。

> 4.8 定義演算子
> 定義形式によって定義される名前は、最上位有効範囲全体で使うことができるが、
> ISLISP テキスト単位における実行準備された最上位形式は、左から右に順に実行される。
> (略)
> (defun function-name lambdaform*) → <symbol>
>
> defun 形式は、 function-name を、関数名前空間の識別子として定義する。 function-name は、 (lambda
> lambda-list form*) と等価な関数オブジェクトに束縛される。

> 8. マクロ
> (略)
> マクロは、実行準備時に展開される。 いかなる実行時情報も使えない。使用可能な操作は、単純なデー
> タ構造の生成及び処理に制限される。すなわち、（端末への入出力のような) 環境への副作用、(記号の属
> 性リストの変更のような)外部的にアクセスできるデータ構造への副作用、及びマクロ形式自身への副作用
> を起こす操作は禁止する。

「4.6 評価モデル」も関連するけど長くなるので要約。
・ まず実行準備される
・ 実行準備が完了してから実行される
・ 実行準備完了時点でマクロ展開は終わっている
・ 実行準備のための処理は処理系依存

断言できるほどはっきりしてないけど、関数の定義名はマクロ展開時にも見えてて、
関数名と関数オブジェクトを結びつけるのは「実行」だと解釈するのが妥当だと思う。
マクロ定義中にユーザー定義関数を使えないとする解釈を私も支持する。

ただ、全体を通して見ると副作用のない (プログラマが定義した関数を含む) 関数なら使えると想定しているっぽい雰囲気
はあるような気がする。

368 ：
>>365,365,366

みなさん情報ありがとう。
ISLISPの日本語の仕様書はどこかなと思ったら、ここにあった。
http://www.jisc.go.jp/app/pager?id=1759608

ダウンロードしての閲覧禁止って。変な制限かけてるなぁ。

369 ：
>>368
その URL では見れないよ。
URL 中の番号はあなたがアクセスしたときのセッション番号。
文書に固有の番号ではないので、パームリンクとして使えない。
ダウンロード禁止なだけじゃなく、たぶんサーチンエンジンのクロールも避けてるんだと思う。

370 ：
表示中オフラインにするとpdf中のjsに怒られたような記憶がある

371 ：
普及させる気ないんだろうね

372 ：
買ってもらってるから、不公平って話だと思われる。
紙も実費で配れる財源あるといいんだけどね。

isoは販売になってるけど、他団体と共同でたまに公開されてるのがある。
草稿は公開してるところもある。

373 ：
ここで公開してたやつも草稿であって、ってリンク切れしてるのな。
http://www.open-std.org/JTC1/SC22/WG16/

http://www.islisp.com/jp/ISLisp-spec-jp.html

374 ：
isoやansiよりはjisの方がweb公開進んでるのだけど、
ecmaならecmascript(js)やclr(.net)みたいに公開されるのか。

375 ：
日本の法律だと JIS 規格に著作権が認められるかどうかははっきりしない。
総合的には認められないとする説の方が有力らしいんだが、
ISO は規格の著作権を主張してるからそれに加盟してる JISC も倣うしかなくて、
間をとって閲覧だけは無料という曖昧なところでぼやかしてるらしい。

376 ：
工業規格は事実上の業界標準を後追いで規格化したのがほとんどだから、著作権どころか特許が生きてるのが混じってるので注意が必要

377 ：
> 366
> 断言できるほどはっきりしてないけど、関数の定義名はマクロ展開時にも見えてて、関数名と関数オブジェクトを結びつけるのは「実行」だと解釈するのが妥当だと思う。

入手できたISLISP Working Draft 23.0をベースにして述べるが，その理屈だと備え付けの関数も展開には使えないように思える．
備え付け関数もユーザ定義の関数もpreparation for executionの間に実行可能という記述はない．
不可能という記述もない．(定義はしないとある)

仮にユーザ定義の関数は使えないとしよう．
ローカル関数 (flet labels)が，defmacro 内で使えないようには見えないのでこれで対処できる．
また，マクロは使用場所に先行して定義があることが必須とあるということは，ユーザ定義のマクロは使えるように見えるので，補助関数の所を補助マクロとするのも良いだろう．
CommonLispでもマクロ展開の補助でユーザー定義関数の利用は必須ではないし，利用するには評価フェイズを合せなくちゃならない問題がある．(ISLISPはこれを回避したのかもしれない)
これをもって「ISLISPを使うべきでない」とするのは誇張が過ぎるし，真に受ける者が出るとしたら害悪だろう．

378 ：
そのページの害悪よりも、isLispの素晴らしさが伝わるようなページが
検索トップに来ないことの方がずっと問題だと思うけど

379 ：
>>377
「実行準備」「実行」の繰り返しがどういう単位なのかっていう、フェイズの分離の仕方の問題だよな。
ひとつの式ごとなのかプログラム全体にわたってなのかでも解釈が違ってくる。

まあ最大限に安全な方向に見積もって未定義だと解釈しても、
それで ISLISP の有用性が全部失われるわけではないということには賛成できる。
あの記事はよくある誇張した煽り記事だろ。 センセーショナルなタイトルをつけてるだけで大したこと言ってない。
しょうもない記事が上位にきてしまう程度に ISLISP に関する記事が少ないってだけ。

380 ：
ISLispを普及させるために必要な10のこと
・ISLispBoxを無償提供する
・ISLisp Hyperspecを無償提供する
・SICPをISLispで書き換える
・On ISLisp、Little ISLisper、Land of ISLispを出す
・ISLisp for Dummies、すごいISLisp楽しく学ぼう！も
・WhyのISLisp感動的ガイドを公開する

381 ：
他の実装へのトランスレータがあれば普及させる必要はない

382 ：
・良い実装
・無料
・商用利用に優しいライセンス
・寛容的なコミュニティ
・サクセスストーリー

上記があれば、ドキュメント、ライブラリ、ツールなどの問題は自然に解決するかと

383 ：
God Wrote in Lisp (The Eternal Flame)
http://www.catonmat.net/blog/musical-geek-friday-god-wrote-in-lisp-eternal-flame/

384 ：
>Lispを普及させるために必要なこと
括弧が少ない言語の方が好まれる傾向にある
よって括弧が一切存在しないLispが誕生すれば爆発的に普及するだろう

385 ：
今年のscheme workshopは日本
いつもwebdbfと重なって行けなかったが今年は行けそう

386 ：
言語で使う括弧の量と、括弧打つのが面倒な場面の数ってあんま関係ないよね。

括弧使う言語を書いてるときに面倒なのは、今書いた式を引数にして別の関数を更に適用しようかとかなったときに、
後に閉じ括弧つけてカーソル前に戻して関数名書いて括弧つけて、ってやるときがほとんどなんだけど、
例: foo(x,y)_ → bar(_foo(x,y)) # "_"はそのときのカーソルの位置
Emacsなら一発で飛べる分、むしろLispの方が楽なときがある。

そういう意味だとOCamlの foo x y _ → foo x y |> bar_ は便利だった。

387 ：
Lispが普及しないのはEmacsで開発するのが当たり前ってところでしょ？それじゃ新規は増えないよ。

388 ：
それはいいんだよ
CLやscheme, Racketに比べてISLISPが普及してないのはもったいないよね
という話

389 ：
>>387
F#はVisual Studioだけど普及してないし

390 ：
>>389
F#は好きな言語ではあるが、C#と比べるとVSの動作が重くてしんどいよ。
型推論が遅いのか構文解析が面倒なのか、自動でエラー箇所表示させると凄く反応が悪くなる。
FParsecとか関数型言語ならではの便利ライブラリ使うとより顕著に。

ISLispはロクな実装無いし真面目に使っている人がいないから、どこが便利でどこに課題があるかも分からんのがね。

391 ：
>>389
なら開発環境と言語の両方に魅力がないとダメってことじゃない？

392 ：
smalltalkは普及してないけど、objective-cは普及した
つまり、Lispを普及するには中間言語をcにして、、、

393 ：
そういえばsqueakがレイヤごとに言語変えるとかどっかでチラと読んだような気がする

394 ：
>>392
Objective-Cは絶滅危惧種だったがジョブズのおかげで生き延びた

395 ：
最も愛されているプログラミング言語や技術

1. Rust(79.1%)
2. Swift(72.1%)
3. F#(70.7%)
4. Scala(69.4%)
5. Go(68.7%)

http://news.mynavi.jp/news/2016/04/07/062/

Most Loved Programming Languages Of 2016 ? Rust, Swift, F#, Scala, Go
http://fossbytes.com/loved-programming-languages-rust-swift-go/

だそうです

396 ：
>>395
愛人にしても本妻には決してしたくない言語だね

397 ：
Rustは好き。C/C++が引き受ける低レベルな領域に型システムの安全性と利便性を突っ込んでみたっていう発想は良い。

けど、コンパイル時間がコード量から予測しづらい(イテレータやジェネリクスを使ってると特に)のと、
莫大なライブラリを資産に持つC/C++と比べたときの実用性の差を考えると、
潤沢な計算資源があって、比較的優秀な人材が揃えられるところ向け。

Schemeのような、スタンドプレーの生産性を莫大に高める言語じゃあないと思う。

398 ：
俺もRust好きだな、ただObjective-Cみたいに言語のはらわたまで触れる(smalltalk由来の部分ね)緩さをもった言語も大好きなんだよな
あとはClojureが好き、これはWebアプリ書いてるとき限定だけど。

LispスレなのにLisp系がClojureとかでスマヌ

399 ：
Lisp系言語のネックは言語実装じゃなくて実行環境だと思う

400 ：
>>399
マルチプラットフォームでコンパイラで実行バイナリも吐けるし何が問題?

401 ：
>>400
「Common Lisp なら問題なく安定して高速な実行バイナリを吐ける」　という前提が必要かと

402 ：
マルチプラットフォームとかより.NET Frameworkとか使えるかが問題

403 ：
Biglooは高速なんじゃないの？

404 ：
Hyper Specが日本語に翻訳されたら増えるかもね。
日本語の情報が少なすぎだよ。

405 ：
Racketからpython使うだいぶ楽になったけど、逆はどうすればいいんだ？

406 ：
Deep Learningライブラリkeras
がニューラルネットワークのグラフ処理と数式処理を組み合わせた
ちょっと気の利いた自動処理をやってくれてたんだけど，バグだらけで
pyrhonで数式処理やるの無茶だしこんなものだろうと思ってたら
最新版で気の利いたグラフ処理を全部削除してきた

数式処理をLisp以外でやるのは，やっぱり無理だったんだな

407 ：
sympy ないからね～♪

408 ：
SymPyはテンソル処理できないし

数式を評価して数値にしないで式のまま扱うには
どうあってもマクロの機能が必須

409 ：
もうちょっと具体的に言うと
x_iのiも数値じゃなくて数式になってるような処理がmaxima以外じゃできないんだよ

410 ：
ややスレ違いで申し訳ないのですが、
Common Lispで記述されてるMaximaのWindows版バイナリの
GCLやSBCL版がDEPの対象からから外さないと動かないのって、
多分fasl絡みだと思うのですけど、これってどうしようもないのでしょうか？

411 ：
をを専ブラじゃなくってIEで書き込めたぞ

412 ：
windows10のubuntuサブシステムってguile動くのかな？

413 ：
ubuntu subsystemはterminal関連やプロセス情報周りまだ調節してるみたいなので、起動で使ってるととまるかも。

cygwinと違いlinuxのバイナリがwindowsのシステムコールに変換してそのまま動くらしいが、プロセスfork周りとか安定するのかな。

docker for windowsでも結構いろいろ出来るけど、
こちらはファイル連携の効率が鬼門？

414 ：
schemeでSDL使ってなんかやってみたいのだが
guileでもgaucheでもうまく使えるようになってくれん・・・（´・ω・｀）

週末おわったからまた来週までおあずけ・・・

415 ：
>>375
規格そのものには著作権はない
規格書にはある
JISはお役所っぽいとはいえ
規格書は著作権法の除外対象である
「憲法その他の法令」「告示・訓令・通達等」「判決等」などには含まれない

416 ：
>>415
というはっきりした根拠がないという話な。

417 ：
著作権法の保護対象は、思想や感情などを創作的に表現したものだから、規格書が該当する可能性は低いんだよね。
執筆者の思想や感情に染まった創作的な規格書とかアレだし。

418 ：
規格化されたから安心して使えるよね、ってのが長所だろうに
なぜ規格書を半クローズドにするのか全然意味が分かんないｗ
パンピーから見て「馬鹿なんじゃねえの？」ぐらいある

419 ：
Wikipedia にもそのあたりの経緯は書かれてる。

https://ja.wikipedia.org/wiki/%E6%97%A5%E6%9C%AC%E5%B7%A5%E6%A5%AD%E6%A8%99%E6%BA%96%E8%AA%BF%E6%9F%BB%E4%BC%9A

公官庁が作ってるとは限らない (つまり原案が民間からの提案による) というのが著作権が保護される根拠になってるな。
でも、規格票やハンドブックの売り上げは規格団体の活動資金であって (原案の) 著作者に還元されてるわけでもないみたいなので、
その点でも説得力に欠ける気がする。

420 ：
誰かが法廷で争って白黒付けん限りはどうにもならん

421 ：
>>419
それは権利が移譲されてるだけ

422 ：
権利守るためには普及しなくてもいいや、ってことか

423 ：
>>421
手続き上どうなってるか知らんけど、民間の権利を保護することを理由にしてるのに
権利を移譲させているのなら保護する理由として説得力が欠けることにはかわらん。

424 ：
問題は特許の方だったりする
規格化されてる技術でも、民間企業の特許権が放棄・委譲されてない場合があるから注意ね

425 ：
いつのまにか Chez がオープンソース化されとるんやけど。
https://github.com/cisco/ChezScheme

426 ：
ライセンスは Apache License 2.0 か

427 ：
匿名通信（Tor、i2p等）ができるファイル共有ソフトBitComet（ビットコメット）みたいな、
BitTorrentがオープンソースで開発されています

言語は何でも大丈夫だそうなので、P2P書きたい！って人居ませんか？

Covenantの作者（Lyrise）がそういう人と話したいそうなので、よろしければツイートお願いします
https://twitter.com/Lyrise_al

ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーｗ


The Covenant Project
概要

Covenantは、純粋P2Pのファイル共有ソフトです

目的

インターネットにおける権力による抑圧を排除することが最終的な目標です。 そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します

特徴

Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW)

接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です
DHTにはKademlia + コネクションプールを使用します
UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります)
検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません
7

428 ：
The Little Prover (MIT Press)
by Daniel P. Friedman et al.
Link: http://amzn.com/0262527952

429 ：
>>428
https://github.com/the-little-prover/j-bob
http://the-little-prover.github.io/

430 ：
Scheme workshopに間に合わなかった論文を投稿できる国際会議って他にないものでしょうか？

431 ：
elispで"で囲まれる文字列をエディター上で複数行にわたって一行の
文字列を作るにはどうやりますか？

432 ：
>>431

"foo
bar
baz"

を

"foobarbaz"

にするってこと？

433 ：
>>430
ACMのプログラム言語系国際会議だとここらへんに
http://www.sigplan.org/Conferences/
https://en.wikipedia.org/wiki/SIGPLAN

Scheme workshopはICFPと併設か
http://conf.researchr.org/home/icfp-2016
http://scheme2016.snow-fort.org/
Submission deadlineJune 24th, 2016

似た時期にやってるSPLASHと併設はアブストラクト提出があるみたいで締め切りがはやそう？
http://www.sigplan.org/Conferences/SPLASH/

POPLが1月、PLDIが6月みたいだけど、この時期は各種言語系の併設少ない

European Lisp SymposiumもACMと共同みたい？だけど
来年は4-6月ぐらいなのかな？
http://www.european-lisp-symposium.org/

そして、ILSの開催はよくわからない

434 ：
>>432
ということです

435 ：
例えばリージョンを指定して
(replace-regexp "\n" "" nil (region-beginning) (region-end))
とするとか。

436 ：
こういう改行を自動的にオミットしてくれるraw文字リテラルとか言語によってはあるよね。

437 ：
バックスラッシュで改行をエスケープしたらできました
ありがとうございます

438 ：
Racketのメモリ使用効率が最近、劇的向上したと聞いたがソースが見つからない

439 ：
適当なコードをプロファイラ付きで動かしてみれば自分で確かめるのも簡単にできそうに思うが

440 ：
scheme workshop のホームページが落ちてる

441 ：
scheme on you!

442 ：
python のdoctestっぽいのが
コメント領域
#|
...
|#
で囲まれた範囲に書かれている
https://github.com/JeffBezanson/femtolisp/blob/master/examples/bq.scm

こういうテストの記述方法使えるscheme処理系って他にないものでしょうか

443 ：
>>442
doctest ではないけど、同じファイルにテストを書ける方法がある。

SRFI-22 で、 main 手続きがあるとそこをエントリーポイントにする機能があるんだが、
Gauche では -m オプションでモジュール名を指定すると
そのモジュール内にある main (通常は実行されることはない) を実行できる。
ライブラリとして書いたものをスクリプトとしても実行できる仕組みなんだけど、
実際のところそういう使い方は普通はしないので main にテストを書いておくという使い方も出来る。

あるいは、 -F オプションの有無で cond-expand を使って分岐してテスト部分を走らせるという方法もある。

444 ：
Clojureだと関数定義にmeta情報としてtestを登録できるけど
Schemeのマクロでtest呼び出し可能なdefine-with-testみたいなの作れないものなの？(あたしゃSchemeいぢった事ないのでわからん)

445 ：
>>444
出来る。

446 ：
http://ecraven.github.io/r7rs-benchmarks/benchmark.html
Chez が圧倒的なんだが、何故か string のテストだけ突出して順位低いな。

447 ：
文字列の取出しや結合を繰り返すベンチだな。
Chez の実装をおおざっぱに見てみたら、文字列はただの配列らしい。
string-append も新しくアロケーションしてコピーするだけ。

https://github.com/cisco/ChezScheme/blob/fe172bfdfbf2f606db611013e7689d6a2b117d5e/s/5_4.ss#L33

文字列が rope ならこの種類のベンチは高速になるはずなんだけど、
それはそれで string-ref などが少し遅くなるという欠点もある。
R6RS は string-ref や string-set! が定数時間と要求してるのでそっちを優先したのかも。
(要求といっても `should` はその処理系でコストが大きかったり他との兼ね合いで難しいようなら無視してよい緩い要求。)

あと、 Chez のこういった基本的な手続きは Chez 自身によってコンパイルはされるが、
C で書かれている場合と比べると遅くなると思う。
C で書かれているライブラリを呼出したら、呼出されている間は C の速度ってことだからな。
それらと比較して多少遅い程度で戦えてるならかなり強いんじゃね。
他の実装がどうなってるか知らんけど。

448 ：
>>436
どういうraw文字リテラル?

449 ：
YAML のこれ https://ja.wikipedia.org/wiki/YAML#.E6.9C.80.E7.B5.82.E8.A1.8C.E3.81.AE.E6.94.B9.E8.A1.8C.E3.81.AE.E3.81.BF.E7.B6.AD.E6.8C.81.E3.81.97.E4.BB.96.E3.81.AF.E3.82.B9.E3.83.9A.E3.83.BC.E3.82.B9.E4.B8.80.E5.AD.97.E3.81.AB.E7.BD.AE.E6.8F.9B
とか思い出した。Lisp では知らないや。

450 ：
Gauche 0.9.5 のリリースが近いみたいだよ

451 ：
まだメンテとかしてたのか…

452 ：
バージョン1にならないうちにプロジェクトが消滅しそう

453 ：
中の人が存命な限り続くだろう
本人が使ってるんだし

454 ：
リリースの間隔は長いけど、かなりの頻度でコミットはされてるよ。

455 ：
Gaucheはschemeである限りschemeの1処理系にしかすぎない
schemeのノロノロした規定の縛りに従っていくのもアホらしいと感じているだろう
.NETに対応して誰もを唸らせるLispやSchemeという分類を超えた新たなLISP族が誕生してもいいんじゃないっか

456 ：
powershelがマルチプラットフォーム＆オープンソース化して化けたしここらで標準で使えるpowerLispっぽい何かが欲しいとこだに

457 ：
JVM にとっての Clojure みたいな？
特定の VM に縛られる方が特定の言語仕様に縛られるよりあほらしくない？

.NET の世界でのスタンダードな LISP 系言語があったらいいなぁというのはわかるけど、
.NET なライブラリを呼び出すだけなら適当なバインディングを作れば Gauche からだって出来るので、
Scheme の仕様が足かせということはないと思う。

458 ：
ttps://github.com/clojure/clojure-clr
clojureは.net版もあるね,JVM版とバージョンは一緒だけど
clojureでよく使われているプロジェクトはjavaライブラリのjarに依存してるのも多いからどうなんだろ?

459 ：
>>455 について意見した >>457 にもうちょっと意見を付け足し

どちらを軸にするかという問題だから、
Java の世界を軸にすれば厳密に Scheme の仕様に従おうとするといまいちなところは出てくるだろうし、
Scheme の仕様を軸にすれば Java (JVM) のデザインがクソザコに思えたりもするだろう。

Scheme からでも Java やら dotNET の機能は呼び出せるが、
単に呼び出せるというのと全体として違和感なく統合されているというのは別物なので、
dotNET ユーザにとっては dotNET の世界に合わせた LISP が欲しいというのは納得のいく意見だと思う。

でもそこで Scheme を引き合いに出されると違和感あるわ。
Gauche は別に dotNET を想定してデザインしたわけじゃないしハナから Scheme 処理系なんだから
軸足は Scheme にあるわけで dotNET 的に制約に感じられても当たり前の話。
勝手な評価軸で「アホらしい」なんてのはそれこそアホらしい。

460 ：
.netはc#,f#に集約されているので、S式使った組み込みDSL向けか、replなどのユーティリティー系しか用途がない気はする。

最近はnotebook形式のツールが増えてきたので、そっちも限られてきた気はするが。

461 ：
.netはDLRが出た時に.net言語の実装増えたけど、利用者少ないし、ほとんどがメンテできてないんじゃないかな
JVMだと使える処理系としてkawa、abclもメンテされてるはず。
それとリッチ・ヒッキーは.netでscheme実装やってみたけど、意図的にclojureからjvmに移行したという記憶が。

clojureは組み込みデータ型がJVMに寄ってるので、cljsもclojureclrも組み込みのデータ型で苦労してるし、clrは特にサードパーティーのライブラリが対応してなくて苦労してる。
ただ、ニュートラルにするとshenとかFantomみたいにあんまり他の言語と相互利用できなくなる。
clrは、unity使えるけどスマホで使えないし、WPF対応させたりしてるけどクロス環境では使えないみたいな話も。

JVMは末尾再帰辛いけどindyやgraalvm+truffleみたいにネタが増えてて実装オタク向けの新しい題材が増えてるし、他のVMでも.netよりもerlangのvmや、llvmあたりの方がまだ活発なイメージがある。

462 ：
>>461
> clojureは組み込みデータ型がJVMに寄ってるので、cljsもclojureclrも組み込みのデータ型で苦労してるし、clrは特にサードパーティーのライブラリが対応してなくて苦労してる。

なんでそういう勘違いしてるのか気になるな
clojureの組み込みリテラルは数値、シンボル,キーワード、文字列、キャラクタ、list、vector、dictionary(map)とsetでCLRでも問題無い奴しか無いよ

> clrは、unity使えるけどスマホで使えないし、WPF対応させたりしてるけどクロス環境では使えないみたいな話も。
スマホはiOSが実行時評価禁止してるからunity上でのclojure.clrは制限があるのは事実だけど、これも誤解が入っていると思うぞ

> JVMは末尾再帰辛いけどindyやgraalvm+truffleみたいにネタが増えてて実装オタク向けの新しい題材が増えてるし、他のVMでも.netよりもerlangのvmや、llvmあたりの方がまだ活発なイメージがある。
JVMは末尾再帰を完全に保証できないからclojureのrecurが生まれたのだけど、順序間違ってない？

463 ：
フォローありがとう。
unity+clojureclrってiosで動くようになったのか。

javaの規格では末尾再帰最適化はないけど、
ibmのj9 vmでは、末尾再帰最適化してくれる。

464 ：
S式はいつまで日陰なのか
なんでXMLは普及したのか
XMLの前身のHTMLはなぜS式ではなかったのか
無茶苦茶汚くなるスクリプト埋め込みやCSSとかをなぜ苦労してまで使うのか
そんなにS式が嫌か

465 ：
手習いの推薦図書で興味を惹かれたんだけど
物まね鳥きちんと読むと、どうなるの？
Lispをやるのにどんなご利益があるの？

466 ：
>そんなにS式が嫌か
はい

467 ：
括弧の対応わかんなくてインデントで対処したら
だったらインデントあれば括弧いらなくね？ってなって
いまでは立派なHaskeller

468 ：
ごめんなさい、殺さないで

469 ：
にわかHaskellerだけど立派ではないだろ盛るのもいいかげんにしろ

470 ：
Gauche 0.9.5 出たよー

471 ：
いつまで0.9彷徨ってんだよ
そんなハードル高く設定して何になる

472 ：
今のバージョンを何と呼ぼうと手に入る機能は変わらないのに、バカなの？

473 ：
ナンバーが 1 未満だと未完成という印象になっちゃうのかな？
バージョンナンバーの振り方はそれぞれのプロジェクトでのポリシーで決める話。
Gauche の場合はこういうマイルストーンが設定されてる。
http://practical-scheme.net/gauche/devinfo-j.html

たぶん作者が考える一通りの機能がこれだけということではあるんだろうけど、
バージョン 0.9.5 は 0.9.5 という完成品だし、 1 を過ぎたからってそれで終わりってわけでもない。
所詮は一区切りの目安。

474 ：
セマンティックバージョニングみたいなのがあるし、最近だと1.0を出さないのは個人で開発してるとおおいのかな？
昔はtexみたく収束していく系やってる人は多かったけど、やっぱり個人かね。

475 ：
というかそのドット別に小数点じゃないし・・・
混同するのは間違いないのでいっそコロンやセミコロンで区切ったほうが理解しやすいかもしれない

476 ：
いや、本来は小数点だったよ
「0.9の次だけどまだ未完成だから0.10にしたよー」とかやらかしたから信用を失っただけで

477 ：
>>476
具体的なソフト名挙げろや。普通 0.91 とかに行くだろ。

478 ：
社内業務ソフトですらバージョン番号が0.xなのってざらだと思うのだけどなぁ
1.0ってほぼこれで完璧的な意味で付ける会社もあるだろうし
(売り物のくせにVer 3の倍数から完璧の会社もあるけど：老舗のOS屋さんとか)
なお、1.0以降になるとちょっと仕様が変わっただけでメジャーバージョンが上がる会社もあるけど(猫科の動物の名前付ける所とか:Ver 9までクソだったような気もするけど)

ようするにバージョン番号って作者が自由に付ける物じゃないの？

479 ：
>>478
自由でいいけど、ひとつのソフトは一貫した (わかりやすい) ルールを持っておいてほしくはあるね。

480 ：
まあ linux もいきなり　3.x になったり，よく分からない理由で 4.x になったり

481 ：
Windowsも10になったけど中身は8なんだろ？

482 ：
0-originでバージョン付けたっていいじゃない。

483 ：
0.x.yは劇的な変更があっても泣くなよ、という意味合いだと思っている

個人的にはセマンティックバージョニングを付けてもらえるとありがたい
1.x.yなら、機能追加でxを1つ増やして、バグ修正でyを1つ増やすってやつ
0.a.bは開発途中だから後方互換性は無くてもいいので、開発者が試行錯誤しているうちは1未満だとはっきり分かる

firefoxやchromeの馬鹿みたいなバージョン上げはマーケティングの意味合いが強くて好きになれない

484 ：
つーても実際非互換変更頻繁に入るから厳格に管理する意味ないだろ

485 ：
仕様バグの修正なんかだと、バグ修正でもあるし、非互換な変更でもある。
ライブラリのバージョンにセマンティックバージョニングを採用した場合、
パッチバージョンの変更があったときにそのライブラリを使うアプリケーションが本当に正しく動くのかは
厳密にいえばライブラリの個別のバージョンを確認しないとわからんだろ。
あまりあてにならない。
ライブラリにバグがあってもそのバグの挙動に依存しているアプリケーションだってありうるわけで。

目安としてセマンティックバージョニングを導入するのは賛成だけど、厳密にしきれない部分はどうしてもあるわな。
そこらへんは柔軟に対処するしかしゃあねぇべ。

486 ：
>>484はJSブラウザエンジンの話な
何にしても各言語なりの界隈の慣習に則ればいい

487 ：
>>481
Windows8.1までは6.3とかだったけど
10は10.0が返ってくる

488 ：
そういうことにしちゃっただけで、実質8.xx(6.xx)みたいなもんでしょ

489 ：
http://lipn.univ-paris13.fr/~bennani/CSRank.html
コンピュータ関連国際会議ランキングをlispで検索すると
European Lisp Workshop
しかなかった

490 ：
https://en.m.wikipedia.org/wiki/International_Conference_on_Functional_Programming
時代の流れにより96年にFPCAとLFPがICFPに置き換えられた。

491 ：
これがリストのランクcにすら入ってないのは何故
もうじき締め切りだけど
http://www.european-lisp-symposium.org/

492 ：
何か革新的な話題無いの？

493 ：
Anything.el再起動と革新的話題では？

494 ：
>>464
つ WebAssembly

495 ：
>>494
命令セットの検討を優先したからとりあえず柔軟なS式ということにしただけで、
ずっとあれを使うつもりはないみたいだよ。

496 ：
ところで R7RS-Large は Red Edition (データ構造に関する部分) がワーキンググループの Wiki に上がってる。

http://trac.sacrideo.us/wg/wiki/RedEdition

ほぼ SRFI から名前を変えてそのまま導入する形になる模様。
今のところ Sagittarius が積極的にサポートしている。

http://compassoftime.blogspot.jp/2017/01/r7rs-large.html

Larceny もライブラリの名前を除いてサポートできているとのこと。

497 ：
並列処理で高速化できるlispってないの？
GPU使えるのはハーランだけ？

498 ：
>>497
高速ブン回しと違うけど、Lisp Flavoured Erlangとかだめ？
ttp://lfe.io

499 ：
これはclojureの資料だけど、いまのところfloatをSSE2に投げるみたいな、なんでもGPUに投げるみたいな仕組みはないんじゃないかな。

http://dragan.rocks/talks/EuroClojure2016/clojure-is-not-afraid-of-the-gpu.html

500 ：
ある程度大きな単位でならバインディング作って投げてしまえばいいんだけど、
ちまちまやると境界を超える部分のオーバーヘッドで逆効果になったりするので、
本格的にやろうとすると処理系自体がサポートする必要はあると思う。

501 ：
Racketのプログラムを並列化して高速化したい。ハーランに書き直すのが1番手間かからずに高速化できるのだろうか

502 ：
Scheme:Schemeプログラマのレベル10

http://practical-scheme.net/wiliki/wiliki.cgi?Scheme%3AScheme%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9E%E3%81%AE%E3%83%AC%E3%83%99%E3%83%AB10

503 ：
『scheme手習い』読み始めた
この本自体はめっちゃ面白いけど実際に自分のPCでschemeを走らせる方法が全く分からないのはどうすれば

504 ：
>>503
goche を入れればよい

505 ：
>>504
ぐぐったらGaucheじゃないかってGoogleに怒られた
チュートリアルがないみたいだけど絶版の『プログラミングGauche』を買った方がいいの？

506 ：
プログラミングGaucheはそろそろ次版が欲しい

507 ：
>>503
特にこだわりが無ければ、Racketが最も簡単なのでおすすめ。
ダウンロードしてインストールするだけでプログラミングに必要な環境が全て整うぞ。

508 ：
>>507
簡単でいいね
言語選択はR5RSでok?

509 ：
>>508
オッケー

510 ：
個人的にはそろそろ R7RS (の処理系) を前提にしてもいいんじゃないかと思ってるが、
総合的な開発環境の便利さとしては Racket が優勝だわな。
少なくとも初心者にすすめられるものとしては。

511 ：
>>510
> 個人的にはそろそろ R7RS (の処理系) を前提にしてもいいんじゃないかと思ってるが、

R7RSはsmallの範囲は言語仕様書のドラフトが提出されたというのを何かで見た覚えがあるが
R6RSで巨大化した範囲に対応largeの部分の仕様書はドラフトでも出たのか？
あれがまとまるとは思えんのだが

それに処理系側もR7RSへの対処は結局はsmallだけへの対応で終わる…R6RSが処理系屋からほとんど無視されたように…のでは、と
個人的には予想している
そしてその予想が正しいならば、R5RS対応の処理系を使う前提で十分な気がする
（R7RSで言語仕様をsmall/largeの２階層モデルにした意図が、Come back! R5RS! Good bye R6RS! X-p にあるのは明らかだからね）

512 ：
>>511
Large の状況については >>496 の通り。
全部の議論が終わるのはまだかなり先のことになるだろうし、
処理系の対応がどうなるかはまだなんとも言えないところはあるのは確かだと思う。
でも、 R7RS Small については R5RS を少し拡張するにとどまったからこそ、
その程度の小さな差を導入することをためらわなくていいんじゃないかという意図だった。

R5RS でも十分といえば十分なのかもしれないけど
特にライブラリなんかは結局のところ R5RS 処理系でもそれぞれの処理系ごとに機構を持ってたりするし、
SRFI を使ったりするときに統一的な書き方ができた方が教える方もやりやすいよ。

513 ：
>>512
詳しい説明どうもありがとう
なるほど、そういうことですか、了解しました

514 ：
ここはスレチかもしれんがGo言語の勉強兼ねてR7RS片手にScheme処理系組んでみようとしてるけどトークナイザ書くの面倒すぎて心折れそう、お前らどうやってコード書くモチベ維持してるの？

515 ：
schemeレベルで面倒つったら他の演算子入りの言語じゃどうなるんだ

516 ：
トークナイザなら特に変わらん

517 ：
>>514
最初から完全である必要はないよ。
数値を整数だけにして文字列や識別子のエスケープも全部省略くらいのものから始めたらいいと思う。
限定的にでも動くものが目の前にあればモチベーションを維持しやすい。

518 ：
>>517
なるほど、とりあえず簡単なとこからやるか

519 ：
通常のletのように使うだけでgensym済みのlet文を生成するマクロ用コードを作ったのですが、このような挙動をする関数名を教えてください。
(let ((foo (gensym))) `(let ((,foo ,x)) ...)
が
(my-let* ((foo x)) ...)
と書ける感じです。再発明でなく役立つのであればここにCC0で貼りたいです。

520 ：
On Lisp に with-gensyms っていうマクロが載ってるけど、
それとは違う？

521 ：
with-gensymsではたぶんこうなると思います。
(with-gensyms (foo) `(let ((,foo ,x)) ...))

522 ：
突然死しないうちにとりあえず貼りますね。
アカウントは消すのでいいものであればbase64で書き残します。
ttps://gist.github.com/lla/f9244aefb7eee18db4cd

523 ：
レキシカルスコープのletやlet*でgensym必要なの？
使い道が良く判らない

524 ：
こういう時に要ると思うのですが...。要りませんか？
ttp://www.sampou.org/scheme/t-y-scheme/t-y-scheme-Z-H-10.html#node_sec_8.2

525 ：
要るよ

526 ：
`((lambda (foo) ...) ,x)と展開すりゃ要らないんじゃないの

527 ：
schemeでは衛生マクロを使うので不要だと思います。
commonlispでも仕様が中途半端なので不要だと思います。
そのまま書くのと手間が変わらないですし。

528 ：
バカにマクロは無理だと何度

529 ：
(define-macro (my-or a b) `((lambda (x y) (if x x y)) ,a ,b))

>>526 こうですか？　副作用に対してはより良いと思いますが、関数化した時lambdaが二重になって連続使用した時嬉しくないと思います。

>>527 仕様が中途半端という点、gensymのプレフィックスがないこと以外で何か不都合の起きる文があれば知りたいです。それともgensym名の変数は込み入った文や副作用でセットすることが多く、最初に全てのシンボルに値を入れられると不便ということでしょうか？
　ネストが一つ減る程度の関数は不要ですか？

530 ：
そもそもgensymがなんで必要なのかを理解しているのかという

531 ：
>>526
要るよ。

532 ：
>>529 once-only っていう定番マクロしらないの?
(defmacro square (x) (my-let* ((g x)) `(* ,g ,g)))
(defmacro square (x) (once-only (x) `(* ,x ,x)))
それは中途半端なonce-onlyの再発明なんよ

533 ：
and や orって短絡評価な気がして>>529はもやもやする
それと副作用のある式を同一式に並べるのは未定義だった気がする

534 ：
>>532
素敵です！　ありがとうございます！　これが探し求めていたものです。より良いものがあることを願っていました。

535 ：
>>533
確か評価順が未定義なだけ。

536 ：
((a b c) d)の評価順序は
a b cの順序は決まってなくて(a b c)の後にdが評価されるのだけは保証されている。で合ってるよね？
もちろんマクロや特殊形式の引数は除外だけど>>529の展開結果は(a b c)と同じことになってる

さらに(or a b c)ならaがtrueの時点で評価打ち切りでb cは評価されない(短絡評価)
(or a b c)がマクロなら以下のように展開されないといけない
((lambda(x k) (if x x (k))) a (lambda() ((lambda(x k) (if x x (k))) b (lambda() c))))

537 ：
>a b cの順序は決まってなくて(a b c)の後にdが評価されるのだけは保証されている。で合ってるよね？
これ合ってないわ。評価されるからそれを見越して>>536の最後のように遅延評価を入れとくって話
もういいです。

538 ：
評価されるから、じゃなくて評価の順序が決まってないから
それを見越して無引数lambdaを1つ挟む必要があるだった。

539 ：
気持ち悪いからまとめると、
((a b c) d)のa b c dの評価順序は何も決まってないから気をつけてねって事。

540 ：
最初の要素を最初に評価しないとマクロかどうか分からないかと思ってたが、その前の段階でマクロかどうかを判断することができるらしいんで、仕様では決まってないのか
((begin (display "1st\n") +) (begin (display "2nd\n") 2) (begin (display "3rd\n") 3))
をchezとgaucheで評価したら
2nd
3rd
1st
5
って順番だった。guileやchickenだと
1st
2nd
3rd
5
って順番になる。

541 ：
最適化や諸々の都合で、同じ処理系でも順序が変わることはあるので、
単純な事例だけでは処理系の性質を推し量ることは出来ない。

542 ：
(define-macro (my-once-only1 x . body)
(let1 tmp (gensym)
`(glet1 ,tmp ,x
(let1 ,x ,tmp ,@body) )))

(use srfi-1)
(define-macro (my-once-only vars . body)
(let ((names (map (lambda (_) (gensym)) vars)) )
`(glet* ,(zip names vars)
(let ,(zip vars names) ,@body)
) ))
念願のものが作れました…。これで心残りはありません。

543 ：
Scheme でやるなら syntax-rules でやったほうが楽だと思うが。

544 ：
>>535
> >>533
> 確か評価順が未定義なだけ。

少なくともSchemeではandやorでの式の評価順序は未定義でなくは左から順番に評価すると一意的に規定されているぞ
CLはどうだが知らんが

545 ：
>>544
そうだった。間違えた。
未定義なのは関数呼び出しの引数の評価順だね。

546 ：
やっとリスト処理に慣れてgensymであーだこーだしてる人にsyntax-rulesは敷居高いと思う

547 ：
syntax-rulesはR7RS眺めてもよくわからんかった

548 ：
むしろSchemeから学ぶとマクロ入門にはsyntax-rulesしか書いてなくてdefine-macro&gensym触る機会が無かった

549 ：
伝統的マクロの方が動作モデルを想像しやすくはあるかもね。

550 ：
Racketは死んだ

551 ：
>>548
> むしろSchemeから学ぶとマクロ入門にはsyntax-rulesしか書いてなくてdefine-macro&gensym触る機会が無かった

>>549
> 伝統的マクロの方が動作モデルを想像しやすくはあるかもね。

Schemeの場合、何でもありのマクロを排除して意味や動作を形式的に定義でき、
展開結果の正しさ（変数が展開したとたんに突然バインドされたりしない等）を保証できる範囲に留めたいという発想が
根底にあるからね

だからsyntax-rulesなどSchemeでの「マクロ」はあくまでも構文の拡張（カスタマイズ）のためなんだよね
つまり字句レベルを勝手に弄らせるとどんなトラブルでも起こし得るから勝手に弄らせたくたくない、
プログラマがお好みの構文を既存構文を使って定義して追加したいというならそれは許してあげよう
（例えばCみたいにwhile文…ループ条件の判定が最初に行われる構文…がある言語にrepeat～until文を追加したいなら
許してあげように相当）というのがSchemeの基本的なスタンス

つまり、Schemeの場合はソースレベル（テキストレベルと言っても良い）で好き勝手な操作を許す本来のマクロ
（ソースコードレベルのメタプログラミング手段）でなくて、抽象構文レベルでの変換規則を定義し使用する範囲だけに
限定しているんだと考えれば良いと個人的には思ってるけどね

だから（メタ）プログラムの動きで理解するタイプの人（プログラマには多い、特に優秀な人ほど）にとっては
古典的なマクロのほうが却って理解しやすく、逆に理屈が好きで系統的に理解したがる（代わりにプログラムの腕は
さほどでないのが多い）人間にはSchemeの構文拡張のほうが理解しやすくそちらを好む人が多い

もっともsyntax-rulesとかを提案して実現した向うの連中はプログラミングの腕力も上級者以上ばかりだけどね
（でも殆どの凡人は、プログラミングの腕か理屈かの高々どちらかしか得意でない、まあだからこそ凡人なわけでして
どっちも両立できちゃったらGuy Steele, Jr.みたいになれちゃうよね）

552 ：
syntax-rulesの動きがよくわからなくて理解できなかったけど古典的マクロなら単純で理解しやすかったな、準クォート使えば面倒でもなかったし(プログラムの腕はだめです)

553 ：
>>551 あくまでも構文の拡張のため
他のlispでもそうでしょ．具体的にそれ以外の他になにがある？

554 ：
>>553
他のLispに限らずマクロは構文の拡張と言えるほどの系統的な代物にはなってないでしょ
だからマクロを展開した途端にグローバルだったはずの変数が束縛されてローカルな変数に化けたりする（変数のキャプチャね）
つまり通常のマクロは（必要に応じて実行時と同じ計算も許して）ソーステキストという文字列データを処理しているだけ

それに対してsyntax-rulesなどに代表されるSchemeのは抽象構文上での操作とすることでテキストという文字でなく構文の句構造のレベルで扱い
変数のキャプチャなどを起こさないように保証するわけだ

ソースコードを文字データとして処理するのか句構造として処理するのかでは考え方も保証できる正しさや展開の安全性も全く違う

555 ：
>>554
> lispマクロは構文の拡張と言えるほどの系統的な代物にはなってない．
そんなお前定義しらんし，そんならsyntax-rulesも違う．
はなしが無限退行しそうだからもういいわ．

556 ：
Common lispにschemeのmatchマクロを移植したのないのでしょうか？

557 ：
さあ、わかんなくなってきました。
とにかくsyntax-rulesの方が高級で、実装がめんどくさくて、低機能で、とりあえずほとんどの用はたりる。

558 ：
そのめんどくさいの一点だけでLISP系にsyntax-を導入する価値は微妙
パターンマッチだからLISPじゃなくていいわけよね
syntax-rule/caseを日本語で詳細解説した本とかWebページってない？

559 ：
なんだっけsyntax-rule/caseの他にもう2つぐらい別種があるんだよね
重複しないシンボル名の管理の観点では手間は同じだけど概念的にはより簡単な感じだったと思う

560 ：
case は削除されなかった？他の２つも結局どうなったんだか

561 ：
>>558
> そのめんどくさいの一点だけでLISP系にsyntax-を導入する価値は微妙

一概には言えない。
たとえば letrec のようなものをマクロで書こうとするとフォームを分解したり
衛生的にしたりする処理はいずれにしても必要なことで、
それを自動的にやってくれる syntax-rules だと簡単に書ける。

syntax-rules や syntax-case は言語のプリミティブな機能としては高級すぎるのは確かで、
これは低水準の部分でどのパラダイムを採用するかで意見が一致しなかった末の妥協案として
いきなり高級な機能を持ち込んだ結果。

参考: http://blog.practical-scheme.net/shiro?20100425-scheme-macro

実際の処理系では explicit renaming や syntactic closure を基礎に据えてその上に
syntax-rules や syntax-case のインターフェイスを実装している場合もよくある。

562 ：
schemeだとread macroの定義ってどないなっとるん？
自分common lispとバージョンが上がるといつ消えるか解らないclojureのしか知らんのだけど。

563 ：
>>562
リードマクロについては Scheme の仕様には含まれないし SRFI にもないし、デファクトスタンダードといえるものもない。
処理系が独自にやっている場合はあるけど。

私見だが、 Common Lisp に比べて Scheme はモジュール化を強く意識していると思う。
R6RS でフェイズの制御について一応の考え方が確立したものの、
リーダの適用範囲をうまく制御するにはまた別の軸を持ち込む必要があるので厄介なのだと思う。

564 ：
>>563
あ、やっぱりなかったのか探しても定義みつらんわけだ
DSL書きたいので処理系の小さい実装のschemeでやろうとおもったのだけど駄目か orz

ありがとね

565 ：
Racket はどうや？

566 ：
schemeのリードマクロってCL踏襲じゃまずい理由でもあるの？
健全とか関係なくね？

567 ：
>>564
それはいっそプリプロセッサ的なものを書いてしまえばいいんでないかい？

568 ：
Lispの論文で英語表現とか定理の書き方みたいので参考になる論文ってどこらへんみればいいでしょう

569 ：
>>568
定理はともかく英語表現はRnRSの原本読んどけばいいんじゃないかな
後はこんなのとか
http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-353.pdf
wikipediaのScheme系の記事の参照元を読み漁るといいと思う

570 ：
RnRS は仕様書っぽい言い回しだけど論文と同じかなぁ、論文読む方に賛成

571 ：
>>566
リードテーブルの状態によってプログラムの意味が変わってしまうのは不健全さを嫌うScheme的にはだめでしょ

572 ：
>>571 の主観なのかそれとも論文にまとまってたりするのか．
racket#!langはどうなる．

573 ：
>>572
そもそもRacketはScheme的にだめでしょ

574 ：
わかったおまえの主観ってことな．あんがと．

575 ：
Chez Schemeの日本語ドキュメントないの～？

576 ：
ない。

577 ：
ちぇっ

578 ：
Chez Scheme について具体的に知りたいことがあればここで質問すれば簡単な回答くらいはつくかも？

579 ：
最近のlisp webフレームワークで良いのって何でしょうか

580 ：
Kahuaなら知ってるが更新されてないっぽいし使ったことないからよくわからん

581 ：
>>579
Artanis とかどうよ
http://web-artanis.com/

582 ：
逆転ポインタなつい
ttp://qiita.com/kingshine/items/d74576886c067737ad18

583 ：
Common lispのnilとfalse区別しないの気持ち悪いけど
Schemeでまともな処理系もう残ってない感じして
Common Lisp に移住するしかない

584 ：
何をもってまともと言うのか、Gauche使ってるけど普通に安定してるぞ

585 ：
>>579-580
Kahua ほどダイナミックな運用はできないが Gauche-makiki は簡単に使えるし
活発に更新されているのでいいかも。

586 ：
Scheme のこと好き？ 忌む？

587 ：
忌マラン

588 ：
>>586
好きだよ。

589 ：
最速の処理系ってどれ？

590 ：
Chez >>446

591 ：
最高の処理系ってどれ？

592 ：
自作の処理系が最高、性能使い勝手を抜きにすれば

593 ：
さぁ、行こう

594 ：
picrin使ってたのにgitのｔipがビルド通らん…巻き戻すしか

595 ：
>>589
そんなスピードで何するの？
速いに越したことはないけどさ。

596 ：
速いに越したことはないなら一番速いやつを選ぶじゃん

597 ：
>>594
picrin のどういうところが好き？

598 ：
>>596
他の条件が同じなら速いやつを選ぶけどさぁ、
そんなの用途によるだろ。

599 ：
実際のところSchemeでどんなプログラム書いてる？
具体的に晒せるものがある人いる？

600 ：
晒せないが、S式で書いたテンプレートからHTMLに変換してた
CSSで過去の技術となったが

あとはC++に組み込みスクリプト

601 ：
あれー、この話題ってあまり盛り上がらない？

602 ：
>>596
schemeと俺を比べたら俺が遅いからあんまり意味無いんだよトホホ

603 ：
>>601
そもそも盛り上ってないこのスレを盛り上げるにはお前が身を削ってネタ投下するしかないだろ

604 ：
biwascheme http://www.biwascheme.org/ はページ上にREPLあるから遊べるかも

605 ：
>>446
実際の時間差はあまりないな
順位はかなり後ろだけど

606 ：
picrin のコア機能では unicode サポートなしで、後付けは可能なようにするという方針も提示されている
ので、コアだけのスピードで評価するのもアンフェアな気がする。

https://twitter.com/___yuni/status/504240324831477760

607 ：
AIの分野はもう完全にPythonに譲ったの？

608 ：
Python ってプログラマでない人にも使いやすいデザインなんだとさ。
数学屋や物理屋もプログラムを書くことはあるけど、専門家じゃないからな。
言語に関わってばかりはいられん。
綺麗な抽象化とか考えずに愚直に書いて動くってのはそれはそれで良い言語なんだよ。
VB とかな。

AI の核になるライブラリが出そろってきていろんな応用をする段階になると
Python の方が色んな人に使ってもらえるという意味で良いんじゃないか？

それに今の AI ってのは記号処理するのに柔軟なデータ構造が必要って感じじゃないだろ。
計算量を投入しまくって結果を出す機械学習とかじゃん。
広い意味では AI つってもやってることは違うよ。

609 ：
Schemeが本当に美しさと強さを両立させようと思うんなら
速さを二の次にして仮想機械の仕様も標準に入れてしまえばよかった
Smalltalk-80のVMは美しかったが
RnRSのdenotational semanticsの記述はCOBOLのコードみたいで正直読みたくない

610 ：
Scheme の仕様ってのは業務マニュアルみたいなもんだよ。
たとえば「誰にハンコをもらえば進めていいのか？」みたいな手順は組織の秩序としてやらなきゃならないことだから
個人の創造性で決めれることじゃないし、仮にそれぞれの場面で最高の才能を発揮して根回ししたところで
正事の成果が良いものになるわけじゃない。
どうでもいいことはマニュアル通りにやってもっと大したことに力を入れようってのが業務マニュアルだろ。
逆に言えば創造の余地がある部分は決めつけてしまいたくないんだ。

611 ：
lispworks 32bitを使ってて、fliを使ってwindowsのdllから関数を呼ぼうとするのだけど、
一部の関数だけがunresolved symbolだと言われて呼び出せない。
dll exported functipn viewerとかでみてみると、
ちゃんと関数を確認できるのに。

何でかわかる人いる？
おいどん、初心者やからわけわかめなのよ。

とりあえず、cffiでもできないかどうかと、ほかの処理系ではどうかを試そうとは思うのだけど、
なんか知ってる人いたら助けてー

612 ：
>>611
呼び出せなかったのは具体的にどの関数？
確認した範囲で呼び出せている関数も書いてもらえれば
何か違いを見出せるかも

613 ：
>>612
windowsのdllってのは適切な言い方じゃなかったかも。
具体的には、趣味で下記のライブラリをlispworks上で使いたいと思っているんです。

ttp://www.astro.com/swisseph/swephinfo_e.htm
ttp://www.astro.com/ftp/swisseph/

ここのsweph.zipにWindows 32bit用のdllがあるのですが(swedll32.dll)、
lispworksのfliを使って呼び出そうとすと、呼び出せる関数と呼び出せないのがあるんです。

ただ、私、lispもcもwindowsプログラミングも素人なので、何が問題なのかもよくわかってません。

後ほど、呼び出せる、呼び出せない関数の例や、その定義等含め書いてみます。
なにかアドバイスありましたらいただけますと幸いです。

614 ：
６０９です。
うまくいく例とダメな例を挙げてみます。おそらく皆さんは全く興味のないライブラリだと思うので、質問するのも恐縮ですが。

問題なく呼び出せる例：

CL-USER 1 > (fli:register-module "swedll32.dll")
"swedll32.dll"

CL-USER 2 > (fli:define-foreign-function (swe_julday "_swe_julday@24" :source) ((year :int) (month :int) (day :int) (hour :double) (gregflag :int)) :result-type :double)
SWE_JULDAY

CL-USER 3 > (swe_julday 2001 1 1 0d0 1)
2451910.5D0

CL-USER 4 > (fli:define-foreign-function (swe_calc_ut "_swe_calc_ut@24" :source)
??? ((tjd_et :double) (ipl :int) (iflag :long) (xx (:reference-return (:c-array :double 6))) (serr? (:reference-return (:ef-mb-string :limit 256))) ) :result-type :int :lambda-list (tjd_et ipl iflag &aux? xx? serr))
SWE_CALC_UT

CL-USER 5 > (swe_calc_ut (swe_julday 2001 1 1 0d0 1) 0 0)
4
#<Foreign-Array :DOUBLE (6): addr #x02189F08>
"SwissEph file 'sepl_18.se1' not found in PATH '\\sweph\\ephe\\'
using Moshier eph.; "

615 ：
今度はダメな例です。

CL-USER 6 > (fli:define-foreign-function (swe_version "_swe_version@4" :source) ((sver (:reference-return (:ef-mb-string :limit 256)))) :result-type :pointer :lambda-list (&aux sver))
SWE_VERSION

CL-USER 7 > (swe_version)
Error: Foreign function SWE_VERSION trying to call to unresolved external function "_swe_version@4".
? 1 (abort) Return to level 0.
? 2 Return to top loop level 0.
Type :b for backtrace or :c <option number> to proceed.
Type :bug-form "<subject>" for a bug report template or :? for other options.


CL-USER 8 : 1 > :c 1

CL-USER 9 >

一応、自分なりに調べてソースファイルからdefファイル使ってコンパイルしなおしたりもしたのですが、
やはりだめでした。もっとも素人なので意図していることができているかどうかも怪しいのですが。。。

もし何かアドバイスありましたらお願いします。

616 ：
612訂正

誤：

＞CL-USER 4 > (fli:define-foreign-function (swe_calc_ut "_swe_calc_ut@24" :source)
＞??? ((tjd_et :double) (ipl :int) (iflag :long) (xx (:reference-return (:c-array :double 6))) (serr? (:reference-return (:ef-mb-string :limit 256))) ) :result-type :int :lambda-list (tjd_et ipl iflag &aux? xx? serr))
＞SWE_CALC_UT

不要な?がはいっちゃいました。


正：

CL-USER 4 > (fli:define-foreign-function (swe_calc_ut "_swe_calc_ut@24" :source)
((tjd_et :double) (ipl :int) (iflag :long) (xx (:reference-return (:c-array :double 6))) (serr (:reference-return (:ef-mb-string :limit 256))) ) :result-type :int :lambda-list (tjd_et ipl iflag &aux xx serr))
SWE_CALC_UT

617 ：
>>611です。自己解決しました。
defファイルを使ってソースファイルからコンパイルしなおしたら
問題なく呼び出せるようになりました。汗
これまでも何度かVisual Studioからコンパイルを試していて、
dllは問題なく作成されるものの、一部呼び出せない関数があり、問題は解決しませんでした。
しかし、今回コマンドラインからコンパイル、リンクすると、なぜかうまくいきました。

結局、何が問題だったのかはわからないのですが、
とりあえず利用で来るようになりましたので、ご報告です。
お騒がせしました。。

618 ：
そうか。

619 ：
ISLISP界隈が復興の予感？

620 ：
そういやピンボールゲームSchemeの人、ピンボールも放置してるし死んだのかと思ったら
Twitter社に入ってたんだよな。

621 ：
ひげぽんも Twitter じゃなかったっけ？

622 ：
>>607
今のAIはPythonが完全に主流だね

>>608
そりゃ大多数にはLispより
Pythonの方が使いやすいだろう

623 ：
>>619
ISLispの話ぜんぜん聞かないけど
Clojureとかの方が圧倒的に普及してるんじゃね

624 ：
そもそも本質的にLISPはAIとは関係がないぞ。
未だにAI=LISPなどと言っている輩はだめだと最近まで言われていたのにな。

Pythonだってライブラリがあるかないかというだけの理由であって
AIはスクリプト言語とは無関係だから。みんな誤解している。
AI言われる以前からPythonはあっただろ(w

625 ：
マッカーシが AI 研究者だったこともあって、
実際に AI 研究に使われたのと、
その流れで AI 分野での利用実績は有るけど、
言語仕様的に特別 AI に向いてるってことはない。

ただ、当時のプログラミング言語っていうと Fortran とかの時代だから、
それで柔軟なデータ構造を必要とする記号処理をするのはつらかっただろうし、
その中で選ぶなら LISP は圧倒的に AI 研究に向いてたとは思う。

626 ：
>>624
本質的に関係ないとまで言いきっちゃうと
それはそれで違う

Lisp（とProlog）は記号処理に向いてたから
一昔前のAIブームで利用された

>>625
記号処理がしやすいんだから
結局向いてたんだよ

627 ：
>>626
あ、 >>625 の「特別 AI に向いてるってことはない」の前に「今では他と比べて」 を付け加えといて。
今なら Ruby や Python くらいでも記号処理をする上で LISP よりすごく不利ってことはないと思うって話。
まあ不向きの部分もあるかもしれないけど、それ以上のメリットがある部分もあるし、それはバランスの問題ってことで。

逆に 今じゃ LISP も普通に汎用プログラミング言語として使いうるわけだし、
あまり AI を強調して LISP を紹介するようなのがあってもなんかもにょっとすることあるよね。

628 ：
書籍や情報が多い少ないだけでも、向いてる向いてないと言われるだろう

629 ：
AI 分野であろうとなかろうと言語の盛衰があったっていう単純な話かもね。

630 ：
そのAIってのが曲者で、単なる構文解析やエキスパートシステムじゃん。
それは単なる文字処理と機械のモノマネでAIじゃないですよ。

上の人も書いているけど、今だからスクリプト言語がある。当時はそれがなかったから
LISPが応用分野の開発の道具として開発され選択されたというだけ。
世界初の難解言語であるが、関数型のLISPはAIとは本質的に関係はないですから。

Prologも関数型のように基本となる仕組みが手続き型と違うのであってそれが評価されるのであり
本質的にはAIとは関係が無い。

631 ：
LISPに限らず定義が曖昧なAIなどという話を持ち出すことがいかにデタラメで間違いであるかに気付くべき。
AIという呼称で、いかにLISPが誤解され続けて来たのかを問題視するべき。
失敗事例も多く、何十年も前から存在している技術なのに今更AIなど言うのもおかしい訳。

632 ：
>>630
>>631
いや一般的なジャンル区分では
エキスパートシステムはAIでしょ

強いAIは実現できてないけど
弱いAIをエキスパートシステムと呼んでる

定義が曖昧とか言っておいて
自分でオレ定義使ってる気がする

633 ：
MITの人工知能研＝Lisperの巣というイメージはもう古いのかな

634 ：
あとシグマの時代だったか、テレビで日本人のAI研究者が
マクロが使えるから人工知能に向いてる的なコメントしてた記憶が

635 ：
今のAI開発に言語の自己プログラミング能力なんて求められてないでしょ

636 ：
せやな。

637 ：
うん・・・

638 ：
>>635
今のAIとLISPが生み出された時代のAIとは全く違うからねえ
今のAIは本質的にはパラメータの最適化だよ

ところが当時のAIは記号処理（数式処理…つまり数式のままの微分や不定積分とか…だって
70年代初頭頃まではAIのテーマだったんだから）が中心で、その記号処理がAIに求められた時代に
科学技術計算向けのFORTRANやALGOLあるいは事務計算向けのCOBOLといった本質的には数値計算しか
できない言語しかない時代に、ATOMの概念を持ち込んで更にリストの任意の入れ子のデータ構造によって
記号のプログラム上での直接的な表現とそれら多数の記号から成る複雑な構造（特に言語の構造として
Chomskyの主張した句構造）の処理をサクサクと書けるLISPは当時の人々の眼には画期的に映ったのは
容易に想像がつく

要するに「AI」という言葉の表す内容とその研究の推進に必要な技術がLISPが生まれた時代と今とでは全く違うと
いうだけの話

639 ：
AI って言葉が広すぎるってのもあるけど、
LISP ってのも初期と今じゃやっぱり違うやで。

640 ：
最初のLisp処理系がつくられたのと同じころには
「今のAI」のもとになるものも考案されていたらしい
https://ja.wikipedia.org/wiki/%E3%83%91%E3%83%BC%E3%82%BB%E3%83%97%E3%83%88%E3%83%AD%E3%83%B3

641 ：
AIの意味自体はほとんど変わってないやろ。研究すすんでちょっと内容が豊かになって、訳のわからなさがふえて、短期目標がいろいろ設定されて、研究予算獲得やもの売るための宣伝文句としてのAIのイメージがかわってきただけ。
今も昔もLispでAIやるのは楽しい(と思ってる人がいる)というとこだけが変わらん。

642 ：
>>マクロが使えるからAIに向いている
頭がおかしい?
別の文脈で言えば、マクロアセンブラが使えるからAIに向いているのか?。
その人間の勘違いさに気付くべき

>>638
数式処理は別にしても今なら記号処理はスクリプト言語で可能な話。それをAIとは言わないでしょ。
Siriなんて原理は人工無能ですよ。昔からあったでしょ。本気でAIと思っているなら勘違いもはなはだしい。

>>640
それはLISPとは関係ないから

643 ：
海外でやっている人工知能の対話実験は、単に人工無能の二台並べて会話させているだけでしょ。
それのどこが先進的で時代先取りのAIなんですかね?

>>640のような話はニューラルネットといって昔からあったし今更な話題でしょ。
画像認識なら別にニューラルネット使わなくともあるでしょ。
グラフのフィッティング実演見せてこれがAIですという場面見るとシラけるのですよね。
そんなものは昔からフィッテングアルゴリズムあるし、AI違うでしょ。

644 ：
人工知能って言いながら実体は
昔からあるアルゴリズムだったり
人工無能だったりするのはそうなんだが

たんにハードルあげて
こんなのくだらないって
こき下ろすのも簡単

既存のアルゴリズムでも
実際に少しでも精度を上げるのは
すごい大変だし大事なことだよ

645 ：
>>644
なんかズレてる気がするな。
ある程度手法が確立してひとつの分野になったものをいまだに AI って読んでるのに違和感があるってのが >>643 の言ってることなんじゃないの？
ニューラルネットワークの界隈では大した成果なのかもしれないけど、 AI としてのインパクトに欠けるってのは両立する話で、
それをこき下ろしているといって批判するのはちょっと違うでしょ。

646 ：
>>642
> >>638
> 数式処理は別にしても今なら記号処理はスクリプト言語で可能な話。それをAIとは言わないでしょ。

だから今はどうかでなく、1970年代初頭辺りまでは数式処理、特に不定積分は人工知能研究のテーマと看做されてたんだよ。
更に言えば、1950年代はコンパイル技術の研究はAIにおける自動プログラミングというテーマだったんだよ。

当時はそういうテーマも人工知能研究の一環として研究されていたという歴史的事実が厳として存在しているということだ。
それら歴史的事実に対して、今はどうだからとか、Siriが人工知能でなく人工無能だからとかは全く関係ないし反論になっていない。

647 ：
mccarthyは 1959 年から programs with common sense っていってる。
おまえらこれの意味わかった上でAIがどうのこうのっていってるの?
歴史云々するならちゃんと原典も読めよ糞が

648 ：
いちいち汚い言葉を吐かないと死んじゃう病かね

649 ：
渋谷Lispとかの勉強会、以前は誰でも発表できたはずなのに
今は有名人以外はお断りになったの？

650 ：
んなこたーない。
手を上げる人がいないだけ。

651 ：
Lisperなんてマニアックな奴が多いから
相当な知識がないと発表できないだろ

652 ：
聴衆のレベルが高いことがわかっている場所でアホなことは言いたくないだろうし、
そういうところで気後れしやすい素地はあるのかもしれんなぁ。
わかってる人には今更すぎることでも知りたい人はいると思んだが。

レベルが高すぎると思うんならそうでもない人向けの勉強会を開催してもいいんですよ。

653 ：
>>649

ほんと何から何まで他人のせいにしてて2chの化身みたいな意見だな
誰一人おまえの邪魔なんかしてないから．おまえが勝手に障壁つくってるだけだから．

654 ：
初歩的な質問いいっすか？

ドット(.)とかカンマ(,)を標準入力で文字列として受け取るにはどうすればいい？
readじゃ無理ですよね？

655 ：
(read-line) じゃダメなの？

656 ：
ボードゲームの盤面を表したような、空白で区切られた複数文字を受け取ることを想定してたんですが、read-lineで受け取ってsplitとかするのが無難ですかね

657 ：
空白で区切られているのにカンマやピリオドも出てくるの？

658 ：
セミコロンやカンマで区切られた文字の中に空白が入っていることもある形式って意味かな？

659 ：
>>649
むしろshibuya.lispは事前審査も何もないし、入門してみた的な内容でも全然大丈夫だと思うぞ。LTでもいいし。
発表登録も単にconnpassのページのコメント欄で表明するだけだし。

660 ：
記号処理ってC言語で言ったらどういう処理のことですか？

661 ：
記号処理は文字列処理のうち
人工知能の分野に関係する処理
たとえば機械翻訳とか

662 ：
コンパイラの字句解析、構文解析みない処理といことですかね。
Lispはそういうのが得意なんですか？　まだ関数型言語の実装イメージがよくわかりません。

663 ：
そういうコンパイラなどの言語処理系も記号処理と言える
Lispは言語処理系の実装が得意

664 ：
LISP言語の設計は人工知能とはまったく関係がない。
機械翻訳は翻訳であって人工知能ではないが、LISPの記号処理の使用例でもない。

コンパイラはコンパイラ技術であって記号処理ではない。Cで書かれた処理系は幾らでもある。
だからといってCが記号処理得意なんですか?違うでしょ?
LISPはコンパイラ処理が得意という訳ではない。LISP製コンパイラを見たことがない。

665 ：
LISPだからといって何でもAIと結び付けて考えるのが間違い。

コンパイラはAIですか?->違います。LISPはAIツールですか->違います。

これははっきりしてる。だから90-2000年代になってLISP==AIという認識が間違いだよねという
コミュニティの認識があった。今再びAIと叫ばれ、LISPに対する誤解が再生産されている。
全てをAIと表現して記号処理もAIとしてしまうと、コンピュータサイエンスも何も無い。
AIというバズワードこそが詐欺的だということです。

666 ：
>>664
＞LISP製コンパイラを見たことがない
それは知らないだけだろ
なんで開き直って確信してるのか

>>665
＞コンパイラはAIですか?->違います
いやそれは現在の認識だろ
当時は言語処理系もAIだと認識されていた

667 ：
Common Lispはネイティブコードへのコンパイルも仕様に入ってなかったっけ？

668 ：
Lispで書かれたコンパイラ、、、そう言えば20年くらい前だったか Zeta C ってのがあったなぁ

669 ：
>>664
あーでもない、こーでもないと、外堀埋め的説明じゃなくて、
LISPとは何なのか、記号処理とは何なのか、AIとは何なのか、結論だけ教えて。

670 ：
記号処理は記号を処理することだよ。
数値演算ではなく、たとえば数式みたいなものをいじってなんやかんや。
というのでなんとなくコンパイラ技術とも関係があるというのがわかると思う。

AI (人工知能) は人の知能を真似ようとするもの。
かつては (数値計算ではなく) 数式の変形をするのは機械には出来ない人間的なことだったから、
それをやるのは人工知能というカテゴリだった。

やり方がある程度確立した今では知能もクソもない、普通の数式処理じゃんって話になるから人工知能だとは思われない。
人工知能という言葉が指す具体的な技術の範囲は時代によって変わることになる。

LISP が直接的に得意としているのは名前が示す通りにリスト操作でしかないよ。
それが記号操作に便利だったし、記号操作はかつては人工知能の重要トピックだったって話。

671 ：
今時の言語にはリスト用のライブラリは揃ってる。

672 ：
こマ？

673 ：
lispアイデンティティの最後の砦はs式と同図像性であろう。

674 ：
ライブラリがあるのと言語に組み込まれてるのは違うよな

675 ：
>>674
区別なく使える程度の抽象化能力が有ればどうでもよくなる。

676 ：
あのさ、俺小学生なんだけど、HaskellとLispどっちが強いの？
おっさん、おばさん教えてよ。

677 ：
Lispがさいつよだよ
https://www.youtube.com/watch?v=HM1Zb3xmvMc

678 ：
どっちも信者しか使う必要を感じない方向での強さしかない
だから信者対策にどっちも舐めとけ

679 ：
おっしゃ、嫌いな言語ランキングに入ってないぜ！
https://s.news.mynavi.jp/news/2017/11/02/073/

680 ：
>>679
それはたんに「仕事で使わざるを得ないランキング」に見える
Lispは最初から仕事で使われないから対象外なだけ

それに23位にClojureがあるし普及したらもっと上がりそう

681 ：
>>680
マジレスは断る！

682 ：
食わず嫌いランキングには確実に上位に入りそう

683 ：
入門サイトを読んでみたが必要性が分からない言語だな。

684 ：
>>683
勉強用には最適だと思うけど実用性はかなり低いからね。
2020年のプログラミング教育必修化の教育に使ってほしいが可能性は0.0000000000000000000001%くらいか。

685 ：
>>684
Lispは学習用言語に向いてるとは思う
実用できなくはないが大変

あとLisp教えられる教師なんか
ほとんどいないだろ
大学じゃないと無理

686 ：
プログラミング言語の習得とは、
基本的なデータ構造とアルゴリズムが実装できるようになることだとすると、
この言語は向いてると言えるのか。

687 ：
理解することと実用することは違うんだわいな

688 ：
言語の習得のための言語ではなく、プログラミングを習得するための言語だよね

689 ：
>>685
MITでもScheme教えられる教師が居ないと言うのに

690 ：
汎用言語じゃね？ 特別に何かに特化しているわけじゃないと思うが。
レイモンドは「悟り体験のため」って言ってるけど、
グレアムはそんなこと言わずに使えばいいじゃないのという立場で莫大な収入を得ているので、
使いたいように使えよ～

691 ：
>>689
ああそうか
LispからPythonに変えたんだろ
もう大学でも無理って時代になってきたかもな

692 ：
教える人がいないからってわけじゃないよ。
Sussman 自身もまだ現役だし。
Sussman が語った内容の日本語訳がここにある。
https://cpplover.blogspot.jp/2016/05/mitsicp.html

693 ：
>>692
「教わる人がいないから」
「教える意味がなくなったから」
って方が実態に近いかもな

694 ：
主にC++な自分にとって、Lispはmodern C++が目指す最先端なんだけど、
Lispの人たちゃもうどっかに行っちゃってるのかね。

695 ：
>>693
要約すると「総合的に考えて Scheme は入門講義ではベストではなくなった」って話で、
MIT での教育・研究全てから LISP が排除されたって話ではない (大幅に縮小はしてるかもしれない) ので、
Scheme が手頃な場面では Scheme だって使うだろうし、
時代の変化とそれに合わせた適材適所っていう当たり前の話なんだよね。

696 ：
ジョエル「なんてこった(略)」

697 ：
>>692
70の爺さまだぞ
モチベーションなかろ

698 ：
>>697
言語を変更するにあたってサスマン自身も主導者のひとりであるように書かれてる。
モチベーションがないならむしろそのまま続けるんじゃね？

だいたい LISP と言ってもフルセットの Common Lisp を隅々まで使おうってんじゃないんだ。
SICP で使ってるのは R4RS 時代の Scheme だぞ。
MIT の教員レベルならどうということのないものだろ。

699 ：
>>698
>>692 の中で1997年の時点で教えるの嫌になったって書いてる。サスマン50歳でモチベ低下w

700 ：
>>699
「今のエンジニアリングに求められるエンジニアを育てる」ということにモチベーションがあったから、
「それに合ってないカリキュラム (SICP) で指導する」というモチベーションが低下したんだよ。

701 ：
>>700
そうなのかw
今でもエンジン設計できるヤツとかエンジンの部品を開発できるやつは必要だな。
出来合いの部品買おうにも部品屋がいないと駄目だ。

702 ：
>>701
MIT で SICP を使ってた講義ってのはあくまでも入門講義であって、それだけで課程が終わるわけじゃないかんね。
そこんところ誤解なきよう。

703 ：
>>702
その入門レベルで挫折したわけだが
決して翻訳のせいなどではない

704 ：
>>703
入門って言っても MIT のレベルの入門だから仕方がない

705 ：
アメリカの大学は1～2年生の時に適正ない奴をふるい落とすんだよ
ジョエルがJavaスクールのなんたらで書いているように

706 ：
MITは、入学は簡単、卒業は難しいと言うアメリカの大学の常識は当てはまらないな。
どっちも超難しい。

707 ：
あーいえばこーいう
のらりくらり

708 ：
Common Lisp でscheme と同じ感じで...の使えるMatch マクロ使う方法ないですか？

709 ：
>>708
部分的に syntax-rules を再現したようなライブラリはこういうのがあるよ。
http://www.ccs.neu.edu/home/dorai/mbe/mbe-lsp.html
省略子は ... ではなく *** になってるのと、ハイジニック性は再現されてないことに注意。

マクロ展開器としてだけでなく、パターンマッチ関数を直接使うことも出来る。

710 ：
>>706
それは両方の敷居が高い方にスライドしてるだけとも言えるのでは
つまり反論になってない

711 ：
Lispworks 7.1出た

712 ：
買った人いる？

713 ：
継続渡しスタイル難しい😭

714 ：
cpsスタイルはクロージャの応用にすぎない。慣れれば難しくないし、jsのコールバック地獄の意味も分かってくる。
難しいのは各種継続オペレーターのセマンティクスと使いこなし。

715 ：
gaucheって20個以上の多値扱えないの？

716 ：
SCM_VM_MAX_VALUES を適当な値に書き換えてからgaucheコンパイルすれば？

717 ：
そんなことはないはずだが、少ない多値を扱うときに特別な最適化をしていたような気がする

718 ：
(apply values (iota 25))でtoo many valuesとか出る

オセロとかチェスの座標（SQ_A1, SQ_B1, ... , SQ_G8, SQ_H8）に連続した数字を割り当てるにはどうすればいいでしょう？

719 ：
へー、そんな制限があったのか。
まあそんな多値を使うのはアレであることには違いないのでしょうがないといえばしょうがない。
識別子に連続した数値を割り当てるにはマクロが必要だが Scheme 的には R6RS を仮定するか処理系の拡張を使う必要がある。
Gauche を使う前提でいいの？

720 ：
racketとchickenではエラーが出ないのでgaucheやめるかも✋

でも
(define-values (SQ_A1 SQ_B1 ... SQ_G8 SQ_H8) (apply values (iota 64)))
と同じぐらい簡単な他の表現をぜひ知りたいです

721 ：
Gauche だとこういう風にすれば識別子の方の自動生成も含めて出来るけど、
なんかイマイチすっきりしないなー。
もっといい方法ありそうだと思うんだけど。

(use util.combinations)
(use gauche.sequence)

(define-macro (define-serial-numbers)
`(begin
,@(map-with-index
(^(i x) `(define ,(string->symbol (apply format #f "SQ_~a~a" x)) ,i))
(cartesian-product `((A B C D E F G H) ,(iota 8 1))))))

(define-serial-numbers)

722 ：
scheme勉強するならこのコード読んどけみたいなのあります？
せいぜい1000~2000行程度の綺麗に書かれてるコードを探してるんですが

723 ：
3x3の0Xゲームの評価関数をこの言語なら簡単に書けると思いましたが無理でした。

724 ：
言語関係なくね

725 ：
Lispに簡単を求めても仕様がない

726 ：
言語のせいです。ぶっちゃけAI記述に向いてません。

727 ：
今風AI記述向けDSLってできるよねきっと
内部でマクロ書く言語ならアドバンテージあるんじゃないか？

728 ：
>>727
マクロの有無（内部でマクロ書けるってのはC的なんじゃなくてLisp的なマクロって意味なのか？）がAIプログラミングと何の関係があるの？

729 ：
AI書いたことない人がLISPはAIに向いていると言ってるだけ。

730 ：
お前の言うAIはAIというよりディープラーニング限定だろ

731 ：
いいえ人工無能です

732 ：
>>729
LISPを知らない奴ほどLISPについて語りたがる、とどこかの先生が言っていたけど、
まさに君のことだな

733 ：
>>732
キミがどーんとLISPにおけるAI記述を語ってもいいんだよ。

まぁ書いたことないから低レベルな煽りしかできないんだろうけど。

734 ：
８０年台に腐るほど論文が書かれてるから勝手に探して読んでよ
集大成的なのは人工知能学会から出ている「人工知能ハンドブック」とか、まあ探せばいくらでもある
AI=ディープラーニング前提で話をしてんのかね

735 ：
パズルを解かせるのも人工知能！！！

736 ：
>>734
1980年代の人工知能の研究成果で現在でも役に立ってるのあるのか?

737 ：
80年代といえばエキスパートシステム。壮大な詐欺だったな。

>>734 で？　キミはその詐欺に加担した一人？

738 ：
何でこんな上から目線なの？

739 ：
80年代のAI理論が役立たずだからだろ。

740 ：
んなこたーない

741 ：
中身はif分並べただけの実装だらけ。

742 ：
>>727
LISPのマクロってたいしたことないよ。それがLISPの本質でもないし。
ただインタプリタでC風にマクロが書けるというだけで。

マクロはマクロなんで、LISP内部で置き換えするだけで本質的なコード処理はしてないし。
それ(マクロ)が記号処理の本質ではないし。
何ならCのマクロ使って記号処理しましたって公開してみ。笑われるだけだから。
LISPの世界はこの程度の話すら理解できてないから誤解されているといっている訳。

だいたい最近までOpenSourceでScheme処理系開発してた連中が居たけれども、
彼らがAIと言った事はただの一つもないよ(w

743 ：
おいらも735に賛成。
エキスパートシステムは失敗と無駄そのもの。第五世代も。

現実には民間企業ではMSエクセルが経営支援機能を果たしている。
表計算がAIより機能を果たしている皮肉。

744 ：
いやマクロ使わなかったら
Lisp使う意味ほとんどないだろ

745 ：
誰かコイツに構ってやれよ薄情だなおまえらw

746 ：
インタプリタだとかCのプリプロセッサマクロだとか、イカレ過ぎててツッコミどころすらわからんｗ

747 ：
ディープラーニングを機械学習と言えば詐欺臭はでない。人工知能なんて言うから投資詐欺に使う奴が出てくる。
既存のTCP/IP使ったクライアントサーバシステムをクラウドなんて言い出すのと同じ。

748 ：
みんなschemeで何作ってるの？
これからscheme始める人は何作るべき？

749 ：
lispインタプリタ

750 ：
好きなもん作ればええがな

751 ：
俺はホームページ自動作成

752 ：
あとC++に組み込んで3Dモデルの作成しようと思ったがまだ上手く行ってない

しかし、おかげで継続が理解できてJSやC#のコルーチンが中でどう動いてるの、とか
本当に勉強になった
人に説明できるようになって仕事に役立ったよ

753 ：
LISPは計算コストの感覚が掴みにくいのが難点。

754 ：
実測せよ！

755 ：
継続理解出来ない😭

756 ：
あれは理解するものじゃない
感じるんだ

757 ：
CPUのコールスタックがわかってれば、スタックでなくヒープを使い捨てることにしたと思えば理解は容易いんじゃないか。
プログラミング言語の抽象度しか知らないならCPS変換から入るのが早道かも。

758 ：
私も CPS で考えるのが早道だと思う。
CPS で考えた時に表出する環境の受渡しを普段の Scheme では暗黙にやってる感じ。

759 ：
俺はコールスタックからだったが
＞CPS
こういう捉えかたもあるんだね
知らなかった、ありがとう！

760 ：
>>755
ナカーマ
誰かこのスレで解説してー

761 ：
関数の戻り値が渡る先を操作できるだけじゃん。

トップレベルの特異性には注意だけど。

762 ：
c++で継続はライブラリ使うだけで良いみたいだけど
C言語では継続はマシン語いじらないと実現出来ないの？

763 ：
ロングジャンプが継続

764 ：
>>762
C++ではライブラリで継続が使えるってどういうこと？

765 ：
>>762,764
このあたりの話かな。
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0534r3.pdf
今のところはまだ提案があるだけで標準に入ったわけではない。

継続を表現するライブラリっつっても、
そのライブラリの中身は何がしかアーキテクチャ依存になるだろうけどな。

766 ：
C++には、GCとか実装から切り離して、実行環境をカプセル化した
関数オブジェクトがあるから、そのことかも

767 ：
ええと、一応念のため説明させていただきますが、C++では関数は
オブジェクトではないのです……

768 ：
>>765
うおぉ、なにこれ！
情報ありがとう。

769 ：
Exaリーディングのすゝめ
https://www.slideshare.net/ShinichiMakino1/exa-84358376

👆これええな
schemeでも読んだら勉強になる、程よい大きさのコードないものか

770 ：
schemeについてのことではなくてelispについてなんですが、同じかもしれないと
おもってお尋ねします。コードを書いた実行をして、（コードを読み込んで）
そのあとその実行して読み込ませたものをclearして、（書いているコードはそのまま
なんですが、読み込んだという事実をclearしたい）それで別のコードを下に書いて
その下に書いたものだけを実行するという風にしたいのですが、そういうclearする
ことは可能でしょうか？どのようにするのでしょうか？

771 ：
>>769
3imp

772 ：
768の質問を取り消します。後日に尋ねるかもしれませんがその時には
よろしくお願いします

773 ：
>>771
schemeってみんなインタプリタとかコンパイラの実装ばっかですね
schemeの勉強でもmapやappendを実装しましょうみたいなのばっかやし
まあguiもwebもゲームも低レイヤーも出来ないとなれば仕方ないんかな

774 ：
皆さんclassとかrecordとか使うんですか？

775 ：
>>773
あまり話題に上がらないけど GTK バインディングとかウェブフレームワークとかは有る。

FFI を使えばどんなライブラリでも使えるのでとりたてて分野が限定されているということは無い。
メモリ管理とか、Scheme として自然に使えるようにする面倒くささはあるので、
それを整備したものってのは最終的には物量の問題だと思う。
Chicken には Eggs が、 Racket には Planet というモジュール管理システムがあって公式リポジトリに登録されているライブラリの量もまあまあ多いので、
そのあたりから興味があるものを探してみたらいいんじゃない？

776 ：
>>774
Scheme の record は R6RS と R7RS で違うし SRFI でも微妙に違うのがいくつもあるので、
処理系によってサポート状況が違って使いにくいってのは感じるかな。
それでも多少ラップすればそれなりの移植性は確保できるので、
個人的には積極的に使ってる。

class というかオブジェクトシステムについては Scheme ではまとまった提案がないから
CLOS をベースにデザインされたものが多いとはいうものの処理系による差が激しくて、
最初から特定の処理系をターゲットにすると決めている場合じゃないと使わないな。
でも使うと決めたら積極的に使ってる。

777 ：
webやるならclojureで良さそう(´･_･`)

778 ：
人生3度目の the little schemer です。
xyzzy で確かめながら読んでいますが、一つ疑問が生じました。
教科書では

(lat? (atom turkey or))

と印刷されていますが、手元の処理系（gauche 0.9.5) では

(lat? '(atom turkey or))

と関数 lat? の引数に ' をつけないとうまくいかないのです。
これはどういう理由なのでしょうか？この ' は scheme の用語ではなんと呼ばれているのでしょうか？
ずっと教科書を読んでいくうちに自然とわかってくる事項でしょうか？

よろしくお願いいたします。

779 ：
>>778
' は quote の略表記。 たとえば '(a b c) は (quote (a b c)) と書いても同じ。

私はその本を持ってないからそのコードで何を教えようとしてるのかよくわかんないけど、
quote はかなり基本的な要素なので理解できるようにしてるとは思う

780 ：
>>779
ご回答ありがとうございます！
教科書 'the little schemer' -> https://www.amazon.co.jp/dp/4274068269 有名そうで読んでいる人が多そうなものを選びました！

781 ：
little schemerはsicpの前に読む人が多いのかな
自分は読まずにsicpに突っ込む予定だけど

782 ：
SICP は計算機科学の専門書だし、趣味プログラマには高度すぎるんじゃね？
SICP は現実的な部分についても書いてないから Scheme を (日常的なスプリクティング用途程度に) 普段使いしたいって
程度の気持ちで読み始めると、理論の部分で挫折して放り投げがちなんじゃないかな？

いや、ガチで背景にある理論を理解したいって志があるなら SICP から読むことに反対なわけではないけど、
もっと緩く Scheme を使いたいっていう気持ちで使う人も歓迎したいし、
最終的に SICP を読んで理解するのが前提みたいに言うのはちょっとどうかと思うよ。

783 ：
>>778
その「atom」ってのが実は手続きなのよ。本文ではなく前文かどこかに定義が載っていたと思う。

784 ：
>>783
忘れてくれ。手元の本見たら、手続きなのはatom?だった。

785 ：
xyzzyとgauche並行とか混乱するだけだぞ

786 ：
最近はnumpyにしか実装がない数値計算法が増えた
Racketはnumpyのインターフェースあるけど、他はどう？

787 ：
Racket にはそんな変態なものがあるんか。
どうやって実現しているのか興味あるけど、ググっても見つけられなかった。

788 ：
ラケット王国の和訳まだかなーﾁﾝﾁﾝ

789 ：
C++のインターフェースある処理系ならboost.numpyでnumpyは動きそうだが

790 ：
clmlってどうなん

791 ：
機械学習ライブラリとしてなら優秀だけど
今話題になってるディープラーニング対応してない

792 ：
>>789
boost.numpy はテンプレートもだばだば使ってるし、それをあらためて動的型の言語にバインディングするのあほらしいやろ。

793 ：
numpyも実体はlapackのインターフェース

794 ：
Fortran最強か。

795 ：
gaucheかchickenでGUIやるの厳しい？
tkはlinuxだとめっちゃ汚いから嫌なんだけど
Iupというの気になるんだけど試してみた人いませんか

796 ：
Gauche や Chicken なら GTK バインディングが楽に使えると思う。

私は使ったことないけど Racket の GUI ライブラリは使いやすいみたいに聞くので、
処理系にこだわりがないなら試してみてもいいんじゃない？

797 ：
gaucheとchickenってどっちがいいの？

798 ：
用途や好みによる

799 ：
(display "Happy New Year.")

800 ：
今からClojure入門しようと思うんですけど
「Clojure for the Brave and True」
この入門書ってどうなんでしょう？
ポチるか悩んでいるので一押し欲しいです

801 ：
それって無料公開されてないか？
読んでないが

802 ：
https://www.braveclojure.com/clojure-for-the-brave-and-true/

803 ：
Clojure スレで相談した方がよくない？

804 ：
(特定のスレに書き込めないテスト)

805 ：
>>778
5章になって急に難しくなりました‥
http://d.hatena.ne.jp/kazu-yamamoto/20101021/1287625788
＞リストのリストに対して、深く再帰します。見方を変えれば、これは木構造に対する再帰です。

それまでは（復習は必要ですが）理解に苦しむことはなかったんですが‥

806 ：
本は仕様の確認程度に留めて処理系の実装を一通り見た方が理解が早いよ
俺は昔SECDR-SchemeやTiny-Scheme辺りのソース読んでSchemeの全てを理解した

807 ：
勉強していく上で参考になるプログラムを見つけられないのが痛い
特にgaucheとかchickenでのオブジェクト指向をどうやって身につければいいの

808 ：
Gauche で書いたプロジェクトとしては WiLiKi とかどう？
shiro さん自身が書いてるのがいちばん Gauche 的に綺麗な書き方じゃね？

809 ：
gaucheがライブラリを含めて固まってから書かれたならそう断言できるけど……

810 ：
RacketのプログラムをCと同じぐらいに高速化したい
Checkenで動くように改変すれば手間かからずに高速化出来るんだろうか

811 ：
なんで Checken? Chez の方が速いでしょう。

812 ：
Racket は速い方なので、それで不満なら単純に (手間をかけずに) 移植してもたいした高速化は望めないと思う。
処理系ごとのクセはあるから場合によっては載せ替えるだけで高速化になることも無いわけじゃないが、
やってみないと (検証の手間をかけないと) 結果はわからぬ。

813 ：
shenってどうなの？

814 ：
どうとは？

815 ：
使ってみた感想あれば聞きたいね
日本語情報少ないし、用途もよくわからない

816 ：
Prolog を結合させた玩具か

817 ：
実装がたくさんあってスマホで遊べるくらいしか知らん

818 ：
スマホアプリもあるんか
シーケント計算ベースの型システムってのが難しそう

819 ：
>>818
> シーケント計算ベースの型システムってのが難しそう

別にそういうことはない
型システムを良く行われるように自然演繹で定式化するかシーケント計算で定式化するかという定式化のスタイルの違いだけだから
大雑把に言えばシーケント計算は自然演繹のmeta calculusというスタイルだというだけだからね

820 ：
https://github.com/adtac/autovpn/blob/master/autovpn.go
このopenvpnを使ってvpngateに接続するだけの、80行程度のgolangのコードをgaucheで書くとどんな感じになりますでしょうか

821 ：
誰かー

822 ：
>>820
こんな感じかな？

https://ideone.com/w5FtZ9

ideone はコード中の URL らしきものを適当にぼやかす機能があるらしく、勝手に置き換えられちゃった。
「download」のリンクでは本来の通りになるみたいなので、 html からコピペじゃなくてそっちを使ってね。
あと、 openvpn を手元で導入せずにそれっぽく書いたのでほんとにちゃんと動くか確かめてないぽよ～

823 ：
>>822
いいかげんに書いたけど、まじめに書くならもうちょっと小さい手続きに分割するかも

824 ：
>>822
ありがと😍

825 ：
ちゃんと使えた？

826 ：
ちょこっと修正すれば接続は出来ました
+(use srfi-11)
- (set! chosenCountry (list-ref 1)))
+ (set! chosenCountry (list-ref args 1)))

でもCtrl-cするとエラーが出て[autovpn] try another VPN? (y/n)に進めない😱

^CMon Jan 15 04:25:51 2018 event_wait : Interrupted system call (code=4)
*** UNHANDLED-SIGNAL-ERROR: unhandled signal 2 (SIGINT)
Stack Trace:
_______________________________________
0 (sys-waitpid (process-pid process) :nohang nohang?)
at "/usr/share/gauche-0.9/0.9.5/lib/gauche/process.scm":436
1 (process-wait process)
at "./autovpn.scm":42
2 (%with-signal-handlers (list (cons (%make-sigset SIGTERM) (^ ...
expanded from (with-signal-handlers ((SIGTERM (process-send-signal process
at "./autovpn.scm":40
3 (fn item)
at "/usr/share/gauche-0.9/0.9.5/lib/gauche/procedure.scm":303

827 ：
>>826
あー、たぶんやけどシグナルマスクがアレなんとちゃうかな。
先にチャイルドプロセスにシグナルが伝播して終了しとんのにシグナルを送ろうとしてもうそのプロセスのうなっとるって感じ。
Windows だとシグナルマスクはなんにも意味なくて、 Unix (POSIX ?) とは扱いが違うんで、ワイにはようわからんのやわ。
すまんの

828 ：
自分でも調べてみるわ😷

829 ：
:optional引数ってどうやって指定するんですか（？＿？）

830 ：
Scheme でオプショナル引数を受け取る手続きをどう書くか？ という意味？

831 ：
オプショナル引数を受け取れる手続きにどうやって渡すかという意味でつ

832 ：
それって聞かなきゃわからんような要素あるか？
普通に引数を書く以外にすることないだろ。

833 ：
はちみつ餃子 ◆8X2XSCHEME怒らせたら大したもんやで

834 ：
(apply オプショナル引数付き関数 (list 引数))
こうです

835 ：
あー、なるほど、そういうことを聞きたかったのか。

836 ：
Lisp勉強するのに、白と黒の扉、聖霊の箱って役に立つ？

837 ：
>>836
amazon でみたところ、「白と黒の扉」とかは、オートマトンやチューリングマシンの話だから lisp とはあまり関係ないんじゃないかな？
いや、 lisp でオートマトンやチューリングマシンを記述したいのだったら話は別だが

この手の話は、私は手元に
https://www.amazon.co.jp/dp/4627805500/
を置いて逐次参照しています、チューリングマシンの適当な発展書があれば、教えていただけるとうれしい

838 ：
>>836
そういう目的には合ってないと思う
ある程度知ってる人が読みものとして楽しむもの

839 ：
>>837
激しくすれ違いだけど
http://www.saiensu.co.jp/?page=book_details&ISBN=ISBN978-4-7819-9929-6&YEAR=2017
とか
http://gihyo.jp/book/2015/978-4-7741-7270-5
とか

840 ：
>>837-838
わかったそのうち読んでみる

841 ：
もねまね鳥をまねる
スマリヤン先生って去年亡くなってたのか
120歳まで生きると思ってた

842 ：
スマリヤンって関西っぽい響きがあるよね。
スマリやん？ｗｗｗ

843 ：
>>841
あれはチューリングマシンじゃなくてコンビネータ

844 ：
>>842
ああっ昔駄洒落自動生成機を作ろうとした黒歴史を思い出した

845 ：
すまん。初心者です。教えてください。

仮に学校の比較？などを扱うプログラムを作ろうとしていて、schoolという1つの学校の情報をまとめたクラスを作るとします。
そのクラスの中に、以下のような学生の情報をまとめたテーブルの情報をぶち込みたいとして、どのようにこれらのテーブルをschoolクラス内に保存するのがいいですか。


名前 整理番号 性別 2ちゃんねら 馬鹿 橋本環奈好き 年齢
taro 0 #\M t t nil 16
hanako 1 #\F nil t t 16
nagisa 2 #\L nil nil t 18
hoge
piyo
foobar
...

学校によって人数は若干違いますが、基本的にテーブルの大きさはそれほど大きくないとします。
それぞれの要素を頻繁に検索・参照する必要があります。
僕が思いつくのは、

・schoolのstudentsというスロットに、1人のデータの1つのリスト・構造体・クラスにして、そのリストとして保存。
・ハッシュテーブルをつかって、下記のような形で保存。

2CHP ((NAGISA NIL) (HANAKO NIL) (TARO T))
BAKAP ((NAGISA T) (HANAKO T) (TARO T))

ぐらいなのですが、このうちどれがおすすめとか、これら以外にもっと便利な方法などありましたら教えてください。
よろしくお願いいたします。

846 ：
作ったハッシュテーブルをschoolのstudentsスロットにぶち込むと言うことです。
あと、nagisaさんは馬鹿ではありません。失礼しました。

こーいうクラスとかの設計の基本と言うか定石ってどうやって勉強したらええの？

847 ：
何が良くて何が悪いかなんてやってみなきゃわからんよ。
まず動くものを作ってから出来が悪いと思ったところを直していったらいい。
LISP の良さってそういうとこだろ。

848 ：
studentクラスの定義がまず先かな
あとstudentsはキーを何にするかが問題
多分名前なんだろうけど、他の項目でも取り出したいときはハッシュテーブルだと面倒だから単に配列でも良いと思うがな

849 ：
>>845
そもそもクラスは初心者向きじゃないし
Lispのような関数型言語では無理に使わなくても別にいい
多用したいならオブジェクト指向言語を使えばいい

850 ：
オブジェクトシステムを積極的に使うべきかどうかは確かに場合によるし使わなくても割といけるが、
関数型とオブジェクト指向は直行する概念で、関数型であるからオブジェクトシステムの価値が低いというわけじゃない。

851 ：
CLOSは初心者に分かりにくい
Lisp自体もそうだけどさらに分かりにくい

852 ：
CLOSみたいなんじゃなくてもっと言語仕様に密着したオブジェクトシステムがあればと思う
例えばコンスセルはcarとcdrをメンバーに持つクラスみたいな
Gaucheってそうなってんだっけ？

853 ：
LispでSmalltalk実装すれば解決

854 ：
オブジェクト志向うんぬんの空気読まずにカキコ

>>846
>こーいうクラスとかの設計の基本と言うか定石ってどうやって勉強したらええの？

LISPというよりも、どちらかというとデータベース設計が主題になるね
もし手早くSchemeで小規模なデータベースを実装したいのであれば、
SLIBと呼ばれるよく知られたライブラリに含まれている
データベースを使うのが最短だと思う
・The SLIB Portable Scheme Library
　http://people.csail.mit.edu/jaffer/SLIB
日本語では、以下の書籍で文献データベースを主題として丁寧に解説されている
・入門Scheme
　　- Schcme入門からXツールキットを使ったリレーショナルデータベースプログラムまで
　https://www.amazon.co.jp/dp/4879669547

もしLISP(による実装)を離れて一般的なデータベース設計そのものを勉強するなら、
たとえば定番の入門書(教科書)である以下の書籍の前半を読む
・リレーショナルデータベース入門―データモデル・SQL・管理システム・NoSQL
　https://www.amazon.co.jp/dp/4781913903

もしLISPプログラミングに自信があり、その上で広義のデータベースとして
「LISPによる知識表現プログラミング」を習得したいのなら、
遠回りになるけどSICP本の「４.4章 論理プログラミング」への挑戦を勧める
　

855 ：
>>851
どうだろうなぁ。 初心者っていうか人によるんじゃね。
俺は JavaScript のプロトタイプベースのクソさに辟易した (実利があるのはわかってはいる) けど、
Gauche の (CLOS 風の) オブジェクトシステムにはそんなに忌避感ないし。

856 ：
みなさん、アドバイス・参考書の紹介などありがとうございます。

いろいろ自分で試してみて、どれがいいか決めようと思います。
とりあえずの方針としては、school-baseみたいなクラスの下に、studentsクラスを作って
そこにテーブル属性ごとにスロットを作って、alist形式でぶち込むことにしました。
キーの設定やら検索の便宜やら考えた結果、alistが一番手軽そうだと言うことで。

BAKAP ((taro.t) (hanako) (nagisa.t) ... )

みたいな感じで。学生を単位にデータを作ると扱いづらそうなので。

857 ：
オブジェクト指向的には
学生ごとにインスタンスを生成して
各属性はインスタンスのスロットに入れるのが自然な実装だろう
属性が動的に変わるなら
そこをalist/plistにするか
プロトタイプ思考のOOPSを使うといい

858 ：
本屋に行ったらLittle Proverの和訳が出ててびっくりした

859 ：
Coq/SSReflectの本が発売されるらしい
https://www.amazon.co.jp/dp/4627062419

一ヶ月以上後だけど

860 ：
またkaizenさんが和歌でレビュー書いてるのかと思った

861 ：
教えてください。
cxmlで150mbぐらいのファイルをparseしようとしたら、
メモリのリミット来てるでーって怒られてダメでした。
巨大ファイルの扱い方教えてください。

862 ：
saxとかklacksってのを使えば良いのか。
どうやっても空白を拾ってしまう。何でだ。
いろいろ頭痛い。

863 ：
>>858
これか。字が小さいんだよなぁ。
ttps://www.amazon.co.jp/dp/4908686025

864 ：
>>862
空白はそのままに認識するのが XML の規約じゃなかったっけ。
空白を除去したいかどうかはアプリケーション側の裁量。
よく使われるライブラリなら何かオプションを持ってたりすることはあるかもしれんけど。

865 ：
これがLispだ！は教科書っぽくていいな
これと実践あたりを順を追って読んでみようと思う
それからSICPにいこうかな

竹内初めてのとかLand of Lispみたいなノリの本こそLispらしいのだろうが、ついていけないと嫌いになる^^;
LittleはCPSからいきなり難しくなるし、その前も背景知識ないと消化不足になる
Yコンビネータも一応流れはつかめても、自分みたいな頭良くない初学者にはあの試行錯誤から何かを掴むのは難しい
Lispは表面的な軽さと話してることが乖離している書籍が多いし、独学者にはキツイ

これらが、同時並行的にあーなるほど、となると悟ったという事になるのかな？

866 ：
>>865
＞LittleはCPSからいきなり難しくなるし、その前も背景知識ないと消化不足になる
おっと、いつのまにか　little schemer の読み込みが途絶えてしまっていた、今日から馬力をかけて、ぜひ読みきろう！

867 ：
CPSも紙に書いてトレースすることはできるんだけど
見た目が難しいのにご利益があまり感じられないのは俺の頭が悪いからかな？

868 ：
>>867
Scheme の意味論的には重要なのは確か。
そういう理屈はどうでもいいやってのなら知らなくてもいいかもしれぬ。

869 ：
>>868
それはどうしたら学べますか？
プログラム意味論とか読めばいいの？

870 ：
>>869
うーん、俺も理屈をきちんと学んだわけじゃなくて CPS 変換を通して理解したんだけど、
CPS 変換しても何もつかめなかったのならどうすればいいんだろう……。

CPS は継続の理解の助けになるんだよ。
入門書で CPS 変換を取り上げるのは継続を理解させるため。
CPS 変換すること自体が普段のプログラミングですごく役に立つってわけではない。

継続ってのは call/cc で取り出せるやつってだけじゃなくて、
Scheme のプログラムでは常に背後にある。
Scheme に限らずどんな言語にも、 C にだってある。
call/cc は背後にあるのを表に引きずり出す仕組みなんだ。
だから背後でやってるやつを明示的にやったらどないや？ っていうのが CPS なの。
そんだけ。

871 ：
CPS変換はCLとかelispでジェネレータの実装に使われてるよね

872 ：
>>870
> CPS は継続の理解の助けになるんだよ。

その通り

> CPS 変換すること自体が普段のプログラミングですごく役に立つってわけではない。

まあ普通のプログラミングではCPS変換なんて必要ないわな

> 継続ってのは call/cc で取り出せるやつってだけじゃなくて、
> Scheme のプログラムでは常に背後にある。
> Scheme に限らずどんな言語にも、 C にだってある。

上の３行はもちろん間違っていないんだけれども補足しておくと、
Cなどの通常のgoto文（やCのbreak文等のような制限されたgoto文）とか例外処理を有する命令型プログラミング言語の意味論（正確には表示的意味論）を語る上でこそ継続が不可欠になる

Schemeからcall/ccを除けば（call/ccやそれを含むライブラリ手続きの類を一切使わない範囲でしかSchemeを利用しない人は）継続を使わない意味論で考えても何も問題ない

例えば、命令型言語でも制御構文としてif文とwhile文しかない（goto文やbreak文等のジャンプは含まない）言語…しばしば「While言語」とか呼んで手続き型言語の表示的意味論の
説明用としてに最初に取り上げられるミニチュア言語（一応、万能ね）…の意味を与えるだけなら継続は必要ない

そういう単純な（いわゆる「構造的」な）制御フローしか許さない言語では、個々の文（命令）の意味は状態から状態への写像（つまり文の表すものは一つの状態変換関数）として考えれば済む

goto文や例外処理のような構文に関して制御の流れが（文の構文構造について）構造帰納的でなくなる制御フローを生み出してしまうものを含んだ言語の意味論を考えようとすると継続が不可欠になる
もはや、個々の文を状態変換関数（そして個々の式を状態の集合から値の集合への一つの関数）として考えるような直感的に分かり易い意味の与え方は通用しない

表示的意味論の生みの親のStracheyが、compositionalつまり大雑把には構造帰納的に意味を与える表示的意味論において構造帰納的でない制御フローを生み出すgoto文の意味を
如何に与えるかで悩んだ末に発明した概念こそが正に継続なんだ
（因みに日本語の表示的意味論の教科書でやや古いものは“continuation”の訳語として「継続」でなく「接続」という言葉を使っている場合があるが両者は全く同じ）

873 ：
何時からこんな長文のレスが出来るようになったのかと

874 ：
>>867
簡単なスタックマシンにコンパイルしてみてはどうか?

875 ：
>>874
継続がない言語からね
CSPありとなしで比較して

876 ：
継続ってラムダ計算にもあるの？

877 ：
CPSは必ずしも再帰で使う必要はないということでいいのかな
リトルのCPSが消化不良なのは前の章までの理解が足りてないってことか

878 ：
再帰とは関係なく全ての計算に関わってるよ。

879 ：
再帰の際に、例えば階乗計算で終端条件から戻ってきて
1*2*3*.......*(n-2)*(n-1)*nと掛けられるものも継続ですか？

880 ：
>>879
再帰はなくても
関数からのreturn実行が
継続の適用そのものです

881 ：
>>880
ああ、その説明は見事ですね

882 ：
C ではアドレスが継続だと思えばだいたい合ってる。
環境が保存されないから Scheme より限定的だけども。

C だと実引数と一緒にリターンアドレスもプッシュするじゃん？
それと同じように Scheme でも戻ってくる継続を暗黙に渡してるんだよ。
Scheme の call/cc は gcc 拡張の __builtin_return_address みたいなもん。

883 ：
俺Cわかんないんだよね^^;

884 ：
そっか～

885 ：
>>879はあってますか？
終端から戻ってきた値が、入れ子の外側、つまり継続に渡されて
さらに外側の継続に渡されて
継続がなくなったら値がプリントされる
というイメージなんだけど

886 ：
Cで継続を保存しようとしたら、setjmpで保存してるもの(全レジスタの状態)とスタックの内容のコピーだろ(場合によってはかなりのサイズになるが)

887 ：
>>886
setjmp/longjmp は、スタックポインタは保存してもスタックの内容のコピーはしない、だからネストの浅いところから深いところにジャンプできない

888 ：
>>887
ん？だからsetjmpの内容とスタックの内容をコピーすると思いっきり書いたつもりだったが…

889 ：
C++ coroutinesだとスタック全コピーも実装の有力な候補だな

890 ：
というか、おととし最後に聞いたときには>>886の言う通りでほぼ決まりみたいな話だった
C/C++では何と、スタックの中を書き換えることができるのだ！

891 ：
Smalltalkならスタックフレームもオブジェクト

892 ：
Smalltalkって業務で使ってるとこあるのかな
LISP系よりはありそうなんだが

893 ：
ヨーロッパや南米での事例が多いとか

https://medium.com/@newapplesho/今時-2017-のsmalltalkの始めかた-93c044820e1b

日本にも地味に仕事あるらしいけど守秘義務で見えにくい

スーパーの古いレジ（POSシステム）で使われているのを見かけたのはNEC系のこれか？

http://tech.nikkeibp.co.jp/it/members/NT/JIREI/20011220/1/

比較的最近の話題はLispばりにスタートアップに活用されたこと

http://web.archive.org/web/20171111102557/https://thepedia.co/article/1068/

894 ：
>>892
> Smalltalkって業務で使ってるとこあるのかな
> LISP系よりはありそうなんだが

少なくともアメリカでは実アプリをSmalltalkで作ってるケースはほとんどないんじゃないと思うが
プロトタイプをSmalltalkでちゃっちゃと作ってしまい動作確認をするってのはアメリカでも昔からさほど珍しくないそうだが

ちなみにCommon Lispはアメリカでは以前から実用アプリの記述言語としてそれなりの頻度で使われてるよ

895 ：
>>882
スタックも含まないと継続にはならない

896 ：
>>895
Scheme 用語で言う「環境」のことな。
それを含まないから限定的と説明しているわけ。

897 ：
>>896
Cではと限定してんだから、普通にsetjmpと言ってほしいんだが…
IP(インストラクションポインタ)だけを指して限定的な継続言われても逆に分かりにくいと思うが

898 ：
環境をあえて使わない継続の応用はあっても
環境を含むことができない機構を（「限定的」と断ったとしても）継続だと言い張るのはオカシイよ

899 ：
別に「限定継続/delimited continuation」ってものもあるしな
話がややこしくなるだけで理解の助けにならない

900 ：
Racket で escape continuation って言ってるやつと近いかな。

901 ：
schemeをjsに変換してreactやるとかelectronでGUIアプリ作るとかいう話ない？

902 ：
scheme->jsの変換は簡単そうだね
継続使ってなければ

903 ：
そもそもJSにトランスパイルできる
まともなscheme処理系が無いだろう

904 ：
loopがマジでわからん。
どうしたらいい？

905 ：
loop マクロを自作してみる

906 ：
実践Common Lispで覚えた
formatも同じく

907 ：
ocamlでさえjavascriptにコンパイル出来るというのにschemeも頑張ろうや

908 ：
Scheme -> Clojure -> javascript の順番に変換するなら、

Clojure -> javascript はすでに自動変換だし、

Scheme -> Clojure も define -> def 等、機械的な置き換えである程度出来るから、

単純なプログラムを変換することは出来るけど、それほど需要がないから無いんじゃないの。

909 ：
つうかemscriptenで幾つかの実装が動いてるよね
ただそれだけで

910 ：
emscripten で C言語 -> javascript に変換が可能だから、Chicken で Scheme -> C言語 に変換すれば、
Scheme -> C言語 -> javascript が実行できるハズか。うまく通らないコードもあるだろうけど。

911 ：
>>910
そんなチキンなやり方が許されるとでも？

912 ：
>>910 ＞Chicken
>>911 ＞チキン
日本語でおｋ

913 ：
なんだそのツッコミは

914 ：
なるほどもっとキチンとやれと

915 ：
ところで「ブラウザでCLを動的にJSにトランスパイル可能なライブラリ」って聞いたら何が思い浮かびます？

916 ：
>>915 (loop) >>903

917 ：
>>916
ワロタww

918 ：
質問です！

動的スコープってスタックに積み上げるだけで実現できるじゃないですか
静的スコープってどうやって実装すればいいんですか？ヒント下さい

919 ：
コンパイル (意味解析) 時にスタックを使えばいいんじゃないのかな。

920 ：
>>919
なるほど、意味解析時にスコープの構造をスタックで再現しといて
eval時に該当するスタックを参照できればいいってことですよね。

なんだか、ソースマップみたいですね。ひとつひとつのAtomに該当するスコープの参照を持たせるとなると、なんか重くなりそうですね

921 ：
Have you ever read The Little Schemer? => #t
Have you ever read The Seasoned Schemer? => #t
Have you ever read The Reasoned Schemer? => #t
Have you ever read The Little Prover? => #t
Have you ever read The Little Typer? => #f
What's The Little Typer? => Pie language book.

922 ：
David Thrane Christiansen のやっている Idris や Pie language といえば、
依存型 (dependent type) を使用した Type-Driven Development かな。
定理証明系の次の話題としては順当なところ。

923 ：
もうなんのことだかさっぱり

924 ：
依存型についてのテキストはこれまでにこういうのが出てるよ。
Edwin Brady "Type-Driven Development with Idris"
Adam Chlipala "Certified Programming with Dependent Types"
Aaron Stump "Verified Functional Programming in Agda"

Edwin Brady と David Thrane Christiansen は協力して Idris を作ったひとで、
今回、Christiansen が Racket 上で Pie language を実装したみたい。
Pie languageの実装を理解させる本が出ることで Type-Driven Development の
低レベルでの詳細が明快になると期待できる感じかな。

925 ：
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

VU7Z1

926 ：
ちょっと聞きたいんですけど
JSONをS式で書いたらどんな書き方になると思いますか？

(users . (
((Name . John)
(Age . 25))
((Name . Mike)
(Age . 24))
))

みたいな感じですか？

927 ：
cl-jsonとかで読み込んでみたら

928 ：
>>926
Gauche だとこんな感じにマッピングされる。
https://practical-scheme.net/gauche/man/?l=ja&p=parse-json

Sagittarius だとこう。
http://ktakashi.github.io/sagittarius-online-ref/section753.html

XML だと SXML でほぼ統一されてるけど、JSON に関してはまだ揺らぎがある。

929 ：
素直に連想配列にした方が良いのか、それだと巨大なデータの時にアクセス効率が悪いからハッシュテーブルやdefstructした方が良いのかとか、一筋縄では行かないだろう

930 ：
Expat みたいな方式で、オブジェクトの構築はユーザまかせにするってのもひとつの案かな。
まあ、 JSON が必要な場面は設定ファイルとかウェブ API の類とかだと思うので、
極端に巨大な JSON を仮定する必要はあまりないと思うが……。

931 ：
JSONをS式で書くといっても、いろいろやり方はあるよね。
Pie language みたいにDSLを使って、Name型、Age型、users型を定義すれば、
型推論、Type-Driven Development を導入できる。

932 ：
ほえー、難しいですな

933 ：
結局pieてなに？

934 ：
PIE には、元々「インド・ヨーロッパ祖語」(Proto-Indo-European language) という意味があるらしい。
そこから転じて Type-Driven Development の祖語たれかし云々。
Pie言語のような Type-Driven Development と J-Bob(ACL2) の定理証明器の組み合わせによって、
新しいプログラミング・サイクルがもたらされる。
[1] 型を定義する（自動的に型チェックもされる）だけで、
[2] Type-Driven Development 環境が型定義から実行可能なプログラムの雛形を生成してくれる。
[3] プログラムの雛形に実装部分を書き加える。
[4] 書き加えた実装部分の数学的正しさを定理証明器でチェックする。
こんな感じで開発するだけでプログラムの正しさが保証付きで出来上がる。もちろんOOPでもOK。
将来、ほとんどの言語がこういう機能を持つと思われる。

935 ：
荒っぽく言うと、英文作成時にtypo checkerとgrammar checkerを併用すると、
正しい英文が簡単に書けてしまう。そのプログラミング言語版みたいなものかと。

936 ：
既存の XML や Json のデータからスキーマを構築するやつはどっかで見たことある。

937 ：
>>936
JSONスキーマつかってvalidationするやり方は、テスト駆動開発だからミスリード。

938 ：
初心者なんだけど、qiitaでlispの勉強ブログやるのどう思う？
ブログとか自分の趣味ではないんだけど、勉強はかどるかと思って。

939 ：
>>938
いいと思うよ。
ただ、 Qiita はブログホスティングサービスではなく、
「知識を共有する」ということをコンセプトにしたサイトだから、
やったことを箇条書きにするだけとかコードが貼っているだけみたいなのではなく、
自分に続く人に参考になるような書き方を心がけてね。

940 ：
数行のコードをコンパイルしてみた
chickenでとても小さいバイナリが生成されて満足したあと
Racketが生成するバイナリの大きさに驚いた
そしてSBCLでやってみたらさらに5倍以上も大きくてビックリだわ

それぞれに理由があるのは分かるけど

941 ：
実行ファイルのサイズがでかくても役に立つアプリだったらいいんじゃないの
役に立たないアプリだからサイズが小さくないとまずいって話かな

942 ：
ばかか？

943 ：
SBCLで「ビックリ」したのはこれ

(eq 'abc 'ａｂｃ) ;=> T
(eq 'アイウエオ 'ｱｲｳｴｵ) ;=> T
'ｱｲｳｴｵ ;=> アイウエオ
'㌰㌰ ;=> ピコピコ

(setf (sb-ext:readtable-normalization *readtable*) nil) すれば変換されなくなる
http://www.sbcl.org/all-news.html#1.2.5

944 ：
皆様に質問です！

JSCLみたいに「サーバサイドもクライアントサイドもlispで！」みたいな思想のやつって他にもありますか？

単にトランスパイラというわけでなく、ブラウザでevalできるのが理想なんですけど...

よろしくおねがいします！

945 ：
>>944 (loop) >>903

946 ：
>>941
自分はFDDの時代から使ってるような老害なので、バイナリは機能なりの大きさのほうが自然に感じるよ
まあ本体が小さくても巨大なランタイムが別にあるんだから同じだろと言われればそれまでだけど

947 ：
スマホで無駄にデカイバイナリーは迷惑だけどPCアプリのサイズなんて気にしない。
昔はユーザーもアプリサイズやメモリー使用量に敏感だったけど、今はそんなこと気にしてないみたいだし。

948 ：
>>945
なるほど、ありがとうございました。

949 ：
すみません、LISP初心者ですが、追加の質問させてください！

JSCLを試してみようとgithubのGetting StartedとBuildの項目に挑戦しています。
https://github.com/jscl-project/jscl

サーバでnpm install -g jsclしたあと、jscl-replコマンドを打つことでreplが動くところまではできたのですが
GithubのBuildの項目のところでつまずいています。

git clone https://github.com/jscl-project/jscl.git
することでnode_modulesやpackage.jsonなどが存在するプロジェクトディレクトリ上部に
jsclディレクトリが作成されたのですが（一体これはなんでしょう？サンプルプログラム集なのでしょうか）

replで(jscl:bootstrap)を評価しても
ERROR: The symbol `"BOOTSTRAP"' is not external in the package #<PACKAGE JSCL>.
と表示されてしまい、次のステップに進むことができません。

このステップは、githubのreadme.mdで
「あなたのLispにjscl.lispをロードし、ブートストラップ関数を呼び出して実装自体をコンパイルします」
「ソースツリーの最上部にjscl.jsファイルが生成されます。 これで、ブラウザでjscl.htmlを開いて使用できます。」
と記載があるので、(jscl:bootstrap)を実行することによりgit cloneで落としたプロジェクトをコンパイルし
出力されたjscl.htmlにApacheなど使ってアクセスできるようにすれば、bootstrap？とかいうサンプルアプリが動くと思っているのですが
何がいけないのでしょう？？

マニアックな質問で申し訳ないのですが、ぜひお助け願います。
（ところでbootstrapってなんでしょうか？cssフレームワークのTwitter bootstrapのことでしょうか？）

950 ：
SBCLは実行ファイルを圧縮して作成できる
40MBが10～15MB位になるはず
それでもデカイけどね
ちなみに起動時間は全く変わらない

951 ：
よく考えたらスタックオーバーフローとかで質問するべきだったかもしれません(´･ω･`;)

952 ：
>>949
> 「あなたのLispにjscl.lispをロードし、ブートストラップ関数を呼び出して実装自体をコンパイルします」

マニュアルの文章は、あなたが使っている LISP 処理系の上で jscl.lisp をロードした上で (jscl:bootstrap) を評価せよという意味だと思うんだけど、
あなたがやっているのは jscl-repl を起動した中で (jscl:bootstrap) を評価しているように読める。
そうだとしたらそんなものは無いので無いというエラーになるのはわかる。

953 ：
>>952
ご回答ありがとうございます！

つまりCLISPかなにか、適当な処理系をサーバにインストールして
そこから呼び出せばいいのですね！？

試してみます！

954 ：
Land of Lispはおもしろいですか？

955 ：
マンガは面白い

956 ：
stackoverflowってホントの初心者が質問してもいい雰囲気なん？

957 ：
>>956
雰囲気ってのが曖昧だけど、質問内容が馬鹿げたものでもどんどんしていいよ。
初心者の質問内容がしょうもないことなのは普通のこと。
だけど、質問の仕方にはある程度の作法がある。

https://ja.stackoverflow.com/help

「ホントの初心者」というのは自分が何を知りたいのか理解していないことが多いので、
回答できる質問に修正されるまでしつこくコメントされるかもしれないけど、
それは非難ではなく回答するために必要な対話なので、面倒くさがらないでね。

958 ：
>>957
＞自分が何を知りたいのか理解していないこと
それがわかるようであれば、回答を半分得たも同然ですね…
私にはわからないことが沢山あります、それが減る気配もない…

959 ：
Gauche の 0.9.6 リリースが近いらしい

960 ：
>>959
川合さん、未だメンテしてるのか。
ハワイで俳優業やってんじゃなかったけ?

961 ：
>>960
ずっと兼業してるみたいだよ。

俳優としての履歴はここに書かれているけど、 (実際には仕事につながらなかったオーディションも含めると) 2003 年からスタートしてる。
http://practical-scheme.net/wiliki/wiliki.cgi?Shiro%3AAuditionRecords

スクウェアの映画の仕事を終えてから Scheme Arts という名前で法人 (といっても史郎さんひとりの会社だが)
を立ち上げてコンサルティングの仕事を始めて、そのほんの少し後から平行して俳優としても活動してることになる。

962 ：
0.9.6 ｷﾀ――♪ o(ﾟ∀ﾟo) (oﾟ∀ﾟo) (oﾟ∀ﾟ)o ｷﾀ――♪

963 ：
関数型言語で画像処理をやってみたいんだけれど
Common Lispで画像読み込みの定番ってある？

debianでcl-png使おうとしたらlibpng12が必要みたいで
使えませんでした。(libpng16ならある)

clwikiに載っているimageライブラリでドキュメントが充実してるのって
cl-pngが一番なんだけど。

964 ：
そーいやgimpがlisp系

965 ：
KI1

966 ：
>>964
Scheme やね。
TinyScheme がベース。
R5RS のサブセットになってる。

967 ：
ラムダ計算と純lispはともにチューリング完全
だからlambdaだけで純lispが作れるはず
実際、cons,car,cdrは作れる
(define (my-cons a d) (lambda (f) (f a d)))
(define (my-car ad) (ad (lambda (a d) a)))
(define (my-cdr ad) (ad (lambda (a d) d)))
でも、atom?またはpair?はどう作ればいいの？

968 ：
教えてください。初心者です。

(defun test ()
(let ((result '(0 0 0 0 0 0 0)))
(format t "~{ ~a ~}" result)
(incf (nth 4 result) 7)
(incf (nth 6 result) 6)
result))

この関数なんですが、実行するたびに結果が変わるのです。

HOGE 28 > (test)
0 0 0 0 0 0 0
(0 0 0 0 7 0 6)

HOGE 29 > (test)
0 0 0 0 7 0 6
(0 0 0 0 14 0 12)

(let ((result (make-list 7 :initial-element 0)))...
にすれば意図したとおりに動作するのは分かっているのですが、
何で元の関数定義でだめなのかが分からないのです。
ちなみに、Lispworks 7.0 Windows 32bitです。
他の処理系でも同じような動作になるのでしょうか。

969 ：
何でこうなるかは、何となくわからなくはないのですが（1回目の実行と2回目の実行で同じリストをletで束縛してるってことですよね？）、
letってそういう動作するのを想定して使わなきゃいけないものなのか、ってのがわかってないのです。
僕の理解では元の関数定義でいけそうな気がするのです。

970 ：
(defparameter *FOO* '(bar bar bar))
(defun hoge-is-foo (&optional (piyo nil))
(let ((hoge '(fuga fuga fuga)))
(if piyo (setf *foo* hoge))
(format t "HOGE: ~{ ~a ~}~%" hoge)
(format t "*FOO*: ~{ ~a ~}~%" *foo*)
(if (eq hoge *foo*)
(format t "HOGE IS FOO!~%")
(format t "HOGE IS NOT FOO!~%"))))

PIYO 82 > (hoge-is-foo)
HOGE: FUGA FUGA FUGA
*FOO*: BAR BAR BAR
HOGE IS NOT FOO!
NIL

PIYO 83 > (hoge-is-foo t)
HOGE: FUGA FUGA FUGA
*FOO*: FUGA FUGA FUGA
HOGE IS FOO!
NIL

PIYO 84 > (setf (car *foo*) 'baz)
BAZ

PIYO 85 > (hoge-is-foo)
HOGE: BAZ FUGA FUGA
*FOO*: BAZ FUGA FUGA
HOGE IS FOO!
NIL

こーゆーもんなん？

971 ：
>>968
let の使い方というより、 quote されたリストの破壊的変更は literal object の変更にあたるから未定義動作になるはずで、そのせいで変な挙動になってるんだと思う。


ちなみに Allegro だと LispWorks と同じ挙動になった。

SBCL だと警告で "Destructive function SB-KERNEL:%RPLACA called on constant data: (0 0 0)." と出る。
で、繰り返し呼んでも毎回 (0 0 0 0 0 0) が返されるみたい。

972 ：
>>969
あ、質問の趣旨が違うか。

(defun hoge ()
'(1 2 3))

があるときに、

(eq (hoge) (hoge))

は、同じリストを返すのだから常に T になるのか？って話かな

973 ：
>>972
966です。
僕が知りたかったのは>>971の内容です。どうもありがとうございました。
未定義動作なのですね。基本的にこのような破壊的代入は避けるってことですかね。

しかし、これが未定義だと、確率は低いでしょうけど、いつかどこかで事故が起こったりするんじゃないのかな。知らんけど。

974 ：
>>973
うーん、リストを破壊的に変更する場合、上のようにリテラルを破壊するのもまずいし、リテラルでなくても部分共有されたリストだと予想外の場所に影響が及ぶので、自分は安全とわかってないとやらないです。

破壊的変更をするのが前提なら、 list 関数や言及されてるmake-listで新しく作ったり、 copy-list で複製してからいじったりすることが多いかも。

975 ：
>>967
↓の isnil あたりを参考にすれば作れそう。
https://en.wikipedia.org/wiki/Church_encoding#List_encodings

976 ：
>>974
破壊的な変更には注意が必要なこと自体は、入門書などを読んで知っていたのですが、
今回の例では関数を呼び出す度に別のリストをletが束縛するだろうjkと勝手に思っていました。

勉強になりました。ありがとうございます。

977 ：
>>968
SBCLは警告が出るから出ないように修正するだけだし、無視しても意図した通りに動く
LispWorksは警告出ないの？

978 ：
>>977
でないっす。

979 ：
自分の環境でSBCLでやってみたら↓みたいになった。
個人的にはLispworksの挙動より意味不明かも。
(hoge-is-foo)はLispworksと同じ結果。

* (test)
0 0 0 0 0 0 0
(0 0 0 0 7 0 6)
* (test)
0 0 0 0 7 0 6
(0 0 0 0 7 0 6)
* (test)
0 0 0 0 7 0 6
(0 0 0 0 7 0 6)

980 ：
リテラルのリストに対する破壊的変更はダメ
っていうのはLand of Lisp(の訳注)で初めて知った
他の本やサイトでこれに関する注意を見た覚えがない

「literal object の変更にあたるから未定義動作になる」(>>971)ということは、リストに限らないんだね

[1]> (defun f () (let ((x "abc")) (format t "~S~%" x) (setf (elt x 0) #\!) x))
F
[2]> (f)
"abc"
"!bc"
[3]> (f)
"!bc"
"!bc"
[4]>

981 ：
CLHSで "The consequences are undefined if literal objects are destructively modified." って書いてあるページ
http://www.lispworks.com/documentation/HyperSpec/Body/03_ga.htm

そして、 literal の方には "appearing as data in a quote form" なんて書いてあるので (http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_l.htm#literal)
quote の中身は literal, よって破壊的に変更すると undefined ..?

982 ：
何故maxには:keyがつかえないの？
定義だから。いや、知ってるけどあってもええやん。
みんなreduceとか使ってやってんの？

983 ：
リテラルの破壊が駄目ってのは割と一般的な気がする。
C がそうなってるのを知ってたので、
後に他の言語を学ぶときも意識して仕様をチェックしてる。

984 ：
>>979
SBCLは警告出すということは危険なコードと言うのを認識してコピーを作成してるんでしょ
ちなみにEmacsだとクオートされたリストの書き換えは問題ないからついやってしまうな

985 ：
>>979
すまん間違えた
普通にリテラル内が書き換えられてるって事か

986 ：
>>975
なるほど、first側にatomかpairかのフラグを入れて、実際のリストの構造はsecond側に入れればいいのか。
ありがとう、この線でやってみる。

987 ：
mapcarしてremove-if #'nullするのと、
mapcan使うのとどっちがおすすめなん。

988 ：
>>987
filter 的な話？こういう
(mapcan #'(lambda (x) (and (numberp x) (list x)))
'(a 1 b c 3 4 d 5))
=> (1 3 4 5)

上の例は CLHS からの引用だけど (http://www.lispworks.com/documentation/HyperSpec/Body/f_mapc_.htm)
そこで 「mapcan を使った idiom」とか言ってるから、 mapcan でいいんじゃないの。

989 ：
>>982
:key を持つのは sequence か cons を扱う関数/マクロだけみたい。
max は数を扱う関数だから :key がない、くらいの理由なのではと予想。

で、僕だったらそういう状況は loop ~ maximize で書いちゃうな:

(loop with list = '((1 a) (100 b) (5 c))
for i in list
maximize (car i))

990 ：
1の関連スレっているの？
どこもレス皆無なんだけど。

ここらへんは辛うじて今年レスがある。
【Lisp】プログラミング言語 Clojure #4【JVM】 [無断転載禁止]©2ch.sc
http://mevius.2ch.sc/test/read.cgi/tech/1483498849/
【GNU】Emacs Lisp 【Elisp】
http://mevius.2ch.sc/test/read.cgi/tech/1382223056/

991 ：
Lisp系だからってひとまとめにするには違いが大きすぎるし、
ちょっとしたことならともかく、
入り組んだ事柄を話すにはやっぱり専門のスレがよさそうな気もするし、

それぞれの言語でコミュニティがあるから、
2ch は雑談程度って割り切ってもいいのかもしれないとも思うし…。

992 ：
Maxima以外に実用出来るオープンソースの数式処理システムを知らないのだけど
Common Lispが優秀過ぎるからmaximaしかないのか
自分の知らない数式処理システムが他にあるのか

993 ：
>>992
俺が知ってるのだとこういうのもある。

http://www.math.kobe-u.ac.jp/Asir/asir-ja.html
https://www.gap-system.org/

貢献する人が多いと良くなっていくのは当然だし、
良くなるとまた人が集まってくるというスパイラルが出来るので、
一度人気が出るとあえて他の不人気のプロジェクトに手を出そうという人は
現れにくいんじゃない？

まあ、数式処理と一言で言っても数学の分野は広大だから、
今までコンピュータで扱えなかった分野のためのソフトが新たに出てくることだってあるだろうし、
ちょっと別の分野用の数式処理ソフトを探したら案外たくさんあるかもしれないぞ。

994 ：
>>991
ええ……

Lispでスレ分割なんかしたら
過疎って仕様がないぞ
現に今過疎ってるのにもっと過疎る

995 ：
んじゃ関連サイトは過去スレを除きとりあえず残すけどええんか？

996 ：2018/07/14
Emacs Lispは毛色が違う気がする

疑似乱数２
推薦図書/必読書のためのスレッド 83
【マウスだけで】Scratch【プログラミング】その1
NullPointerExceptionを「ぬるぽ」と呼ぶスレ6
Visual Studio 2013 SP8
Java 高速GUI SWT　3
【魔法】リリカル☆Lisp【言語】
【Alloy】形式言語による仕様記述【VDM】
C++相談室 part150
ネットワークプログラミング相談室 Port30
--------------------
【どろろ】百多/主従 カプ・信者アンチスレ
【EA】 NHL シリーズ総合 【アイスホッケー】 Part.2
馬具について語ろう
【2019】MotoGP総合 466周目【スペイン】
【ライバルに】オフトレ！【差をつけろ】
【眞子様】小室圭氏　61【婚約延期！】
【護憲派集会】枝野代表「そもそも単純な多数決が民主主義なんでしょうか。正義なんでしょうか。」演説★2
レチノール化粧品総合
ワインは必然ボルドー赤に行き着く
就職したくない俺が親のすねをかじるのをやめるスレ
19卒就活生だけど，就活のことについて書きたい
●新宿ﾙﾐﾈ1地下2階の東京ﾙｰ●
サニーデイ・サービス 22
ハイレゾ時事スレ2
珈琲Part.159
【NIA】Scanner[Redacted] (Ingress Prime) LVL7
駅名しりとり 169
民進党が分裂 赤松グループと旧維新、前原玉木が離反 グループ離脱 党内内ゲバ
◆◆歴史難民版(仮)雑談スレ◆◆
映画詳しいモメンおる？夏の少年時代を思い出せてなんか懐かしい気持ちになれる恋愛要素含まない邦画ない？ [813035252]
TOP カテ一覧 スレ一覧 100～終まで 2ch元 削除依頼