Lisp Scheme Part41 (856レス)
Lisp Scheme Part41 http://mevius.5ch.net/test/read.cgi/tech/1531587928/
上
下
前
次
1-
新
通常表示
512バイト分割
レス栞
572: デフォルトの名無しさん [sage] 2023/01/11(水) 17:40:33.93 ID:/IOcm4EW >>571 どうも、俺のも原理的には…という同じ意図の話だよ eclやgaucheが有名実装では最もアグレッシブな感じなのかな? (declaim (optimize (speed 0) debug safety) が外せない俺には怖くて触れないよ http://mevius.5ch.net/test/read.cgi/tech/1531587928/572
573: デフォルトの名無しさん [sage] 2023/01/11(水) 18:02:49.87 ID:/IOcm4EW なおeclのlocked package?の件、標準の宣言を全て付けても有効な模様… http://mevius.5ch.net/test/read.cgi/tech/1531587928/573
574: デフォルトの名無しさん [sage] 2023/01/11(水) 18:12:33.46 ID:qLQaVlgq notinlineも効かないし独自機構だな http://mevius.5ch.net/test/read.cgi/tech/1531587928/574
575: はちみつ餃子 ◆8X2XSCHEME [sage] 2023/01/14(土) 01:01:49.57 ID:9ctkhBjT >>572 > 有名実装では最もアグレッシブ そんなことはないんじゃないかな。。 実行前の処理に時間をかけない (かけても総合的な性能向上にならない) という 判断でエラーチェックに消極的だけど最適化にも消極的だから。 http://mevius.5ch.net/test/read.cgi/tech/1531587928/575
576: 本田 [] 2023/01/25(水) 23:58:21.43 ID:PahnnjBC UCB Scheme https://people.eecs.berkeley.edu/~bh/61a-pages/Scheme/ UCB Scheme is a modified version of STk 4.0.1 by Erick Gallesio. http://mevius.5ch.net/test/read.cgi/tech/1531587928/576
577: デフォルトの名無しさん [sage] 2023/01/26(木) 19:06:40.12 ID:lq03KzKz USB Schemeじゃないのか どっちかって言えばUSB Schemeが欲しいのだが http://mevius.5ch.net/test/read.cgi/tech/1531587928/577
578: デフォルトの名無しさん [sage] 2023/01/28(土) 14:07:46.81 ID:BDgiT21v nptcl https://github.com/nptcl/npt http://mevius.5ch.net/test/read.cgi/tech/1531587928/578
579: 本田 [] 2023/01/29(日) 22:24:48.67 ID:XMFhzyDs アルゴリズム言語 Scheme 報告書 四訂版 H. Suzuki訳 https://groups.csail.mit.edu/mac/ftpdir/scm/r4rs-ja.texi http://mevius.5ch.net/test/read.cgi/tech/1531587928/579
580: はちみつ餃子 ◆8X2XSCHEME [sage] 2023/01/30(月) 00:59:07.34 ID:kRDQpz8S そのリンクがどうしたっていうんだ? 何か思うところがあるなら話題に挙げるのはかまわんが ただリンクを置いて去るのはやめて欲しいな。 ニュース系のネタならお知らせの意味で貼ったのかなと思うところだが、 そういう感じでもないみたいだしな。 http://mevius.5ch.net/test/read.cgi/tech/1531587928/580
581: デフォルトの名無しさん [] 2023/01/30(月) 19:13:37.70 ID:prACFehy そもそもダイナミックスコープの何がだめですか Emacs lispはダイナミックスコープですが、 あちこちから呼ばれてる関数を、空関数で上書きして殺すとかできて便利です Emacs lispの感覚でGIMPのスクリプト(scheme)を書こうとすると なにか何でもかんでもラッパー渡し(いちいちcarをひとつ辿る)って感じです ちなみにLispは普通の手続き型言語としてしか使ったことないです そんな奴への説教とかあったら聞きたいです マクロとか、「確かにif文を関数として実装するのは
無理かもしれないし、 そういう時に使うのかな」くらいにしか解ってないです http://mevius.5ch.net/test/read.cgi/tech/1531587928/581
582: デフォルトの名無しさん [sage] 2023/01/30(月) 19:45:34.45 ID:w7gs7hNq >>581 全然ダメじゃないよ。でも誰か(昨日のオレ)が余計なことをやって不審な挙動をしてるけど原因がさっぱり分からないというのは起こりやすいかもしれない。 http://mevius.5ch.net/test/read.cgi/tech/1531587928/582
583: デフォルトの名無しさん [sage] 2023/01/31(火) 01:40:41.84 ID:t9l1A9G+ Lispではたまたまうまく動いてるように見えるけど変数宣言の無い言語でダイナミックスコープやると死ぬ http://mevius.5ch.net/test/read.cgi/tech/1531587928/583
584: はちみつ餃子 ◆8X2XSCHEME [sage] 2023/01/31(火) 10:19:46.67 ID:XA5Y5Qfu >>581 元のプログラムを書き換えずに影響を差し込むことが出来るってのはアプリケーション拡張用として便利だけれど 元のプログラムが想定してない滅茶苦茶なことも出来ちゃうということと最適化が困難になるのが深刻な問題だと思う。 ユーザーが変な使い方をして変なことを起こす分には自業自得といえるにしても 今ではパッケージをネット上からダウンロードしてインストールまで自動だから 悪意あるコードが他のパッケージを好きなように変更できるようだと
影響範囲が大きい。 たとえばウェブブラウザのアドオンなんかだど各アドオンは通信によって協調は出来るが 環境は共有しないようにすることで影響力を制限している。 参照しているものがことごとくいつでも変更される可能性があると インライン化や畳み込みといったごく基本的な (しかし効果が高い) 最適化すらできない。 現代的な言語処理系に対して数十倍単位で遅いのはさすがに困る。 ものごとの良し悪しにはトレードオフがある。 どちらの問題もコードが小規模ならどうということはないので利点のほうが上回っていたのかもしれないが、 時代を経
て巨大になりすぎた。 疎結合を意識した構成にしないと手に負えない。 http://mevius.5ch.net/test/read.cgi/tech/1531587928/584
585: デフォルトの名無しさん [sage] 2023/01/31(火) 10:34:59.12 ID:tSjB9eWW グローバル&ダイナミックは罠になり得るけど、対話的に使うコマンド言語(シェル)は大体そうだし利便性の問題、新しいpwshでももそう 定義をテキストとして全てダンプして、読み戻せる利点がある cl/scheme(fluid-letとかそんな名前の拡張)のように基本レキシカルで、ローカル&ダイナミックは宣言が必要なら意図せず使う事は稀なはず (form-in-scope? (declare (special x)) form-in-scope) (locally (declare (special x)) (form-in-scope)) 面倒だけど(declare…)が外
、つまり同じレベルのフォームに影響する場合があるのが気持ち悪いから、明示的な後者を好む http://mevius.5ch.net/test/read.cgi/tech/1531587928/585
586: デフォルトの名無しさん [sage] 2023/01/31(火) 10:56:14.75 ID:tSjB9eWW レキシカルな情報を取り込んでしまう(暗黙にクロージャを作る)クロージャにはテキスト表現が無いから、ダンプが出来ないのは致命的な欠点 よってダイナミックスコープ一択になる pwshだと gci function: bashだとdeclare -f (多分、よく知らん) でダンプ、出力されるテキストを読み直せば(大体)環境が復元できる pwsh方式だと{code}.GetNewClosure()でクロージャは明示的に得る http://mevius.5ch.net/test/read.cgi/tech/1531587928/586
587: デフォルトの名無しさん [sage] 2023/01/31(火) 11:08:10.67 ID:tSjB9eWW >>581 guileだっけ? あれ変な拡張山盛りだから出来るんじゃない?fluid-letみたいな名前がないかaproposしてみたら http://mevius.5ch.net/test/read.cgi/tech/1531587928/587
588: はちみつ餃子 ◆8X2XSCHEME [sage] 2023/01/31(火) 11:28:43.20 ID:XA5Y5Qfu >>587 GIMP の Scheme (Script-fu) は TinyScheme が使われている。 (昔は SIOD だった。) まあ fluid-let くらいなら自分で書いてもたいした手間じゃないけどね。 http://mevius.5ch.net/test/read.cgi/tech/1531587928/588
589: デフォルトの名無しさん [sage] 2023/01/31(火) 11:31:05.15 ID:cAwVb56Q #<closure ...>が嫌ならいにしえのfunargを使えばok 別にレキシカル環境をリストで持ったって構わないわけで、印字表現が不透明なlispはインクリメンタルコンパイルやリストより効率の良いデータ構造を選んだ結果 厳密にはダイナミックスコープでないけれど、コード注入なら'ラムダ式を渡して廻っても同等の自由が得られる(call by name) 既存のコードの方でも準備が必要だけど http://mevius.5ch.net/test/read.cgi/tech/1531587928/589
590: デフォルトの名無しさん [sage] 2023/01/31(火) 11:33:22.79 ID:tSjB9eWW >>588 ええ…gnu公式の拡張言語とは一体なんだったのか http://mevius.5ch.net/test/read.cgi/tech/1531587928/590
591: はちみつ餃子 ◆8X2XSCHEME [sage] 2023/01/31(火) 12:23:06.03 ID:XA5Y5Qfu >>590 アプリケーションに特有の機能はアプリケーション側で用意されたものを呼出して使うわけだし 言語側のライブラリはほどほどで足りるんで小さい処理系のほうが面倒がないというのはあるかも。 Guile はビルドするだけで面倒くさいが TinyScheme はファイル数個の簡単構成だし。 http://mevius.5ch.net/test/read.cgi/tech/1531587928/591
592: デフォルトの名無しさん [sage] 2023/01/31(火) 12:38:01.83 ID:mFP57axK ローカルにダイナミックな束縛をやるなら、それ専用のprogvフォーム(clにある)はどう思われてるんだろ? (progv 変数リスト 値リスト body) let系列の (変数 値)リスト慣習を転置(zip)した記法だけど、束縛が多くても縦にスペースを取らない let慣習では変数 値はsetq/set!だけど、progvの変数リストは評価されるから、リード時にバッククオートでシンボルを埋め込むようなハックが不要 動的束縛を活用するようなメタな場面では特にだけど、埋め込む為だけにわざわざリ
ーダを何度も通すのが歯痒い 多分に個人的な好みだと思うけど http://mevius.5ch.net/test/read.cgi/tech/1531587928/592
593: デフォルトの名無しさん [sage] 2023/01/31(火) 13:07:01.68 ID:tSjB9eWW >>592 転置されてるのと束縛リストの実行時評価は、おそらくlet風のマクロを書く時に便利だからかな mapcar #'list let-like-binding-list がprogvに渡せて、あと欠損値も勝手にnilで埋まる あと機械的に名前を処理するならgensymもお忘れなく http://mevius.5ch.net/test/read.cgi/tech/1531587928/593
594: デフォルトの名無しさん [sage] 2023/01/31(火) 13:18:26.31 ID:tSjB9eWW 例が悪かった 単にlistをmapcarするだけでは、let形式のリストをそのまま渡した方が早い 不定数の引数を取ってリストを返す関数で、自明なlist以外をmapcarするならかなり楽が出来るはず しかし何に便利か今すぐ具体的な例は思い付かない() http://mevius.5ch.net/test/read.cgi/tech/1531587928/594
595: デフォルトの名無しさん [sage] 2023/01/31(火) 14:00:30.21 ID:tSjB9eWW >>591 俺環ではインストール(展開後)で50MBのディスク容量占めてるな 実験的なelisp対応(編集機能無しで一体何の意味が?)とか 興味深いけど謎な方向に突き進んでるね http://mevius.5ch.net/test/read.cgi/tech/1531587928/595
596: デフォルトの名無しさん [sage] 2023/01/31(火) 14:46:13.56 ID:CmTey6Bh GNUは昔から他人の成果物の丸パクリしか脳が無い団体だよ http://mevius.5ch.net/test/read.cgi/tech/1531587928/596
597: デフォルトの名無しさん [sage] 2023/01/31(火) 15:18:25.22 ID:AYYg8Thv emacsの膨大なテキスト処理関数群に依存していない純ロジックのみのelispコードなら資産になる そんなの指折り数える量だろう http://mevius.5ch.net/test/read.cgi/tech/1531587928/597
598: デフォルトの名無しさん [sage] 2023/01/31(火) 15:38:47.41 ID:sZCc+g+m ライセンス問題でどうしてもコードを触りたくないなら別だけど 何らかのlisp書きであれば、コピペしてその方言に適合するよう手直しする程度は自明な作業でしょう http://mevius.5ch.net/test/read.cgi/tech/1531587928/598
599: はちみつ餃子 ◆8X2XSCHEME [sage] 2023/02/01(水) 01:45:17.62 ID:ySbq2UIa >>598 ダイナミックスコープとレキシカルスコープでは埋めがたい差があるし、モジュールやフェイズの方針なども大きな差だ。 伝統的に方言と称してはいるが個々に定義された別の言語なのでそんなに簡単に修正は出来ないよ。 私自身はそこそこ Scheme には習熟している自信があるが Common Lisp も Clojure も全然わからん。 C と JavaScript の外観はなんとなく似せてあるが静的型と動的型の違いという根本的な部分で違うからそう簡単に移植はできないのと同
じような感じ。 http://mevius.5ch.net/test/read.cgi/tech/1531587928/599
600: デフォルトの名無しさん [sage] 2023/02/01(水) 06:05:03.14 ID:BjxytPYm いっそ Emacs そのまま組み込んじゃうとかそんな方向に進まないかな… 近頃の環境ならそんなに重くないはずだし。 http://mevius.5ch.net/test/read.cgi/tech/1531587928/600
601: デフォルトの名無しさん [] 2023/02/01(水) 14:47:30.69 ID:MmorO90J >>600 やってできなくはないのかもしれないよ 昔、zlibがまだなかった時代にDOSでzオプションの利くtarを使いたくて、 仕方なくtarとgzipをまとめて一つのバイナリにリンクしてしまって、 スタートアップでヒープを半分に割って、スタックをそれぞれに割り振って、 あとはバッファが一杯になるたびにtar側とgzip側をsetjmpとlongjmpで行ったり来たり、 解凍は問題ないんだけど圧縮がどうしても同じ結果にならなくて、発表せず一人で使ってた http://mevius.5ch.net/te
st/read.cgi/tech/1531587928/601
メモ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 255 レスあります
スレ情報
赤レス抽出
画像レス抽出
歴の未読スレ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.024s