- Lisp Scheme Part39
589 ：デフォルトの名無しさん[sage]：2015/01/03(土) 09:58:40.63 ID:6aBF9uSO - しかし、現実的に100人規模でCommonLispを書いてる会社や、50万行から100万行規模のアプリケーションでも
それが問題になっているという話は耳にしたことがない。
航空ルート検索/予約システム 50万行から http://www.itasoftware.com/
鉄道運行システム http://www.siscog.eu/upload/GESTAO-DE-LISTAS/News/PDF/eclm-2013-siscog-a-story-written-in-lisp-20130602.pdf
昔から積み重ねた実績からして既に充分で新しいマクロ方式に対しての需要もないのだろう。
ずっと昔からCommonLispでは、マクロは実装方式を議論するものではなくて、当り前のように使う単なるツールなんだよ。
|
- Lisp Scheme Part39
591 ：デフォルトの名無しさん[sage]：2015/01/03(土) 11:30:42.47 ID:6aBF9uSO - >>590
伝統マクロ好きだけど、schemeで伝統的マクロ+gensymは駄目だと思うが。
しかしｓｃｈｅｍｅにとってマクロというのはこれから未来の話か？
現在主流の方式も、もう20年前には出尽してるし、メジャーな処理系もマクロのシステムは確立してるだろ。
|
- Lisp Scheme Part39
595 ：デフォルトの名無しさん[sage]：2015/01/03(土) 15:16:41.73 ID:6aBF9uSO - >>592
いっとくけど、CommonLispでのマクロに対するレスで、CommonLispでの話だからね。
危険性が0じゃなかったら何一つ実用的なものは書けないのかよってこと。
schemeで伝統的マクロ+gensymはそれこそ簡単にバッファオーバーランが起こるとかいうのと同じレベルだろ。
でもCommonLispでの問題点とそれを運用で回避する方法を具体的に知ってて言ってんの？
パッケージロックで何万行レベルのコードでも簡単にほぼ100%回避できるよ。マシにしようという方向に動いてるって話だな。
CommonLispトータルのシステムと、取ってつけたようなscheme＋伝統的マクロを同じ俎上に乗せないでくれよ。
|