Lisp Scheme Part41 (856ﾚｽ)
上下前次1-新
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
だからなんやねん
つか何年前から来たの？ってレベルの話だろ
604: 2023/02/15(水)12:56 ID:Iq74I464(1) AAS
目くじら立てることかよ
605: 2023/03/05(日)13:42 ID:nmaj3sub(1) AAS
オンラインでuLisp動かしてみようかとTinkerCADのArduonoUnoにソースコード流し込んでみたけどさすがに5000行は許してもらえないみたいだな。
606: 2023/04/24(月)08:39 ID:AD1D3xO/(1) AAS
最適化されたCLは最適化されていないCよりは速い
昔Common LispでCより速いHTTPパーサを書いたとか言ってたのを見かけた
コードを見るとnodejsのCで書かれたHTTPパーサをパクったみたいな感じなのに
比較対象はなぜかどっかの個人がCで書いたHTTPパーサだった
その個人が晒してたソースのMakefileはデフォルトでは最適化なし
なぜ比較する前にCの方を最適化することを思いつかなかったのだろうか
というかなんでnodjsの方と比較しなかったんだ？
誰か理由わかります？
607: 2023/04/24(月)08:46 ID:Z0B9bFh/(1) AAS
なぞなぞかな
608: 2023/04/25(火)20:39 ID:wy/j7fQc(1) AAS
おじいちゃんそろそろマクロを飲む時間ですよ
609: 2023/05/24(水)21:31 ID:w5+jyJkb(1) AAS
氏のイキリ芸でしょ
610: 2023/06/20(火)13:38 ID:Dvlv0UV+(1) AAS
scheme処理系作ったりSICPで悟り開いたりしたけど今の使い方は実質電卓
スペース区切りの値そのまま貼り付けられて便利なんよなー
611: 2023/08/18(金)02:03 ID:dtVdNVwB(1) AAS
John Cowan 氏が R7RS-large の議長の座を降りることを表明した模様。
これからの体制については現時点は決まっていない。
612: 2023/08/19(土)10:24 ID:L0GsKMkM(1) AAS
実質機能しない規格なんて不要
主要処理系の実態調査して
ANSI Common Schemeを策定すべき
613: 2023/08/19(土)20:44 ID:2cGgFupU(1) AAS
実用的で無い言語にANSI規格とか要らないだろ
それより、Type Script 普通に良い言語だぞ、
あれ実質的に型付きのlispだわ
614: 2023/08/20(日)18:08 ID:Jez4Fpf5(1) AAS
「Type Scriptはlisp」発言頂きましたー
615(1): 2023/08/20(日)18:21 ID:P3ytobrG(1) AAS
JavaScriptがそもそもschemeだし。
616: 2023/08/20(日)21:24 ID:CVtYBdI9(1) AAS
>>615
設計者の「そうしたかった」という発言が拡大解釈されたもので、
インタビューをちゃんと読むと「そうできなかった」ということも言ってる。
上下前次1-新書関写板覧索設栞歴
あと 240 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.019s