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