https://gist.github.com/kb10uy/c171c175ba913dc40a73c6ce69da9859
参考までに Seaurchin はこれぐらいだった
kb10uy(@kb10uy@mstdn.maud.io)の投稿
https://gist.github.com/kb10uy/c171c175ba913dc40a73c6ce69da9859
参考までに Seaurchin はこれぐらいだった
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
「【イメリス専用】谷間追加テクスチャ」を Luu∔rium で購入しました！ https://mormor.booth.pm/items/3503054 #booth_pm
だいたいそんな感じです。R6RSは実用的なプログラミング言語を目指したのですが、いくつかの点で議論が収束せずに投票でぎりぎり可決されたという経緯があってGaucheのようにR6RSをサポートしないと明言したグループもあり、R7RSはR5RSにいくつかの拡張を施したコア言語とその拡張という二部構成にすることになったのですが、R6RS互換でも別に良かったんじゃないかなという部分がR6RS非互換になったなどコミュニティ分裂の傷跡が残っており、今は互いに歩み寄りを模索している時期という印象。
本当にStandardと名乗っているSchemeの仕様はIEEE 1178-1990 - IEEE Standard for the Scheme Programming Language（RnRSでいうとR4RSに近い）だけなのだけれども、Schemeコミュニティで委員会を組織して改定を続けているRnRSが広義の標準とみなされていて、現時点で活発にメンテナンスされているScheme処理系はR6RSを実装している処理系とR7RSを実装している処理系に分かれる。
今なぜ急に Scheme の話をしだしたかというとブクマに入ってた Scheme のページをなんとなく読んでたら call/cc の意味が急にわかったからです
@kb10uy 「標準」がR7RSのことだと仮定すると、-r7オプションを付けるとR7RSモードでREPLが起動します。あとはマニュアルの「ライブラリモジュール - R7RS標準ライブラリ」を参照しつつ、 (scheme ...) と (srfi ...) ライブラリのみを使うようにすればGaucheに強く依存するコードになることは少ないと思います。R7RSの範囲内であることを重視するのであればChibi Schemeで動作確認するとよりよいと思います。
@kb10uy 日頃のスクリプト言語としてならGauche、自分のプログラムに組み込みたいならChibi Scheme、コードの速さならChez Scheme、コンパイラを読むならGNU Guileかなぁ
GNU Guileはほぼ完全なR6RS Schemeで、コンパイラがきれいな構造になっているのもあってJavaScriptのサブセットに対するコンパイラフロントエンドなどがオマケに付いているのも面白い。
あえて今 Smalltalk の系譜を触ってみたいなという気持ちもあり、Pharo を入れようとしたりしなかったりもしている
@omasanori なるほど
Gauche でなるべく標準に準拠して書く場合気をつけたほうがいいポイントとかありますかね
11 月末が近づいてきており、つまり オンゲキのハイレゾ音源ボックスの発売が近づいているということです
これ最後の 5000pt ボードと同じような方法で取らないといかんのか(数は足りてるから必須ではないけど)
このアカウントは、notestockで公開設定になっていません。
動的型付けのオブジェクトに対して hidden class って最適化があるのね
V8のHidden Classの話 https://engineering.linecorp.com/ja/blog/v8-hidden-class/
おっ
GitHub - luajit-remake/luajit-remake: An ongoing attempt to re-engineer LuaJIT from scratch
https://github.com/luajit-remake/luajit-remake
このアカウントは、notestockで公開設定になっていません。
E2EE を丼でサポートするの、 UI/UX が統合されてうれしい以上に意味があるか？という感じがする
