Lisp Scheme Part40 [転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
教祖が思いつきで適当こいたことを信者が一生懸命意味づけしてるみたい PGは経済的な感覚はするどいと思う
プログラマとして、言語設計者としてはどうかと思う グレアムは現実寄りの感覚を持っていると思う。
言語設計者が陥りがちな罠として一貫性とか対称性とかを過度に重視してしまうことがあるんだけど、
グレアムの場合は逆に「汚くてもこの方が効率的だ」と言えちゃうところがある。
それはそれでプログラマ、言語設計者に必要な資質だと思う。 >>70
教祖様べったりか。おまえ、自分の頭で考えたか? 意味わからんだろうから少しだけ説明してやるか
おまえの評価は彼の主張内容への批判にまるでなっていない。彼という人物そのものの評価をしているだけだ。
比較して
>>69は、彼の考え方なり特性についての評価であるから問題はない
>>67
これでも恥じ入らないなら終わってるから底辺でウジウジしてろ グラハム師は絵かきでもあるんだが?
尊師、いやセンスも抜群であるぞよ? ちょっと見ないうちに発展してるんだな
ChickenなんてPython並みにライブラリ充実してるやん ☆ 日本の核武装は絶対に必須ですわ。☆
http://www.soumu.go.jp/senkyo/kokumin_touhyou/index.html
☆ 日本国民の皆様方、2016年7月の『第24回 参議院選挙』で、改憲の参議院議員が
3分の2以上を超えると日本国憲法の改正です。皆様方、必ず投票に自ら足を運んでください。
私たちの日本国憲法を絶対に改正しましょう。☆ >>77
某大統領はツーマンルールの束縛をも離れ自由に核を行使することができるようになるのですね pythonのdoctestに相当するものって
schemeの実装でもってる処理系ってありますか? SICPは糞訳だから難しいだけで
普通の入門書やで 学生がはじめて触るプログラミング言語としてschemを想定している時点で普通ではない 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版買いましたが
もうムリポ >>84
以前お試し版でどうにもならなかったので価格に見合わんと思って捨て置いたのだけど
LispWorksのIDE日本語まともに動くようになりました?(UIで使うのよ) >>85
Windows版しかわからないけど、LispWorks 6.1あたりから日本語は問題なくなってるよ。
インライン入力、日本語フォントの表示など。
ただ、Shell Panelについては相変わらず文字化けするね。
(前から要望は出してたけど結局対応されてない。) https://github.com/pedropramos/PyonR
Racketとpythonの混合できるって聞いて動かそうとしてるんだけど
Gentoo Linuxだと動いてくれない
ひょっとしてWindowsでしか動かなかったりします? >>86
>ただ、Shell Panelについては相変わらず文字化けするね
まだ多国語対応未対応な箇所あるのか orz
LispWorksはVSと値段かわらんから購入候補になるんで頑張って欲しいんだが。(DB必須なので必要なのはEnterprize版)
Franzは良いとは見聞きして知ってるけど零細企業で買うのは開発に必要なライセンスは2か3でなんとかなっても再配布ライセンスがちょっと躊躇する(値段が見えないので銀座の寿司屋な気分だ) きちんとしたサポート込みで、個別の相談にもかなり乗ってくれるらしいからなぁ。
処理系の値段つーより、ある種のコンサルみたいなもんなんじゃね。
用途を説明して概算を聞いてみてもいいと思うよ。 issueとpull reqみると、osxは分からんってかいてあるけど、
作者がどの環境で動かしてるかよくわからないね。 >>87
Gentoo Linuxだけど動いたよ
動かないってのは具体的にどんな状況? >>91
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 >>92
そのエラーメッセージに解決法書いてあるよ
> 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
以下略 最近流行のdeep learningだけどlispと組み合わせて何かやった研究とかないのでしょうか 型つき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
訂正
もし、全ての関数を評価せずに
もし、全ての引数を評価せずに ■ このスレッドは過去ログ倉庫に格納されています