ぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬ¦みむかゥわナイストライ¦初音ミク¦ボカロ
https://youtu.be/Ljr2wMSBHqU
ぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬぬ¦みむかゥわナイストライ¦初音ミク¦ボカロ
https://youtu.be/Ljr2wMSBHqU
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
@kb10uy そこそこ有名な 3rd party lib のやつは natvie モジュールでも definition file のカタログレポジトリに置かれがち
https://github.com/LuaCATS
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
話は変わってパターンマッチがキーワードベースで英語っぽく書けるやつ、僕はゆるやかにアンチで(歴史的経緯でそうなっちゃうの自体はしょうがないと思っている)、なぜかと言うと往々にして not x is y も x is not y も書けちゃいがちだからですね
Lua 互換ではないけど昔は Squirrel とかがあり、あれは組み込む側の API が Lua みたいな感じでありながら OOP とかがやりやすい構文だったんだけど、最近はやはりタイプヒントとかの方がウケが良い気がするね
altLua というのは僕が勝手にそう呼んでるだけだけど、要するに Lua に現代的な改修を施しつつ既存の Lua コードと互換性があるようなやつね
組み込みを志しているスクリプト言語はその言語で書かれたソースや標準ライブラリだけじゃダメでちゃんとホスト側環境もしっかりサポートしてはじめて完全だ、という主張にもなる
ANSI Common Lisp(INCITS 226-1994[S2008])、こちらモノリシックな1000ページ超の仕様書となっております
GNU Emacsの愛好者があれはエディタではなく環境だというのも根っこは同じで、コンパイラやインタプリタがあるだけでは不十分で、そのプログラミング言語が第一級の言語として完全にサポートされた環境があって初めて実用的なんだという考えがあるんだと思う。Lispマシンが現役だった時代を生きたLisperにとっては特に。
TS の d.ts みたいなのを書いたら(自動生成できるとなお良い)それを LSP 鯖実装が読み込んでそれっぽく振る舞ってくれる、みたいな感じになってほしい。特に Lua。
組み込む話書いて思い出したけど、組み込むためのスクリプトを静的解析サポート受けながら書くときの問題として「ホスト側から提供される環境の定義手段が意外とない」というのがありがちなんだよな
Common Lisp の仕様のよく知らないけどモノリシックなのかしら、それとも R⁷RS みたいにいくらか分類がされてるのか
仕様がデカいということは逆に言うとそれだけ準拠した実装を用意するのが大変(他のアプリに組み込んだり新規の処理系を起こしづらい)ということになるけど、端から端まで安心できるというメリットでもあるしなあ
単に構文や意味論だけでなく足回り全部含めてその言語・処理系だというのは現代プログラミング言語を見るにその通りだけど、それらが**言語仕様に**入ってるのが重要というのを当時から言ってるのはすごすぎるな 先見の明というか
Common Lisp派の人はあの言語仕様に無駄なものは一切ない、実用的なプログラムを書くならいずれ必要になるものばかりだと主張する。エディタやデバッガに関する規定も含めて。
それを2020年代ではなく1980年代に言い張って譲らなかったのがLisperは未来に生きてたなという感じ
まあ、だからCommon Lisp話者がエディタやデバッガがプログラミング言語仕様で言及されているのを擁護するのは、今どきにいうと「LSP実装もtree-sitter文法も用意されてないプログラミング言語はやってられん」という話に近い