「コンパイラ・スクリプトエンジン」相談室8

「コンパイラ・スクリ ..

643:デフォルトの名無しさん
05/12/11 13:11:24
>>642
> 処理系の研究してる人いるみたいだから聞きたいんだけど、今時はどんな研究が盛んなの？
俺、大学院の研究室がプログラミング言語関係の研究室だったから、この世界には多少つながり
がある。

で、今盛んなのは、プログラミング言語の機能拡張をいかに安全に行うか、ということ。

安全とは、処理系素人が中身を知らずに処理系（ＪａｖａでもＬｉｓｐでも）に、拡張機能モジュールを
突っ込んでも、モジュール同士が干渉することなく、素人が拡張機能の恩恵にあずかれること。

モジュールを突っ込んで言語処理系の機能（というか、糖衣構文かなぁ）を増やす、というアイディア
は、ＭＯＰ、mixinとずっと前からあるわけだが、安全性については発展途上。

俺はいま、言語、ソフトウェアとは別業界なので、個人的趣味でたまにサーベイした範囲で書いてる
けど、本職さんのアドバイスをおながいします。

644:デフォルトの名無しさん
05/12/11 14:34:24
テンプレの>>5をみればこの分野の流行はつかめると思う。

645:デフォルトの名無しさん
05/12/11 18:22:09
>>643
こんな香具師おおいの？
専攻分野と就職先がなさならないと言う意味で

646:デフォルトの名無しさん
05/12/11 18:29:18
むしろ直結してるほうが稀

647:デフォルトの名無しさん
05/12/11 18:36:25
>>645
大学院たって修士だろ。それじゃあ、専門家とは到底言い難いから、企業としては都合のよいソルジャー
扱いで、専攻も分野も関係なく配置するんじゃない。

俺、ＩＴ関係企業でリクルーターやった経験あるんだが、専攻分野イコール業務分野という奴は見たこと
ない。大体、適当に丸め込まれて、学部、高専卒と机を並べて、畑違いの分野で研修、ＯＪＴだったなぁ。

俺はこれがやりたい、という強い意志を持ってる奴は、博士まで取るべき。企業としては、博士は専門
馬鹿でもてあますことが多いのだが、研究部門でツボにはまると、とんでもない力を発揮する。

648:デフォルトの名無しさん
05/12/11 18:40:34
つーか言語開発の仕事って例えば何？
SunとかMSとかBolandみたいに明らかに言語作ってる部隊以外に何がある？

649:デフォルトの名無しさん
05/12/11 18:55:21
>>648
> つーか言語開発の仕事って例えば何？

自分がかかわった範囲でいうと、組み込み用マイコン向けコンパイラの開発、ＨＤＬをパースして
さまざまな解析、設計アシストするツールの設計だな。

コンパイラはｇｃｃでいいじゃん、と思われてるけど、特定のマイコンに特化して徹底的に
チューニングするとｇｃｃが吐くコードより２割は小さく、速くなるんだな。
ｇｃｃは、マルチアーキテクチャ対応ゆえに中間コードレベルでしか最適化できないから。

ＨＤＬはね、単純にケイデンスやメンターのツール買ってきて導入して終わり、じゃないんだよ。
自前で故障検出パタン作成用ツールを作ったり、自社の設計ルールにのっとって記述されて
いるかチェックするツール（lintみたいなもんか)を作ったりする。昔は、自社で独自のＨＤＬを
設計、実装して、大型電子式自動計算機で長時間シミュレーションをまわしたもんだよ。
運が悪いと、数日ジョブを突っ込めなかったり、ディスパッチがまわってこないなんてことは
ざらにあった。

650:デフォルトの名無しさん
05/12/11 18:56:21
組み込み機器用にgccを移植するような地味な仕事から
簡単な業務処理用スクリプトを書いたりならしたことがあるが
コレといって”言語を作る”ってのはやったことないなぁ。

651:６４９
05/12/11 19:09:57
あとは、半導体テスタ用のテストパタンを加工するための言語を独自設計してつかっていたこともある。
awk,Perlでは、汎用性ありすぎて、かえって使いにくいから。

652:デフォルトの名無しさん
05/12/11 19:16:22
>>5の一番上のリンクから適当にピックアップ＋適当に訳
>>643の安全性ってのも一番最初に出てるね

* language support for security and safety　セキュリティと安全性のサポート
* dynamic compilation and optimization techniques　動的コンパイルと最適化
* languages and compilers for parallel computing　並列計算用の言語とコンパイラ
* storage management techniques　保存管理法？
* design and processing of domain-specific languages　ドメインに特定な言語？
* compilation for distributed heterogeneous systems　分散異種系コンパイル？
* effective implementation of advanced language features　よりよい機能の実装？？
* techniques for embedded and of mobile code　組込とかモバイル向けの手法
* program representations　プログラム表記？
* interactions between compilers and architectures　コンパイラとアーキテクチャの相互作用
* program analysis　プログラム分析
* software development tools　ソフトウェア開発ツール
* program optimizations and transformations　プログラムの最適化と変換
* techniques for effective compiler construction　効果的なコンパイラ製作？

ぜんぜんわからんかったorz

653:デフォルトの名無しさん
05/12/12 08:11:40
>>649
マイコン価格の暴落と処理速度の改善で、その仕事の半分は無くなる予感。

654:デフォルトの名無しさん
05/12/12 11:27:16
>>652
* language support for security and safety
　セキュリティと安全性をサポートする言語
　（例えばPerlのテイントとかJavaのベリファイアとか。
　最近は実行時に検査する内容を減らすために静的な検査も多いので型理論と関連が深い。）

* dynamic compilation and optimization techniques
　動的な（実行時）コンパイルと動的な（実行時）最適化
　（JavaのJITコンパイルとか。言語じゃないけど昔WindowsがBitBltナントカというAPIで
　画像のビット演算処理を実行時にコンパイルっぽいことして最適化してたような記憶も。）

* languages and compilers for parallel computing
　並列計算用の言語とコンパイラ
　（並列処理の関して通信とか同期とかメモリ共有とか負荷分散とかで
　抽象化と効率の、あるいは自動化と手作業でのカスタマイズのせめぎ合いから
　丁度いい点を見出す研究。）

