Lisp Scheme Part40 [転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
型つきschemeで一番まともなのはbiglooぽいけど ライブラリが一番充実してるのはracketぽい Racketのパッケージをbiglooで動かせないものか 他人の作ったJavaプログラムのバグをとりつつ 自分の使いたい機能を追加したりするなら Scala Clojure どっちがおすすめ? Javaとの融合はScalaが上っぽいけどLispになれてるのでLispの方がいい >>98 Lisp慣れしてない自分でもClojureに楽しくはまったのでClojureを押してみるなり JVM用言語で最も短いコードで最良の結果だす言語の一つだと感じる >>98 後者。 Leiningen の checkout dependency が便利すぎてはげる モナドのちゃんとした定義ってあるの? 言語ごとに定義が違う気がするんだけど 関数型言語「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などの支援を受けている。 >>104 記事読んだけど、マルチパラダイム言語って誰が言い始めたんだろ そもそもシングルパラダイム(原理主義)な言語なんて非実用的なものの対義語なんか冠にしても意味ないと思う typed-racketが変なバグ起こさなくなったの? 安心して使えるようになったのなら使ってみようかな Clojureと同じ文法でC++もwrapしようとしてるプロジェクトを 2つぐらいみつけたんだが2年ぐらい更新がない JavaからC++の変換はそんな難しくないはずなんだけど 何か違う理由で頓挫してるんだろうか >>108 (その人達に必要な機能は)完成したからではなかろうか 試しに実装してみたぐらいの気がする。 継続して使うのに作ったかは分からない。 型付きといえばshenも、18.1で型チェックが速くなったらしい。 ソースみたら、該当箇所の型が総称型に変わってた。 http://www.shenlanguage.org CL (というより動的型の言語) は LLVM の抽象度では上手く扱えないしたいして最適化できないという話もある。 GC の性能にも強く左右されるし、 LLVM よりも JVM の方が CL とは相性よさそうな気がする。 昔,kawaからJavaを使おうとして非常に苦労した記憶が ABCLならだいぶ楽にJavaが使えるのだろうか Clojureは最初は楽だけどJavaのパッケージマネージャで苦労するね >>116 Java のパッケージマネージャって Clojure 書くのに Maven とか Gradle でも使ってるの? 一時期Clojureが過剰に持ち上げられていたけど まったく流行らずに終わったな clojure は、lispの対抗馬とか思ってると、 repl 起動するまでにブチ切れると思う やもえずJavaのウンコなプログラムのメンテしないといけない場合に Clojureは便利だった そういう制約ないならRacketが一番 srfiがみんな使える上に pythonとも連携できる jythonみたいにnumpyが動かないとかもない >>124 ありがとう pythonライブラリを透過的に使えるなら便利そうだね 自前でサーバー立てるなら何でもありだけど、実際PaaSのほとんどがJVM前提だからね Javaでプログラム書く人達はユニットテストという概念がないらしく csvに結果を書き出してエクセルで手作業テストを行うという謎慣習があるようだ こういう人達の書いたJavaコードと付き合わざる得ない環境ではClojureは便利 eclipseからJUnit使ってみるとわかるけど エクセルの方が楽 >>129 むしろ、java以外のユニットテストツールを使ったことがない >強力なマクロシステムが特徴で、マクロを使って言語機能を拡張でき このLISP系でよく言われる「言語機能の拡張」って全然的を射てねーなと思う 例えばschemeのファーストクラスオブジェクト(FCO)としての継続って 言語プリミティブとしてFSO継続相当を始めから持ってない限りはどうやっても 拡張で得ることはできないし FCOとしての継続の無い言語から有る言語へ言語機能を拡張するってことは つまり新規にFCO継続付き言語を作るって事に他ならない できることは結局言語に既にある機能の延長上の事だけで 言語拡張なんて大それた事は他の言語同様できやしない 「子供騙しですけど強力なマクロシステムで俺構文糖衣が簡単に作れますんで・・・」 とちゃんと書き直した方がいいね! 「プラグインモジュールを使うと言語機能を拡張できます」とかで売った方がまだ納得できると 思わないかね君たち >>133 ていうか頭悪いと思います 「言語拡張」の俺的意味からの演繹をしてるだけ マクロ展開時になんでもできるのに何で制限があると思うんだ? >>133 みたいな勉強不足の人に黒板先生は本当に便利だ 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 の評論をとうとうとやるわけです。 >>133 マクロは任意の構文木から任意の構文木への変換であって どんなプリミティブが用意されるかは言語の戦略で決まること レイヤーの違うことを関連付けて語るのはやめてちょうだい >>140 その理屈でいくなら、CommonLisp も Lisp ではありませんね >>143 Lisp と CommonLisp を混同しながら、Scheme はLisp ではないと主張ている人の意見はほどほどにして聞きましょう >>144 自身のLispの定義を明らかにせずにCommon Lispは違うって言われましてもw でもCommon LispがLispでないんなら、なおさらSchemeでLispを代表させるような論が成立しないのは同意できるんでないの >>145 まず、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と呼ぶべきだと思います >>140 このKURODA Hisaoって人が書いてる他のページも見たが Abstract Syntaxの概念やこれを設定する意義を理解できない人がSemanticsについて語っても全く説得力がないね それにSchemeの単一name space批判を自然言語での文脈依存性を持ち出してるが 自然言語の柔軟さというかいい加減さを至上の価値とするのならば所詮は知性ゼロ・常識ゼロのコンパイラやインタプリタですら処理できちゃう 普通のプログラミング言語なんてどれも失格、もちろんCommon Lispもね 理論や論理学について良く判っていない人間ほどFregeみたいな「計算機と深い関係があると世間で言われている」哲学者の名前を出したがる わりと どうでもいいよね〜 ね〜♪ _ ‐..::  ̄ ̄ ::::... 、 . ィ r'::/ ::ィ:::::::::::j:::::::ヽ::::\ ,._.._ .......、._ _ /:/l! | ::|::/ |::::::::∧:::レ::l:::| :::::rヘ ヽ :~""''.>゙' "~ ,、、''‐'、| l ::仏_ノヘ:/ ー- ハ:::!::::::|::::i ゙、'、::::::ノ:::::::_,.-=. _〜:、 /::::リy=ミ ' ィ=ミ /:::::!::::/:::::! ``、/:::::::::__....,._ `゙'Y' _.ェ-、..._ |::::{xx xx/::::::「)'|:::::::| ,.--l‐''"~..-_'.x-='"゙ー 、`'-、 lハ:仆 ..._ヽフ /:::: /´ |:::::::| " .!-'",/ `'-‐'') /\ ` Y::::ソ勺 7イV_ !:::::::! .-''~ >'゙:: ‐'"゙./ ヽ. __ |::/ 爻___ん'´ッ'⌒ヽ! :::::! //::::: ', (__,、\/ /‐―一弋{、 /  ̄_) ' /::::: .:'; \ ' { :::\ /~::! 確かに言語拡張でarduinoと連携してドローンを自動航行できますとか言えた方がかっこいいよな 方言作れるとか書かれてもLisp界隈の事情知らん人間にゃ意味不明だし >>151 バインディング書けば言語に関係なく出来るだろ。 その手のライブラリがたくさんあるとか、 コマンドひとつで導入できるエコシステムがあるとかならアピールポイントになるとは思うけど。 言語は大きい会社や団体が開発してることがほとんど。なので妙な政治意図で故意に機能が削られたりが良くある。マクロありとこういうのは無視出来る。だいたいは誰かが便利なマクロを公開してくれる だって、>133の言い掛かりと言語レベルでの継続の必要性とは、まるで関係がないんだものw フル継続の後付けが難しいのは事実だろ。 cl-cont も Scheme に比べればモドキに過ぎないしな。 そんでもって >>133 は継続は例に出しただけで、 マクロによる拡張が容易であっても言語が持つべきプリミティブの選択が重要だってことじゃないのか? 長々書いてるけどマクロでシンタックスを拡張できてもセマンティクスは変えられないってこと? そりゃそうなんじゃない?この手の話の根はチューリング完全話と一緒だよね 機能拡張という言葉はセマンティクス拡張と同義ではないよなあ それはもう見ているものがLispのマクロによる拡張性ではなくなっている 言語の意味論とシンタクス拡張はレイヤが違う話だよ。 DSL は言語の意味論を変えはしないけど系を作ることは出来る。 物理法則は変えられないけど、物理法則の範囲内でサッカーのルールを定義したとして、それが無意味って言えるか? 上の方の人と偶然被ってるけど、質問。 schemeのdefine-syntaxって何ですか? defineじゃダメなの? Scheme のマクロは式の評価の前に展開される。 ものすごく単純化して説明すると処理されるタイミングが違うの。 >>161 マクロなら可能だがdefineでは定義不可能なケースを上げておく defineで定義された関数(procedure)の適用では、まず全ての引数が評価されてからその結果が関数bodyに渡されて関数の結果が決まる。 もし、全ての関数を評価せずに前から必要な分だけ評価する関数を書きたい場合、defineでは無理。その場合はdefineは-syntaxなどをつかってマクロを定義することになる。 マクロは >>162 が述べているように第一段階としてSchemeのS式を生成し、第二段階でその生成されたS式を評価するわけだが、第一段階ではマクロの引数は評価されない点が重要。 それによって、defieとは異なり一部の引数をのみ評価することが可能となる。 or関数はその一例だな もしdefineでmy_orを定義しようとすると全ての引数を評価するという無駄な関数となるわけだ。 もしaがtrueなら (or a b c d e)でb以下は評価不要 が(define my_or ……)とすると aからeまでを必ず評価してしまう >>163 補足 だからmy_orはマクロで定義するというわけな どうだ? チンコそそり立つほどわかったか? >>163 訂正 もし、全ての関数を評価せずに もし、全ての引数を評価せずに >>162 でスゲーわかった気になったのに、>>163-164 で全然わからなくなりました。 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 >>166 試した処理系は何? それは仕様上未定義だよ。 期待した動作をするように見えてもただの偶然。 全部(lambda()〜)で囲って遅延評価すればなんでもできるよ SICPでマクロが無くても問題なかったのはこのおかげ >>167 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はそうしてるから>>166 で動いてる?) >>169 構文は第一級ではない。 (実行時に値として扱える存在ではない。) 「マクロ展開フェイズ」が完了してから「式の評価」を開始するので、実行時に束縛するのでは遅すぎるんだよ。 式ひとつごとに「展開」「評価」をする処理系でフェイズの分離を有耶無耶にしている処理系だと区別を曖昧にしてもなんとかなるのかもしれないが…… それは実装方針のひとつとしてそういうのもありえる、可能というだけ。 >>170 >構文は第一級ではない。 (実行時に値として扱える存在ではない。) なるほど、疑問氷解です。 .oO( The Little Prover を読んだ香具師がスレの流れを作ってくれる予感 ) なぜ自由なlispより不自由なjavascriptが流行ったのか ウェブブラウザから使えるのが lisp だったら流行ったんじゃないの? とはいえそこに lisp が採用されない理由も結局は一緒か。 IE4やNN4で実装されたスクリプト言語がLISP系だったら… 少なくともfirefoxのnoscriptアドオンは不要だったろうな 逆に考えるんだ、 「lisp でWebブラウザを作ればいいや」 と考えるんだ WebAssembly が一般的になれば Lisp にもワンチャンあるで Javaがダメ言語とあの時点で判明してればなあ。 当初の予定通りschemeが組み込まれてたに違いない。 emacs で Webブラウジングが出来るんじゃ無かったか。 技術系のドキュメントとかあまり凝った事してないものしかまともに見れんよ。 Emacs に Webkit 載せたりしてるのもあったぞ。 Emacs 側から Webkit をどれくらい操作できるのかは知らんけど。 ブラウザ競争っていかにCSSに意図通り対応してるかの勝負だし サーバサイドならemacsでもjavaでも変わらん いや javascript が動かないと。 ああ、其処を lisp にするって話だったか。 いまだに、javascript が scheme だということについて納得できない 第一級の継続も末尾呼び出しの最適化もないしねぇ 手続きが無条件でクロージャになるってのがまあ当時としては特徴的ではあったけども CLみたいな余計な装飾子が無いところはschemeと考え方が近い 末尾最適化が標準のluaのがよりschemeに近い 継続は第一級にする必要ってあんのかな 使い所が難しいし言語に例外機構が備わってればいらないし jsはライブラリ覚えるだけでもしんどい 今JSがコールバック地獄になってるからこそ継続がほしいんじゃん。フル継続じゃなくて限定継続でもいいから。 javascriptのように通信が頻繁に行われる環境で継続なんか入れたときに、例えば途中でブラウザを切ったときの継続がどうなってるのか考えるとワケ分からなくなる schemeの継続ですら、資源を使いまくってるサーバが落ちたときにリソースのclose操作とかきちんと行われるのか不安になる >>188 jsはクロージャがあるからCPS方式で継続もどきは作れるんじゃないの インスタンスが途切れちゃうなら継続使っても同じだし JavaScript 処理系の Rhino は第一級継続を持ってる。 実在する以上、言語処理系レベルでは可能ってことだろ。 だけど、 Scheme 処理系でも外部のライブラリ (バインディングとか) を通過したところで継続が途切れてしまう制限を持っているものがあることからもわかるように、 継続が処理系の外の世界をまたぐのは難しいんだわ。 (※参考 Gauche のドキュメント http://practical-scheme.net/gauche/man/?l=jp& ;p=call/cc ) JavaScript はアプリケーションに組込んで使うタイプの言語だから、当然、外の世界とのやり取りはあたりまえで、 そこに第一級継続を持ち込んでも途切れまくりであんまり役に立たんのじゃないか? Gauche のドキュメントには限定継続の利用を勧めるようなことも書いてあるけど、 フル継続で途切れてしまうところを越えられるって意味ではなくて、 継続の範囲を明確に書けるから変なところをまたがないように注意しやすいって意味だと思う。 そういやGNU標準言語?だかのはずのguileって使われてるんだろうか ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる