Lisp Scheme Part40 [転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
miniKanrenの日本語解説本
誰も書かないなら個人出版で出しちゃうぞ >>304
サンプルの範囲では
「○○が出来ます」＋コードサンプル
で１㌻
それが延々続いてた
目次見るとそこそこ解説もコードも書かなきゃいけなさそうなことも取り扱っているはずなんだが 自分もサンプル版を読んでみたけど、言語の解説という雰囲気ではなく、自分の勉強した内容を箇条書きっぽく書いてあるように感じた。
サンプルは最初の方しか読めないから、LISPそのものの説明のところだけしか読めてないけど、後半の応用部分は面白くなる可能性はあるかもしれないな。
英語学習法の部分については、
http://primitive-lisp.blog.so-net.ne.jp
独学でこのくらい書けるようになるのであればスゴイと思うし、ブログを日本から発信するのには十分かと。
でもネイティブの人はカタコトのように感じるレベル。 英語学習法の部分はサンプルに入ってないので、自分テキトーなことを言ってるぜ！？ Deep Learningの人達はpythonフレームワークを乱立させてるけどlispのマクロ下位互換マクロ作ってるだけなのにいつ気がつくんだろ。lisp使えばフレームワークとかそもそも必要ないのに フレームワークを乱立させやすい言語は流行る
Lispもそうだった Theanoとかlispで書き直したらかなりスッキリするのに
ごちゃごちゃしすぎ 他人の書いたpythonコードを解析しないといけなくなって
「めんどくさい
何でLispで書かないんだ
解析させられる俺の身にもなれ
Lispなら長さが半分以下の読みやすいコードになるのに」
という感情がとても高まってきている お前が書いたlispのコードの方がもっとひどいんだがｗ windows内蔵言語のvbscriptでschemeモドキを作ろうと目論んでる
つってもちゃんとやるのはマクロと末尾再帰だけでね
variant型使ったリスト処理がどんだけ遅くなるか見ものだ 100Gぐらいのメモリーに入りきらないデータを扱う時にpythonではジェネレター式というのを使うけどschemeやlispではどういうふうにするの？ 典型的なのはストリーム (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
単なるバイト列やテキストであればカスタムポートも使いやすいと思う。 https://github.com/dherman/c.rkt
これでC言語のプログラムを自由に加工したりできるっぽいのだけど
ドキュメントらしきものがない
誰かexample usageみたいなものどこかにないか知りませんか？
使えればかなり便利そうなんだけど >>320
拡張子が scrbl のファイルはドキュメントだぞ。
Scribble で html などに変換できるはず。 >>324
いや違うと思う。CLって多分思考（若しくは試行）ツールなんだと思うよ
俺が使いこなせないのは普段から抽象を扱ったりしてないから 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を手元に置いていますがよく読めてません
よろしくお願いいたします >>328
if のときじゃなくて cond のときはどうでしょうか？ >>329
condはifとbeginに置き換えられる
condをマクロとして実装してる処理系は多い
まず処理系のソースを見てごらんよ
(cond (test1 body1) (test2 body2) (else bodyn))は
(if test1 (begin body1) (if test2 (begin body2) (begin bodye)))
に一旦展開された後で項書き換えとかコンパイルとかされる
要するにcondのbody節は複文相当で最後の式の値が全体の式の値になる
構文が判らないレベルなら教科書は一旦捨てて処理系のソース読んだ方が早い ちなみにschemeはマクロを除いて基本構文は5つしか必要ない
define lambda set! if beginだったかな？
でも厳密にはquote関係も数に入れると10個ぐらいかもしれない
それ以外は全て上の5構文を組み合わせたマクロとして定義できる
つまり上の5構文だけマスターしとけばよい
例えばletがマクロなら(let((var value)) ～)は((lambda(var) ～)value)
のように意味を全く違えずに置き換えられる
残りのマクロも同様に基本構文への展開形を連想できるようになれば
schemeの基本はマスターしたと思ってよい
ただし肝心のschemeのマクロの定義は手段が沢山あってカオスなので
schemeマクロの闇については自分で調べて下さい
gaucheなら大きく分けて2つだろうけど 最近の Gauche には explicit renaming マクロ変換器が入ってるよ。 ノートぱちょこん買い替える非業界人なんだけど、最近話題沸騰中の
LispとSchemeにちょっと興味があって。やっぱりマックにしたほうが
幸せになれるんでせうか？それとも、今までのぱちょこんをLinixに
したほうがいいのかな？ >>333
LispとSchemeで遊びたいならWindowsでもMacでも好きな方買って大丈夫
WindowsならWindowsに適したものが、MacだとUnix処理系から普通にって感じで入れられるよ。 Gauche で OpenGL 使うときは Windows の方がよい メモリを多めに積んだやつに VMware なり Virtual PC なりの仮想化ソフトを入れて使い分ければいいよ。 レスありがとうございます。質問者です。
やっぱりマックがいいという意見が多いみたいですね。
そろそろ新型出るという噂もあるようなので様子見て買ってみたいです。
LinuxはArchってのがいいんですかね？
昔のスラックウェアみたいなかんじなのかな。古いPCでも遊べそうですね。 はじめてのLisp関数型プログラミング――ラムダ計算からリファクタリングまで一気にわかる (Software Design plus) 五味 弘
ていう本が出てるけど、これはISLispなの？CL？ >>344に限らず本スレの皆様への質問とお願い
> これはISLispなの？CL？
そもそもISLispを主たる対象とした日本語で書かれた本（言語仕様の詳解中心でもプログラミング中心でもどちらでも可）って
（個人や大学・研究所などのWebサイトにPDFファイル等の形でアップされているとかでなく印刷され商業的に通常の書店で
購入可能な形で販売されているという意味で）出版されているのですか？
日本語でLispの本というとSchemeかCLかしか存在しない（英語圏でも状況は変わらない）と個人的には思っていたのですが？
日本語に限らず英語でも構わないのでISLispを主題とした書籍をご存知でしたら教えて下さい ISLisp は、Lisp言語のISO標準であり、1997年にISO規格が制定されました。
ISLispは、業界標準となっていたCommon Lisp の言語仕様の巨大さに対して、
処理系の効率と学習・利用の容易さを向上するために, Common Lispを継承
しつつ EuLisp, Le Lisp, Scheme を参考としてコンパクトで一貫性のある
言語を目標に 開発されました。
とあるけど、そういえばISLispの本って見たことないかも。 ISLisp、惹句はいいんだど、いかんせんまともな実装が無いのがな。 著者「関数型おしえます！」(お？どれどれ)
著者「Lisp最高です！」(あ、うん)
著者「…islispﾃﾞｽ…」(は？！なにそれ？伊豆lisp?)
ブロガーA「良著なのでコードをschemeで書きなおしました」(いいねえ)
ブロガーB「haskellでかきました」(うおおおおおおお！！！！！)
という反応になるよね。一般的には。
common lispかschemeで書き直したものをHPにアップすべきだと思う。 せめて伊豆用slimeぐらい用意しないと女子高生には読んでもらえないと思うんだ はじめてのLisp関数型プログラミング、昨日買ったばかりなんだけど
ハズレ感が半端ない ISLisp でggrと「ISLISPを使うべきでないたった1つの理由」がトップに並ぶ哀しさよ サンプルプログラムダウンロードしてみればわかるのでは。 最近は、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のテンプレートエンジンの置き換えからだそうで。 clojure が lisp方言として紹介されてると違和感がある >>356
すまぬが理由がわからないのでkwsk解説を求む >>357
・特に [ ] のあたりの文法が違うのでLispの資産を移行できないから
・Lisp の ( ) の対応に慣れた人には、罠のようにはりめくらされた文法不一致があるから
・S式だけで構成できないから
・再帰末尾最適化に制限があるから >>358
1の[]に関しちゃ大昔のスーパー閉じ括弧の存在を忘れてもらっては困ると思うしschemeの一部処理系も括弧の代わりに表現力の強調で括弧と同等に扱う等に導入してるからそこまで嫌わんでもと思う
2の部分は許容してもらうしかないんじゃないのかなぁ、まぁ否定はしない
3は1と2の事だよね？
4はLispというよりscheme好きの人なら反発するのとてもよくわかる。(jvm側の問題でもあるけど)
[]に関しちゃむしろ良く出来てると思うのだよね、3が許せないとどうしようもないけど。
リーダーマクロが普通に扱えないって言う意味で怒ってるのかと思ったのでちょっとびっくりしました。>>358 >>358
> ・再帰末尾最適化に制限があるから
「再帰末尾」じゃなくて「末尾再帰」
元の英語は "tail recursion" > ISLisp でggrと「ISLISPを使うべきでないたった1つの理由」がトップに並ぶ哀しさよ
これ根本的に間違えてんね．ユーザーいないし訂正する人もいないからこのページが消滅するとよいね >>361
ちょうど、昨日、そのページ読んだばかりだった。
どこらへんが間違ってるの？ > 「実行時情報」が使えないということは，つまり，自分で定義した関数によるマクロの展開は行えない，ということです．
ココ。つまりこのページの主張全部 仕様から関連しそうな箇所を抜き出してみた。
> 4.8 定義演算子
> 定義形式によって定義される名前は、最上位有効範囲全体で使うことができるが、
> ISLISP テキスト単位における実行準備された最上位形式は、左から右に順に実行される。
> (略)
> (defun function-name lambdaform*) → <symbol>
>
> defun 形式は、 function-name を、関数名前空間の識別子として定義する。 function-name は、 (lambda
> lambda-list form*) と等価な関数オブジェクトに束縛される。
> 8. マクロ
> (略)
> マクロは、実行準備時に展開される。 いかなる実行時情報も使えない。使用可能な操作は、単純なデー
> タ構造の生成及び処理に制限される。すなわち、（端末への入出力のような) 環境への副作用、(記号の属
> 性リストの変更のような)外部的にアクセスできるデータ構造への副作用、及びマクロ形式自身への副作用
> を起こす操作は禁止する。
「4.6 評価モデル」も関連するけど長くなるので要約。
・ まず実行準備される
・ 実行準備が完了してから実行される
・ 実行準備完了時点でマクロ展開は終わっている
・ 実行準備のための処理は処理系依存
断言できるほどはっきりしてないけど、関数の定義名はマクロ展開時にも見えてて、
関数名と関数オブジェクトを結びつけるのは「実行」だと解釈するのが妥当だと思う。
マクロ定義中にユーザー定義関数を使えないとする解釈を私も支持する。
ただ、全体を通して見ると副作用のない (プログラマが定義した関数を含む) 関数なら使えると想定しているっぽい雰囲気
はあるような気がする。 >>364,365,366
みなさん情報ありがとう。
ISLISPの日本語の仕様書はどこかなと思ったら、ここにあった。
http://www.jisc.go.jp/app/pager?id=1759608
ダウンロードしての閲覧禁止って。変な制限かけてるなぁ。 >>367
その URL では見れないよ。
URL 中の番号はあなたがアクセスしたときのセッション番号。
文書に固有の番号ではないので、パームリンクとして使えない。
ダウンロード禁止なだけじゃなく、たぶんサーチンエンジンのクロールも避けてるんだと思う。 表示中オフラインにするとpdf中のjsに怒られたような記憶がある 買ってもらってるから、不公平って話だと思われる。
紙も実費で配れる財源あるといいんだけどね。
isoは販売になってるけど、他団体と共同でたまに公開されてるのがある。
草稿は公開してるところもある。 isoやansiよりはjisの方がweb公開進んでるのだけど、
ecmaならecmascript(js)やclr(.net)みたいに公開されるのか。 日本の法律だと JIS 規格に著作権が認められるかどうかははっきりしない。
総合的には認められないとする説の方が有力らしいんだが、
ISO は規格の著作権を主張してるからそれに加盟してる JISC も倣うしかなくて、
間をとって閲覧だけは無料という曖昧なところでぼやかしてるらしい。 工業規格は事実上の業界標準を後追いで規格化したのがほとんどだから、著作権どころか特許が生きてるのが混じってるので注意が必要 > 366
> 断言できるほどはっきりしてないけど、関数の定義名はマクロ展開時にも見えてて、関数名と関数オブジェクトを結びつけるのは「実行」だと解釈するのが妥当だと思う。
入手できたISLISP Working Draft 23.0をベースにして述べるが，その理屈だと備え付けの関数も展開には使えないように思える．
備え付け関数もユーザ定義の関数もpreparation for executionの間に実行可能という記述はない．
不可能という記述もない．(定義はしないとある)
仮にユーザ定義の関数は使えないとしよう．
ローカル関数 (flet labels)が，defmacro 内で使えないようには見えないのでこれで対処できる．
また，マクロは使用場所に先行して定義があることが必須とあるということは，ユーザ定義のマクロは使えるように見えるので，補助関数の所を補助マクロとするのも良いだろう．
CommonLispでもマクロ展開の補助でユーザー定義関数の利用は必須ではないし，利用するには評価フェイズを合せなくちゃならない問題がある．(ISLISPはこれを回避したのかもしれない)
これをもって「ISLISPを使うべきでない」とするのは誇張が過ぎるし，真に受ける者が出るとしたら害悪だろう． そのページの害悪よりも、isLispの素晴らしさが伝わるようなページが
検索トップに来ないことの方がずっと問題だと思うけど >>376
「実行準備」「実行」の繰り返しがどういう単位なのかっていう、フェイズの分離の仕方の問題だよな。
ひとつの式ごとなのかプログラム全体にわたってなのかでも解釈が違ってくる。
まあ最大限に安全な方向に見積もって未定義だと解釈しても、
それで ISLISP の有用性が全部失われるわけではないということには賛成できる。
あの記事はよくある誇張した煽り記事だろ。 センセーショナルなタイトルをつけてるだけで大したこと言ってない。
しょうもない記事が上位にきてしまう程度に ISLISP に関する記事が少ないってだけ。 ISLispを普及させるために必要な10のこと
・ISLispBoxを無償提供する
・ISLisp Hyperspecを無償提供する
・SICPをISLispで書き換える
・On ISLisp、Little ISLisper、Land of ISLispを出す
・ISLisp for Dummies、すごいISLisp楽しく学ぼう！も
・WhyのISLisp感動的ガイドを公開する 他の実装へのトランスレータがあれば普及させる必要はない >Lispを普及させるために必要なこと
括弧が少ない言語の方が好まれる傾向にある
よって括弧が一切存在しないLispが誕生すれば爆発的に普及するだろう 今年のscheme workshopは日本
いつもwebdbfと重なって行けなかったが今年は行けそう 言語で使う括弧の量と、括弧打つのが面倒な場面の数ってあんま関係ないよね。
括弧使う言語を書いてるときに面倒なのは、今書いた式を引数にして別の関数を更に適用しようかとかなったときに、
後に閉じ括弧つけてカーソル前に戻して関数名書いて括弧つけて、ってやるときがほとんどなんだけど、
例: foo(x,y)_ → bar(_foo(x,y)) # "_"はそのときのカーソルの位置
Emacsなら一発で飛べる分、むしろLispの方が楽なときがある。
そういう意味だとOCamlの foo x y _ → foo x y |> bar_ は便利だった。 Lispが普及しないのはEmacsで開発するのが当たり前ってところでしょ？それじゃ新規は増えないよ。 それはいいんだよ
CLやscheme, Racketに比べてISLISPが普及してないのはもったいないよね
という話 >>385
F#はVisual Studioだけど普及してないし >>387
F#は好きな言語ではあるが、C#と比べるとVSの動作が重くてしんどいよ。
型推論が遅いのか構文解析が面倒なのか、自動でエラー箇所表示させると凄く反応が悪くなる。
FParsecとか関数型言語ならではの便利ライブラリ使うとより顕著に。
ISLispはロクな実装無いし真面目に使っている人がいないから、どこが便利でどこに課題があるかも分からんのがね。 >>387
なら開発環境と言語の両方に魅力がないとダメってことじゃない？ smalltalkは普及してないけど、objective-cは普及した
つまり、Lispを普及するには中間言語をcにして、、、 そういえばsqueakがレイヤごとに言語変えるとかどっかでチラと読んだような気がする >>390
Objective-Cは絶滅危惧種だったがジョブズのおかげで生き延びた 最も愛されているプログラミング言語や技術
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/
だそうです >>393
愛人にしても本妻には決してしたくない言語だね Rustは好き。C/C++が引き受ける低レベルな領域に型システムの安全性と利便性を突っ込んでみたっていう発想は良い。
けど、コンパイル時間がコード量から予測しづらい(イテレータやジェネリクスを使ってると特に)のと、
莫大なライブラリを資産に持つC/C++と比べたときの実用性の差を考えると、
潤沢な計算資源があって、比較的優秀な人材が揃えられるところ向け。
Schemeのような、スタンドプレーの生産性を莫大に高める言語じゃあないと思う。 俺もRust好きだな、ただObjective-Cみたいに言語のはらわたまで触れる(smalltalk由来の部分ね)緩さをもった言語も大好きなんだよな
あとはClojureが好き、これはWebアプリ書いてるとき限定だけど。
LispスレなのにLisp系がClojureとかでスマヌ Lisp系言語のネックは言語実装じゃなくて実行環境だと思う >>397
マルチプラットフォームでコンパイラで実行バイナリも吐けるし何が問題? >>398
「Common Lisp なら問題なく安定して高速な実行バイナリを吐ける」 という前提が必要かと マルチプラットフォームとかより.NET Frameworkとか使えるかが問題 Hyper Specが日本語に翻訳されたら増えるかもね。
日本語の情報が少なすぎだよ。 Racketからpython使うだいぶ楽になったけど、逆はどうすればいいんだ？ Deep Learningライブラリkeras
がニューラルネットワークのグラフ処理と数式処理を組み合わせた
ちょっと気の利いた自動処理をやってくれてたんだけど，バグだらけで
pyrhonで数式処理やるの無茶だしこんなものだろうと思ってたら
最新版で気の利いたグラフ処理を全部削除してきた
数式処理をLisp以外でやるのは，やっぱり無理だったんだな ■ このスレッドは過去ログ倉庫に格納されています