* storage management techniques
　メモリ管理技術
　(たとえばGCとか、もっと進んでヒープを使わないプログラミングの可能性とか。
　研究者人口は多くない気がするけどディープなマニア多し（個人的偏見）。)

* design and processing of domain-specific languages
　ドメイン固有言語（特定分野向け言語）の設計と処理
　（例えばMathematicaやMATLABみたいなのとか。ハードウェア記述言語（VHDLとか）とか。
　論文ではAT&Tが交換機の構成記述言語なんてのを提案してるのを見たことがありますな。
　Flashのスクリプト言語とかあるいはSQLとかもそうかもね。
　このテの言語は必ずしもプログラミング言語屋が作らないので時々風変わりな実装がある。
　つーか今私がWindowsに移植してる言語がそうだというのは個人的なグチ。）

655:デフォルトの名無しさん
05/12/12 11:28:21
>>652
* compilation for distributed heterogeneous systems
　異種分散システムのコンパイル
　（CPUやメモリの構成が一様でない分散システムを扱う技術ですな。
　通信とか同期とかメモリ共有とか負荷分散とか、
　あるいはそもそも各ノードの構成情報をどうやって管理伝達するかとか。）

* effective implementation of advanced language features
　言語の機能の効率的な実装
　（例えば、大昔ならサブルーチン呼び出し、
　最近ならオブジェクト指向とかアスペクト指向とか
　リフレクションとかを効率よく実行する方法について。
　多分現在コンパイラ研究で実装面の主流。激しく応用寄り。
　多分このスレの王道？）

* techniques for embedded and of mobile code
　これは
　「（他言語やデータへの）埋め込みコード
　　　＆（アプレットやエージェントとかの）移動可能なコードの技術」
　のことか
「組み込みシステム向けコード＆移動体向けコードの技術」
　のことか少々迷うな。どっちもあり得る。forとcodeに注目して英文解釈すると前者？

* program representations
　プログラムの表現
　（一瞬、インテンショナル・プログラミングみたいにテキスト表現を用いない
　開発環境と一体化した言語（？）とか連想したけど多分違ってて、
　数学的＆理論的なプログラムのモデルのことだろうな。
　だとすると業界で一番の理論寄り分野。）

656:デフォルトの名無しさん
05/12/12 11:29:28
>>652
* interactions between compilers and architectures
　コンパイラとアーキテクチャの相互作用
　（キャッシュやパイプラインや特定の命令の有無などハードウェアの構成を知ったり、
　もっと意欲的には再構成可能ハードウェアを構成したりとかも入るのかな？）

* program analysis
　プログラム解析
　（まぁ最適化や書き換えなどのためにプログラムの性質をいろいろ調べる技術ですな。
　目指す処理に必要でかつ調べやすい性質のアイディアと
　そうやって提唱された性質をプログラムから取り出すアルゴリズムがセット。
　最適化のためのループの分類やら、ある変数の定数性を調べたり、
　ポインタがどのオブジェクトを指してるか調べたり。
　あとは型検査なんかもこのジャンル。
　末尾再帰かどうかを判定するなんてのは古典ですな。
　最近では型と絡めて安全性とかも話題。多分現在コンパイラ研究で理論面の主流。）

* software development tools
　ソフトウェア開発ツール
　（例えば開発環境とかデバッガとかリファクタリング・ツールとかテスト･ツールとか
　プロファイラとかソースコード管理とかドキュメントやUML図の作成ツールとか
　GUIウィザードの類とか。）

657:デフォルトの名無しさん
05/12/12 11:29:54
>>652
* program optimizations and transformations
　プログラムの最適化と変換
　（プログラムを書き換える技術一般。
　ジェネラティブ・プログラミングのように変換の枠組みを言語的に用意して
　プログラマに分野に特化した最適化などを書かせたり、
　あるいはコンパイラの最適化のようにプログラム解析の結果を適用して
　（多くは）自動的にプログラムを書き換えたりする技術。
　プログラム特化とか、部分評価とかアスペクト指向もこの文脈で語られること多し。
　そもそもコンパイラ自身を変換（あるいは変換の集まり）としてモデル化して
　考えることもあってその場合次項とも関連が深い。
　個人的にもっと日本でも流行ってほしい分野。）

* techniques for effective compiler construction
　効率的なコンパイラ構築の技術
　（effectiveがコンパイラにかかるのか構成に掛かるのか迷うところだけど
　多分、コンパイラ開発自身の効率化のほうだと思う。
　コンパイラの構成を工夫して新しい機能や最適化とかを
　あとから追加・変更したりできる技術とかコンパイラ･フレームワークとか。）

658:デフォルトの名無しさん
05/12/12 11:35:09
>>653
確かにハードウェアが進歩すると
トレードオフが程よくバランスする点は変わるから
最適化などで個々の技術が顧みられなくなることもあるんだけども、
プログラムのほうもどんどん規模はでかく、処理は重くなる傾向はあるので
研究分野としてなくなることはなかったりする。

後は昔のハードでは速度や容量の点から
夢物語だった先進的過ぎるアイディアを
実際に試せるようになったりすることもある。

659:デフォルトの名無しさん
05/12/12 11:40:42
このすれｽｻﾏｼﾞｽage

660:デフォルトの名無しさん
05/12/12 11:50:45
訳と解説乙。
次スレから、(個人的～の部分を省いて)テンプレにするといいと思う。
以下ツッコミ。間違ってたらごめん。

>techniques for embedded and of mobile code
普通に組み込み機器向けって意味じゃない？
データに埋め込む言語って意味だと、mobileと一緒にする理由がわからない。

>program representations
program representationというと、Abstract Syntax TreeとかGraphとか、
パースしたプログラムの表現形式(なぜか大抵は中間形式)を言う事が多いと思う。

661:デフォルトの名無しさん
05/12/12 12:08:45
>>660
techniques for embedded and of mobile code
に関しては正直どっちかわからんですよ。どっちの分野もあるし。
そのうえさらにややこしい事に移動体機器や組み込み機器向のコードとして
（容量や更新の都合で。）移動可能なコードを使うことが最近ちょくちょくあるようだし。

あー、program representations
に関しては>660の言うとおりかもなぁ。
その場合、インテンショナル･プログラミングの内部構造とか
バイトコードとその仲間達とかも入るかもね。

662:デフォルトの名無しさん
05/12/12 13:22:53
>>660 にだけ突っ込むけど、他意はないから許して
(>>654-657 を検証するような目で見るガッツがないもので…)

"mobile code"は日本語で「可搬コード」とでもいうような、
プログラムが分散環境を移動するやつかもしれない。

それから、"program representations"は、プログラム意味論とかの
「プログラムをどのような *モデル* で表現するか」というテーマだと思う。

663:654-657、661
05/12/12 14:11:41
>>662
まぁ、mobile codeに関しては私もそっちが第一候補ではある。
でもembeddedと対になってたりするし、
曖昧な言葉ではあるので文脈がないとどっちにも取れる面はあるなと。

program representationsに関しても最初私もモデルかと思ったけど、
>>661的なテーマも確かにあったりしてそっちな可能性も結構あるなと。
ぶっちゃけこれも文脈を聞かないとイマイチ特定しにくいかも。

664:デフォルトの名無しさん
05/12/12 14:18:55
ACMのDigital Libraryでみつけた論文では
・high level representations
・directly interpretable representations
・directly executable representations
っていう分類してparse treeとか語ったりしてるのと、他にもwikipediaから
URLﾘﾝｸ(en.wikipedia.org)
の中でa portable program representation such as Java or CLR bytecodesって表現があるから660でいいと思う。

同じくACMのDigital Libraryから
mobile code, that is, programs traveling on a heterogeneous network and automatically executing upon arrival at the destination
という言い回しも見つけた。
たぶんモバイル機器向けってことだと思う。（よく知らないけど）

embeddedは何とも言えないけど、組み込み系以外の意味でembeddedっていう単語が使われてるのはあまり見かけない希ガス。
他言語に埋め込むとかは普通inlineじゃないかな？（勘違いしてたらつっこみよろ）

665:654
05/12/12 14:25:24
embedded languageってのを
DSLの文脈で見かけたことがあるような記憶はあるんだが
いまいち定かでなかったりして決定打に欠ける。
その上そこで組み込み機器向けのDSLの話だったのか、
別の言語に埋め込む特定分野向の簡易言語の話だったのか思い出せないので
こんな記憶があっても決定するだけの根拠なし。

666:デフォルトの名無しさん
05/12/12 14:43:52
>>654
> (たとえばGCとか、もっと進んでヒープを使わないプログラミングの可能性とか。

これすごいな。そんなの実現可能なの？
ヒープ使わないとなるとデカイ静的メモリ領域用意して全部つっこむしか思いつかない俺に喝を入れてくれ。

667:デフォルトの名無しさん
05/12/12 14:46:25
>>664
mobile codeの部分だけ反応してみる。
異機種ネットワークを移動し、到達点で自動的に実行するプログラム
ということだから、RPCっぽいことなのかなと思った。

> Programming languages for mobile code
> Tommy Thorn
> ACM Computing Surveys (CSUR)
> Volume 29 , Issue 3 (September 1997)

ただこの論文の冒頭で、「"mobile code"には文章によって様々な
意味を持つ」とか言ってる。
この論文では、「異機種ネットワークを移動し、保護ドメイン
(企業ネットワークからPDAまで)を渡り、到着点で自動的に実行する
ソフトウェア」と定義してる。

けっこう面白そうな論文ぽい。

668:654
05/12/12 14:51:51
私もちゃんとは知らないウロ覚えの聞きかじりなんだが、
何年か前に日本ソフトウェア科学会のとある研究集会あたりで聞いたような気がする。
私の気が確かならば関数型プログラミング方面から来た話で、
プログラムを解析（エスケープ解析とかあたりかなぁ）して
関数呼び出しの階層の中の適切な階層に記憶管理コードを埋め込むような話が
あったような気がする。
ただ3時から仕事上の講演会を聞きに行くので今は調べられない。
戻ってきた後でちょっとググって見る。

669:654
05/12/12 15:11:16
>>666(>>668続き）
PPL2003の招待講演だったNe（希ガス）
URLﾘﾝｸ(www.csg.is.titech.ac.jp)

"Functional Programming without Garbage Collection"
Martin Hofmann (University of Muenchen)
[PSファイル]
URLﾘﾝｸ(www.csg.is.titech.ac.jp)

670:654
05/12/12 15:13:10
ちなみに内容はウロ覚えなんで論文読んで確認されたし。
(聞きに行く講演は15時半からだった。)

671:666
05/12/12 16:03:54
>>669
㌧ｸｽ！
なるほどね。ヒープを使わずに再帰しながらスタックを使う（関数の引数に詰め込む）ってことっぽい。

672:654
05/12/12 18:37:12
>>671
ま、それを手でやったら単に面倒なだけなんだけど
プログラムを解析して自動でそういうように書き換えるって話だったように覚えるんだけど
どうだったかいね。
（最近PDFが多くて生PSのみってあんまりないから今使ってるマシンに
PSプロセッサを入れてないのでURLの論文をまだ読んでない罠。
や、まぁ入れりゃいいだけなんではあるがマンドクセぇという。）

673:デフォルトの名無しさん
05/12/12 19:48:02
スレの質が急激に向上してまいりました

674:デフォルトの名無しさん
05/12/12 20:08:44
スレの質が急激に向上してきたようだね

675:デフォルトの名無しさん
05/12/12 20:27:22
スレの質が急激に向上しているようだな

676:デフォルトの名無しさん
05/12/12 20:41:15
上がってきたと見るや躊躇いなく下げようとしているなｗ

677:デフォルトの名無しさん
05/12/12 20:42:54
>>676
このダッチワイフ野郎。（くうきよめ）

678:デフォルトの名無しさん
05/12/12 21:51:48
PLDIは組み込みシステム向けの言語設計・実装の話題も範囲内だよ。
(過去にEmbedded Systemsってセッションが開かれるくらい)

design and processing of domain-specific languagesの一部っちゃそうなんだけど、
for embedded and of mobile codeは素直に解釈すればいいんじゃないかな。

ていうか、「(他言語やデータへの)埋め込みコード」って、PHPのような言語、
って意味でいいのかな。そんな話題はPLDIでは見た事ないような…(知る限りでは

679:デフォルトの名無しさん
05/12/12 22:40:59
そろそろPOPLの時期ですね。行く人はいますか？

680:デフォルトの名無しさん
05/12/12 23:48:13
>>678
PHPって埋め込みに入るのかな？
あれってタグの外側を標準出力に流してるだけでしょ。
「埋め込める」ってのは見た目の上だけで、Zendのただの宣伝文句に過ぎないと思うんだが。
専門の人とかはどう分類するんだろ？

681:デフォルトの名無しさん
05/12/13 00:23:09
>>679
落ちたので行けません。鬱

>>680
PHPが間違いなら間違いでいいから、
正しくは何が「埋め込み」なのか教えてくれないか。できれば例で。

682:680
05/12/13 00:31:34
>>681
> 正しくは何が「埋め込み」なのか教えてくれないか。
俺もそれとほぼ同義のことを質問してるんだけど。
HTMLのscriptやstyleとかCのインラインアセンブラあたりは埋め込みじゃないかとは思うんだが、PHPはわからんと思っただけ。
ソースの見た目で定義するべきなのか機能で定義するべきなのか。
654の再登場を待つしかなさそうだなｗ

683:デフォルトの名無しさん
05/12/13 00:45:43
>>654ではないが、「他言語やデータへの埋め込みコード」って言ってるぞ。
HTMLのscriptとかがいわゆる「他言語への埋め込みコード」で
PHPがいわゆる「データへの埋め込みコード」というつもりだったんじゃないか。
(>>654がそこまではっきり意識して話したのかはわからないけどな)

どっちにしても、PLDIで見る話じゃないような……(俺も、知る限りでは)

684:デフォルトの名無しさん
05/12/13 00:52:08
>>683
正直、「データへの埋め込み」ってのがイマイチ意味がわかんないんだよなぁ。
できれば解説ｷﾎﾞﾝﾇ。
（あ、ちなみにPHPは<?php～?>の外側も含めた全体がPHPのソースなので、そもそも埋め込みではない思う）

685:デフォルトの名無しさん
05/12/13 01:14:20
>あ、ちなみにPHPは<?php～?>の外側も含めた全体がPHPのソースなので、そもそも埋め込みではない思う

そういう哲学をお持ちの方には、そうですか、としか言いようがございませんね。
あまり一般的な哲学ではないように存じますけれど。

以下、何事もなかったように議論が再開することを願います。

686:681
05/12/13 01:20:12
HTMLのscriptか。納得。
まあこんなことで議論してもしょうがないな。
しかも今見ると>>681はなんだか喧嘩腰だな。
そんなつもりは全くなかったのだが、失礼した。

(煽りの部分は無視して)>>685の言うとおり、
何事もなかったように再開してほしい。

687:デフォルトの名無しさん
05/12/13 01:41:20
ＬＩＳＰはなんなんですか

688:デフォルトの名無しさん
05/12/13 01:43:01
まあ俺はPHPを言語処理系っていう側面から見て埋め込みかどうかに疑問を思ったんだが、興味ない奴は読み飛ばしてくれい。
>>686が良い切り返ししてくれたので先に進むけど、「データへの埋め込み言語」って何だろう？
一瞬スタックオーバーランみたいにマシンコード埋め込んで攻撃することだと思ったんだけど違うよね？
あーマシン語は「言語」じゃないか・・・

689:デフォルトの名無しさん
05/12/13 01:46:03
どうか>>687をスルーしてくれ

690:デフォルトの名無しさん
05/12/13 01:55:57
embedded ruby

691:デフォルトの名無しさん
05/12/13 03:42:12
たいていのプログラミング言語に対して正規表現が使えるけど、
あれは一種の埋め込み言語であると思う。

692:デフォルトの名無しさん
05/12/13 03:57:10
>>691
なるほど。確かに。
大抵は正規表現用に、言語自体の字句解析とかとは別口のモジュールで解析してるもんな。

693:デフォルトの名無しさん
05/12/13 04:06:40
たいていのプログラミング言語に対して整数が使えるけど、
あれは一種の埋め込み言語であると思う。

って言ってるのと変わらないぞ、それ。

ていうか、「埋め込み」の厳密な定義なんてないんじゃね？
「埋め込み」の厳密な意味を議論する意義はあるの？

と思いつつも>>654に集まる期待。

694:デフォルトの名無しさん
05/12/13 04:42:12
>>693
> ていうか、「埋め込み」の厳密な定義なんてないんじゃね？
> 「埋め込み」の厳密な意味を議論する意義はあるの？

むしろembedded＝組み込み系って流れじゃなかったっけ？
このスレなんかおかしな方向に行ってるな。

695:デフォルトの名無しさん
05/12/13 04:42:20
プログラム言語なんか研究してる人がいるんだね。
あんなのは有名なのも含めて全部趣味で俺言語作ってるのと
同じレベルだと思ってた。
まさか真面目に研究した成果が、あの行き当たりばったりの
つぎはぎだらけの仕様とはねｗ

696:デフォルトの名無しさん
05/12/13 04:51:01
正直、仕様がつぎはぎになるまで使われる言語なんて全体の 0.1% にも満たないと思うんだが。

697:デフォルトの名無しさん
05/12/13 04:52:38
D言語は最初からつぎはぎでしたが何か？

698:デフォルトの名無しさん
05/12/13 04:53:02
まあいいじゃん。楽しく俺言語つくろうぜ。

699:デフォルトの名無しさん
05/12/13 04:54:28
>>697
つぎはぎってそういう意味なのか？

700:デフォルトの名無しさん
05/12/13 04:55:57
おまいら、>>695みたいな100%の釣りですらスルーできないのかよ…
>>680のような巧妙な釣り(後であからさまになったけど)ならともかく…

701:デフォルトの名無しさん
05/12/13 04:57:30
釣って釣られて盛り上がるのが醍醐味ですが何か？

702:デフォルトの名無しさん
05/12/13 04:57:59
>>700
自分たちでも理解できるレベルになったのが、
嬉しくてしょうがないんだろう。ほっといてやれ……

703:デフォルトの名無しさん
05/12/13 05:03:01
それじゃそろそろprogram representationsとインテンショナル・プログラミングの話をしようか

704:デフォルトの名無しさん
05/12/13 07:29:09
>>696
Ｃ言語の事でつか？

705:デフォルトの名無しさん
05/12/13 10:24:35
>>694
embeddedのIT業界でのデフォはそれで正解
ただ、ここは言語すれなので

706:654
05/12/13 11:07:54
期待されても大して何もでないぞ。

埋め込まれた言語っていってもHTMLファイル
（データ記述のための言語で書かれたデータなんでデータでもあり言語でもあり）
にスクリプトを～くらいしか念頭にはなかったし。
（ちなみにJavaScriptあたりをイメージしてた。PHPはよーしらんです。）

まぁ、ライブラリで提供される正規表現を言語内に埋め込まれた言語と見る
というのもあるかなとは思う。
それに整数など数値演算が埋め込まれた言語というのは
理論上そういう観点もありえなくはないかなという気がする。
こういうのは視点の問題であって一つの存在が一通りにしか解釈できないと
決まったものでもないわけで。

大体今時の言語の文法定義自身が再帰的に部分文法を"埋め込んで"定義されてるわけで
この観点から言えば埋め込まれてる言語とホスト（宿主）言語の区別ってのは
結構便宜的なモンでしかないんじゃないかと思う。
分けて考えるのが便利なときは分けて考えることもできるし、
全体で一個の文法と見るのが便利ならばそう見ても問題ない。

余談だけどそう思ってみると
数値演算につきものの演算子の結合や優先順位の規則の文法的表現ってのは
言語の文法定義の中でもそれ以外の部分とは若干異質な部分でもある。
言語定義をする人は皆、当たり前なんで慣れてしまっているけどね。

707:654
05/12/13 11:37:54
例をあげて考えてみる。

まずはライブラリなどとして提供されるユーザ定義のデータ型が
ベースとなる言語に埋め込まれてベースとなる言語を拡張している例。
データ型といっても整数演算くらいだと見慣れているだろうし、
あんまりピンとこないかもしれない。
けども複雑なテキストデータは実際にパースしないといけないわけだから
単に観念の問題ではなくて技術的にも結構言語チックではある。
既に出ている正規表現もそうだし、例えば昔、私が多項式型を作ったときには
多項式のインスタンスを文字列リテラルで初期化するようにしてみたことがあって
このような場合だと単にユーザ定義のデータ型のリテラル
（正確にはそのように見立てた文字列リテラル）の癖に
その中に「変数」（数学的には不定元か）や「演算子」なんかがあって
その"埋め込まれた"リテラルの扱いはミニ言語っぽくなる。
多項式はデータ・値として4則演算の対象であると同時に
実際に値を代入（数式処理的には「置換」）することで関数のように評価もできたりする。

逆に通常一個の言語として見ている言語の定義を
幾つかのミニ言語を埋め込んで組み立ててあるとみることも実際に可能。
例えばC++を
式言語を制御構造言語に埋め込んでそれを関数宣言言語に埋め込んで、
それらと単純型宣言言語を合わせてクラス宣言言語に埋め込んで、
さらにそれをtemplate宣言言語に埋め込んだものとして考えることもできる。
この時例えばtemplate宣言言語は関数型言語として見ることができて
実際にそのようにプログラミングすることもできるというのが
テンプレート・メタプログラミングだったりする。

708:デフォルトの名無しさん
05/12/13 12:16:37
>>706-707
禿しく納得した。あんたにゃ脱帽。

709:デフォルトの名無しさん
05/12/13 13:23:05
>>654って例の、外国人とRubyに悩まされてる人か？
もしそうならかなり煮詰まってるな。

710:デフォルトの名無しさん
05/12/13 14:06:54
>>709
な、なぜそう思うのかな？

711:デフォルトの名無しさん
05/12/13 15:08:51
>>709の元ネタがよくわからん罠

712:デフォルトの名無しさん
05/12/13 15:12:04
ｽﾚﾘﾝｸ(prog板:924番)
と思われ。

713:デフォルトの名無しさん
05/12/13 15:12:40
いずれにせよ、Rubyに好意を持っていない所から類推すると、
研究畑の人間だと思われる。

714:デフォルトの名無しさん
05/12/13 15:14:23
>654は別にRubyについては何も書いてないよな。

715:デフォルトの名無しさん
05/12/13 16:12:53
>>713
研究の人はルビー嫌いなの？

716:デフォルトの名無しさん
05/12/13 16:22:54
>>715
いんや、少なくとも>>712のリンク先のそのまたリンク先のヨーロッパ人研究者には大好評のようだゾ。

717:デフォルトの名無しさん
05/12/13 16:32:43
日本の研究の人は、自分よりも名前が売れていることでRubyを妬んでいるのです

718:デフォルトの名無しさん
05/12/13 16:44:49
妬むかどうかはさておきRubyの人が（昔はリーマンしながら作ってたようだけども）
いまやオレ言語で食えているのがウラマヤシクないと言えば嘘になろう。

プログラミング言語研究も成熟してきた昨今、
どうしても言語研究で食っていこうとすれば全く新しい俺言語の開発ではなく
言語の一部（例えば既存言語の拡張とか最適化とか）をテーマにすることに
ならざるを得ないが、言語屋の多くは俺言語への夢ってモンをやっぱり持ってるからな。

まぁそういう研究屋業界の世知辛い世情はRubyの人も（出身は言語屋なわけだし）
分かってるからあくまで彼が自称するのは言語オタクであって
研究者とは名乗らないし、開発に徹して研究者的な活動には深入りしないのだろう。

719:デフォルトの名無しさん
05/12/13 16:47:28
>>710
>>714の言う通りRubyについちゃ何も言ってないんだけど、
>>654の最後の「風変わりな実装」と「Windowsに移植」ってとこでそう推測した。
あと>>707であげられている例やら「埋め込まれた言語」に対する態度やらから
そうなのかなあと。
過去ログを調べたら、例の人を2chで初めて見かけたのは2ヶ月以上前だ。
まあ>>654とは別人だろうな。

720:デフォルトの名無しさん
05/12/13 16:50:22
>>712の引用のしかたにﾜﾛﾀ
マ板経由かよｗ

721:デフォルトの名無しさん
05/12/13 16:51:47
別段Rubyに含むところはないが
Unitテストもなしに6万行もあるバギーな拡張ライブラリはキライｗ
特にキャストやテンプレートを濫用して型がスパゲティ化しているプログラムはｗ

722:デフォルトの名無しさん
05/12/13 17:16:30
Rubyとかそういう問題じゃないな。
他の言語でもそれは嫌だぞ。

723:デフォルトの名無しさん
05/12/13 17:28:21
>>722
まぁ、そういうことですよｗ
Rubyが使われてるプログラムの移植でヒドい目に合ってるからRubyの話題も出るけど
それは多分に使い方の問題であってRubyの問題じゃない。

例えば、C++でそんなデカイもんを作るなら最初からC++で書いてRubyから呼び出すとか、
RubyでBisonやflexやXMLパーサ用のコードを生成するとかなんて構造・設計は
勘弁なってくらいでいずれも問題はRubyそのもの良し悪しや好き嫌いの話ではない。

以上誤解のないように。

724:デフォルトの名無しさん
05/12/13 17:30:15
謹んで訂正>>723

誤> 例えば、C++でそんなデカイもんを作るなら最初からC++で書いてRubyから呼び出すとか、
正> 例えば、C++でそんなデカイもんを作るなら最初からC++で書いておいてくれればよいわけで、
Rubyから呼び出すとか、

725:デフォルトの名無しさん
05/12/13 17:43:02
やっぱRubyじゃ巨大プロジェクトの開発は無理か。
せいぜい数千行程度？

726:デフォルトの名無しさん
05/12/13 18:25:20
さぁ？

「やっぱ」とあるが>>723-724はそういう問題ではないだろう。

まぁ、一応Script言語はそれ単体であまり大きな規模の開発を行うことは
想定してないとは思うので個人的にそういう目的に用いることをオススメはしないが、
どこにそのラインがあるかは自明でないのでキッパリ無理とも言い切れない。

727:デフォルトの名無しさん
05/12/13 18:27:04
>>725
別にRubyで何万行書いてもいい。
むしろRubyだけで書く限りであればそれほど問題はないと思う。
Rubyがアホなとこは、そうやって書くと思いっ切り遅くなることがわかってるから、
現実は他の速い言語で拡張ライブラリ作ってツギハギしてくしかないってこと。
拡張ライブラリが順調に動いている内はいい。が、そこでバグが発生したりすると
もうグダグダになる。拡張ライブラリが絡むと環境やモジュール連続性もなく
まず原因の特定が困難で専用のデバグ環境もない。もはやまともなデバグなど
期待できない。だから拡張ライブラリを書いた場合は事前のテストが重要となる。
が、現実はこれをまともにやっている人間は少ないようだ。
ほんとは他の言語で書かす拡張ライブラリみたいなアホな非常口は言語の
作者の目の届かない所でもあるし、とっとと廃止した方がいいのだけど、
Rubyはそれをいつまでもやめないし、既にRubyの仕様上速くなる手段は
閉ざされており、もう誰もがアホだとわかっていてもその非常口に突っ込んで
自滅するしかない、という悪循環がどうみても出来上がっていました。
ありがとうございました。

728:デフォルトの名無しさん
05/12/13 18:30:33
精子コピペすか？

729:デフォルトの名無しさん
05/12/13 18:34:25
わかってはいるが、わかるわけにはいかん！
というやつだね。
墓穴は掘り終わりましたか？

730:デフォルトの名無しさん
05/12/13 18:41:06
>>727
遅くなるって言うけど
手軽さではなく早さが求められるようなプロジェクトで
Script言語を選んじゃう見識は問われないの？

731:デフォルトの名無しさん
05/12/13 18:51:28
言語というより、開発手法や設計のお話だな。

732:デフォルトの名無しさん
05/12/13 18:52:31
この件でRubyの拡張ライブラリがヤバイ事はよくわかった。

733:デフォルトの名無しさん
05/12/13 18:59:05
そういやRubyはVMにできないみたいな話が以前のスレにあった気がするけどあれってなぜ？

734:デフォルトの名無しさん
05/12/13 19:08:15
そろそろスレ違いに気づけ。
Rubyヤバイとかは専用スレがあるんだからそこで騒げ。

735:デフォルトの名無しさん
05/12/13 19:11:25
>>725
デカいプロジェクトだと開発以前に、運用で却下。
保守できる人間が少ないのは怖いし。
もっともここで話す問題ではないが。

736:デフォルトの名無しさん
05/12/13 19:29:06
そう思うなら余所逝けよ。

737:デフォルトの名無しさん
05/12/13 22:21:58
ちょっと勘違いしてるようだけど、数千行のRubyコードって
数十万行のLispコードに匹敵する処理内容が記述できるでしょ。
なので、スクリプト言語≒簡易処理というのは全くの思い違いだと思うよ。

速度が遅くなるのは同意だけど、

738:デフォルトの名無しさん
05/12/13 22:24:27
オ～レ～～～。オ～レ～～～。ジャカジャカジャン！
ま・つ・け・ん・さあ～んば～～～

739:デフォルトの名無しさん
05/12/13 22:48:17
数十万行のC言語のコード、というならともかく・・・

740:デフォルトの名無しさん
05/12/13 23:16:02
>>737
だいぶ勘違いしてるようだけど、RubyとLisp比較するなら
記述量的にはあんま変わらない気がするけどな。
速度気にするならまともなコンパイラ付いてるLispで書いた方が
良かったんじゃないの？
Rubyと違って処理系も色々選択できるし、拡張ライブラリを
速度のために別言語で書く、みたいな馬鹿馬鹿しい問題もない。

741:デフォルトの名無しさん
05/12/13 23:27:55
Lispは、チェックを省いてプロトタイプを作ろうとすると、めちゃくちゃ少ないコード記述量に
なるけど、パフォーマンスを考えてチューニングしようとしたり、エラーチェックを厳密に
やろうとすると他の言語と同じぐらいになってしまう。

742:デフォルトの名無しさん
05/12/13 23:55:27
>>741
憶測だけで言ってない？
つか、付けたしだけで速くなるなら別の言語で書き直すよりは
そっちの方がいいよね。
下のサイト見ると行数もそれほど変わらないし
チューニングコード入れなくても速いみたいだが。
元々速度では勝負にならん差があるけど。

Ruby
URLﾘﾝｸ(shootout.alioth.debian.org)

Lisp
URLﾘﾝｸ(shootout.alioth.debian.org)
URLﾘﾝｸ(shootout.alioth.debian.org)

743:デフォルトの名無しさん
05/12/14 00:14:14
>>742
Rubyが速度で上回るのはstartupだけか。
ひでえなこりゃ。
Rubyってコンパイラ作れないの？

744:デフォルトの名無しさん
05/12/14 00:31:28
ハッキリ言ってしまえば、速度なぞ時間がすぐに解決するんだけどなw
リアル社会を知らない音質Lisperはアクキンにしる！

745:デフォルトの名無しさん
05/12/14 00:33:18
>>743
コンパイラは作ってもあまり意味がないというか、
そもそも作る人がいないという話だった気がする。

746:デフォルトの名無しさん
05/12/14 00:33:43
>>743
作れるはずだし、
作ってる人も（複数人）いるっぽい。
実用になったという話は聞いてないけど。

747:デフォルトの名無しさん
05/12/14 00:41:45
>>744
Ｒｕｂｙはそう言われてきたＪａｖａと事情がだいぶ違うし
言語仕様的に無理かも。
あと１０年待とうね。

748:デフォルトの名無しさん
05/12/14 00:44:51
プロセッサがマルチコア方向にシフトしてきてるっぽいので、
ネイティブスレッドに対応しないと辛いかもね。

749:デフォルトの名無しさん
05/12/14 00:49:15
>>742
おいおい、そこのコードは速度を上げるために
かなりチューニングしてるぞ。
少なくかけるところをあえて速度が上がるような
書き方してる。

750:デフォルトの名無しさん
05/12/14 00:49:52
だから、コード量は、本当はlispはめちゃくちゃ少ないよ。

751:デフォルトの名無しさん
05/12/14 00:50:18
PythonはPython自身で書かれたり他の言語やVMに変換して速くしたりできるっぽい
そういう意味ではPythonの方は将来期待できるかも

752:デフォルトの名無しさん
05/12/14 00:53:09
これなんて象徴的だよな。
本当は5行で終わるところを12行かけて書いてる。
コメントにその5行のコードが書いてあるｗ

URLﾘﾝｸ(shootout.alioth.debian.org)

753:デフォルトの名無しさん
05/12/14 00:56:25
Pythonって構文をちょっと変えたLispそのものだからな

754:デフォルトの名無しさん
05/12/14 01:03:49
出来るだけタイプ量少なくすることで競うならperlが最強。

755:デフォルトの名無しさん
05/12/14 01:04:33
>>752
そのコメント部だけのコードでも動的言語の割には結構速度出るね。
やっぱこの差はネイティブコンパイルしてるからかね。

756:デフォルトの名無しさん
05/12/14 01:04:59
>>754
C++は最下位。

757:デフォルトの名無しさん
05/12/14 01:08:10
>>756
COBOLだろ

758:デフォルトの名無しさん
05/12/14 01:12:24
>>754
LispやSmalltalkなんかは前提とするコアイメージ弄くればなんでも1行で書けるよ。
それに配布物も本体とコアファイルの２ファイルだけで
perlみたいにごちゃごちゃライブラリディレクトリ掘ったりする必要ないし。

759:デフォルトの名無しさん
05/12/14 02:01:41
いや待て、言語同士を競争させるのにコアやライブラリを弄っちゃいかんだろ。

760:デフォルトの名無しさん
05/12/14 02:13:34
Smalltalkならいじるのが当たり前なんだが

761:デフォルトの名無しさん
05/12/14 02:31:30
ライブラリ弄っていいんだったらどの言語でも1～数行で終わって
比較する意味ないじゃん。

762:デフォルトの名無しさん
05/12/14 03:17:26
ライブラリ弄るとかいう発想じゃなくて、LispやSmalltalkでは
言語環境が最初から違うスタート地点に立てる、という観点が
使ったことのない人には想像つかないのかな。
OSで言えば最初からスタンバイ状態になってると考えればいい。
そもそも「出来るだけタイプ量少なくすることで競う」って話だし。

763:デフォルトの名無しさん
05/12/14 03:19:35
いやいや駄目でしょ。
Lispは結構知ってるし、Smalltalkもある程度は知ってるけどさ。
標準ライブラリで、標準のコアで勝負でしょ。

764:デフォルトの名無しさん
05/12/14 03:22:05
まあ拡張を定義した部分まで行数に入れるんだったら
もちろんいい。

765:デフォルトの名無しさん
05/12/14 03:23:18
他の言語じゃ不可能な時点で勝負にもなんないね。

766:デフォルトの名無しさん
05/12/14 03:23:25
あと、その言語として自然な記述で比べること。
7行プログラミングスレみたいな奇怪なコードならCでも短くなるけど、
そういうコードで比べるのも反則。

767:デフォルトの名無しさん
05/12/14 03:23:52
>>765
別に不可能じゃないよ。ライブラリなんてどの言語でも書ける。

768:デフォルトの名無しさん
05/12/14 03:27:34
>>766
ああいう奇怪なコードで書くのがPerlの自然な流儀ですが何か？

769:デフォルトの名無しさん
05/12/14 03:27:56
こんな夜中に何を必死になってんだ

770:デフォルトの名無しさん
05/12/14 03:46:42
>>767
知ってていってるならしょうがないが
開発環境と実行環境が一体化してるもんだから
単なるライブラリとは違う。

771:デフォルトの名無しさん
05/12/14 03:59:21
いくらそんなこと言ったって、同じにしなくちゃ駄目だろう。
やっぱりライブラリを作ってこれ使えば一行とか言ってるのと同じぐらい
反則に俺には感じる。

772:デフォルトの名無しさん
05/12/14 04:00:09
いい加減宗教戦争は勘弁して下さいよ、本当に。

773:デフォルトの名無しさん
05/12/14 04:56:09
スレの質が急激に低下してまいりました

774:デフォルトの名無しさん
05/12/14 05:33:44
>>1 に出てくる語句について教えてください。

「データ分散」って何ですか? NUMAとかのヘテロなアーキテクチャでの話?
「スクラッチメモリ」って何ですか? CellのSPEが持っているような
プロセサ固有のメモリ?

775:デフォルトの名無しさん
05/12/14 05:54:04
>>773
おまえが上質なネタを投下しろよ

776:デフォルトの名無しさん
05/12/14 06:08:41
>>775
おまえが上質なネタを投下しろよ

777:デフォルトの名無しさん
05/12/14 06:51:03
>>774
>>1に聞けよ

778:デフォルトの名無しさん
05/12/14 08:16:38
HTML化されてる最初のスレはかなりレベル高かったみたいだね。
今の>>1-5のテンプレはいつごろからあったんだろ？

779:デフォルトの名無しさん
05/12/14 14:52:11
>>774
厳密にはともかく概ねそれで合ってんじゃない？

>>772
宗教戦争になるのは
優劣を計ろうとしていながら物差しがちゃんと定義＆評価されてないからだと思う。
言語設計ということを理解するに当たって既存の言語を比較対照することそのものは
悪くないと思うのだけれど、基準が独りよがりすぎるから感情論になる。

それにRubyがでてくるのは話の流れとしてまだわかるが
Lispはいくらなんでも唐突過ぎる。
イキナリRubyと比較してるが使われる局面も設計時の背景や目的も明らかに違うから
何を比較したいのだかよーわからんことになってる。
言語設計の課題は設計目的にどのくらい適っているかどうかだし、
言語選択の問題は開発対象の性質に言語がどのくらい適合しているかだろう。
いずれにせよ目的も基準もハッキリしない漠然とした優劣は問題ではない。

780:デフォルトの名無しさん
05/12/14 14:55:35
プログラムの長さ、記述量が問題になっていたようだが…

情報理論の教えるところによって符号化という視点で考えれば
プログラムもまたプログラムの仕様という情報を符号化したもの。
言語が違えば符号化の体系が違うと考えられるわけで、
単純にコードの文字数を云々することにはあまり意味がない。

例えばコードの中でよく使われるパターンが短く、
あまり使われない構文が長くといった設計上の戦略もある筈だから
どういう目的で設計されているかということを考える必要がある。

また誤り訂正符号などの例のように純粋に内容の情報
（プログラムなら例えば中心となる内容はデータ構造とアルゴリズムだろう）
だけでなく誤りを見つけやすくするための付加情報が含まれるケースもある。
特にプログラミング言語という符号体系は人と機械の間をとりもつ際の
ユーザ側インターフェイスであるわけで
人の認知科学的な処理特性を無視することはできない。

例えば制御文と式と宣言文の構文が分かれていたり、
意味が連想しやすい名前がキーワードに使われるとか、
ユーザが把握しやすい動作モデルを提供するというのは
文字数単位でコード量（端的にはタイプする量）が増えても
そういう観点からは意味がある。

781:デフォルトの名無しさん
05/12/14 15:01:42
>>778
4からじゃね？

782:デフォルトの名無しさん
05/12/14 15:07:53
>>779-780
なげーよ
日記なら他所でやれ

783:デフォルトの名無しさん
05/12/14 15:20:39
言語の設計には必ず設計目的があり、
設計目的はその時点での背景がある。
そういうことを考えずに闇雲に優劣をつけようとするのは無意味なことだ。

以下に技術的背景が言語設計に及ぼした影響について幾つか例を挙げる。

まず言語は既存言語の存在を前提にしている。新しいものは特にそうだ。

Javaの例で言えば：
JavaはCが存在していて必要ならば使うことができることが前提だから
比較的汎用指向の言語でありながら
Cで書くことが適切であるようなハードウェアレベルの記述機能を
潔くスッパリ切り捨てた設計ができている。
例えば、バイトコード＆仮想マシンの採用やポインタ演算の放棄などがそうだろう。
Javaではそれらと引き換えにより厳密な静的型検査が可能になり、
それがバイトコードの検証といったセキュリティ技術、
ひいてはモバイル・コードの実現といった当初の設計目標を支援している。

784:デフォルトの名無しさん
05/12/14 15:21:25
また、言語は設計当時の技術水準を前提にして設計されているし、
当時重要であった課題を優先して解決するように設計されている。

FORTRANの例で言えば：
FORTRANの行指向な言語設計は行単位に1枚のカードが使われていた
ハードウェア技術に大きな影響を受けている。
構文解析が案外面倒な面倒な算術式のパース技術が取り入れられた背景としては
当時算術演算を手軽に記述できる言語が他になく正にそれが求められていたからだ。
その一方で計算機のメモリやディスクの容量が限られていたこともあって
プログラム規模が当時は現代より比較的小さかったので
ユーザ定義のデータ型への需要は相対的に小さかったためそういう機能は貧弱だ。

LISPの例で言えば：
何よりAI研究で必要な柔軟なデータ形式である
リンクリストやそれを利用したツリーを簡単に操作できることが優先目標だったから
それが充実している一方で、算術式はお世辞に読みやすいとは言えないし、
効率のよいランダムアクセス可能な配列といった機能はなかった。
（近年LISPを語る際によく言及される、
メタな機構が充実したのはちょっと後のことで誕生当時の古LISPでのことではなかった筈だ。
言語のメタな構造がLISPが解く意図するツリー構造と相性がよかったこと、
元々の適用分野がAI研究だったことなどが影響しているのだろう。）

785:訂正
05/12/14 15:24:35
解く意図する→得意とする

786:デフォルトの名無しさん
05/12/14 15:25:54
ここは公開オナニー劇場ですか

787:デフォルトの名無しさん
05/12/14 15:26:55
宗教戦争なんてしてたっけ。

788:デフォルトの名無しさん
05/12/14 15:27:18
>>782
日記など書く趣味はないよ。
言語戦争の発端のグチを>>654-の記事の一部にポロっと書いた責任を取って
正攻法で技術論に戻して収拾しようとしてるだけ。

789:デフォルトの名無しさん
05/12/14 15:33:02
ｳｻﾞｽ
２、３行で要約しろよ

790:デフォルトの名無しさん
05/12/14 15:36:33
冗長でも誤りを見つけやすくするため云々は一理あるけど、
冗長に書かないといけないせいで入るバグもあるから
トレードオフであることは意識しないとね。

「把握しやすい」ってのも、
その感覚はユーザによってばらつきがとても大きい。
これを意識しないで話すと宗教戦争になる。

791:デフォルトの名無しさん
05/12/14 15:41:37
>>787
顛末は例によってRubyが貶されて信者が暴れただけ。

次ページ