Lisp Scheme Part34

1 名前：デフォルトの名無しさん mailto:sage [2012/01/29(日) 15:37:08.66 ] Common Lisp、SchemeをはじめとするLisp族全般のスレです ■前スレ Lisp Scheme Part33 toro.2ch.net/test/read.cgi/tech/1318150738/ ■テンプレ wiki.fdiary.net/lisp/ ■関連スレ 【入門】Common Lisp その8【質問よろず】 hibari.2ch.net/test/read.cgi/tech/1309940115/ 52 名前：デフォルトの名無しさん mailto:sage [2012/02/06(月) 22:58:30.75 ] c.l.sへの投稿乙。興味持ってくれる人いると良いね。 53 名前：デフォルトの名無しさん mailto:sage [2012/02/06(月) 23:39:04.66 ] >>51 wiki.call-cc.org/eggref/4/stalin The compiler has been tested on Mac OS X 10.4 (ppc) Intel Mac は無理っぽい 54 名前：デフォルトの名無しさん mailto:sage [2012/02/07(火) 00:02:01.12 ] >>52 c.l.sって何の略？ アドレス、教えて。 55 名前：デフォルトの名無しさん mailto:sage [2012/02/07(火) 00:06:42.00 ] ecl 12.2.1が出てたのに今気付いた。 enable-unicodeがデフォになった。 weak-hashが入ってdrakmaが動くようになった。 Archのextraはまだ前のVer。Aurのgit版は--enable-hoehm＝を変更する必要あり。 >>53 Macは持っていないからスマンけど、ビルドが出来るか確認した？ chickenは移植性が高いし、ソースもschemeみたいだけど。 56 名前：デフォルトの名無しさん mailto:sage [2012/02/07(火) 00:08:00.58 ] >>54 横レスだけど、たぶんcomp.lang.scheme。 57 名前：SCHEME餃子 ◆8X2XSCHEME mailto:sage [2012/02/07(火) 00:08:55.44 ] >>54 ニュースグループの comp.lang.scheme のこと。 ネットニュースなので NNTP に対応したクライアントで見るのが本来だが、 サーバが減りまくっていてまともに繋げるところが少ない。 今ではありがたいことに google group 経由で見れる。 https://groups.google.com/group/comp.lang.scheme/topics?hl=ja 58 名前：デフォルトの名無しさん mailto:sage [2012/02/07(火) 00:32:57.33 ] stalin本家も移植性に気を使ってるコードだから、手間をかけずに移植できる気がする。 とはいえ型推論するschemeコンパイラの需要は多大なので期待しております。 59 名前：デフォルトの名無しさん mailto:sage [2012/02/07(火) 01:10:55.72 ] >>53 www.ibm.com/developerworks/jp/opensource/library/itm-progevo4/ StalinはCを介してネイティブコードを出力するのですが、gcc-4系列ではgcc自身の最適化ルーチンが終了しなくなるので、gcc-3系列を用いて処理系をビルドする必要があります。 Intel Macにgcc3は入らない discussions.apple.com/thread.jspa?messageID=6900842 iodonacht.blog90.fc2.com/?mode=m&no=27 60 名前：デフォルトの名無しさん mailto:sage [2012/02/07(火) 01:44:25.43 ] >>56-57 サンクス 61 名前：デフォルトの名無しさん mailto:sage [2012/02/07(火) 02:14:47.49 ] >>59 これかな。 ttp://newsgroups.derkeiler.com/Archive/Comp/comp.lang.scheme/2006-02/msg00002.html 62 名前：デフォルトの名無しさん mailto:sage [2012/02/07(火) 19:59:11.83 ] lispやscheme系で10年後にも開発が継続しているのはどれだろう？ gaucheは中の人が精力的に更新しているけど本人が倒れてしまったらどうなるかわからない 手堅いのはchickenやracketあたりか 63 名前：デフォルトの名無しさん mailto:sage [2012/02/07(火) 20:22:42.28 ] それはわからないよ。 Gauche は確かに shiro さんが今のところはほぼ全てを支配しているけど、 拡張パッケージを見ると Gauche の内部構造を良く理解していないと 実現できないものとかもあったりするので、そんな人たちならいつでも 開発を引き継げると思う。 ある程度大きな開発コミュニティがあるものも、それはそれで分岐したり なんなりがありうるから現状の体制のまま 10 年後もあるかっていうと疑問だな。 統計的には、今まで長く続いているものはこれからも長く続く可能性が高いけど。 64 名前：デフォルトの名無しさん mailto:sage [2012/02/07(火) 20:25:29.85 ] gaucheはソースが綺麗だから引き継ぐ人が出易いと思う。 R7RSが決まればscheme処理系毎の差異も小さくなるだろうし、そんなに心配はしてない。 racketは独自路線すぎてついていけない。 型推論するR5RS compilerが欲しいなー（チラッ R7RSといえばsyntax-caseだけは嫌なので、explicit renamingが採用されて欲しいな。R6RSがあんな美しくないミニ言語を入れた理由が分からない。 65 名前：デフォルトの名無しさん mailto:sage [2012/02/07(火) 23:12:09.39 ] r7rsていつ決まるの？ 66 名前：デフォルトの名無しさん mailto:sage [2012/02/08(水) 00:48:16.17 ] >>64 > あんな美しくないミニ言語 解が見つからないまま publish に至っちゃった結果なんじゃないかなぁ。 Scheme マクロの出発点は「文脈によって意味が変わらないマクロを定義したい」 というところなんだろうけど、それがどうにも上手く行かない。 Common Lisp の symbol は名前を持つ object であるのに対し、 Scheme の symbol はちょっと変わった文字列でしかない。 つまり (eq? (string->symbol "foo") 'foo) => #t であることが保証されている。 ということは explicit renaming では 文脈によって意味が変わらないマクロを定義できない。 というわけで Scheme のマクロ変換の対象となるのは マクロ変換時の情報を格納したオブジェクト(構文オブジェクト)とならざるを得ない。 で、マクロ変換時の情報って何よ？ ってなったときにどうにも合意できるものが無い。 合意できるものがないので (datum->syntax identifier datum) という identifier の中に隠れた(仕様書に無い)構文情報を datum に付加できる手続きを仕様とすることでなんとなく合意された。 と推測している。 67 名前：デフォルトの名無しさん mailto:sage [2012/02/08(水) 02:07:25.92 ] 個人的にはsyntactic closureが良いなー。レガシーマクロっぽくて。 explicit renamingでも良いけど、何度もrenameするの面倒な気がする。 d.hatena.ne.jp/leque/20080528/p1 68 名前：デフォルトの名無しさん mailto:sage [2012/02/08(水) 03:06:13.27 ] なんで scheme って、衛生的マクロに拘るの？ defmacro の方が、シンプルかつ必要最小限じゃん？ 69 名前：デフォルトの名無しさん mailto:sage [2012/02/08(水) 05:20:32.66 ] defmacroはbrokenだから。どう使っても確実に動くというマクロが書けない。 運用上のルール (RnRSで定義されてるグローバル束縛をシャドウするローカル変数は作らない、とか) で回避できなくはないけど、そこで妥協したらSchemeじゃない。 70 名前：デフォルトの名無しさん mailto:sage [2012/02/08(水) 05:38:39.35 ] やだ、かっこいい・・・ 71 名前：デフォルトの名無しさん mailto:sage [2012/02/08(水) 10:41:16.35 ] ファミコンをCommon Lispでプログラミング。 developers.slashdot.org/story/12/02/07/0043241/hacking-the-nes-with-lisp 72 名前：68 mailto:sage [2012/02/08(水) 16:45:06.95 ] >>69 ごめん、よく知らないんだけど、そもそもそういう思想なの？ 刃物が危ないから規制する、みたいな感じに受け取れるんだけど…。 マクロの外側では普通に、グローバル束縛をシャドウするローカル変数、って(作っちゃだめだけど)作れるんだよね？ (define (let) 10) でめっちゃめちゃだよね？ なんで defmacro だけ目の敵に…。 73 名前：デフォルトの名無しさん mailto:sage [2012/02/08(水) 17:05:59.38 ] >>72 let を変な風に定義しなおしたとしても、何も変えてない let* とか letrec とかは今まで通り普通に動いてほしい でも let* がマクロで let に展開されると、変な風に変えた新しい let を使うと、正しく動かなくなってしまう 自分が let を使うときは自前の定義した let を使いたいけど、 let* とかがマクロの内部で使ってる let は元々の let を使ってくれれば、素敵だと思わない？ そんな気持ち 74 名前：デフォルトの名無しさん mailto:sage [2012/02/08(水) 17:10:55.65 ] macroは式の変形なので、普通にやると展開時の文脈で評価されてしまう。 これに対してCommon Lispではgensymやパッケージ指定や命名規則で対応する。 schemeはLisp-1で名前空間が少ないのでCommon Lispと同じ対応は難しいし、直交しないので美しくない。 そこで定義時の文脈で評価する清潔なマクロを使用する。 R5RSのsyntax-rulesは純粋に定義時の文脈しか参照できない。 そこでR6RSに文脈を好き組み合わせられるsyntax-caseが入った。これは文脈を選べるので古典的マクロより強力。 ただsyntax-caseは通常のLispの文法に似ていないし、パターンマッチなど余計な仕事をしているので美しくない。 そこでexplicit renamingかsyntactic closureに変更しろという文句が出て来る。 75 名前：デフォルトの名無しさん mailto:sage [2012/02/08(水) 17:14:28.23 ] 個人的な感想だと、explicit renaming=gensym類似、syntactic closure=closure類似、syntax-case=Lispじゃない。 76 名前：デフォルトの名無しさん mailto:sage [2012/02/08(水) 17:20:18.70 ] >>72 マクロじゃない、普通のライブラリは既にそういう分離が出来てるから。 自分のモジュールで (define car '(toyota prius)) したら、突然 標準ライブラリで内部でcarを読んでる関数が全部動かなくなる、なんてことはないよね。 (R6RS以降、もしくはR5RS+適切なモジュールシステムを使ってれば)。 マクロでもそれと同じことを保証したいけど、defmacroではできない、っていうこと。 77 名前：はちみつ餃子 ◆8X2XSCHEME mailto:sage [2012/02/08(水) 19:23:37.41 ] >>68 小さければ良いというものではないよ。 プリミティブとしてふさわしいかどうかっていうことが重要で、 結果的にある程度小さいことが求められる。 defmacro がふさわしくない理由は↓の記事が詳しい。 blog.practical-scheme.net/shiro/20100425-scheme-macro 78 名前：デフォルトの名無しさん mailto:sage [2012/02/08(水) 22:39:10.44 ] >>72 > なんで defmacro だけ目の敵に…。 昔は手続きにも同じ問題があった(funarg問題)。 これに対してはレキシカルクロージャで一応解決した。 Scheme はマクロの方も解決しようとしている。 でもみんなが満足する解は今のところみつかってない。 79 名前：デフォルトの名無しさん mailto:sage [2012/02/08(水) 22:46:26.14 ] >>64 >型推論するR5RS compilerが欲しいなー（チラッ 今がんばっています 80 名前：デフォルトの名無しさん mailto:sage [2012/02/09(木) 16:13:55.29 ] >>79 ほうほう 楽しみにしています 81 名前：デフォルトの名無しさん mailto:sage [2012/02/11(土) 04:44:52.24 ] Schemeの衛生マクロではアナフォリックマクロみたいな意図的に変数捕捉するマクロは書けないと聞いた。 まあaifくらいしか使わないけど・・・ 他にもdefmacroでしかできないようなことってある？ 82 名前：デフォルトの名無しさん mailto:sage [2012/02/11(土) 07:18:20.00 ] アナフォリックマクロは無理矢理スコープをねじ曲げて作ってるのを何ヶ所かで見たことがある。 多分、ググれば出て来る。 83 名前：はちみつ餃子 ◆8X2XSCHEME mailto:sage [2012/02/11(土) 12:49:13.70 ] >>81 かなり面倒くさいが出来ないわけではない。 d.hatena.ne.jp/leque/20100826/p1 84 名前：デフォルトの名無しさん mailto:sage [2012/02/11(土) 13:37:23.08 ] syntax-rulesでは面倒でもsyntax-caseなら普通に出来るじゃん。 R5RS処理系でも主要な物には外部変数捕捉が可能な健全なマクロシステムが入ってるよ。 85 名前：デフォルトの名無しさん mailto:sage [2012/02/11(土) 13:40:57.53 ] >>81 defstruct みたいに prefix 付き手続きを自動生成するとか。 86 名前：はちみつ餃子 ◆8X2XSCHEME mailto:sage [2012/02/11(土) 15:59:41.06 ] R6RS のマクロと defmacro の差ってことで言えば defmacro でないと出来ないことってのはほとんど無いと思うなぁ。 むしろ defmacro には出来ないことがあると思う。 一応 >>81 が期待している回答が syntax-rules と defmacro の比較と仮定すると、 >>85 の他に マクロ展開時の数値計算みたいなのとかも syntax-rules では無理ってことになるんじゃないかな。 例えば (plus 1 2) を 3 に展開するみたいなのは無理。 (define-syntax plus (syntax-rules () ((_ 1 2) 3))) みたいな感じで全ての数値の組み合わせを網羅するとかいった方法が無いでもないが非現実的だわな。 87 名前：デフォルトの名無しさん mailto:sage [2012/02/11(土) 16:25:57.01 ] 一段落目のあいまいな内容の感想文ﾜﾛﾀ 88 名前：はちみつ餃子 ◆8X2XSCHEME mailto:sage [2012/02/11(土) 17:08:26.17 ] 思想が違うものなので比較するのが難しい。 R6RS のマクロは defmacro に出来る大抵のことは出来るはずだけど、 展開時に使う関数は別のライブラリに分けなきゃならない制限があったりする。 (フェイズの分離がライブラリ単位。) 「defmacro は関連定義をひとつのパッケージにまとめることが出来る (が R6RS のマクロはそうではない)」 という点で能力の差と言えなくもないけど、定義したマクロを使う分には関係無いので単に記法の違いと言えなくもない。 一方で、 >>77 にあげたように「defmacro では完全に変数衝突を避けることは出来ない」というのは 定義したマクロを使う時にも注意を強いるという点で「defmacro には出来ないことがある」と考えた。 つまり、定義時の楽さや複雑さを置いといて、どれだけマクロの中に隠蔽できるか (マクロ使用時に見えないか) で測ると >>86 という意見になるわけだけど、そうじゃない解釈もできるので曖昧な文章になってしもたという感じ。 89 名前：デフォルトの名無しさん mailto:sage [2012/02/13(月) 00:28:30.09 ] Creating Languages in Racket queue.acm.org/detail.cfm?id=2068896 特別な内容という訳ではないと思うけど、queueだけではなく John McCarthyが表紙のacm会誌('12/01)にも転載されてた。 90 名前：デフォルトの名無しさん mailto:sage [2012/02/14(火) 17:54:07.78 ] RacketのGUIをちょっとやってみたけど、 message%のlabelが全部表示されない だめだな 91 名前：デフォルトの名無しさん mailto:sage [2012/02/14(火) 19:05:01.69 ] ふと気になったんだけど、schemeって代数幾何でいうスキームと何か関係あるの？ 92 名前：はちみつ餃子 ◆8X2XSCHEME mailto:sage [2012/02/14(火) 19:14:01.90 ] >>91 無い。 93 名前：はちみつ餃子 ◆8X2XSCHEME mailto:sage [2012/02/14(火) 19:16:47.01 ] Scheme の名前の由来はこの記事が詳しい。 www010.upp.so-net.ne.jp/okshirai/scheme-20070402222203.txt 94 名前：デフォルトの名無しさん mailto:sage [2012/02/14(火) 19:37:41.97 ] >>93 ありがとう 勉強になった 95 名前：デフォルトの名無しさん mailto:sage [2012/02/14(火) 19:57:47.92 ] 新宿ジュンク堂が閉店するみたいだ。残念。 Lisp関連書籍やものまね鳥なんか買うことが出来てお世話になった。 96 名前：デフォルトの名無しさん mailto:sage [2012/02/14(火) 22:05:27.83 ] ぇえー残念 って、そういえば、三越自体がなくなるせいか まぁ仕方ないね 97 名前：デフォルトの名無しさん mailto:sage [2012/02/14(火) 22:37:18.96 ] ジュンク堂自体はおなじ規模でどんどん出店してるから、また新宿に出来るかもね。 98 名前：デフォルトの名無しさん mailto:sage [2012/02/14(火) 23:31:00.57 ] 後釜のビックが書籍のフロアを頑張ってくれると有難いんだが。 99 名前：デフォルトの名無しさん mailto:sage [2012/02/15(水) 01:47:04.54 ] 新宿三丁目のあたりで良いからまた店出して欲しいな。 100 名前：デフォルトの名無しさん mailto:sage [2012/02/16(木) 03:04:19.85 ] 新宿は紀伊国屋本店があるから無理じゃね？ それにしても紀伊国屋の3階はLisp関連書だけ外れの方に追いやられてるのは何故だ・・・ 101 名前：デフォルトの名無しさん mailto:sage [2012/02/16(木) 08:01:16.78 ] 行ったことないから判らんのだが コンピューター書のコーナーが中央にあって、そこと別にLispコーナーが端にあるのか？ 102 名前：デフォルトの名無しさん mailto:sage [2012/02/16(木) 08:34:03.94 ] 本店があって、（行政区画上は渋谷区だが）新宿南店もあるもんな。 103 名前：デフォルトの名無しさん mailto:sage [2012/02/19(日) 00:22:46.67 ] >>101 一応コンピュータのコーナーだが概論的なコーナーだし 空間的に、ん？ここもコンピュータ書のコーナーなのかな？ というような微妙な位置にある。 104 名前：デフォルトの名無しさん mailto:sage [2012/02/23(木) 22:48:15.88 ] JVM版CLのABCLも1.0.0が出てたのか・・・ abcl-dev.blogspot.com/2012/01/abcl-101-released.html abcl-dev.blogspot.com/2012/01/closing-in-on-closer-mop-in-abcl-110.html 地道にやってるのかな・・・ 105 名前：デフォルトの名無しさん [2012/02/28(火) 23:26:45.58 ] WEB+DBの最新号、関数型言語入門を山本和彦が書いてるのを立ち読みして来た けど、LISPに関する文章が悲しくて泣けた 家に帰ってリスト遊び窓から投げ捨てた 106 名前：デフォルトの名無しさん mailto:sage [2012/02/28(火) 23:42:50.17 ] >>105 どんな文章なんだろう 読んでみるよ 107 名前：デフォルトの名無しさん mailto:sage [2012/02/29(水) 05:52:25.13 ] 論点の前半は、下記のclojureの説明とおなじかんじだった。（デフォルトで不変データ構造から組み立てた言語が関数型言語とする） www.geidai.ac.jp/~marui/clojure/index.html https://sites.google.com/site/clojurejapanesedocumentation/home/reference lisp系でそこに名前が上がっていたのは、clojureだけで、racketさんは認知されていなかった。 もう一点は、コンパイル時の型チェックは重要ということで、型推論からパターンマッチングあたりの積み上げやすさを説いていた。 （値のテストだけで済む） なので、定義では関数型言語は不変データ構造だけど、MLレベルのコンパイル時チェック（テストを値での分岐チェックに落とし込める）がないとダメじゃないかという内容でもあった。 108 名前：デフォルトの名無しさん mailto:sage [2012/02/29(水) 06:02:06.45 ] S式（単一シンタックス）やマクロといったlispの特徴は二の次というか、あまり興味なさそう。 （マクロはAST操作やテンプレートがありますが） 前半でいえば、最近だと、逆に値の変更をプログラマーが管理してチューニングする方がいいと、clojureからclに流れる人もいるし、 haskellも性能出すのにチューンされた通常のデータ構造は管理して使ってるみたいだけど。 （ただclojureやscalaの影響で不変データ構造の高速化にチャレンジするライブラリ制作者も増えた気がする） 後半の型推論といえば、shenが（ry 109 名前：デフォルトの名無しさん mailto:sage [2012/02/29(水) 09:47:21.10 ] >>108 Clojureもjavaのコードを動的コンパイルしてreloadできれば値の変更を伴うコード書くのもたやすいんだがなぁ CLとくらべちゃうとどもならんけど 110 名前：デフォルトの名無しさん mailto:sage [2012/02/29(水) 10:14:13.14 ] そんな凝った事しなくてもJavaのデータ構造使えばいいじゃないか 配列も使える 111 名前：デフォルトの名無しさん mailto:sage [2012/02/29(水) 11:52:59.90 ] 関数型言語入門でLisp大きく取り上げてたら それこそ頭おかしい。 112 名前：デフォルトの名無しさん mailto:sage [2012/02/29(水) 12:01:59.01 ] 関数型の利点として副作用がない事をあげてしまうと、constやimmutableが基本ですからと返される気がするのだけどな。 高階関数やマクロや型推論などのコードがスッキリ書ける技法を押した方が良いと思うのだけど。 113 名前：デフォルトの名無しさん mailto:sage [2012/02/29(水) 12:04:56.93 ] マクロ、型推論、パターンマッチ渡しは 関数型言語と独立した概念。 114 名前：デフォルトの名無しさん mailto:sage [2012/02/29(水) 13:36:21.87 ] 独立した概念だろうと、副作用がない事は手続型への優位にはならないよ。 constは常識ですから、で終わり。高階関数でさえ取り入れられてきて、優位としては怪しい。 やはり対話環境も含めた言語全体の機能を押した方が良いと思う。 115 名前：デフォルトの名無しさん mailto:sage [2012/02/29(水) 14:36:51.26 ] 参照透明性についてちゃんと勉強してから偉そうなこと言えよwwwwwwww 116 名前：デフォルトの名無しさん mailto:sage [2012/02/29(水) 15:09:43.56 ] なにそれ？ 説明してもらえるかしら？ 117 名前：デフォルトの名無しさん mailto:sage [2012/02/29(水) 15:10:24.83 ] 最低限でもCTMCPとか知ってれば、「副作用が無いのが優位」とまでは考えないだろうな。 「副作用（内部状態）を活用したプログラミング」「副作用に依存しないプログラミング」などがある。 副作用に依存した言語しか知らないプログラマーが、余計な副作用に悩まされるというのは判る。 大抵は>>114の、constなどで解決出来るから、ネイティブCでは難しいこと（DSLを作るとか） が必要になったらLispなどが選択肢に入る、ってだけだと思う。 118 名前：デフォルトの名無しさん mailto:sage [2012/02/29(水) 15:20:05.46 ] pc.watch.impress.co.jp/docs/news/20120228_515140.html この FAST LISPの説明がよくわからないんですが 「ビットスライスプロセッサ上に、マイクロプログラム化した」というのは どういうことでしょう？ 119 名前：デフォルトの名無しさん mailto:sage [2012/02/29(水) 15:39:13.99 ] >>118 「ビットスライスプロセッサ」、「マイクロプログラム化」の意味ならWikipediaあたりで見てもらうとして、 意義は、ハードレベルでLisp対応マシンを作製した、という事。 現在の個人向けPCのCPUは、どちらかと言うとC言語対応。 C言語対応CPU + Cソース + Cコンパイラ → Lispコンパイラ + Lisp ソース → C言語対応CPU用実行ファイル → C言語対応CPUで実行、よりも Lisp対応CPU + Lispソース → Lisp対応CPU用実行ファイル → Lisp対応CPUで実行 の方が速度的に有利だし、Lispの内部構造改善も容易。 120 名前：デフォルトの名無しさん mailto:sage [2012/02/29(水) 17:34:21.00 ] ttp://museum.ipsj.or.jp/computer/other/0001.html ここに参照すべき文献が出てる 121 名前： ◆QZaw55cn4c mailto:sage [2012/02/29(水) 20:25:51.28 ] >>119 >C言語対応CPU そんなものがあるのか？ 122 名前：デフォルトの名無しさん mailto:sage [2012/02/29(水) 20:47:12.95 ] Cコンパイラを意識しながら進化してきてるって意味でしょ。 123 名前： ◆QZaw55cn4c mailto:sage [2012/02/29(水) 21:33:46.93 ] >>122 そんな事実はあるのか？具体例をひとつ。 124 名前：デフォルトの名無しさん mailto:sage [2012/02/29(水) 21:38:31.08 ] どっか他所でも誰かに同じ議論吹っかけてたね。 125 名前：はちみつ餃子 ◆8X2XSCHEME mailto:sage [2012/02/29(水) 23:34:11.55 ] インテルアーキテクチャでは命令をμopに分解してCPU内部で最適化したりもするらしいね。 最適化って処理に時間がかかるよくあるパターンを置換える処理だけど、 「よくあるパターン」ってやっぱ言語によると思うんだよな。 インテルはあまり詳細な資料は公表してないけど、少なからず言語を意識せざるを得ないはずではある。 126 名前：デフォルトの名無しさん mailto:sage [2012/02/29(水) 23:51:50.05 ] らしい、とか、思う、とか、はず、とか言われても…… 127 名前：デフォルトの名無しさん mailto:sage [2012/02/29(水) 23:56:11.75 ] そろそろスレチ。 128 名前：デフォルトの名無しさん mailto:sage [2012/03/01(木) 01:05:40.84 ] >>123 x86: enter命令やleave命令 SPARC: レジスタウィンドウ MIPS: 大量のレジスタと少ないアドレッシングモード Atmel AVR: (PIC あたりと比べて)Cで書きやすいように設計された C だけでなく Pascal や FORTRAN あたりも視野に入ってるんだろうけど。 ARMv8 でタグ付きポインタ入らないかなと期待してるんだけど無理だろうな。 129 名前：デフォルトの名無しさん mailto:sage [2012/03/01(木) 01:16:43.05 ] Cの実装でも用いられるスタックを使った環境フレームモデルは データの時間的局所性を自然に表現することになるから、キャッシュが効きやすいはず 原理的にCPUとは相性がいいんじゃないの？ 130 名前：デフォルトの名無しさん mailto:sage [2012/03/01(木) 04:38:06.51 ] 山本和彦の文章立ち読みしてきたけど、まあHaskell宣伝の文章だからそっちのを 持ち上げるのは仕方ないとして、LISPでやって来たことは頃は何も分かってなかった みたいに否定的に思い出しているのがちょっとショッキングだったなあ。 俺もHaskellやろうかな？ 131 名前：デフォルトの名無しさん mailto:sage [2012/03/01(木) 07:31:42.23 ] 心が揺れてるなら自分の答えを得る為にやってみてもいいんじゃね？ 「俺も全然分かってなかったわ……」と結論付けるにせよ 「あいつがLisp全然分かってなかったわ……」と結論付けるにせよ 132 名前：デフォルトの名無しさん mailto:sage [2012/03/01(木) 14:05:17.12 ] 読んで疑問に思ったんだけど、 何でlispの頃はそもそも理解できなかったんだろう？ 理解できてもいいと思うんだけど。 lispだから理解できなかったというよりも lisp経験を積んだから最終的に理解できたんじゃないかな 133 名前：デフォルトの名無しさん mailto:sage [2012/03/01(木) 14:15:01.27 ] Lispに潜在的能力があるとしても、やっぱり言語仕様にないと利用者に伝わらないんじゃない？ Cしか使ったことない人にGObjectを説明してもたぶんよく分からないだろうけど C++を一度経由させてみたらオブジェクト指向について理解が深まる……みたいな感じで ほかの言語に触れたからこそ目が覚めた、でも元々使ってた言語でも同じようなことはできた ってことはあるかもしれない 134 名前：デフォルトの名無しさん mailto:sage [2012/03/01(木) 14:27:56.13 ] うん、lispやったから理解できないってのは 何か意図があるのかないのか この手の文章によくあるセンスの悪い誇張だろう 135 名前：デフォルトの名無しさん mailto:sage [2012/03/01(木) 14:54:00.62 ] ある程度の宣伝口はしかたないでしょ。 Haskelは型付けの意識が強すぎて、書きながら考えるのがやりにくいのがイヤ。優等生向け言語。遅延評価もマイナス。 136 名前：デフォルトの名無しさん mailto:sage [2012/03/01(木) 15:26:55.07 ] >>135 >遅延評価もマイナス。 メリットを上回るデメリットって何？ 137 名前：デフォルトの名無しさん mailto:sage [2012/03/01(木) 16:15:27.97 ] 「人は副作用から離れては生きられないのよ」ってことじゃねぇの？ 多分それに対する返しは「副作用に魂を縛られた人々よ」なんじゃないかと思うが。 138 名前：デフォルトの名無しさん mailto:sage [2012/03/01(木) 16:19:32.71 ] >>136 あくまでも個人的な感想。言語の機能は目的に応じた選択だから良い悪いの評価は難しい。だからこそLispは言語が作れる言語になってる。 静的型の利点に性能をあげやすい点があるけど、デフォルトが遅延評価だとやりにくい。 139 名前：デフォルトの名無しさん mailto:sage [2012/03/01(木) 16:37:25.31 ] もともとelisp以外にlisp書いてない人なんじゃないの? elispは開発環境として、プロトタイプ志向がすごく強くて、 コンパイラの性能も悪いから、ちょっと特殊だしね。 140 名前：デフォルトの名無しさん mailto:sage [2012/03/01(木) 16:40:19.88 ] 遅延評価は結構厄介だぞ 性能評価とか人が直感的に理解できる範疇をはるかに超えてる 141 名前：デフォルトの名無しさん mailto:sage [2012/03/01(木) 16:59:49.49 ] でもまあMew作ったほどの人があれだけはっきりLISPにネガティブなこと書くという のはそれなりに影響を与えそうな気はする。 142 名前：はちみつ餃子 ◆8X2XSCHEME mailto:sage [2012/03/01(木) 17:19:02.05 ] 俺らが日本語を話すときにいちいち文法を考えたりしないだろ。 公式文書とか入り組んだ理屈を書くときにちょっと確かめたりするくらいだ。 合理的な理由があったとしても、メンタルモデルとかけ離れた言語は使い難いよ。 Lisp は言語の方を自分に (あるいは目的に) 合わせていける余地があるところが良い。 だけど、自分の裁量が大きいっていうのは自分の能力次第でグダグダにもなるってことでもあるわな。 Haskell は知識を体系的に表すことが強要される気がするけど、 それが使い難いと感じるのは、人の脳味噌が実際のところそんなに体系的に考えるのには向いてないってことなんじゃないかな。 143 名前：デフォルトの名無しさん mailto:sage [2012/03/01(木) 18:01:53.72 ] >>137 副作用が良くない事のように捉える人が少なくないのに違和感あり。 144 名前：デフォルトの名無しさん mailto:sage [2012/03/01(木) 18:09:54.90 ] >>143の文章に違和感を覚える 145 名前：デフォルトの名無しさん mailto:sage [2012/03/01(木) 18:22:35.35 ] そこは違和感ありだろと違和感あり 146 名前：デフォルトの名無しさん mailto:sage [2012/03/01(木) 18:28:50.59 ] イスラム名のように違和感なく聞こえないこともない 147 名前：デフォルトの名無しさん mailto:sage [2012/03/01(木) 18:32:07.85 ] でも、副作用については、厳密に副作用を禁止するより むしろ禁止しないほうがいいというのが、大多数の言語の主張だろ 148 名前：デフォルトの名無しさん mailto:sage [2012/03/01(木) 18:39:58.90 ] たとえば薬とかの副作用は、基本、ないほうがいいものだから、手続き型ないし 命令型（プロシージャルorインペラティブ）のそれを「副作用」と呼ぶのには 問題があると言えばある。今更「仮想」とかと同じでどうにもなりそうにないが。 149 名前：デフォルトの名無しさん mailto:sage [2012/03/01(木) 18:45:15.14 ] 説教つうと、基本悪い事した時に正座させられた上でこれでもかと聴かされるアレだから、 宗教家のそれを「説教」と呼ぶのには問題があると言えばある。 のか？ 150 名前：デフォルトの名無しさん mailto:sage [2012/03/01(木) 18:46:02.62 ] 代入なんか言ってみればmain effectだしな。 151 名前：デフォルトの名無しさん mailto:sage [2012/03/01(木) 18:46:15.60 ] はっきりとコードの領域を副作用と純粋に分けられるかじゃないの haskellはいい線行ってるとおもうけど 152 名前：デフォルトの名無しさん mailto:sage [2012/03/01(木) 19:10:15.74 ] 副作用を目の敵にしてるんじゃなくて 副作用のある部分もない部分もプログラムの正しさを証明できればいいなっ という試みだろ

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef