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

1 ：デフォルトの名無しさん：2005/11/06(日) 19:45:18

プログラミング言語処理系の開発に興味のある人達のスレッドです。

字句解析・構文解析から，データフロー解析，ループ並列化，データ分散，SSA変換，
CPS変換，レジスタ割付，命令スケジューリング，ソフトウェアパイプライン，
SIMD命令生成，VLIW向けクラスタリング，スクラッチメモリ向け最適化，リンク時最適化，
JIT，動的バイナリ変換等の各種最適化，それにVM，GC，低消費電力化などなど。
意味論に関する話題も歓迎です。

前スレ
1 http://pc.2ch.net/tech/kako/981/981672957.html
2 http://pc2.2ch.net/test/read.cgi/tech/1021136715/
3 http://pc5.2ch.net/test/read.cgi/tech/1070089173/
4 http://pc5.2ch.net/test/read.cgi/tech/1100097050/
5 http://pc8.2ch.net/test/read.cgi/tech/1106129164/
6 http://pc8.2ch.net/test/read.cgi/tech/1115335709/
7 http://pc8.2ch.net/test/read.cgi/tech/1129287390/

関連リンクは多分 >>2-10 あたり

2 ：デフォルトの名無しさん：2005/11/06(日) 19:45:58

★コンパイラ一般

・色々なツールの紹介
　http://catalog.compilertools.net/
・コンパイラ関連のリンク集
　http://www.ulis.ac.jp/~nakai/rel_web_compilers.shtml
・スクリプティング言語資料室(仮) (リンク集)
　http://www.kt.rim.or.jp/~kbk/
・Compiler Construction
　http://rananim.ie.u-ryukyu.ac.jp/~kono/lecture/2000/compiler/index.html
・Compiler Construction　(1997)
　http://rananim.ie.u-ryukyu.ac.jp/~kono/lecture/1997/compiler/compiler.html
・情報システム工学実験 III コンパイラ・コンパイラ
　http://math.cs.kitami-it.ac.jp/~fuchino/proin/experimentIII-2000/jikken.html
・OS/Programming 簡単な C コンパイラ
　http://www.csg.is.titech.ac.jp/~chiba/lecture/os/
・正規表現
　http://hp.vector.co.jp/authors/VA007799/viviProg/doc_regexp.htm
・コンパイラ研究・開発情報の一集積所
　http://compilers.cs.uec.ac.jp/
・Links and Selected Readings
　http://www.gnu.org/software/gcc/readings.html
・国産のコンパイラ共通インフラストラクチャCOINS
　http://www.coins-project.org/

3 ：デフォルトの名無しさん：2005/11/06(日) 19:47:47

★字句・構文解析

・Lex and YACC primer/HOWTO （邦訳）
　ttp://www.linux.or.jp/JF/JFdocs/Lex-YACC-HOWTO.html
・Turbo Pascal Lex/Yacc
　ttp://www.musikwissenschaft.uni-mainz.de/~ag/tply/tply.html
・Jim Roskind's LALR(1) C++ Grammar
　ttp://www.empathy.com/pccts/roskind.html
・Flexと Bisonを同時に使う
　ttp://guppy.eng.kagawa-u.ac.jp/~kagawa/1999/SysProg/both.html
・KITE_ASM (yacc,lex)
　ttp://www.arch.cs.kumamoto-u.ac.jp/project/kite/kiteasm/
・bison用のC++ LALR skeleton
　ttp://www.bj-ig.de/software/bison/
・ANTLR（非yaccのパーサジェネレータ）
　ttp://www.antlr.org/
・JavaCC(Java Compiler Compiler)
　ttps://javacc.dev.java.net/
　ttp://village.infoweb.ne.jp/~fwif0083/program/java/javacc/javaccgrm.html
　ttp://www.asahi-net.or.jp/~DP8T-ASM/java/tips/JavaCCHelloWorld.html
・CUP, JLex, JFlex
　ttp://www.cs.princeton.edu/~appel/modern/java/ (JLex, CUP)
　ttp://www.jflex.de/
・SableCC
　ttp://www.sablecc.org/
・￢＜＞＜∪∪ （notavacc）LALR(1)
　ttp://ne.cs.uec.ac.jp/~koto/notavacc/
・boost::spirit（C++のテンプレートでEBNFの構文を模倣）
　ttp://spirit.sourceforge.net/
　ttp://boost.cppll.jp/HEAD/libs/spirit/index.html（マニュアル日本語化プロジェクト）
　ttp://www.fides.dti.ne.jp/~oka-t/cpplab-boost-spirit.html

4 ：デフォルトの名無しさん：2005/11/06(日) 19:48:38

★ごみ集め

・GC FAQ -- draft
　http://www.iecc.com/gclist/GC-faq.html
・A garbage collector for C and C++
　http://www.hpl.hp.com/personal/Hans_Boehm/gc/
・一般教養としての Garbage Collection
　http://www.is.s.u-tokyo.ac.jp/~vu/01/jugyo/processor/process/soft/compilerresume/gc/gc.html
・Garbage Collection : Algorithms for Automatic Dynamic Memory Management
　http://www.amazon.com/exec/obidos/ASIN/0471941484/

★処理系,スクリプト

・kikyou.info (吉里吉里というゲームのスクリプト)
　http://kikyou.info/
・tiny C コンパイラ (C)
　http://www.watalab.cs.uec.ac.jp/tinyCabs.html
・6809用 Micro C コンパイラ
　http://www.axe-inc.co.jp/pds/mc09.html
・Portable Object Compiler (Obj-C >> C のトランスレータ？)
　http://users.pandora.be/stes/compiler.html
・自作コンパイラの部屋(PL/1, Pascal等)
　http://www.tokumaru.org/
・『Rubyソースコード完全解説』サポートページ
　http://i.loveruby.net/ja/rhg/
・『やさしい Lisp の作り方』『やさしい Java インタプリタの作り方』
　http://www.okisoft.co.jp/esc/go.html
・MSによるPEフォーマット仕様書(日本語)
　http://www.interq.or.jp/chubu/r6/reasm/PE_FORMAT/intro.html

5 ：デフォルトの名無しさん：2005/11/06(日) 19:49:35

★学会

・PLDI
　http://research.microsoft.com/conferences/pldi06/
　コンパイラの研究に関する最新成果を知りたければまずはここ。
・POPL
　http://www.cs.princeton.edu/~dpw/popl/06/
　PLDIよりは理論寄りだが大いに参考になる。
・ICFP
　http://icfp06.cs.uchicago.edu/
　関数型言語に関する学会。とても難しい。
・OOPSLA
　http://www.oopsla.org/
　オブジェクト指向言語に関する学会。最近はやや低調？
・ICCC
　http://www.st.cs.uni-sb.de/cc/
　ヨーロッパ系。派手さはないが堅実。

6 ：1：2005/11/06(日) 19:55:29

つうわけで立てました。>>3だけリンクがhttp～になってないのは、
http://が多すぎます、と怒られたため。

7 ：デフォルトの名無しさん：2005/11/06(日) 20:02:13

キチガイ隔離スレ立て乙です。

8 ：デフォルトの名無しさん：2005/11/06(日) 20:04:45

で、教材に向いているコンパイラってなによ

9 ：デフォルトの名無しさん：2005/11/06(日) 20:07:04

>>8
マジレスするとMinCaml

10 ：デフォルトの名無しさん：2005/11/06(日) 21:02:37

書籍関係のテンプレは？

11 ：デフォルトの名無しさん：2005/11/06(日) 21:05:41

>>1乙
取りあえず、禁句一覧は以下の通りとする。
（以下よろ）

12 ：1：2005/11/06(日) 21:36:56

>>10
ごめん、飛ばしたらしい。

★参考書籍

・コンパイラ　原理・技法・ツール　１＆２
　http://www.amazon.co.jp/exec/obidos/ASIN/4781905854/
　http://www.amazon.co.jp/exec/obidos/ASIN/4781905862/
　通称ドラゴンブック。バイブル。
・コンパイラ構成法　原田賢一
　http://www.amazon.co.jp/exec/obidos/ASIN/4320029224/
　http://www.hara.cs.keio.ac.jp/kCompiler/　(ソース、正誤表のダウンロード)
・プログラミング言語処理系岩波講座ソフトウェア科学〈5〉佐々政孝
　http://www.amazon.co.jp/exec/obidos/ASIN/4000103458/
　一冊で済ませたい人へ。
・コンパイラの構成と最適化中田育男
　http://www.amazon.co.jp/exec/obidos/ASIN/4254121393/
　最適化がメインだが、構文解析からコード生成までの基本事項も解説されている。
・コンパイラの仕組み　渡邊　坦
　http://www.amazon.co.jp/exec/obidos/ASIN/4254127081/
　薄い奴(185p)を読みたい人に。
・21st Century Compilers (Alfred V. Aho, Sethi, Ravi Sethi, Jeffrey D. Ullman, Monica Lam)
　http://www.amazon.co.jp/exec/obidos/ASIN/0321131436/
　まだ出ていない。
・スモールコンパイラの制作で学ぶプログラムのしくみ
　http://www.cbook24.com/bm_detail.asp?sku=4774121770
　初心者向けの優しい解説本。

13 ：デフォルトの名無しさん：2005/11/06(日) 21:54:48

>>1 に書いてある低消費電力化まで
考慮する処理系なんてあるの？

14 ：前スレの971：2005/11/06(日) 21:57:31

拡張ライブラリを書くのに、俺言語のソースを文字列リテラルの形で
C中に埋め込むのはありか、と質問していたものです。

現時点の案としては、
a)文字列リテラルでCにソースを埋め込む。
b)バイトコードを埋め込む。
c)シリアライズしたものを埋め込む。
d)Cでゴリゴリ書く。
ってとこですね。

b)はバイトコード実行系でないからパス、
c)は、なにしろCなので、シリアライザもデシリアライザも書くのが大変だからパス、
d)は、やっぱり書くのが面倒(いちいち関数呼んで型を変換したり、オブジェクトを
　GCの管理下に入れたりするのが)。

ってことなんですが、こういったデメリットを上回るデメリットがa)にあれば
やめるけど、今のところ思いつきません。
パースなんて重い処理じゃなし、それも1回動くだけだし。

前スレ973に笑われるだけなら、笑わせとくよ俺は。情報科出じゃないし。

というわけで引き続き情報よろしく。

15 ：デフォルトの名無しさん：2005/11/06(日) 22:03:58

いまどきのプログラム言語の作り方（randy (著)）
って、買ってみた人いる？
どんな感じなんでしょ。

16 ：デフォルトの名無しさん：2005/11/06(日) 22:07:34

http://pc8.2ch.net/test/read.cgi/tech/1130602100/138

17 ：デフォルトの名無しさん：2005/11/06(日) 22:11:17

>>13
少なくとも研究レベルではよく聞くね。

18 ：デフォルトの名無しさん：2005/11/06(日) 22:11:52

>>15 書名でぐぐれば目次が見つかる

19 ：14：2005/11/06(日) 22:44:18

俺言語の改良点早くかきこめ馬鹿
特にLispで威張ってたやつらw

20 ：デフォルトの名無しさん：2005/11/06(日) 22:51:15

>>18
Amazonはチェックしたんだけど、良さそうな気がする

21 ：デフォルトの名無しさん：2005/11/06(日) 22:54:03

>>19
ごめん。全然気付いてなかった。
Lisper じゃないけど、俺は普通に a で良いとおもう。

22 ：デフォルトの名無しさん：2005/11/06(日) 22:57:23

このスレでは異端かもしれんが、
難しい理論や高度な技術よりも、
使い易いってことの方が言語としては大切な気がするんだけど。

すまん、スルーしてくれ。

23 ：デフォルトの名無しさん：2005/11/06(日) 23:10:50

>>19
とりあえず、Lispに出来るだけ近い言語にしとけばいいと思う。

24 ：本物の14：2005/11/06(日) 23:16:54

なんのこっちゃ。
わけわからん行動する奴がいるなあ...

25 ：本物の14：2005/11/06(日) 23:21:12

肝心のことを書き忘れた。

>>21
>Lisper じゃないけど、俺は普通に a で良いとおもう。

どうもです。
私には a)の方法で特に問題があると思えないんですよね。
やっぱりa)でいくとします。

26 ：デフォルトの名無しさん：2005/11/06(日) 23:22:25

急に新スレに移ったので驚きました。
あわてて前スレを読み終わったところです。

前スレの最後のほうで、ECMAScript(JavaScript)にはLispと同じような
言語的能力がある、という話が出ていたのですが、それはどのような点なのですか？
Lispは簡単なプログラムが書けるくらいですが、是非教えてください。

27 ：デフォルトの名無しさん：2005/11/06(日) 23:38:34

>>14
a)でいいと思うけど、.hに入れるか別の拡張子にして
#includeするのを薦めてみる。

>>26
GC, クロージャ, 関数オブジェクトあたりだと思う。
関数の合成とかカリー化とかできて、その辺がLispと似通ってる。
この辺はRubyでもサポートされてる。

28 ：デフォルトの名無しさん：2005/11/06(日) 23:48:07

> カリー化とかできて、
できたっけ？

> この辺はRubyでもサポートされてる。
されてたっけ？

29 ：14：2005/11/06(日) 23:49:36

>>27
>.hに入れるか別の拡張子にして#includeするのを薦めてみる。

そうすることで、#includeされる方のファイルでは俺言語そのままで書けるなら
いいんですが、実際にはそうも行かないと思ってるんですけど、
27さんが想定しているメリットはそれ以外のことですか?

30 ：デフォルトの名無しさん：2005/11/06(日) 23:58:13

>>29
ソースコード中に点在するのは避けた方が良いってことじゃないか？

31 ：デフォルトの名無しさん：2005/11/07(月) 00:00:24

>>26
http://d.hatena.ne.jp/brazil/20050829/1125321936

>Cの皮を被ったLisp
>JavaScriptには、Cのような中括弧や、不格好なforステートメントがあるため、
>一般的な手続き型言語のように見えます。しかし、それは間違っています。
>JavaScriptは、CやJavaよりも、LispやSchemeのような関数型言語と多くの
>共通点を持っているのです。JavaScriptには、リストの代わりに配列があり、
>プロパティリストの代わりにオブジェクトがあります。関数はファーストクラスであり、
>クロージャを備えています。*2括弧のバランスをとる手間なしに、ラムダを利用できるのです。

32 ：デフォルトの名無しさん：2005/11/07(月) 00:19:38

>>29
makefile使うなら俺言語→ヘッダの簡単なスクリプト書いて規則に入れちゃえば？
周辺ライブラリの一部を俺言語で実装するというのは結構Unix系のこんなにスクリプト
が流行る前の言語で見た気がする、ただ組み込み前提では無い為よく見かけたのは起動時
に初期化スクリプトを読むorVMイメージをロードする、もしくはCへのトランスレータ
を介して自己に結合するという方法だった気がするけど

33 ：デフォルトの名無しさん：2005/11/07(月) 00:20:44

もうグダグダだなこのスレ。S/N比が悪すぎる。

次スレからは構文解析より後(Lispならmacroexpandの後)だけを対象に限定しようぜ。
表層だけしか見ない厨がよってたかって暴れたあげく
処理系開発と全然関係ない話するバカまでわいてくる現状はかなわん。

既成言語を出すのも、その言語自体の実装に関する話題か、その言語を使って
言語処理系を実装する話題のみに限定し、それ以外は禁止で構わないと思う。

どの言語がいいわるいだの開発体制がどうだのという話はどっか隔離スレを
作ってやってくれ。

34 ：14：2005/11/07(月) 00:22:05

>>32
です。その、俺言語→Cの変換スクリプトを俺言語で書いて、
miniperlのような形でまずmakeし、そのmini俺言語で変換スクリプトを
動かして.cを生成するのがいいかなあ、と思ってます。

35 ：デフォルトの名無しさん：2005/11/07(月) 00:51:15

昔はあんなにぼろくそに言われたJavaScriptもこんなに人気になるんだな。
ブラウザ以外の用途でも結構お目にかかるようになってきた。

36 ：デフォルトの名無しさん：2005/11/07(月) 01:05:17

>>35
例えばどこで? SVGとかかな

37 ：デフォルトの名無しさん：2005/11/07(月) 01:06:23

>>36
Flash、PDF、Macのダッシュボードとか。

38 ：デフォルトの名無しさん：2005/11/07(月) 01:08:29

ダッシュボードは違うか

39 ：デフォルトの名無しさん：2005/11/07(月) 01:11:44

>>33
お前はLispでもいじってろw

40 ：デフォルトの名無しさん：2005/11/07(月) 01:14:39

ダッシュボードもそうだしLaszloというRAIフレームワークもJSだ。
RhinoやSpiderMonkyなど組み込みもあるし、組み込み用ライブラリが増えるといいな

41 ：デフォルトの名無しさん：2005/11/07(月) 01:22:56

だれか >>28 に答えて。俺も気になる。

Flash や Laszlo は ActionScript じゃないの？
ていうかさすがにこういう話題のときは ECMAScript って言おうよ。

42 ：デフォルトの名無しさん：2005/11/07(月) 01:25:04

まあESだな。エンジョイプログラミング復興のためにもスクリプトアプリには頑張ってもらいたい。

43 ：デフォルトの名無しさん：2005/11/07(月) 01:30:16

JavaScriptの開発はデバッグが苦しい、
というのは旧世代的な思い込みでしょうか。

44 ：デフォルトの名無しさん：2005/11/07(月) 01:33:06

>>41
http://www.google.com/search?hl=ja&q=JavaScript+%E3%82%AB%E3%83%AA%E3%83%BC%E5%8C%96&lr=
http://www.google.com/search?hl=ja&q=Ruby+%E3%82%AB%E3%83%AA%E3%83%BC%E5%8C%96&lr=

45 ：デフォルトの名無しさん：2005/11/07(月) 01:33:45

IEならスクリプトデバッガがあるし、狐ならJSコンソールがある。
変数監視系のデバッグツールまでいくと聞かないけどね。

46 ：デフォルトの名無しさん：2005/11/07(月) 01:44:24

>>45
デバッガの有無というより、形無し言語だからでは?

47 ：41：2005/11/07(月) 01:51:57

ははぁ、どっちもarityメソッドとか使って
ライブラリにできなくもない、という感じですか。
勉強になりました。ありがとう。

48 ：デフォルトの名無しさん：2005/11/07(月) 01:53:40

ふむ。しかしまぁ、JSでデバッガが必要な規模のコードなんて書かないけどねぇ。
Ajaxなら必要なのかも知れんけど1000行程度の外部JSファイルで1アプリ分かけない？

49 ：デフォルトの名無しさん：2005/11/07(月) 02:02:09

デバッグツールなんて、ベースがLISPだったら簡単に作れるのにね。
こういうレベルの話ばっかだからダメなんだよ。
わかれよ。

50 ：43：2005/11/07(月) 02:09:10

かつては、型がない、開発環境がない、実装間の互換性がない、の三重苦でしたが、
後ろ2つまではわりと解決されてるっぽいですね。
型はまあ、趣味の問題かなぁ。

>>49
言語ユーザとしての話に過ぎませんでしたね。すみません。

51 ：デフォルトの名無しさん：2005/11/07(月) 02:14:09

コードでエラーはなくともIEが突然落ちるJSはまだまだ怖い。

52 ：デフォルトの名無しさん：2005/11/07(月) 04:27:21

そういや、前スレの埋め立て時に出てた話題だケド、
GCまで作ってる人って、そんなに珍しいの？
俺の作ってる俺スクリプトでは、今、GCを作ってる途中なんだが・・・

53 ：デフォルトの名無しさん：2005/11/07(月) 05:11:32

そんなに珍しくも無いんじゃない？明示的削除構文の無い言語でオブジェクト
をサポートする言語なら必須でしょ。値,文字列,配列のサポートのみで
配列内に配列を入れない制約をして良いならリファレンスカウンタで処理できるけど

ただ自分の場合はCのスタックを直にスキャンするような方式にはしなかった
けど、その分ちょっと処理が重くなったかもしれない

54 ：デフォルトの名無しさん：2005/11/07(月) 05:15:20

ECMAScript作った時はクロージャサポートの為構文木もGC対象にしなきゃいけなかった
んでちょっとめんどくさかった、それ以外良い方法が思いつかなくて

55 ：デフォルトの名無しさん：2005/11/07(月) 05:27:44

このスレ的にはファイナライザってどうなんでしょ、俺言語でnativeのdll呼び出し
できるように作った都合上native側で確保したリソースの管理・エラーレポート用
にファイナライザを実装したのですが、GCとの相性が悪くてかなり気持ち悪い思い
気分だったのですが

56 ： ◆LispYaxRvY ：2005/11/07(月) 06:54:53

>>55
GC対象になったファイナライザ付きオブジェクトは、
ファイナライザ用のスタックに一端退避して保護対象にする。
GC後にそのスタックの各々に対してファイナライザを起動、
処理が終わったオブジェクトは処理済みマークか何かを付けて保護から外す。
処理済みオブジェクトは次回のGCか何かで回収する。
こんなんでどうかな。

57 ：デフォルトの名無しさん：2005/11/07(月) 07:03:38

>>31
俺はLispは知らないECMAScripterなんだけれど、
ラムダが利用できますってどういう意味なんだろう。

クロージャは頻繁に利用しています。便利すぎる。

58 ：デフォルトの名無しさん：2005/11/07(月) 07:56:47

>>56
ふむふむ、現状ではGC実行中に全てのGCを止めた状態でファイナライザを実行して
いるのですが、そのように2本化してしまってファイナライザ実行中は通常GCのみ許可、
ファイナライザ処理のみ禁止としてしまう方が融通効きそうですね、アドバイス
ありがとうございます、早速検討してみる事にします。

59 ：14：2005/11/07(月) 08:11:32

>>52
>GCまで作ってる人って、そんなに珍しいの？

珍しいと思い込んでる妄想クンがひとり暴れてただけでしょ。

60 ：デフォルトの名無しさん：2005/11/07(月) 08:11:43

>>57
ラムダは無名関数リテラルが扱えるという意味で、括弧のバランスはLISPの
大量の括弧を書く話と対比してと受け取った、間違えてるかもしれないけど。

ECMAScriptはクロージャにおけるthisが呼び出しコンテキストに左右されてしまい
必ずしもオブジェクトを指しているとは限らない所と、感情的にだけど宣言なし
で未宣言の変数を使った時に宣言先がグローバルになる所、それからクラスメンバ
の未宣言がエラーにならない所が気持ち悪く感じた。

最新の4th(普及してないけど)での型宣言の書式も冗長な気がするし
でも文句は多いけど頑張って欲しいとは思う。

61 ：デフォルトの名無しさん：2005/11/07(月) 08:16:09

>>60
クロージャにおけるthisが呼び出しコンテキストに左右されるのは
クロージャがある以上当然の設計だと思うんですが。ActionScriptもそうだね。

左右されないthisを使いたいなら、例えば次のように書けばいいはず。
var constThisFunc = function(instance) { return function(x,y){/*real function using 'instance' instead of 'this'*/}; }(this);

62 ：デフォルトの名無しさん：2005/11/07(月) 08:30:24

>>60
なるほど、無名関数のことでしたか。
ありがとうございます。ラムダについては機会があれば詳しく調べてみます。

63 ：デフォルトの名無しさん：2005/11/07(月) 08:33:11

>>61
そそ、そこでthisをクロージャメインと考えると妥当なのだけど、一応オブジェクト
機能もあるのでthis==オブジェクトと考えたい部分もあって、例えば

var a=new Foo();
eventList.add(a.onMouseDown);

みたいな書き方をしたいと、確かにコンストラクタに相当する関数の先頭で
var me=this;
などとしてクロージャコンテキストに入れてしまえば良いだけなんですが、
言語標準の機能としてあればもっと安心かなぁ、という所です。

ActionScriptはそもそもECMAScript実装なので基本的には同じでは？

64 ：デフォルトの名無しさん：2005/11/07(月) 08:37:58

>>63

> などとしてクロージャコンテキストに入れてしまえば良いだけなんですが、
> 言語標準の機能としてあればもっと安心かなぁ、という所です。

なるほど、早とちりすまんでした。
最近は癖でthisを必要が無くても常にクロージャに含めてしまっているので、
いまや何の違和感もないですが、言われてみれば言語標準の機能として
自分自身のオブジェクトを指すキーワードを入れても不自然ではないですよね。

> ActionScriptはそもそもECMAScript実装なので基本的には同じでは？

知らなかった、恥です。

これだけ普及しているのに、なかなかECMAScriptの開発環境出てこないなぁ…

65 ：デフォルトの名無しさん：2005/11/07(月) 10:16:50

実装依存な仕様が多くて、一般的なものを作っても無駄なんじゃなかろうか

66 ：デフォルトの名無しさん：2005/11/07(月) 10:46:27

ちょっとスレ違いかもしれないけど、VBで構文解析しようと思ったらこれ！っていう
ツールある？lex/yaccみたいなのあったら知りたい、、、
現状再帰下降構文解析とかちまちま書いてるんだけど、、、

67 ：デフォルトの名無しさん：2005/11/07(月) 15:11:20

実装依存な仕様というか、仕様範囲外のライブラリが多いからね。
あと、組み込み用途がほとんどだから、ES開発環境自体も
ホームページエディタやFlash MXなど組み込む対象物の開発環境に
組み込めないといけないのも難しいし、今さら感もある。

ところで、俺言語にJSを組み込ませてみたいと思ってるんだけど、
こういうアイデアを実現した言語って既出？
俺言語は関数型言語なので、
手続き型で書きたいところはさっくりJSでかけるよー、
って感じにしたいんだけど。実行速度は気にしてない。

let f x = g (x - 1)
function g(x) { return f(x + 1); }

みたいなのが書けるの。

68 ：デフォルトの名無しさん：2005/11/07(月) 15:40:23

>>67
関数型言語に手続き型記述を埋め込むという話なら、
それこそ前スレで大人気(w)のlispのprog形式とか、
もうちっと今時の言語ならHaskellのMonadとか。

言語に他の言語要素を埋め込むという話なら…
CにSmalltalkを埋め込んだObjective-Cとかかなぁ。

69 ：デフォルトの名無しさん：2005/11/07(月) 18:09:08

Lispの次は俺言語かw

70 ：デフォルトの名無しさん：2005/11/07(月) 18:15:51

だがそれがスレの趣旨にはあってるからなｗ

71 ：デフォルトの名無しさん：2005/11/07(月) 19:55:50

俺言語は隔離すれでやってくれよw

72 ：デフォルトの名無しさん：2005/11/07(月) 20:04:12

>>71
はぁ？

73 ：デフォルトの名無しさん：2005/11/07(月) 20:07:51

隔離スレかどうかは知らないけど、過疎ってるスレ結構あるからな～。
少数で占有すんのもアレなんで、そっちを有効活用するのもアレかと。

74 ：デフォルトの名無しさん：2005/11/07(月) 20:11:46

>>71
はぁ？

俺言語にLispもいれろw

75 ：デフォルトの名無しさん：2005/11/07(月) 20:12:55

俺言語といえば
スリムドカン？だっけか
どうなったんだべ？

76 ：デフォルトの名無しさん：2005/11/07(月) 20:15:07

>>75
宣伝乙ｗ

77 ：デフォルトの名無しさん：2005/11/07(月) 20:17:12

>>75
おみゃーらはようｗ
おみゃーらはようｗ

78 ：デフォルトの名無しさん：2005/11/07(月) 21:00:10

>14
遅レスだけど。
おいらだったら a') ローダを実装して別ファイルの俺言語ソースを読み込む
ですな。
俺言語ソースを変更するたんびに再コンパイルはちょっとスマートじゃないね。
最近のPCは速いからあまり気にする必要がない、つうのはあるかもしれんが……

79 ：デフォルトの名無しさん：2005/11/07(月) 21:25:22

>>78
インタプリタ本体＋標準拡張ライブラリは1ファイルに
という制限があったと思った。

80 ：デフォルトの名無しさん：2005/11/07(月) 21:29:58

>>79
俺様言語の仕様ぐらいちゃんと覚えとけw

81 ：デフォルトの名無しさん：2005/11/07(月) 21:31:45

質問ですけれど、自分言語ってどういうときに必要になるんですか？

82 ：デフォルトの名無しさん：2005/11/07(月) 21:43:18

Lispと一緒で、勉強なり研究なりするとき。
あと、夜のおかずかな？w

83 ：デフォルトの名無しさん：2005/11/07(月) 21:52:30

>>81
特定のドメインに特化した言語を作ることで
開発効率を上げたりとか。

84 ：デフォルトの名無しさん：2005/11/07(月) 21:54:06

>>83
COBOLだな？
俺もそろそろDB直結も可能なCOBOLスクリプトが欲しいと思ってたとこだ。

85 ：デフォルトの名無しさん：2005/11/07(月) 22:00:34

>>82-83
ありがとう。

何らかのフォーマットに対するパーサまでなら良く作りますが
言語を解釈するところまで作ったことはありませんでしたが、
このスレで自分言語を作っている人が多くて、
もしかして何か知らないメリットみたいなものがあるのかと質問しました。

86 ：デフォルトの名無しさん：2005/11/07(月) 22:21:56

>>82 いいかげんウザイ。キモすぎる。Lisp と共に消えてくれ

87 ：デフォルトの名無しさん：2005/11/07(月) 22:27:56

>>85
俺言語があれば他人が作った気に入らないクソ言語でストレス溜めながら
書く必要がなくなるじゃん。それだけでもメリット。
例えばJavaがクソ言語だと思ってる人が仕事か何かでクソで書かなきゃ
いけなくなった時、Javaで俺言語を作って仕事を俺言語で片付ければ２度おいしい。
クソ言語上に俺言語を作っておけば以降のクソ言語の仕事でも俺言語上だけで
仕事できるし、そういう人は俺言語を弄ってるだけで楽しいだろう。
クソ言語から早急に離脱するためには、それなりの俺言語の設計をする
必要があるけど、クソ言語だけで仕事をする苦労に比べたらマシだし
モチベーションにも繋がると考えるだろう。俺言語のためならクソ言語で
書く作業もあまり苦にならないはずだ。
他にも、もしかするとそれでクソ言語の勉強にもなるかもしれない。
あるいはクソだと思っていた言語の良いところが見えて改心するかもしれない。
逆にクソ言語はどこまで行ってもクソだったと確信するかもしれない。

88 ：デフォルトの名無しさん：2005/11/07(月) 22:30:31

>>87
それってオナニーではないでしょうか？

仕事は他の人と一緒にやるものですよ

89 ：デフォルトの名無しさん：2005/11/07(月) 22:31:48

>>88
俺言語はオナニーに決まってるだろ。
それ以外の何かだと思ってる奴はきっと勘違いしてる。

90 ：デフォルトの名無しさん：2005/11/07(月) 22:33:05

>>87
クソ、クソとずいぶんお下品だと見受けられますね。

91 ：デフォルトの名無しさん：2005/11/07(月) 22:41:19

ゲーム作ってると使うよー。
デザイナーにパラメータいじってもらうのとか、
コンパイルせずに修正する箇所があるときに使う。
実行形式の再起動なしで、挙動を変更したり、テストが楽になる
でも最近、Luaとか既存のLLでいいじゃんという気がしてきた。
俺言語メンテまんどくせ。

92 ：デフォルトの名無しさん：2005/11/07(月) 22:43:38

>>90
やっぱ上品に「うんち」って書かなきゃね。

93 ：デフォルトの名無しさん：2005/11/07(月) 22:44:00

オナニーですよ (*´∀｀)
飽きたら捨てるで問題ないでしょー。

94 ：デフォルトの名無しさん：2005/11/07(月) 22:46:45

オナニーがセックスまで進化したのがLISP

95 ：デフォルトの名無しさん：2005/11/07(月) 22:50:20

そろそろ倦怠期

96 ：デフォルトの名無しさん：2005/11/07(月) 22:51:37

>>94
あーなるほど、ぼこぼこ子供(方言、派生言語)が出来上がる意味ではな。

97 ：78：2005/11/07(月) 22:58:00

>79
その制限て何か意味あるの？タダのクソ仕様にしか見えんが……

>81
個人的に一番多いのが、自作アプリなんかの設定ファイルかな。
最近はXML使うことも多いけど、ルールは結局自分で決めなきゃいかんからね。

98 ：デフォルトの名無しさん：2005/11/07(月) 23:15:14

今度は四日ぶりに来たが、凄いことになってるな
読む必要なさそうだから、読まないけどよ

99 ：デフォルトの名無しさん：2005/11/07(月) 23:17:36

>>91
おーなるほど、確かにデザイナーさんなど、
プログラムに慣れていない人のために書くのはありそうですね。
言語というより設定ファイルとパーサみたいな印象でしょうか。

>>97
上を書いてからこのレス読みました。確かに設定ファイルも言語ですよね。

100 ：14：2005/11/07(月) 23:17:50

>>97
>その制限て何か意味あるの？タダのクソ仕様にしか見えんが……

インストールが楽。実行形式ひとつ、パスの通ったところに投げ込めば
動くってのはそれなりのメリットだと思うが。
もっと拡張ライブラリが増えて、必要なライブラリだけをオンデマンドで
読み込むとかするようになったら別ファイルにもするけど、今のところ
実行形式単体で動くのはメリットだと思ってる、ってこと。

まあこれをメリットだと思わない人もいるだろうけどさ。

101 ：14：2005/11/07(月) 23:35:37

しまった100getしとくんだった…
なんてくだらん話は置いといて。

>>55
うちの言語では、ネイティブ側で確保したオブジェクトへのポインタ型に
ファイナライザを付けられるようにしてる。それ以外のオブジェクトにはなし。
あとで知ったんだけど、Luaもそんな感じらしい。ていうかLuaの場合は、
確保の逆順にファイナライザを呼ぶことを保証してるらしい。

>>56
>ファイナライザ用のスタックに一端退避して保護対象にする。

ええと、このスタックから参照張られたオブジェクトについてファイナライザ
走らせる前に、これらのオブジェクトを起点にしてまたmarkするのでしょうか?
この解釈であってる?

102 ：デフォルトの名無しさん：2005/11/08(火) 00:41:05

>>9
そのわりにテンプレには入ってないな

103 ：デフォルトの名無しさん：2005/11/08(火) 04:01:29

相談室八になって、多少はまともになったなw
まぁ、他の擦れでもそうだけど、嵐って擦れ変わりで無くなるもの。

ところで、その俺言語公開してんの？名前だけでもさらして見れば？

104 ：14：2005/11/08(火) 08:08:50

>>103
まともに公開してるんならこんなとこで名前晒すバカはいないと思うが。

こんなこともわからずに、本当に作ったんならupしろ! できないなら脳内言語だ!
とかわめくキチガイがいたから、前スレは荒れたんだよな。
# あのキチガイは誰も彼も脳内で同一人物化してたしなw

105 ：デフォルトの名無しさん：2005/11/08(火) 08:12:14

語るに落ちるというやつですね。
誰もまだ何も言っていないうちから脳内言語脳内言語とｗ

こんな場末の空間で作れもしないものを作ったとアピールするのは
無駄な努力なのでやめたほうがいいと思いますｗ

106 ：デフォルトの名無しさん：2005/11/08(火) 08:48:36

>>105に同意
手探りでレスするのも情報の小出しを食らうのも鬱陶しい

107 ：デフォルトの名無しさん：2005/11/08(火) 08:51:55

>>106
小出しというが、情報を与える側から見れば「与えなければならない情報をどこまで削れるか」なんだよな。
いきなり膨大な量の情報を与えられても、それはそれで困るぞ。

昨日思い知った。

108 ：デフォルトの名無しさん：2005/11/08(火) 08:53:43

んー。VBでparser作る時みんなどうやってんだろ？不思議不思議。

109 ：デフォルトの名無しさん：2005/11/08(火) 10:13:32

なんで単なる相談や経験やアイディアの提示が
「作れもしないものを作ったとアピールする」
と読めるのかが不思議。
もしかして当人がアピールしたくて仕方ないけど何も作れなくて悔しいのかな？

110 ：デフォルトの名無しさん：2005/11/08(火) 10:16:25

>>108
VB使うようなプロジェクトでは普通はパーサなんか作らないからです！

…とか言い切ってみる。
まぁXMLの形式に載せてXMLパーサとか使うんじゃないの？
VBやったことないけどMSXMLのDLLくらいなら呼べるんでしょ？

111 ：デフォルトの名無しさん：2005/11/08(火) 10:20:30

>>108
LLで手作りなら全く問題なかろう？
パーサジェネレータが無いとつらい文法ならそもそもＶＢと言う選択肢棄てるだろうし
ＶＢ自体で済みそうな話の部分に自前文法の言語実装する必要あるとは思えないし。

112 ：デフォルトの名無しさん：2005/11/08(火) 10:36:58

>>111
手作りの場合、漏れは構文解析よりも字句解析のほうが
コードが泥臭くて面倒だなー。
適当にやっつけるにせよ有限オートマトン作るにせよ。

113 ：108：2005/11/08(火) 12:15:17

はぁ、、、そもそもVBでこんなことするのがおかしいのか、、、ショック

実は設定ファイルを書くための簡単な自分言語？が必要なんです。
その設定ファイルは現場の人に書いて貰う予定なんで、あまり難しいの無理だし。
がんがって書くか、、、

114 ：デフォルトの名無しさん：2005/11/08(火) 13:20:33

>>113
ならLL文法で十分ぢゃないか。
LL系の学習用の簡単なソースならMicroPlan(パスカル系でセルフコンパイラのソースが付いてた）
とか言うのが大昔のBitに掲載されてたから図書館で探してみれば？

115 ：114：2005/11/08(火) 13:22:10

これね
http://www.google.co.jp/search?hl=ja&c2coff=1&q=%E3%83%9E%E3%82%A4%E3%82%AF%E3%83%ADPlan+bit&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=lang_ja

116 ：デフォルトの名無しさん：2005/11/08(火) 13:34:18

>>113
設定ファイルならDTDも簡単に書けそうだし、
もうオリジナル言語なんかやめてXMLにしちゃえｗ
一々オリジナル言語設計するより作成もメンテも楽だぞ。
ツールも揃ってきてるし検証パーサ使えば検証もサボれるし。
XSLでHTMLに変換すれば整形表示も簡単ｗ

117 ：デフォルトの名無しさん：2005/11/08(火) 13:39:01

XMLのおかげで、パーサを書く手間がずいぶん減った気がする。
既に存在しているフォーマットを読むとき以外は使わなくなった。

118 ：デフォルトの名無しさん：2005/11/08(火) 13:58:23

VisualBasic XMLでググってみると
ttp://kamoland.com/comp/xml2.html
こんなページがあった。どうやら割と簡単に使えそうじゃないか。

119 ：デフォルトの名無しさん：2005/11/08(火) 14:51:38

果てしなくどうでもいいことだけど、日本人は何でVisual Basicにスペース入れずに書くの？

120 ：デフォルトの名無しさん：2005/11/08(火) 14:54:30

>>119
果てしねーーーーー

121 ：デフォルトの名無しさん：2005/11/08(火) 14:57:38

分かち書きで単語を区切る言語圏に居ないからじゃないのか？

122 ：118：2005/11/08(火) 15:26:02

>>119
漏れの場合は：
スペースはデフォルト設定のMS-IMEでは変換キーなため
日本語入力時は一続きの入力が終わって意図的に変換するとき以外は
スペースキーに触らない。
大文字でスタートするIMEの英字入力モード中はスペースは変換でなく
スで、ペースになるのではあるが、やっぱり触るのに心理的抵抗があり、
入れなくて済むものは入れずに済ましたい心理的傾向がある。
多分それが原因。

123 ：118訂正：2005/11/08(火) 15:27:00

スで、ペース→スペース

124 ：108：2005/11/08(火) 15:42:04

XMLか、、、勉強不足で良く分からないんだけど、例えば、

if (isExist("hoge")) i+3; else i+2;

みたいな条件分岐も何とかなる？

125 ：デフォルトの名無しさん：2005/11/08(火) 15:56:39

「設定ファイル」内でどの程度の計算記述能力が必要かにもよるが、
条件分岐を表現するエレメントを書けば書けない事はなかろう。
（例えばmakeのような働きをするANTのファイルはXMLで書かれている。
あるいはXSLスタイルシートはそれ自身XML形式で、
関数型言語スタイルでかなり複雑な変換処理が書ける）
ただ条件付設定ファイルレベルならばいいが
本格的な汎用スクリプトが必要になるようだと
XMLでは不可能ではないまでもあんまりおいしくなくなる可能性はある。
設定ファイルでどんな種類の条件分岐や計算が必要になるかを
把握することが鍵。

126 ：デフォルトの名無しさん：2005/11/08(火) 16:31:29

>>125
つかそんなXMLを生エディタで書かされる方はたまらんだろう。
108が設定ファイルをXMLにするのなら、むしろそのＸＭＬを生成する条件設定アプリ作る方がマシじゃなかろうか？

127 ：デフォルトの名無しさん：2005/11/08(火) 17:24:44

>>126
いずれにせよ「設定ファイル」として想定される内容次第だな。
ある程度定まったパターンの処理ばかりであるならXML化してもいいが
汎用スクリプト言語的でどんな種類の処理がかかれるかについて
設計時に把握しきれないなら
そもそもXMLを選ばないほうがいい可能性が高いし…。

別の言い方をすれば、主に値や型の宣言が並ぶスタイルならXML向きだが、
複雑な制御フローや汎用の演算セットがあるようなら向かない可能性が高い。
XMLは元来「文書」を表現するためのものだから
「設定ファイル」の性質が「文書」に近ければXMLで比較的表現しやすいし、
「文書」から離れて手続きプログラム的になるとXMLでは段々表現し辛くなる

条件設定アプリはその中間くらいの複雑さのときの解だな。

128 ：デフォルトの名無しさん：2005/11/08(火) 18:07:45

>>124
あくまでも一例
<if test="isExist('hoge')">
<true>i+3</true>
<false>i+2</false>
</if>

実際はXSLなどを参考にしつつもうちょっとマシなのがいいと思うけど。

129 ：デフォルトの名無しさん：2005/11/08(火) 18:14:01

XMLなんて馬鹿の思いつきだよ。
する～よろ>>ALL

ところで、俺言語いいじゃないか。
どんどん語ってくれ！

130 ：デフォルトの名無しさん：2005/11/08(火) 18:24:45

>>129
そういう根拠を述べない決め付けはよくないな。
技術者ならば各手法の選択に当たって目的に対する得失を比較せねばな。

>>127、>>125でも述べた通り、
XMLを使ったほうが開発・維持の手間が減らせる場合は確かにある。
逆に使わないほうがいい場合もある。万能な方法はない。

131 ：デフォルトの名無しさん：2005/11/08(火) 18:42:53

データ構造を記述するだけの場合にはXMLは非常に優れた能力を持つよね。
でもプログラムを記述する場合にXMLを使う例は今のところあまりないと思う。
JavaMLなんてものもあるけれど、あれは構文木をXMLにしただけだし（うろ覚え）。

132 ：108：2005/11/08(火) 18:48:24

んー。XMLでもできそうな気がしてきた。VB使う限りはXML使うのが楽っぽい。
VBはもう終っちゃう言語だろうけどさ、、、
一応XML使ってみるよ。条件分岐が少し多いだけで、多分、そんなに複雑にはなら
ないから多分大丈夫かと。

133 ：デフォルトの名無しさん：2005/11/08(火) 18:57:28

>>131
代入や演算、一般的な条件分岐などで
データ・フローやコントロール・フローが複雑になると
XMLではおそらく読みにくくなる。
データ構造記述は比較的それらが単純で局所的な要素が多いからな。

ANTなんかはタスクの依存関係を記述してプログラムのビルドやセットアップを行う
スクリプト的側面を持つが、処理のパターンが依存関係とコマンドというように定型的で
宣言的だからXMLでも比較的追いやすい。

もう一つの基準はスクリプトや設定ファイルの処理で
ツリー構造を作るところまでの仕事が占める割合だな。
データ構造記述の場合パースしてツリーができればかなりがとこ仕事は終わっている。
タスクの依存関係を記述するANTの場合も然り。
けれど代入や分岐などを認め複雑なデータフローや
コントロールフローなどを処理する必要が生じるとツリーを作った後が中心になってくる。
XMLパーサを使うことでコストが減るのはパースする部分までだから、
ツリーなどのデータ構造を作った後の処理の比重が重いと旨みは減る。

134 ：デフォルトの名無しさん：2005/11/08(火) 19:04:01

もう一つXML使ってメリットがありうるのはスクリプト自身を処理する
スクリプトを書くなどメタな処理をする場合だな。
スクリプト自身をデータとして処理する予定がある場合や、
XPathなどを駆使してXMLファイル内にXMLファイルの構造を辿るような記述を埋め込む場合だ。
XSLやXML Schemaなどはこのような例だな。

135 ：デフォルトの名無しさん：2005/11/08(火) 19:18:46

XSLTはかなり良く設計されていると思う。XML Schemaはノーコメント。

あと、企業独自言語で、XML内にスクリプトを埋め込むというのを何度か見た。
SVGとかも確か、スクリプト(ECMAScript?)をエレメントの中に記述したよね。
よく考えれば、SVGをいうまでもなくXHTMLもそうか。

136 ：デフォルトの名無しさん：2005/11/08(火) 19:37:30

>>128
うへえ。
いろんな意味でLISPのS式の方がいいじゃん。

137 ：デフォルトの名無しさん：2005/11/08(火) 19:48:04

みんな! 136がVB用のLispパーサを書いてくれるそうですよ!

138 ：デフォルトの名無しさん：2005/11/08(火) 19:48:36

>>136 ログ嫁

139 ：デフォルトの名無しさん：2005/11/08(火) 19:52:00

ばかかお前ら？
XMLのコンテンツとして、文をいれる訳？？？
まだ、*ispの方が遥かにいいよw

140 ：デフォルトの名無しさん：2005/11/08(火) 19:53:13

ん、配列扱える言語なら基本的なLISPぐらい書けるでしょ。
VB使う機会があったら書いてみるよ。

141 ：デフォルトの名無しさん：2005/11/08(火) 20:07:38

いや、、お前らよく考えろ。XMLなんて素人に書けないぞ。結局XMLを生成する
アプリ作る必要が出てくるに違いない。いや、中間言語としてXMLを使うのは
悪くは無いかもしれんが、、、

142 ：デフォルトの名無しさん：2005/11/08(火) 20:14:25

>>141
その通りだが、Lispもそうなんだよな。デザイナーが書ける言語って何だろう。

143 ：デフォルトの名無しさん：2005/11/08(火) 20:17:42

デザイナーとプログラマーのプログラミングに対する意識は人それぞれといえまったく違うみたいだしなぁ

144 ：デフォルトの名無しさん：2005/11/08(火) 20:36:48

設定ファイル解釈系相談室、の方が実態に即してるんじゃないか、このスレ。

145 ：デフォルトの名無しさん：2005/11/08(火) 20:58:04

>>142
素人受けして、文法に柔軟性がある言語があるが、
あえて名前は書かないw

146 ：デフォルトの名無しさん：2005/11/08(火) 21:10:57

>>145
ほほぅ、、もしかして「日本語」か？

147 ：デフォルトの名無しさん：2005/11/08(火) 21:12:48

>>145
詳しく

148 ：145：2005/11/08(火) 21:13:20

>>146
その通りw

149 ：デフォルトの名無しさん：2005/11/08(火) 21:45:40

りんごタソは、やまとなでしこ。

150 ：デフォルトの名無しさん：2005/11/08(火) 21:51:52

>>142
素朴な疑問だが、どこから「デザイナー」が出てきたんだ?

設定ファイルにLispというと、.emacs.elの感覚かねえ…
素人にはお勧めできないわな、そりゃ。

151 ：デフォルトの名無しさん：2005/11/08(火) 22:17:56

>>150
あ、ごめん、俺は昔デザイナーがカスタムタグベースのJSPを書けなくて
ショックを受けて、プログラムをする必要のある素人といえばデザイナーが
脊髄反射で出てきてしまった…

152 ：デフォルトの名無しさん：2005/11/08(火) 22:43:01

>>108&113
ここでこういうレスを入れるの自体スレ違いかもしれないけど、iniファイルじゃ
駄目なの？制御構文が絡まなければ別段パーサなんて作る必要性感じないんだけど

153 ：デフォルトの名無しさん：2005/11/08(火) 22:51:32

>>101
>うちの言語では、ネイティブ側で確保したオブジェクトへのポインタ型に
>ファイナライザを付けられるようにしてる。それ以外のオブジェクトにはなし。

成程成程、自分の場合作っているのがECMAScriptのスーパーセットなもので
その辺はファイナライザを指す特定のシンボルを動的検索です、ちょっとオーバー
ヘッドが気になるのだけど致し方無しという所です。

>ええと、このスタックから参照張られたオブジェクトについてファイナライザ
>走らせる前に、これらのオブジェクトを起点にしてまたmarkするのでしょうか?

うちの場合も構文木でスタックは持ってないんだけど、要はオブジェクトリスト
を管理している所を2本化してチェック走らせれば良いのでは、と理解しました。

# ちなみに構文木辿っている途中の中間計算で使用されているオブジェクトは
リファレンスカウンタ介してGC時に除外する方式取ってます、ちょっとオーバーヘッド
あるけど。

154 ：デフォルトの名無しさん：2005/11/08(火) 23:30:51

デザイナー自体は>>91で出てるね。

デザイナーが書ける(こともある)プログラミング言語というと、
やっぱりFlashのActionScriptじゃないかな。

155 ：14：2005/11/09(水) 00:15:53

>>153
うーんと。
ファイナライザがあるとGCが厄介だ、というのは、ファイナライザの中で
thisをグローバル変数か何かに放り込まれると、オブジェクトが「復活」する
からだよね?
んで、復活するのは、ファイナライザを呼ぶオブジェクトそのものだけでなく、
そのオブジェクトから辿れるオブジェクトすべてだから、
>ええと、このスタックから参照張られたオブジェクトについてファイナライザ
>走らせる前に、これらのオブジェクトを起点にしてまたmarkするのでしょうか?
と書いたわけだけど。ただ、今読み返すと、>>56氏も>>58氏も、そんなことは
当然として書いてるように思える。恥さらしましたかね。

ちなみに.NET FrameworkのGCについて以下のページに説明があって、

http://www.microsoft.com/japan/msdn/net/mag00/GCI.asp

下の方に、ファイナライザを含むオブジェクトのGCの話も書いてある。
でも、俺にゃ「完結キュー」がなぜ必要かわからないし(オブジェクトごとの
フラグじゃいかんの?)、復活の話も書いてあるけど、.NETのGCがどう対処してる
のかもよくわからない… 俺がアホなのか。

156 ：デフォルトの名無しさん：2005/11/09(水) 10:53:26

>>141
素人さんにはXMLに限らずどんな形式言語でも書けない。
だからユーザとして想定する相手の技術レベルよっては
どのみち設定ウィザードみたいなものは必要。

157 ：デフォルトの名無しさん：2005/11/09(水) 11:02:10

>>152
どっちみち.iniファイルの中の仕様を決めねばなるまい、
あれだって単純とはいえ一応形式言語だぞ？

それと>>124を見る限り、
>>108は簡単な設定ファイル内で簡単な条件判定くらいはするつもりらしい。

158 ：108：2005/11/09(水) 12:19:08

ん。そうです。設定ファイルというと語弊があったかも、、、実際には
現場の人に計算式を入れて貰うわけです。パラメータにAがあったらこういう計算、
パラメータにBがあったらこういう計算。寸法がある範囲内ならこういう計算、
みたいに計算式と条件を書いて貰おうと。

この条件の部分が後からどうなるか分からないので、比較的自由に条件が設定できる
ようにしたいわけです。

とりあえずLL(1)で書いてみたけど、ちょっと気持ち悪いです、、、
getcharのかわりにmid関数とか使ってるんだけど、こんなんでいいの？

159 ：デフォルトの名無しさん：2005/11/09(水) 12:34:49

条件式はかなり複雑なものになりえる？
計算式もスクリプトが計算するのか？
その辺がYesならまぁXMLは向かない可能性が大なので忘れてくれ。

>>135
XMLに別言語のスクリプトを埋め込むのはまぁあんまりオススメはしない。
特に埋め込む言語が広く使われている既存の言語ではないとか、
XMLのフォーマットが既にある程度普及してる訳ではない場合とか、
スクリプトが断片的でXMLの記述と絡み合い、
それ自身では完結しない場合とか。
いずれも処理が煩雑になり理解もしにくいものになるからな。

まぁHTMLにJava Script(ECMA Script)埋め込んでそれなりに動いてる
って前例があるからやりたくなるんだろうが…。
あれはHTMLが爆発的に普及してその拡張手段が必要となって
止む無くやってるわけで最初から目指すものではない気がする。

まぁTeXとPascalコードを融合してアルゴリズムの文書的記述と
プログラムを融合したweb（Knuthの提唱する文芸的プログラミング）
という試みもあってそういうのは面白いかも試練が、
あの場合はドキュメント＋実行可能サンプルって意味合いが強く
コードとドキュメントにキレイに分離できて、
分離後は別々に処理できたから問題なかった。

160 ：デフォルトの名無しさん：2005/11/09(水) 13:53:46

昔、INIファイルのままでTinyBASICもどきを作ろうとしたことがあった
（実行環境に応じて設定が動的に変わるように)
[MAIN]
VAR=グローバル変数
100=A=0
110=FOR I=0 TO 10: PRINT I;: NEXT I
120=GOSUB MOKEKE
130=END
[MOKEKE]
100=VAR=$SCREENWIDTH
110 RETURN

とか
仕様考えているうちにダルくなってそれっきり。
やっぱGOSUBは!=じゃなきゃだめとか（ぉぃ

161 ：デフォルトの名無しさん：2005/11/09(水) 14:56:17

>>158
やはり、という気がするのだけれど、それを設定ファイルと呼ぶのは、
問題に対する誤解を生むだけの間違いのような。
条件はともかく計算式を「現場の人に書かせる」のが必然かどうか知らんが、
入力の妥当性検査やエラー含めて、どの程度の記述能力が必要なのか、
確定しているのかな? 下手すれば(少なくともUI的には)
本体の処理内容自体よりよほど重要なわけで、それが
>この条件の部分が後からどうなるか分からないので、
というのは、設計以前の問題把握/認識として大丈夫かな、と……

162 ：デフォルトの名無しさん：2005/11/09(水) 16:01:36

58です。
>>155
CLRの図で行くとFリーチャブルキューが生成された時点ではまだヒープに
オブジェクトは残っていて、1回のGCサイクルが

1) 完結キューに無く、かつFリーチャブルキューにのオブジェクトをヒープから削除
2) 完結キューに存在するオブジェクトの参照をFリーチャブルキューに移動
(この時点ではオブジェクトは残っている)

2')非同期でファイナライザ実行スレッドが走る

なので次の実行時に復活されているオブジェクトはそのまま残るのでは？
56の話も1GCサイクルは

1) ファイナライザを持っていてファイナライズされていないオブジェクトはリストへ、
それ以外の未使用オブジェクトは削除
2) ファイナライズリストにあるオブジェクトはファイナライズ実行

なので次の呼び出しで復活している場合は1で参照されているので復活は処理できるのでは
ないかと思ってるんですが、何か抜けてる？

完結キューの話はその方がクラスのメモリ上のレイアウトがすっきりするし、CLRの
場合クラス設計は静的だからオブジェクト作成時にファイナライザがあるかどうかは
はっきりしているので、実装によってはそういう方法もあるかな、位に考えてました
が、、、抜けてるかな

163 ：デフォルトの名無しさん：2005/11/09(水) 16:06:27

間違い)
1) 完結キューに無く、かつFリーチャブルキューにないオブジェクトをヒープから削除

164 ：108：2005/11/09(水) 16:08:50

>>159
ありがとうございます。とりあえず、XMLは勉強不足なので、今後の課題に
したいと思います。

>>161
すみません。設定ファイルと言うと誤解されても仕方ないですね。
条件が後からどうなるか分からないというのは、
現状なら大丈夫だけど、今後、外的要因で変わる可能性もあるっつーこと
です。

165 ：デフォルトの名無しさん：2005/11/09(水) 16:11:02

C言語の学習および開発をしたいのですが、visual C++.netよりも
いいものってあるでしょうか？

166 ：デフォルトの名無しさん：2005/11/09(水) 16:14:10

GCC

167 ：デフォルトの名無しさん：2005/11/09(水) 16:28:06

ICC

168 ：デフォルトの名無しさん：2005/11/09(水) 16:29:52

>>165
学習と開発を一緒にしないでください。

169 ：デフォルトの名無しさん：2005/11/09(水) 16:31:57

>>164
>条件が後からどうなるか分からないというのは、
>現状なら大丈夫だけど、今後、外的要因で変わる可能性もあるっつーこと
いや、当然せめてそのレベルにないと話にならないわけで……
その可能性等、未確定要素でもある程度認識しておかないと、
>比較的自由に条件が設定できるようにしたいわけです。
たって、なんでもできる万能言語を作る能力にめぐまれるわけでも無く、
記述能力の水準やら(言語の)設計方針もきまらないんじゃ? と、
心配するわけです。(だから軽く設定ファイル、なんて言っちゃうのかなと)

170 ：デフォルトの名無しさん：2005/11/09(水) 16:41:26

>>165
TinyCCが良い、コンパクトなのでソースも読み易いぞ

171 ：デフォルトの名無しさん：2005/11/09(水) 17:01:00

>>168
まぁしかし広義には人生これ全て学習じゃよｗ
開発も人生の一部であるからにはまた然りじゃろて。

172 ：デフォルトの名無しさん：2005/11/09(水) 19:22:08

開発が人生のすべてで、他はオマケという人もいる罠。ｗ

173 ：14：2005/11/09(水) 20:27:28

>>162
>1) ファイナライザを持っていてファイナライズされていないオブジェクトはリストへ、
>それ以外の未使用オブジェクトは削除
>2) ファイナライズリストにあるオブジェクトはファイナライズ実行

単純なmark sweep GCを考えると、この1)のフェーズの前にmark phaseがはいってて、
1)はsweepと同時にやるようなイメージなんですが、ここまでの認識は合っているでしょうか?
ファイナライズされるオブジェクトをAとすると、Aは定義からしてマークされていないはずで、
当然、Aが参照しているオブジェクト(Bとします)もマークされていないはずです。
この状態でsweepすると、Bはなくなってしまうわけですが(Bにはファイナライザはついて
ないものとして)、Aが復活したら、Bも一緒に復活しなければなりません。
だから、
>ええと、このスタックから参照張られたオブジェクトについてファイナライザ
>走らせる前に、これらのオブジェクトを起点にしてまたmarkするのでしょうか?
と書いたわけで。

もちろん、mark phaseにて、ファイナライザ持ったオブジェクトは最初から
すべてmark対象にしてもいいわけで、そう考えると.NETの完結キューも
意味があるのかな、とこれは今思った。完結キューもルーツに含めればよいわけで。

174 ：デフォルトの名無しさん：2005/11/09(水) 20:39:13

なんか、俺様言語のオンパレードだなw

プログラミング言語　俺様　改訂２版

175 ：デフォルトの名無しさん：2005/11/09(水) 22:14:28

>>171 >>172 >>174 あたりがウザイ。せめてアボーンできるようにコテハンつけてくない？

176 ：デフォルトの名無しさん：2005/11/09(水) 22:15:21

>>173
指摘thanx、見落としてました。という事は

1) 通常通り変数,Fリーチャブルキューから参照されているものをmark
2) 1でmarkされなかったファイナライザ付きオブジェクトを
ファイナライズリスト/Fリーチャブルキューに登録し、そのオブジェクトを起点にmark
3) sweep
4) ファイナライザ実行

でどう？

177 ：108：2005/11/09(水) 22:20:08

>>169
多分，
＞比較的自由に条件が設定できる
という部分が誤解を招いたかと。すみません。

条件の部分はあらかじめ組み込み関数を用意する予定です。
現場の人にはそれらと論理演算記号とを組み合わせて条件を書いてもらいます。
今後何かあっても変更になるのは条件の部分だけなので，変更があったら，
組み込み関数を都度追加すればよいだけなんで。

正直，これ，条件分岐と，四則演算さえできればいいんです。
言語というほどのものではなく，eval関数に毛が生えたみたいなもんだと
思っていただければ・・・・そもそもあまり難しくすると現場の人書けない
ですから。

というわけで，大体できました。皆さんありがとうです！

178 ：デフォルトの名無しさん：2005/11/09(水) 22:23:38

あれ？ファイナライザでオブジェクトが復活するかどうかって、コンパイル時に決定できる？

179 ：デフォルトの名無しさん：2005/11/09(水) 22:24:55

復活するかどうかは普通は決定できない、持っているかどうかは決定できるという話じゃない？

180 ：178：2005/11/09(水) 22:27:18

ごめん。思いつきで書いたけど良く考えなくても決定できそうにない (；´Д｀)

181 ：デフォルトの名無しさん：2005/11/09(水) 22:45:29

>>１７５
おまえがいちばん鵜剤w

182 ：デフォルトの名無しさん：2005/11/09(水) 23:11:24

>>177
文法がある以上、言語だと思うけど。
多分DB絡んでる？違うかな。。。

183 ：デフォルトの名無しさん：2005/11/09(水) 23:52:02

>>175
ウザイらしいぞw

184 ：デフォルトの名無しさん：2005/11/10(木) 01:32:53

10 omaira
20 nanigeni LV
30 taka sugi

185 ：デフォルトの名無しさん：2005/11/10(木) 22:12:06

構文解析って、もう研究するところないんですかね？
ちょっとそんなこと聞いたもので。。。

#もちろん、皆無っていう意味でなくって、
#大きなテーマが無く、あとは重箱の（ry

186 ：デフォルトの名無しさん：2005/11/10(木) 23:04:46

構文解析に限らず，新たなパラダイムが無いと難しいんじゃないの？この
分野。自然言語処理ならともかく，プログラミング言語って話だと。。。

187 ：デフォルトの名無しさん：2005/11/10(木) 23:18:01

>>185-186
禁句w

188 ：デフォルトの名無しさん：2005/11/10(木) 23:24:34

そこで日本語プログラミング言語ですよ

189 ：デフォルトの名無しさん：2005/11/10(木) 23:36:38

>>188
ぴゅう太やら、年刊Ah!SKI第1号以来の、手垢のついたネタだよなあ。

そういえば、盲導犬に命令を出すとき、日本の盲導犬でも英語を使うんだけど、
その方が、いざというとき言い間違えたりしないからよい、というのを、
大昔ドラマかなんかで言ってたのを思い出した。
犬に、「ゴー」の代わりに「行け」を覚えさせることはもちろん出来るけど、
日本人が普段から「行け」を使っていると、いざっていうときに「行ってえ!」とか
叫んだりして犬にはそれがわからない、ってことだったと思う。

日本語プログラムは、読む方は確かに読みやすいと思うけど、書く方は、
文法エラーにされたりしてかえってストレスたまらないのかなあ。
使っている人の感想求む。

190 ：デフォルトの名無しさん：2005/11/10(木) 23:41:54

あれは読むためのものでしょ？

書く技量＞＞＞＞＞＞読む技量

通常の言語の逆w

191 ：デフォルトの名無しさん：2005/11/11(金) 01:18:54

>>189
そういうのよく言ってる奴いるけどさぁ
じゃあ英語が母国語の奴らはどうしてんだよ。

192 ：デフォルトの名無しさん：2005/11/11(金) 01:27:37

>>191
英語はGO以外の言い方がないんだよバカだから
南部なまりでもGOはGO
おまえだってゴーパピー！って一回ぐらいは言ったことあるだろ

193 ：デフォルトの名無しさん：2005/11/11(金) 03:15:21

>>185
テクニック的な事と研究を一緒にしないでくださいね。

194 ：デフォルトの名無しさん：2005/11/11(金) 05:30:51

>>185
生成文法の分野としてはその通り。
ユーザインタフェースの分野としてはまだまだ、だと思う。

今まではユーザインタフェースは研究と見なされなかったけど、
生産性が重要視されるこれからでは十分研究になるんじゃないかな。

195 ：デフォルトの名無しさん：2005/11/11(金) 06:31:56

研究され尽くしたとか言われる割には、一向に文脈自由文法を実用的
速さで解析するアルゴリズムが出ませんね。

196 ：デフォルトの名無しさん：2005/11/11(金) 07:55:21

>>195
依存と言いたい？慣れない言葉を使う時は気をつけよう。

197 ：デフォルトの名無しさん：2005/11/11(金) 08:17:29

いや、自由の方だよ。LRやLLに全然近づけない。

198 ：デフォルトの名無しさん：2005/11/11(金) 09:04:29

え、、、文脈自由文法ってそういうもんじゃねーの？俺の認識不足？
O(n^3)ってのは崩れないんじゃ？できないものはできないんでは？

199 ：デフォルトの名無しさん：2005/11/11(金) 09:11:50

ハードの側で並列処理が当たり前になれば、新たな進展が見られるんでは？

200 ：デフォルトの名無しさん：2005/11/11(金) 09:43:13

馬鹿？
速度の問題じゃないでしょ？

201 ：デフォルトの名無しさん：2005/11/11(金) 10:15:41

>>195
つ冨田LR

202 ：デフォルトの名無しさん：2005/11/11(金) 10:35:29

CFGについては、並列アルゴリズムは既に提案されてるだろうし、発見的手法も
提案されてるはず。というかどっちかしか研究のネタないよ。後はハード面から
やるか。計算量は理論的に決まってるからどうしようも無い。
できることはできるし、できないことはできないってはっきりしてるのが計算機
科学なんだからさ、、、どのみち斜陽の学問ですよ。

203 ：デフォルトの名無しさん：2005/11/11(金) 14:03:23

社用とはキツイナw
まぁ、社内でも能力給制度が始まったんだが、
飛び抜けて評価が低かったのも実はないしょw

204 ：デフォルトの名無しさん：2005/11/11(金) 14:29:57

>>201
バックトラックしまくってるだけのアホアルゴリズム。

205 ：デフォルトの名無しさん：2005/11/11(金) 15:16:30

>>202
いかにそのサブセットで性質のいいものを見つけるかって方向性もあるだろ？
LALR(1)とかLRとかLL(k)とかはそういう方向でしょ？
斜陽じゃなくてブレークスルーが求められてると見た方がいいんじゃない？
流行が終わるとすぐ誰もやらなくなるのが日本の悪いとこ。

206 ：デフォルトの名無しさん：2005/11/11(金) 15:49:07

下手にブレイクスルーが起きたって自然言語まがいの
複雑怪奇な言語が出てくるのが落ち。

207 ：デフォルトの名無しさん：2005/11/11(金) 16:14:29

やってみる前からキレイにオチつくとわかるなら研究なんていらないよｗ

208 ：デフォルトの名無しさん：2005/11/11(金) 18:43:44

>>207
だから、社用の学問とか言われちゃうんだろ。

209 ：デフォルトの名無しさん：2005/11/11(金) 19:32:47

>>208なんで？

210 ：デフォルトの名無しさん：2005/11/11(金) 20:52:42

>>206
妙に納得w

研究としては面白みに欠ける分野なんだろうけど、
逆の見方をすれば、信頼できる枯れたテクノロジーということも出来る。

211 ：デフォルトの名無しさん：2005/11/11(金) 20:56:33

>>209
バカにマジレスｶｺﾜﾙｲ

>>210
俺も同意。
まあこれ言っちゃおしまいだけど、プログラミング言語の構文としては、
Cあたりでだいたい実用上困らないところまで行っちゃってるんじゃないか。
細かい不満はあるものの、LALR(1)で「プログラミング言語としては」必要十分というか、
これ以上がんばっても98点を99点にするようなもので、労多くして益少なし
なんじゃないかな。

212 ：デフォルトの名無しさん：2005/11/11(金) 21:19:38

>>204
……バックトラックではないよ

213 ：デフォルトの名無しさん：2005/11/11(金) 21:53:30

>>211
> 細かい不満はあるものの、LALR(1)で「プログラミング言語としては」必要十分というか、
> これ以上がんばっても98点を99点にするようなもので、労多くして益少なし
> なんじゃないかな。

うまい表現ですね。私も同感です。
ただ、あえて言うとすると、LALR(1)は表現しにくいという所が
気に入らないと言えば気に入らない点ではありますけどね。

# 言語大量発生の防波堤にはなるのかな？

214 ：デフォルトの名無しさん：2005/11/11(金) 22:05:53

誰も冨田LR（GLR）を知らんのか。
CFGをフルカバーする上に、実用上はO(n)なんだけど。
bisonでも使われてる。

215 ：デフォルトの名無しさん：2005/11/11(金) 22:13:46

それが本当だとしても、最近はLLばかり聞くから、何か欠点があるんじゃない？

216 ：デフォルトの名無しさん：2005/11/11(金) 22:23:44

>>214
bison2.0からだっけ？

217 ：デフォルトの名無しさん：2005/11/11(金) 22:24:45

>>215
LLが流行ってるのは、再帰下降で実装した上で
一部の関数をユーザ定義のもので差し替えるという手が使えるから。
CFGを超えるような言語を扱えるようになったりする。
泥臭いけどがんばれば何でもできるのが魅力。

218 ：デフォルトの名無しさん：2005/11/11(金) 22:33:43

素のLRってテーブルが馬鹿でかくなるんじゃなかった？
それで改良版のLALRが出来たと何かの本で読んだけど。

219 ：217：2005/11/11(金) 22:44:08

>>216
それぐらいだと思う。
もしかしたら 1.8なんとかぐらいの時もあったかも。
>>215
しっかり答えてなかったｽﾏｿ。
LLと比べると、基本はLRなんでユーザが途中の処理にちょっかいをだすのはやりにくい。
あと、yaccみたいに構文の要素に対してプログラムを実行する形式で使うと、
構文の要素が仮決定の段階でプログラムが実行されてしまうということが起こる。
本来の冨田LRは解析木を出力するもので、解析木を完全に作ってから色々すれば問題ないんだけど、
その場合異常に長いソースを食わせたときにO(n)のメモリ量が必要になるので困るかもしれない。
長いソースを書くなとか、メモリをきちんと積んどけとユーザに言える環境だったら問題ないと思う。
>>218
冨田LRはLALRのテーブルでもOK。最近のメモリ事情だったらLRでも大丈夫な気もする。

220 ：デフォルトの名無しさん：2005/11/11(金) 23:11:10

もう構文解析の話はいいよ

221 ：デフォルトの名無しさん：2005/11/11(金) 23:21:55

>>211
>これ以上がんばっても98点を99点にするようなもので、労多くして益少なし

分野は違うが圧縮アルゴリズムを研究してる人間を全否定するような発言だ。

222 ：デフォルトの名無しさん：2005/11/11(金) 23:26:33

全否定はしとらんだろ
＋１点あがってるんだからw

223 ：デフォルトの名無しさん：2005/11/11(金) 23:27:10

>>221
最近は可逆圧縮が人気なのでは？

224 ：デフォルトの名無しさん：2005/11/11(金) 23:38:42

Skypeなんていう素晴らしいものが登場できるくらいだから、コンパイラ屋もがんばれ！
ある程度成熟した分野では、技術は用途が前提にならないと無駄になるよね

225 ：デフォルトの名無しさん：2005/11/12(土) 00:07:47

ここのスレの馬鹿住人 >>206 を１００回読めw

226 ：デフォルトの名無しさん：2005/11/12(土) 00:10:01

>>221
だがそれも事実だ。
企業にとっては対費用効果が重要になる。
決してタイ費用高価ではない。間違うなよ。

227 ：デフォルトの名無しさん：2005/11/12(土) 00:11:30

>>226
すまん。
まちがえそうになった。

228 ：デフォルトの名無しさん：2005/11/12(土) 00:19:24

ここのスレの馬鹿住人 >>206 を１００回読めw

229 ：デフォルトの名無しさん：2005/11/12(土) 00:30:58

なんつーか、前スレからだけど、
面白くもないネタやダジャレ(と本人が思っているもの)や
くだらなーい、くだらなーい煽りとかを、
常にageで書き込んでいる低脳がいるな。

これって何人いるの? もしかしてひとりでやってんの?

230 ：デフォルトの名無しさん：2005/11/12(土) 00:40:56

本人は複数人いるフリをしてるつもりなんだろ。そっとしといてやれよ。
病気なんだって…。

231 ：デフォルトの名無しさん：2005/11/12(土) 00:46:29

例えばJavaを補完するのが目的のスクリプトエンジンがあるとして
Javaオブジェクト生成のルールを統一した複数のスクリプトエンジンを付け替えたりできたら面白いな。
好きなスクリプトでちょろっとDB更新したり、設定値を変更したり（log出力とか）できる。

232 ：207：2005/11/12(土) 01:49:05

>>209
キレイに落ちがつく研究しかないなら研究する必要ないじゃん。
そんな分野は研究する必要がないから，斜陽の学問だろ。
研究しても意味が無い分野も同様だろ。計算機科学の分野はほとんど
そんな感じ。基礎研究は終わっててあとは実用上どうするかとか，
そういう問題になってる。ハードの性能があがるのを待つか，それが
できないなら，小手先の技術でやるかという話なだけで，できるできない
という話になると研究する前にすでに結論が分かってる。この分野の研究
したことあればそれが常識なんであって，ごまかしごまかし，いかにも成果
があったかのように論文書くんだろ。それは一般的な解じゃなくて，ものすご
く限定された用途であることを承知の上で。

233 ：デフォルトの名無しさん：2005/11/12(土) 08:41:03

>>232
何か君を含めて多数の人間が勘違いしているが
ここは「コンパイラ・スクリプトエンジン相談室」であって
「言語相談室」じゃないよ。
>>231みたいなレスがメインでしょ

234 ：デフォルトの名無しさん：2005/11/12(土) 08:47:54

>>233
>>232 は、その研究について話しているのでは？
Lisp馬鹿がでしゃばる流れより、よっぽど良い議論だと思うが？

235 ：デフォルトの名無しさん：2005/11/12(土) 09:25:03

あの w つける自演キチガイですか？ >>234
だからいきなりキチガイみたいにアンチすんなって。
コンパイラとスクリプトの話をしているかぎりは
別に LISP だろうが Ruby だろうがかまないよ。

236 ：デフォルトの名無しさん：2005/11/12(土) 09:31:30

>>234-235

Lispを脈絡なく出してくる＆Lispに過敏に反応するやつ＝Lisper

237 ：デフォルトの名無しさん：2005/11/12(土) 09:34:57

自作言語にオブジェクト指向入れようとすると、つまんない言語になるよね。
あれってなんでだろう。
object.methodみたいなレシーバ従属呼び出しができない言語は
オブジェクト指向言語じゃないと思われる風潮がある。
逆になんであれobject.method形式であればオブジェクト指向言語と勘違いされて
もてはやされる傾向にある。
なんでだろう。

238 ：デフォルトの名無しさん：2005/11/12(土) 09:47:42

低能君は w がつかなくなったんだね。

>>234 Lisp馬鹿が～（←脈絡なくでてくる） → >>236 ～は Lisper（←自演でたたく）

てなパターンを何度見たか。マジで病院いったほうがいいとはおもう。

239 ：デフォルトの名無しさん：2005/11/12(土) 11:16:55

いや、wつけてるのは俺だし、俺はLispマンセーレスしかしてないからｗ

240 ：234：2005/11/12(土) 12:13:42

>>238
病院いった方がいいのは貴方では？
痛いところ指摘されると、何でもかんでも「自作自演」か？

241 ：デフォルトの名無しさん：2005/11/12(土) 12:15:50

232と234の口調が似てる件について。

242 ：デフォルトの名無しさん：2005/11/12(土) 12:43:43

>>241
いや、似てないと思う。
234は文章の最後に？を付けて、他人に疑問系の発言ばかりするのが特徴。
232は逆に文章は断定系の発言が多いというのが特徴。

俺の主観だとむしろ逆のタイプと思うけど。

243 ：デフォルトの名無しさん：2005/11/12(土) 13:00:36

>>232の読点が「，」なのを見ると理系で論文書いたりする感じの人なのか。

…疲れたんだろうなぁ、きっと。

244 ：デフォルトの名無しさん：2005/11/12(土) 13:16:51

それなら，句点も"．"になると思う．

245 ：234：2005/11/12(土) 14:06:09

流石、構文解析やら字句解析に長けてる人達だ。

246 ：デフォルトの名無しさん：2005/11/12(土) 14:07:03

>>236
代入ですか。
まさに「Lisperということにしたい」だけという現実にマッチしていますね :-P

247 ：デフォルトの名無しさん：2005/11/12(土) 14:42:15

おまいらいつから人の発言の構文解析するスレになったんですか？

248 ：デフォルトの名無しさん：2005/11/12(土) 14:47:47

他人の発言って言うけど、自然言語処理の相談もこのスレで良いの？

249 ：このスレの1：2005/11/12(土) 14:58:56

このスレ立てたの俺なんだけど、なにしろ前スレが1000到達寸前だったので
急いで立てたら書籍関係リンクを貼り忘れるわ、前スレで出てきたリンクなんかも
反映させられなかったわだった。今までも、スレの中で出てきた有用なリンクが
テンプレに反映されなかったことは多々あったと思う。

というわけで、勝手にやってすまんが、Wiki立ててみました。

http://www6.atwiki.jp/compilerandscriptengine/

まだテンプレを貼っただけですが(本を1冊増やしたけど)、よければ使ってやってください。

今のところ完全性善説モードになってます。編集もページ立てもファイルアップロードも
誰でも可能。

250 ：デフォルトの名無しさん：2005/11/12(土) 15:20:16

>>249
乙

251 ：デフォルトの名無しさん：2005/11/12(土) 16:00:15

>>249
GJ!

252 ：デフォルトの名無しさん：2005/11/12(土) 19:22:31

>>247
ワロタw

253 ：デフォルトの名無しさん：2005/11/12(土) 20:27:17

言語を現実のITソリューションに活用or適用する技術者と
言語を研究対象とする研究者がまじってるような。。。

前者は企業に不可欠の存在
後者は（ry

254 ：デフォルトの名無しさん：2005/11/12(土) 21:17:10

文字ちっちゃい…… pxで指定してるのかな

255 ：デフォルトの名無しさん：2005/11/12(土) 22:12:31

>>253
前者は変わりがいくらでもいるIT土方
後者は世界を動かす最先端

256 ：デフォルトの名無しさん：2005/11/12(土) 22:56:26

「ITソリューションに活用or適用する技術者」ﾜﾛｽ
格好良く言ってもただの　IT土方　だな確かに

257 ：デフォルトの名無しさん：2005/11/12(土) 23:26:08

>>255

世界を動かす最先端　　　　　　　　false
世界を動かす最先端と妄想する人　　true

258 ：デフォルトの名無しさん：2005/11/12(土) 23:35:41

>>253
前者は、Java/C/C++などに食いつく
後者は、Lisp/Rubyなどに食いつく

259 ：デフォルトの名無しさん：2005/11/12(土) 23:48:02

ITドカタがキレた

260 ：デフォルトの名無しさん：2005/11/13(日) 00:13:22

お前らIT土方の使ってるCやJavaやC#なども、
言語を研究対象とする研究者様が仕様を考えてやった言語だぞ
感謝しろよ

261 ：デフォルトの名無しさん：2005/11/13(日) 00:16:45

Rubyは違いますが何か？

262 ：デフォルトの名無しさん：2005/11/13(日) 00:29:13

>>260
Dennis Ritchie や James Goslingは確かに研究者と呼べるかもしれないが
Hejlsbergはただのプログラマーだろ。

263 ：デフォルトの名無しさん：2005/11/13(日) 00:36:10

>>260
でも、感謝するような研究者って日本には中田氏ぐらいしかいないでしょ？
あんたらは所詮、社会に何の貢献も出来ないシャヨウ研究者w

264 ：デフォルトの名無しさん：2005/11/13(日) 00:37:09

D言語に至ってはコンパイラ屋だからな。
今いちばんの注目株です。最近地味だが。

265 ：デフォルトの名無しさん：2005/11/13(日) 00:37:15

これだから素人はｗ

266 ：デフォルトの名無しさん：2005/11/13(日) 01:31:27

自称クロートキターーーーーーー!!

267 ：このスレの1：2005/11/13(日) 15:22:18

>>254
>文字ちっちゃい…… pxで指定してるのかな

Wikiのことですか?
だとすると、選んだスキンがよろしくなかったということですが、
私自身、ちょっと字が小さすぎかとも思うんですが、他にあんまり
いいのもなくて。

スキンの一覧がここにあります。こっちの方が、というのがあればよろしく。

http://atwiki.jp/design/

268 ：デフォルトの名無しさん：2005/11/13(日) 17:21:35

>>267
http://www6.atwiki.jp/compilerandscriptengine/main.css の…

> body,td
> {
> /* font-family: "ＭＳＰゴシック", Osaka, "ヒラギノ角ゴ Pro W3";
> */ color: black;
>　　 margin-left: 0;
>　　 margin-right: 0;
>　　 /* margin-left: 2%;
>　　　　margin-right: 2%;
>　　 */ font-size: 12px;
>　　 padding:0;
> }

で、font-size: 12px を変えればいいだけ。

>>254
ブラウザの設定で、スタイルシートとかフォントサイズ
指定を無視するようにすればいいだけ。

269 ：このスレの1：2005/11/13(日) 19:18:37

>>268
んなこた言ったってレンタルWikiサービスなんだからスタイルシートを
直接書き換えられはせんだろう、役にも立たない常識レベルの知識を
得意げにひけらかしている人がいるなあ…と思いつつ、念のため調べたら
変更できました。ありがとうございました。

270 ：このスレの1：2005/11/13(日) 22:16:12

http://www6.atwiki.jp/compilerandscriptengine/pages/1.html
・「言語別リンク」のページを追加。
・GC関連のリンクを3つほど追加。
他の方による追加もお待ちしております。

271 ：デフォルトの名無しさん：2005/11/13(日) 23:42:41

>>253
前者は、Java/C/C++/Perlなどに食いつく
後者は、Lisp/リンゴなどに食いつく
素人は、Rubyに食いつく

272 ：デフォルトの名無しさん：2005/11/14(月) 00:37:28

>>271
低能キチガイ出現ー
…ほんと、低能だな。黙っている事も消えることもできないなんて…。

273 ：デフォルトの名無しさん：2005/11/14(月) 00:43:27

これほどのウザさとバカ自演と粘着を兼ね備えたキチガイは近年珍しいね。
ツッコミに対して必死になるところ(>>240 とか)を見ると真性だろうなぁ…

274 ：デフォルトの名無しさん：2005/11/14(月) 01:05:54

>>272
あぁ完全にキレたわ。
放置しようと思ったがお前だけは相手してやる。
Lispとrubyの1vs1。金かけてやろうぜ。負けたほうが10万でいいや。
素で逃げんなよお前。処理系用意できたら連絡よこせ。

275 ：デフォルトの名無しさん：2005/11/14(月) 01:08:32

よし、ここらへんでお前らはマ板にいけ。な？

276 ：デフォルトの名無しさん：2005/11/14(月) 01:14:05

なんか延びてると思ったらまた荒しが暴れてるのか。
>>272 に対してどうしてそーゆうレスになるのか意味わかんない。
バカの考えることって不思議だな。ちょっと恐くなった。

277 ：デフォルトの名無しさん：2005/11/14(月) 01:17:51

あぁ完全にキレたわ。のガイドライン
http://ex13.2ch.net/test/read.cgi/gline/1127121021/

278 ：デフォルトの名無しさん：2005/11/14(月) 01:24:33

ああ
影響されてコピペしたわけね

279 ：デフォルトの名無しさん：2005/11/14(月) 12:17:07

板にID制の導入ｷﾎﾞﾝﾇ

280 ：デフォルトの名無しさん：2005/11/14(月) 12:58:39

>>279
自治スレへどうぞ。

281 ：デフォルトの名無しさん：2005/11/14(月) 19:32:44

たぶん、キレてるやつは
社会に何の貢献も出来ないシャヨウ研究者w

282 ：デフォルトの名無しさん：2005/11/14(月) 21:40:46

うるせぇ！

283 ：デフォルトの名無しさん：2005/11/14(月) 21:56:15

問題はこのスレで何の話が相応しいかだ。
字句解析・構文解析程度だったら別スレ立ててそっちでやってくれって感じ。
いいかげんそっから先の話がしたい。
それともいっそ専門スレでも立てた方がいいのか。

284 ：デフォルトの名無しさん：2005/11/14(月) 22:05:36

例えば最適化ならそれに特化したスレを立ててみるとか

スレタイ：
言語処理系の最適化相談室1

テンプレ：
プログラミング言語処理系の*最適化*に興味のある人達のスレッドです。

データフロー解析，ループ並列化，データ分散，SSA変換，
CPS変換，レジスタ割付，命令スケジューリング，ソフトウェアパイプライン，
SIMD命令生成，VLIW向けクラスタリング，スクラッチメモリ向け最適化，リンク時最適化，
JIT，動的バイナリ変換等の各種最適化，それにVM，GC，低消費電力化などなど。
意味論に関する話題も歓迎です。

※字句解析・構文解析などの表層的な話題は以下のスレでやってください。
「コンパイラ・スクリプトエンジン」相談室8
http://pc8.2ch.net/test/read.cgi/tech/1131273918/

285 ：デフォルトの名無しさん：2005/11/14(月) 22:07:50

>>284
そんなのは他所でやれ。

286 ：デフォルトの名無しさん：2005/11/14(月) 22:17:21

>>284
それでいいんじゃねーの。
本来のスレッドの使い方だよ。
このスレは今後は厨、ネタ隔離スレとして機能する。

287 ：デフォルトの名無しさん：2005/11/14(月) 22:18:18

>>286
自演乙（超久々に使ったよ））

288 ：デフォルトの名無しさん：2005/11/14(月) 22:19:52

自演されるのが嫌ならさっさとID制にしてもらえば？

289 ：デフォルトの名無しさん：2005/11/14(月) 22:20:21

>>283
ネタふれば話が進むだろうが、愚痴じゃ進めようもないじゃねぇか。

290 ：デフォルトの名無しさん：2005/11/14(月) 22:20:38

じゃあ立ててくるか？
俺は無理っぽ

291 ：デフォルトの名無しさん：2005/11/14(月) 22:23:31

ここしばらく変なのが常駐してるから別スレ立てたいなら止めはしない。

292 ：デフォルトの名無しさん：2005/11/14(月) 22:26:10

関係ないけど>>1の「動的バイナリ変換」て何？
昔流行った自己書き換えのこと？

293 ：デフォルトの名無しさん：2005/11/14(月) 22:26:11

既存のスクリプトエンジンをどう組み込むかとかな。
SpiderMonkeyとか設定ファイル代わりに使えば面白い流れが生まれそう。
車輪の再開発より使われていないリソースの発掘のが大事。

294 ：デフォルトの名無しさん：2005/11/14(月) 22:31:28

>>293
使われていないリソースには使われない理由があるような気が
設計が古臭くて今のトレンドとかみ合わないとかライセンスや作者の人格に問題アリとか

295 ：デフォルトの名無しさん：2005/11/14(月) 22:41:42

例えば今まではWebアプリはDBの内容を書き換えることによって動的に設定をいじったりするけど
組み込みが主流になれば、ハッシュをいじる事ができて、マスタテーブルの類はオンメモリで行ける。

296 ：デフォルトの名無しさん：2005/11/14(月) 22:52:59

>>294
（煽りじゃなくって）人格って関係する？

297 ：デフォルトの名無しさん：2005/11/14(月) 23:14:20

>>292
TransmetaのCMSとか？

>>296
RubyはMatzが（略）とか、言語じゃないがOpenBSDはTheoが（やっぱり略）とか、
技術自体とは関係ないところで影響する場合もないとも言い切れないとは思う。

298 ：デフォルトの名無しさん：2005/11/15(火) 00:33:57

Theoどんの人格は確かにアレなんだが、それでも使われてるOpenSSHについて

299 ：デフォルトの名無しさん：2005/11/15(火) 00:36:58

まつもとに何か問題あったか？普通というか優等生過ぎて詰まらん位だと思うが。

300 ：デフォルトの名無しさん：2005/11/15(火) 03:00:22

今BNFを記述しているのですが、
式をexpressionとすると、式を構成する項をあらわす
単語って何になりますでしょうか？

301 ：デフォルトの名無しさん：2005/11/15(火) 03:12:24

>>300
term

302 ：デフォルトの名無しさん：2005/11/15(火) 03:17:22

式を構成するのは式じゃないの？

303 ：デフォルトの名無しさん：2005/11/15(火) 05:36:50

>>292
http://www.microarch.org/micro33/tutorial/m33-t-issues.pdf

304 ：デフォルトの名無しさん：2005/11/15(火) 05:48:47

前スレの消費が早すぎてログ取り損ねた。
だれか、うｐしてくれ。

305 ：デフォルトの名無しさん：2005/11/15(火) 18:56:06

>>304
ttp://www.uploda.org/file/uporg238263.zip.html

306 ：デフォルトの名無しさん：2005/11/15(火) 19:56:34

>>804
どうせ読んでもLispの話しばかりだよw

307 ：デフォルトの名無しさん：2005/11/15(火) 21:15:52

>>301
サンクスです。

>>302
それだとループしちゃうっしょ。

308 ：デフォルトの名無しさん：2005/11/15(火) 21:58:41

>>307
再帰させるのが構文解析のミソ

309 ：デフォルトの名無しさん：2005/11/15(火) 22:27:53

なら、終了条件(終端記号)も用意しなきゃな。

310 ：デフォルトの名無しさん：2005/11/15(火) 23:04:56

>>309
式を展開していくと最終的には値になるからそれが終了条件じゃね？
とか適当なことをほざいてみるテスト

311 ：デフォルトの名無しさん：2005/11/15(火) 23:30:40

>>306
ものすげぇ遠い未来のスレようこそ

312 ：デフォルトの名無しさん：2005/11/16(水) 01:11:11

>>310
それが項だろ。なら「式を構成する項」で合ってるだろ。

つうか、「～みるテスト」って久しぶりに見た。
ものすげぇ遠い過去のスレからようこそ

313 ：デフォルトの名無しさん：2005/11/16(水) 01:37:25

つか、「項」を持ち込まないと演算子の優先順位が表現できんだろ。
*や/でつながれた式が「項」。それを+や-でつなげたのが「式」。

314 ：デフォルトの名無しさん：2005/11/16(水) 01:42:55

(式)は終了してないけど項？
なんだかよくわかんね。
レベル低くてごめん、勉強してくる。

315 ：デフォルトの名無しさん：2005/11/16(水) 01:43:25

じゃあそれを << で繋げたのは何？
さらにそれを && で繋げたのは何？
さらにそれを…

316 ：デフォルトの名無しさん：2005/11/16(水) 02:06:48

>>315
K&Rの末尾の構文規則でも読め。
つかWeb上でも探せば電卓の構文規則くらいあるし。
というわけで探した。再帰下降パーサ付きだ。

http://www.ie.u-ryukyu.ac.jp/~kono/lecture/compiler/c4/lecture.html

317 ：デフォルトの名無しさん：2005/11/16(水) 10:49:28

>>307
解析する式は段々と小さな部分式になっていって
いつか変数か定数に帰着して終わるから無限再帰ではない。
つまり最終的に出来上がる構文木のすべての葉ノードまで
ノードを作成しながら"再帰"的に"下降"して終了する。

（これはプログラミング言語関係の各種の性質の数学的証明で
よく使われるテクニックである「式の長さによる帰納法」に対応してるわけだな。）

とはいえ実際問題としては演算子の優先順位や結合規則を文法的に表現する必要から
式を何種類か（代入式、条件式、論理和、論理積、単項式などなど）にわけて
その間を巡りながら再帰していくわけだけどな。

で、再帰を素朴に再帰呼び出しで書く（再帰降下法）と
大規模なプログラムに対しては
再帰が深くなりすぎて溢れたり実行効率が悪化したりするから
パーサ・ジェネレータは自前で管理するスタックとループで動くような
コードを生成することが多いわけですな。

318 ：デフォルトの名無しさん：2005/11/16(水) 13:58:41

「自分が言い負けたかのように見えなくもない」ログを万が一にも残したくなくて、
みんな揚げ足取りに必死ですね(^_^;

319 ：デフォルトの名無しさん：2005/11/16(水) 14:08:39

>>318
俺も常々不思議なんだが、記名式ならともかく匿名式で必死になる意味がわからん

320 ：デフォルトの名無しさん：2005/11/16(水) 14:58:26

>>318-319
議論では疑問点を質すことは当然だし、
それをやらずになぁなぁで済ませたら正確な情報交換ができん。
その過程が揚げ足取りにしか見えないのは素人の浅墓さというもの。
特に立場も背景も知識も異なる多人数でやりとりしてれば
一見つまらないことに価値を見出し明確にしたいと思うものがいても
全く不思議はないし、むしろそういうことがあるからこそ
細部が詳細になり議論は深まる。
必死なんじゃなくて真面目なだけだろう。
なぜならどうせ時間使って議論するなら意味がある議論をしたいからな。

321 ：デフォルトの名無しさん：2005/11/16(水) 15:31:47

>>320は>>317ってことでＯＫかな？
おまいさんが真面目に語ったのはわかったが、それに対して反論も煽りも来るのが２ｃｈ。
その程度で駄々こねるなら初めから書き込まなきゃいいのに。

322 ：デフォルトの名無しさん：2005/11/16(水) 15:34:33

termがterminationの略だと思ってる人がいるみたいだけど、そうなのか？
そのまま「項」、つまり単項式って意味だと思ってたんだけど。

323 ：デフォルトの名無しさん：2005/11/16(水) 15:51:35

>>321
なんでマジレスすると駄々こねたことになるのかが不思議。

324 ：デフォルトの名無しさん：2005/11/16(水) 16:32:25

マジレスの応酬になると馬鹿には不利だから、
なし崩しにそれを「痛い行為」ということにしてしまっているのでは。

325 ：デフォルトの名無しさん：2005/11/16(水) 16:38:49

2chで必須のスルーを覚えよう。

326 ：デフォルトの名無しさん：2005/11/16(水) 17:05:54

ここより萌え言語スレのほうが熱いな。

327 ：デフォルトの名無しさん：2005/11/16(水) 17:06:14

>>325
スルーすることはもちろんあるがその基準は個人的なものだから
それをとやかく言われてもなんともしようがありませんなぁ。
煽りと反論を弁別する閾値は人それぞれでしょう？
（時間など余裕がなくて結果的にスルーになるなど、
同じ人でも時々の事情で変わるだろうし…。）

自分の場合は愉快犯的であることが明らか（無意味なコピペを繰り返すなど）とか
知的・精神的障害の兆候が明らか（あまりに支離滅裂な内容）とかでなければ
反論と取るし、反論には必要に応じて言論で対処する。

正直>>324のような感想を持つ瞬間もあるが、それは決め付けずに置くべく努めている。

328 ：デフォルトの名無しさん：2005/11/16(水) 17:41:53

注意：スルーしないからこうやって不毛な精神論に発展するのです。

329 ：デフォルトの名無しさん：2005/11/16(水) 18:21:08

>>328
自己言及？ｗｗｗ

330 ：デフォルトの名無しさん：2005/11/16(水) 18:31:43

>>322
termはtermだよ（本当の語源までは知らないけど）。
むしろ英語では式→expressionで、終端記号→terminal、非終端記号→nonterminal

>>300
「項」って何？名前選びに迷ってるならこことかどうよ？（Javaの文法）
http://www.y-adagio.com/public/standards/tr_javalang2/syntax.doc.html#44467
まあ自分で定義した「項」なるものを取り入れたいならtermでいいと思う。

331 ：デフォルトの名無しさん：2005/11/16(水) 18:55:48

>>329
リフレクションかw
何か面白いインターフェースでリフレクションを実装してる人いる？

自分はAspectもtemplate metaprogramming もgenerative Programmingの観点から
見事に整理して見せた書籍（"Generativ Programming", K. Czarnecki and U.W. Eisenecker
, Addison-Wesley, 2000）に感動してGenerative Programmingの観点から
リフレクションを整理した言語を作れないものかと思っているんだが今のところアイディアがない。

332 ：デフォルトの名無しさん：2005/11/16(水) 20:52:27

>>313
どちらもexpressionでしょ普通。馬鹿？

333 ：デフォルトの名無しさん：2005/11/16(水) 20:58:12

ついでに突っ込んでおくと、文->Statement

334 ：デフォルトの名無しさん：2005/11/16(水) 21:06:07

-/*+12345

335 ：322：2005/11/16(水) 22:08:31

>>330
goo 辞書より「項」
> (2)〔数〕
> (ア)多項式を構成するそれぞれの単項式。
> (イ)数列・級数で、そのおのおのの数や式。

336 ：322：2005/11/16(水) 22:20:31

terminationってよりterminalですね。すみません。
terminalの語源がtermとか、その逆とか、同じ語源を持つとか？

まあ語源はどうでもいいんだけど、BNFのそういう例で出てくるtermは
「終端」とか「停止」とかいう意味ではないんじゃないかと。
それにterminalの略なら、expressionもexprとかexpに略すんじゃない？

連投ｽﾏｿ

337 ：デフォルトの名無しさん：2005/11/16(水) 22:22:06

全てはリスト

338 ：デフォルトの名無しさん：2005/11/16(水) 22:29:24

普通はterm->停止でよいかと。

339 ：デフォルトの名無しさん：2005/11/16(水) 22:30:26

おれはexp派

340 ：デフォルトの名無しさん：2005/11/16(水) 22:31:01

普通？

341 ：314：2005/11/16(水) 22:31:52

>>322 >>335
つまり「項⊂式」か。理解したｻﾝｸｽ。
停止云々の発言以外は、両者の言い分どちらも正しかったって感じだな。

342 ：デフォルトの名無しさん：2005/11/16(水) 22:33:42

秀term

343 ：デフォルトの名無しさん：2005/11/16(水) 22:59:42

>>318
勝負あったようだな

344 ：デフォルトの名無しさん：2005/11/16(水) 23:34:55

俺はLisp派

345 ：デフォルトの名無しさん：2005/11/16(水) 23:46:47

>317
>解析する式は段々と小さな部分式になっていって

左再帰性の問題みたいに、段々小さくならない場合もあるよ。

346 ：デフォルトの名無しさん：2005/11/16(水) 23:53:28

>>336
つ http://www.m-w.com/dictionary/term
語源同じだそうです。

347 ：デフォルトの名無しさん：2005/11/16(水) 23:53:58

俺はruby派

348 ：デフォルトの名無しさん：2005/11/17(木) 00:18:57

Rubyソースは見た目が悪い。

349 ：デフォルトの名無しさん：2005/11/17(木) 09:41:12

termを項と訳している本はいっぱいあるよ

350 ：デフォルトの名無しさん：2005/11/17(木) 11:40:50

俺は
statement->expression->term->factor
って使うけど。

というかコンパイラ本ってこうなってね？

351 ：デフォルトの名無しさん：2005/11/17(木) 12:12:07

>>350
Look Ahead（先読み）があるとtermとかfactorとか使わなくてもexpression書けちゃうからな。
特にyacc系から入るとあまり見かけないんじゃないかな。

352 ：304：2005/11/17(木) 17:38:20

>>305
さんくす

353 ：デフォルトの名無しさん：2005/11/17(木) 18:46:22

>>351
そうだな。bison/yaccならexpression以下は本当にそのままを表すだけがほとんど。
例）semicolon

354 ：デフォルトの名無しさん：2005/11/17(木) 21:57:59

俺はりんご派

355 ：デフォルトの名無しさん：2005/11/17(木) 22:16:01

シッシッ

356 ：デフォルトの名無しさん：2005/11/17(木) 23:44:23

合えて言うと真珠派かな？

357 ：デフォルトの名無しさん：2005/11/18(金) 14:24:30

Perlのオブジェクト指向システムってどうよ？
第一引数がパッケージ名や参照でそれがそのままselfになるのって
argv[0]をうまく使ったトリックだよね。
実際はクロージャ生成をNewで隠蔽して、そのクロージャの環境を
持ち回ってるってことになるんだよね。
ああいうの元ネタあるの？

358 ：デフォルトの名無しさん：2005/11/18(金) 15:58:06

>>357
argv[0] つか、$_[0] な。

あれはあれで良いものだが、クラス・メソッドの呼び方に
SomeClass::operation() と SomeClass->operation() があるのは、
美しくないというか、直感的じゃないとは思うね。

359 ：デフォルトの名無しさん：2005/11/18(金) 22:10:53

LL(1)で文法を考えてたんですけど、
式は一般的な形で最終的に、数値か識別子か括弧の式になります。それで
文 ::= 代入文 | 式文
代入文 ::= 識別子 ':=' 式文
式文 ::= 式 ';'
という文法だと、代入文と式文の両方のfirst(n)に識別子が含まれて駄目ですよね。
でもよくありそうな文法で、文法を変形したり、何かアイディアあったら教えてください。

360 ：デフォルトの名無しさん：2005/11/18(金) 22:59:25

BASIC風味で
代入文 ::= 'let' 識別子 ':=' 式文
とか

シェルスクリプト風に変数の参照は$をつける、とか

文 ::= 代入文 | 関数呼び出し文 | while文 | return文 | ...
にして式文を書けなくしてしまう、とか

代入文ではなく代入式にしてしまうとか。

なんかウチの大学のカリキュラム思い出した。
ウチの大学の宿題じゃないよな？

361 ：デフォルトの名無しさん：2005/11/18(金) 23:05:56

LL使ってる時点で実用性が乏しいといえるだろう。
まぁ、宿題なら仕方無いが。

362 ：デフォルトの名無しさん：2005/11/19(土) 00:48:19

>>361
pascal しらんの？アフォ？

363 ：デフォルトの名無しさん：2005/11/19(土) 00:51:04

解析能力と実用性に相関関係は無いと思うが

364 ：デフォルトの名無しさん：2005/11/19(土) 01:02:16

>>363
普通にあるでしょ？
現実をしらない研究者ならともかく、発想がしんじられない。

365 ：デフォルトの名無しさん：2005/11/19(土) 01:19:35

>>364
LLに収まる文法が
LLに収まらない文法に比べて何が劣ってるか説明してくれない？
単純に興味があるので。

366 ：デフォルトの名無しさん：2005/11/19(土) 01:29:37

LL(1)とかに収まらない言語でも今はLLで書くだろ。

367 ：デフォルトの名無しさん：2005/11/19(土) 01:31:54

368 ：デフォルトの名無しさん：2005/11/19(土) 01:32:51

高い解析能力が全く要求されないLispは人間にとって覚えやすいんですか？

369 ：デフォルトの名無しさん：2005/11/19(土) 01:39:00

もちろん文法は覚えやすいだろ。
当然文法を覚えることと言語を使いこなすことは別だが。

370 ：デフォルトの名無しさん：2005/11/19(土) 01:44:50

>>368
forの構文やifの構文など、通常は文法の範疇のものが、
Lispだと関数やマクロの呼び出しになって、文法の範疇から
外れるだけ。

トータルで見れば、通常文法に相当する知識が減ってるわけ
じゃないが、文法に属する範囲は狭い。

371 ：デフォルトの名無しさん：2005/11/19(土) 03:35:02

覚えやすい≠使いやすい

372 ：デフォルトの名無しさん：2005/11/19(土) 06:16:52

また構文の話ですか。。

373 ：デフォルトの名無しさん：2005/11/19(土) 08:34:25

>>368
最近、仕掛けが巧妙になってきている。

374 ：デフォルトの名無しさん：2005/11/19(土) 23:01:29

>>373
｜
｜
｜
しりんご

375 ：デフォルトの名無しさん：2005/11/20(日) 00:02:34

パクッ

376 ：デフォルトの名無しさん：2005/11/20(日) 00:14:02

馬鹿でも理解できるLispってか

377 ：デフォルトの名無しさん：2005/11/20(日) 00:17:31

尻んご

に見えた

378 ：デフォルトの名無しさん：2005/11/20(日) 00:25:36

21st Century Compilers買った人いる？

379 ：デフォルトの名無しさん：2005/11/20(日) 00:30:14

え、アレ出たの？

380 ：デフォルトの名無しさん：2005/11/20(日) 00:50:24

http://www.amazon.co.jp/exec/obidos/ASIN/0321131436/249-1922842-0005150
年末の暇つぶしにでも

381 ：デフォルトの名無しさん：2005/11/20(日) 03:50:30

3～5週間って、運が悪いと年が明けてから着くんじゃないか……

382 ：デフォルトの名無しさん：2005/11/20(日) 03:58:10

円安だからか、洋書が高いな

383 ：デフォルトの名無しさん：2005/11/20(日) 21:52:49

>>380
この本って、一年以上前から紹介されて入るけど、発売が(ry

384 ：デフォルトの名無しさん：2005/11/20(日) 23:22:31

>>368
覚えやすいが、使いにくい。

385 ：デフォルトの名無しさん：2005/11/21(月) 19:23:38

馬鹿研究者程、食いつきが良いw

386 ：デフォルトの名無しさん：2005/11/21(月) 19:29:07

研究者であるならば、内容に関わらず買う必要はあるだろうな。教養として。

387 ：デフォルトの名無しさん：2005/11/21(月) 20:26:57

宣伝ならもうちょっとうまくやろうぜ

388 ：デフォルトの名無しさん：2005/11/21(月) 20:34:38

素人の集まりのくせに、何が研究者だよ。ばかばかしい。

389 ：デフォルトの名無しさん：2005/11/21(月) 23:16:36

>>388
いや、結構いるとおもうぞ。
ただし、パラダイムを買える程のテーマは皆無だがw

390 ：デフォルトの名無しさん：2005/11/22(火) 00:06:54

つまり、重箱の角研究ってやつ？
ワロタw

どこからも引用されず、どこにも適用されずw

391 ：デフォルトの名無しさん：2005/11/22(火) 00:13:46

というか一番作りやすいからだろうな >> 研究用

392 ：デフォルトの名無しさん：2005/11/22(火) 00:21:47

洋書に限らず値が張る書籍は会社に買わせて内容を確認してから気に入った奴だけ個人で購入してる。
研究所勤務のメリットではあるな。

393 ：デフォルトの名無しさん：2005/11/23(水) 00:19:21

つまらんメリットだなw

394 ：デフォルトの名無しさん：2005/11/23(水) 00:41:04

IBMのTRLとか、図書システムに関しては非常に良く出来ていたな

395 ：デフォルトの名無しさん：2005/11/23(水) 01:00:22

>>390
ワロタw

どこかのウイスキーみたいな宣伝文句だなw

396 ：デフォルトの名無しさん：2005/11/23(水) 01:22:41

なんかここ、ロートルの墓場みたいね

397 ：デフォルトの名無しさん：2005/11/23(水) 12:27:15

bison を使って簡単なスクリプト言語を作成してるんですが
実行時にエラーが発生したとき
ソースの何行目でエラーが出たかを出力したいと思います。

例えば、数値と文字列の加算が認められないとき
　　a = 1 + "hello"
とすると実行時にエラーが出るようにしてるんですが
'+' がソース中の何行目かが知りたいんですがいい方法はありますでしょうか？

字句解析の結果に
そのトークンの行数も含めればいいと思うんですが
bison の %union を使うと行数を含めることができないので
なにかいい方法があったら教えてください。

398 ：デフォルトの名無しさん：2005/11/23(水) 13:16:19

>>397
yylinenoじゃ不満？

399 ：デフォルトの名無しさん：2005/11/23(水) 18:48:32

エラーにはならんよ。
a="hellp"

400 ：デフォルトの名無しさん：2005/11/23(水) 19:07:40

>398
bisonで、式を
　　expr
　　　　: expr '+' expr
　　　　| expr '*' expr
　　　　...
という具合に書いているのですが、
間に改行を入れている場合
アクションで得る時点のyylineno では
演算子の出現した行番号と異なってしまうのです。

かといって、演算子を非終端記号にして
その時点のyylinenoを記録しておくとすると
演算子同士の優先の設定ができなくなりますし…。

401 ：デフォルトの名無しさん：2005/11/23(水) 21:00:58

大物は来ないのか？

402 ：398：2005/11/23(水) 22:12:45

>>400
.yで
%union { ...; int lineno; ...; }
%token<lineno> '+' '-' ...

.lで
"+" {yylval.lineno = yylineno; }
"-" {yylval.lineno = yylineno; }
...

ってダメなんだっけ？

403 ：398：2005/11/23(水) 22:16:08

ごめん。 return忘れてた。
"+" {yylval.lineno = yylineno; return '+'; }

404 ：デフォルトの名無しさん：2005/11/23(水) 23:05:34

>402
その方法でいけそうです。
ありがとうございます。

405 ：デフォルトの名無しさん：2005/11/23(水) 23:23:27

yylinenoは標準じゃないんで、男は黙って自力で行番号数える…
ってのはもう古い常識なのかしら。

406 ：デフォルトの名無しさん：2005/11/23(水) 23:39:18

標準って、yacc って何かで標準化されてるの？

407 ：デフォルトの名無しさん：2005/11/23(水) 23:42:44

>>406
ANSI-yacc

408 ：デフォルトの名無しさん：2005/11/24(木) 00:25:06

日本の研究論文って、有名人以外ろくなものがない。
外人でもそうだけど、この分野もはやフンズマリ状態なのかorz

409 ：デフォルトの名無しさん：2005/11/24(木) 00:29:16

有名人の方がやっぱりいい論文書くのか。

410 ：デフォルトの名無しさん：2005/11/24(木) 00:38:26

いい論文を書くから有名人なんじゃないの？

411 ：デフォルトの名無しさん：2005/11/24(木) 13:53:03

そもそも人がいないだろ。狭い世界じゃね？皆知り合いだろ。

412 ：デフォルトの名無しさん：2005/11/24(木) 14:10:59

日本塵はパクって昇華するのが生業なんだよ
論文書く文化なんてそもそも日本に存在しない
書かなくても有名になれる

413 ：デフォルトの名無しさん：2005/11/24(木) 16:03:03

>>412
和算もしらねぇタコはすっこんでろよ

414 ：デフォルトの名無しさん：2005/11/24(木) 16:14:06

知恵の代わりに自意識が育っている間抜けに
その要求はきついと思いますよ :-)

415 ：デフォルトの名無しさん：2005/11/24(木) 18:01:55

>>413
和算てそろばんぐらいしか出番ないんじゃない？
このスレと何か関係あるの？

416 ：デフォルトの名無しさん：2005/11/24(木) 18:13:52

>>415
このスレとは関係ないが、和算はそろばんとかそういうレベルじゃない
413も頭弱そうだが、あんたも教養ないな

417 ：デフォルトの名無しさん：2005/11/24(木) 18:26:09

>>416
スレと関係ねぇならすっこんでろよ

418 ：デフォルトの名無しさん：2005/11/24(木) 18:35:30

>416
>和算はそろばんとかそういうレベルじゃない

きっとすごいレベルなんですね。
どういうレベルなんですか？
教養のある416さんに説明してもらえるとありがたいです。

419 ：デフォルトの名無しさん：2005/11/24(木) 18:48:00

>>418
google wikipedia 和算

420 ：デフォルトの名無しさん：2005/11/24(木) 19:07:06

>>419
http://ja.wikipedia.org/wiki/%E5%92%8C%E7%AE%97
要約すると
和算は中国のパクリ、明治時代没、そろばんは広く用いられた
だから何

421 ：デフォルトの名無しさん：2005/11/24(木) 19:31:08

>>420
読解力ﾋｸｽ…

422 ：デフォルトの名無しさん：2005/11/24(木) 19:38:26

>>420
関孝和とか中学で習わなかった？

423 ：デフォルトの名無しさん：2005/11/24(木) 19:45:16

>>416
それで、どういうレベルなんですか？

424 ：デフォルトの名無しさん：2005/11/24(木) 19:56:13

数学板でやれ
↓のスレ盛り上げてやれよｗ

算額について語るスレ【和算】
http://science4.2ch.net/test/read.cgi/math/1104398345/

1 名前：１３２人目の素数さん投稿日：04/12/30 18:19:05
ここは江戸時代に日本独自に栄えた数学、「和算」について語るスレです

2 名前：１３２人目の素数さん投稿日：04/12/30 18:25:38
クロワッサンでも食べてろ

3 名前：１３２人目の素数さん投稿日：04/12/31 06:30:33
さんがくのもんだいしゅうってでてる?

4 名前：１３２人目の素数さん投稿日：04/12/31 07:15:08
ｶﾄﾁｬﾝ､屁゜

5 名前：１３２人目の素数さん投稿日：04/12/31 14:20:26
荒れすぎ

425 ：デフォルトの名無しさん：2005/11/24(木) 20:04:22

>>423
>>416も頭弱くて教養がないので答えられません
というレベル

426 ：413：2005/11/24(木) 20:32:37

ほんとに教養無いのなorz

今で言う微分、積分とかの概念も日本で独自に育っていたのだよ。

427 ：デフォルトの名無しさん：2005/11/24(木) 20:53:19

外人が、江戸時代、金地金を買い付けに来た時に、地金の重量だけでなく純度も価格に反映すべきだ、
といって日本人が当時小数点付きの割り算を和算でやったという話を聞いたことがある。外人は、
小数点の割り算ができなかったそうだ。

現状、コンピュータサイエンスはほとんど米国主導、輸入品なのは認めるが、日本人だから想像力が
なくて、後追いぱくり研究しかできない、というのは暴論だと思う。可能性はあるのだから。

428 ：デフォルトの名無しさん：2005/11/24(木) 21:06:48

>>426
413=416なら「そういうレベル」を説明しろよ
お前が説明できない＝教養ないだけだろ

429 ：デフォルトの名無しさん：2005/11/24(木) 21:07:56

あんま関係ないけど
日本人なのに論文を英語で書く文化って何なの？
あれって日本じゃ評価してくれないから英語で書いてるわけ？
あと日本語なのに横書きで書くのも変だよね。
縦書きがまともに機能してるのって出版業界だけかな。

430 ：デフォルトの名無しさん：2005/11/24(木) 21:27:41

>>429
はぁ？バカかお前。
そのレスは日本語なのに横書きじゃねーか。変だよね。
せめて縦読みくらい仕込む知能を見せろや。

431 ：デフォルトの名無しさん：2005/11/24(木) 21:32:02

ね
こ
大
好
き

432 ：デフォルトの名無しさん：2005/11/24(木) 21:44:23

>>429
カﾉﾚテをドイツ語で書く文化と同じだよ。
患者に何書いてるかわからなくするため。

433 ：デフォルトの名無しさん：2005/11/24(木) 21:51:14

>>429
日本語読めない人にも読んでもらいたいからだろ？

434 ：デフォルトの名無しさん：2005/11/24(木) 21:59:07

>>433
はぁ？バカかお前。
わざわざ英語で書く意味なんてない。自己満足だよね。
せめて日本語くらい読む知能を見せろや。

435 ：デフォルトの名無しさん：2005/11/24(木) 22:12:04

　　　引
　貴用
　殿
　も .四
　な .百
　　　二
　　　十
　　　九

436 ：デフォルトの名無しさん：2005/11/24(木) 22:19:48

LISPの話しようぜ

437 ：デフォルトの名無しさん：2005/11/24(木) 22:24:00

>>432
最近は英語が主流だけど・・・

438 ：デフォルトの名無しさん：2005/11/24(木) 22:39:00

そもそもカルテはドイツ語なんだが。

439 ：デフォルトの名無しさん：2005/11/24(木) 22:40:49

途中から失礼します。
パーサ(パーサー?)の話とかここでいいんですよね。
(他のスレあったら教えてください)
仕事で幾つかのフォーマットを読み下すプログラムを
書いてきたんですが、毎回使い捨てで同じような
のを何度も書いている気がしています。
そこでパーサーと言われるプログラムの基礎を勉強しようかな
と考えています。
情報系とか出てないので理論的な知識が無いんだけど、
基礎から書いてある良い本とか良いサイトないですか。
よろしくお願いします。
パースだけ出来ればＯＫです。

440 ：デフォルトの名無しさん：2005/11/24(木) 22:42:51

>>439
つ[yacc]

441 ：デフォルトの名無しさん：2005/11/24(木) 22:52:06

>>439
つ[テンプレ]

442 ：439：2005/11/24(木) 22:53:51

>>440 ありがとうございました。
yaccとかlexとかがあるんですね。ちょっと調べると
BNFとか正規表現とかあるんですが、本を買ったりして
調べる前に1つ質問です｡
このyaccとかは世の中にあるtextでかかれているフォーマットなら
基本的に何でも読み下すことが出来るんですか?
cでもperlでもhtmlでも。
自分が今パースしたいファイル形式がこのyaccでパースできるか
どうかはどうやって確かめればいいんしょうか。
spice netlist, verilog gatenet, EDIT, ascii GDSなど
をパースしたいんですが。
よろしくお願いします。

443 ：デフォルトの名無しさん：2005/11/24(木) 22:54:46

>>434
馬鹿はお前だ。わざわざ日本語で論文を書く意味なんてない。
なぜなら、日本人に読ませる意味がないからだ。

444 ：439：2005/11/24(木) 22:59:43

>>441 おお!これらを読んでまた来ます。

445 ：デフォルトの名無しさん：2005/11/24(木) 23:35:30

>>432
それってよく効くけど、
じゃあドイツ人は何語で書いてるん？

446 ：デフォルトの名無しさん：2005/11/24(木) 23:38:48

ドイツ人は正しいことを書いているのだから見られても平気って思ってるんじゃない？

447 ：デフォルトの名無しさん：2005/11/24(木) 23:40:10

>>429
引用されるためだよ。
論文の価値ってのは他の誰かの論文に引用されることにある。
ちなみに日本人の論文は提出率に対する引用率はいまいち低いらしい。

448 ：デフォルトの名無しさん：2005/11/24(木) 23:41:09

>>443
で、研究のオイシイ部分は全部外人に持っていかれるわけだ。

449 ：デフォルトの名無しさん：2005/11/24(木) 23:41:24

>>432
今時の若手の偉いさんだと英語で書いていて、もうちょっと下の年齢だと日本語で書いてるよ<カルテ
習った時分によるみたい。

450 ：デフォルトの名無しさん：2005/11/24(木) 23:42:31

>>447
それはつまり、日本人の書く論文は、世界の役には立って無い？

451 ：デフォルトの名無しさん：2005/11/24(木) 23:44:47

>>450
いや、所謂ポスドクってのが癌なんだよ。
博士になるために助手しながら無尽蔵に数をこなし続ける。

452 ：デフォルトの名無しさん：2005/11/24(木) 23:48:36

>>439
つりんご本

453 ：デフォルトの名無しさん：2005/11/24(木) 23:52:02

>>451
ポスドクは博士持ちの底辺ポストだろ。

454 ：デフォルトの名無しさん：2005/11/24(木) 23:52:24

>>450
一部の有名人を除きその通り。
日本人の論文テーマは、他の論文テーマの一部分について
特殊な前提条件で研究しているものがよくある。

455 ：デフォルトの名無しさん：2005/11/24(木) 23:56:39

耳が痛い
耳が痛い
耳が痛い

456 ：デフォルトの名無しさん：2005/11/25(金) 00:18:01

>>448
まぁまぁ、落ち着いて。
売国奴の>443など放っておいて、あなたはあなたで
外人にオイシイ部分を持って行かれないために
日本語だけを読み、日本語だけを書いて一生を送っていればいいんですよ :-)

457 ：デフォルトの名無しさん：2005/11/25(金) 00:30:39

おめーの重箱の済み研究なんて全く役に立たないよw
ば～ろ～！

って言ってみたいw

458 ：デフォルトの名無しさん：2005/11/25(金) 03:03:06

おもしろいスレだな。LISPで荒れたり、英語で荒れたり、和算で荒れたり、博士で荒れたり。

459 ：デフォルトの名無しさん：2005/11/25(金) 03:06:15

>>442
その質問は本を読めば大体書いてあることです

460 ：デフォルトの名無しさん：2005/11/25(金) 03:22:16

>>458
すべてに共通しているのは
無知なくせにやたらとわめく人がいるところ。

461 ：デフォルトの名無しさん：2005/11/25(金) 06:58:59

>>460
具体例が書かれていないので、
「ここでわめく為に必要な聞きかじりの知識」すら無い人が
「わめき」にすら参加できず悔しがっているようにしか見えません :-)

462 ：デフォルトの名無しさん：2005/11/25(金) 08:27:04

研究ってのは役に立たなくてはいけない研究と、そうではない研究ってのが
あるんだよ。理系の人なら分かってもらえると思うが。

463 ：デフォルトの名無しさん：2005/11/25(金) 08:28:49

この板には残念ながら理系はいません

464 ：デフォルトの名無しさん：2005/11/25(金) 08:30:30

その通り
全員アキバ系です

465 ：デフォルトの名無しさん：2005/11/25(金) 12:18:05

>>464
笑ってしもうたが、本当なら悲しいのぉ。

466 ：デフォルトの名無しさん：2005/11/25(金) 13:40:01

文系、理系なぞ受験科目の分類に過ぎない！

…筈なんだが、日本ではどうもそれが通らなくて困る。
経済学はかなり以前から数学バリバリでついには法学にも法経済学なんてのがあり、
一方でソフト開発が会社組織や経営をオブジェクト指向やユースケースなど
ソフトウェア工学的手法でモデル化したりする昨今、
文系・理系の区別は害あって利なしだと思うんだがね。

と脱線しながらマジレス。

467 ：デフォルトの名無しさん：2005/11/25(金) 13:48:01

困ったことに世の中には、既得権というものが存在する。

468 ：デフォルトの名無しさん：2005/11/25(金) 14:22:47

既得権でガンジガラメになって必要なところに資源が行かないのが
今回の不況の最大の原因だったわけだが。

469 ：デフォルトの名無しさん：2005/11/25(金) 14:42:04

本当は頭を使うのが大嫌いだけどそれなりの学歴は作っておきたい人、の当座の居場所

としての「文系」には、ちょっと違うニュアンスがあるしなぁ。

470 ：デフォルトの名無しさん：2005/11/25(金) 15:52:24

>>468
微妙に違う。既得権に目を奪われて、肝心な部分を
見落としている点が、今回の不況の最大の原因。

471 ：デフォルトの名無しさん：2005/11/25(金) 15:57:54

>>470
つまり、目先の利益を優先してるのが原因と。

472 ：デフォルトの名無しさん：2005/11/25(金) 15:58:24

ここまで脱線したらついでに聞くが、「肝心な部分」とは？

473 ：デフォルトの名無しさん：2005/11/25(金) 16:06:04

>>472
物事を順を追って、論理立てて考える事で導き出される結果。
欲得づくしで思考すれば理性を見失うのは当然かと。

これが金とか権利とかの問題ならまだ楽なんだが、努力とか、
知恵とか、勇気とか、危機管理能力とか、そ～ゆ～能力の無さ
が問題だからなぁ・・・

474 ：デフォルトの名無しさん：2005/11/25(金) 16:15:33

結局の所は、面白くない、面倒臭い、責任は取りたくない、
といった職務怠慢の積み重ねの結果だわな。

475 ：デフォルトの名無しさん：2005/11/25(金) 17:30:56

この流れおもしろいな

476 ：デフォルトの名無しさん：2005/11/25(金) 17:46:40

>>462
そりゃ分かるけど、あまり特殊な前提条件のもとでの研究ばかりじゃねぇ

結果として役にたたなくとも、いままで思いも付かなかったようなテーマとか
だったら９９％役にたたなくてもOKだと思う。

477 ：デフォルトの名無しさん：2005/11/25(金) 18:16:40

10000重ループの画期的な最適化方法を研究しました。
9999重以下のループには役に立ちませんが。

478 ：デフォルトの名無しさん：2005/11/25(金) 22:34:02

>>477
いいんじゃないか。

ダミーで、9999重ループをつけりゃ画期的に速くなる
んだろ？

479 ：デフォルトの名無しさん：2005/11/25(金) 22:38:08

ダミーじゃダミだ

480 ：デフォルトの名無しさん：2005/11/25(金) 22:43:27

>>479
貴様、俺様がこれからイカスギャグをかまそうとしたのに打ち砕いてくれたな～

481 ：デフォルトの名無しさん：2005/11/25(金) 23:40:14

推測してみた
ずばり駅に行きたい
・・・そこまで易しくないか

482 ：デフォルトの名無しさん：2005/11/26(土) 11:13:58

役に立ちそうもないから誰も手をつけなかった事を研究して実際に役に立たない
事を証明すれば、それはそれで立派な研究成果だと思うが・・・

483 ：デフォルトの名無しさん：2005/11/26(土) 11:50:18

>>482
それが、必要とされる証明だったらね。
実際には役に立つ証明はみたことない。

484 ：デフォルトの名無しさん：2005/11/26(土) 11:59:18

>>482
まあ、｢誰も手をつけなかった」んだったら、放置で
いいような気もするが…。
でも、できないことの証明によって無駄な労力の消費が
避けられるというのはあるよな。
大昔には、永久機関とか錬金術とかを真剣にやってた奴
もいるんだし。

485 ：デフォルトの名無しさん：2005/11/26(土) 12:20:31

科学技術の原型が錬金術だったような・・・

486 ：伝説新人タクシ：2005/11/26(土) 12:44:55

その頃は原子や素粒子なんてなかった。
今じゃ、原則的にある原子が他のそれに変わることはない
で済むんだけど。
反応によって全く違う性質を持つようになるのはある意味
錬金術といえなくもない。人工の工業用ダイヤだって使われている。
炭素が４つ結合することでダイヤになるようにね。
ただ、どの分野でも品質とかコストとかいう他の問題になる。
ニュートン　錬金術でぐぐると、wikipediaにも彼が錬金術師とある。

487 ：デフォルトの名無しさん：2005/11/26(土) 12:51:22

雑談なら他でやれ

488 ：デフォルトの名無しさん：2005/11/26(土) 13:02:55

つまりスクリプトの作成というのは、錬金術のようなものだと？

489 ：デフォルトの名無しさん：2005/11/26(土) 13:08:21

目の前にＳＩＣＰの原著あるけど、表紙の絵が魔術師だか錬金術師なんだよな。
スクリプト（コンピュータプログラム）の作成＝錬金術というのは、案外言い得て妙だな。

490 ：デフォルトの名無しさん：2005/11/26(土) 15:38:53

awk?

491 ：デフォルトの名無しさん：2005/11/26(土) 16:09:33

SICP=MITで使われている、コンピュータサイエンスの基礎の基礎をSchemeを通して学ぶ教科書

492 ：デフォルトの名無しさん：2005/11/26(土) 17:34:20

未知の自然物質を相手にした研究と、
人間が考えた文法についての、ある限られた特殊条件での研究。

以下（ry

493 ：デフォルトの名無しさん：2005/11/26(土) 17:51:25

研究もしない穀潰しが何を言っても、なぁに、かえって免疫力が付く

494 ：デフォルトの名無しさん：2005/11/26(土) 18:18:44

お前らも暇な奴らだなｗ

495 ：デフォルトの名無しさん：2005/11/27(日) 00:03:39

研究者の痩せ我慢すれですか？

496 ：このスレの1：2005/11/27(日) 00:13:04

現在>>249で立てたWikiのページが見られなくなってます。
報告が遅くなりましたが、こんなメールが来てましたので、一応報告します。

■■１．メンテナンスのお知らせ

サーバメンテナンスを以下の日程で行います。

日程：2005年11月26日(土)
時間：22:30～翌朝AM:5:00ごろまで
範囲：@wikiサービス全体
内容：サービスのバージョンアップ、電源の点検

この時間、@wikiサービス全体にアクセスできなくなる可能性があります。
ご理解宜しくお願い致します。

497 ：デフォルトの名無しさん：2005/11/27(日) 00:14:17

>>486-489
要するに、プログラムでプログラムを作ってるわけだからな。
・どんな言語を作れば扱いやすくなるのだろう？
・どんな風に言語を作れば今の状況に対応出来るだろう？
みたいな、論理的というよりは直観的な理屈が大事だから・・・

498 ：デフォルトの名無しさん：2005/11/27(日) 03:30:23

>497
直感というか、デザインと心理学かね？

499 ：デフォルトの名無しさん：2005/11/27(日) 09:43:53

>>498
センスが激しく要求される悪寒。
産業総合研究所でプログラミング言語を研究している某氏は、
「言語の設計はセンスのよい技術者だけがやればよい」
と言ってたからなぁ。

500 ：デフォルトの名無しさん：2005/11/27(日) 10:11:07

直感って言葉は、勘違いしてる人も珍しくないからなぁ・・・

駅から自宅への道筋を論理的に説明すると、
駅から北へ２５ｍ、北西に１５ｍ、東に５ｍ、北に９ｍ、北東に１５ｍ
といった説明になる。これに対して、駅から自宅への道筋を直感的に説明すると、
地図を広げて、駅から自宅への道筋に対して線を引いて、それを見せる事が説明になる。

501 ：直感的に説明って何だよ…。：2005/11/27(日) 10:50:51

>>500
まあ、直感って言う言葉を勘違いしてる人は珍しくない
けど、勘違いしたまま自慢げに書き込む奴 (=>>500) は
珍しいけどな。(w

-----------------------------
ちょっかん　ちよく― 0 【直感】

（名）スル
推理・考察などによらず、感覚的に物事を瞬時に感じとること。
「―で答える」「父の身に何か起こったことを―した」

502 ：デフォルトの名無しさん：2005/11/27(日) 11:06:37

とりあえず>>500がアホなことだけは分かった。

503 ：デフォルトの名無しさん：2005/11/27(日) 12:52:45

500はゆとり教育の被害者

504 ：デフォルトの名無しさん：2005/11/27(日) 16:45:42

>>500は悪くない。真に問題にすべきは>>500という怪物を生み出した社会構造ではないのだろうか？

505 ：デフォルトの名無しさん：2005/11/27(日) 16:50:50

つくづく面白いスレだな。今度は教育、社会問題かよ。
>>500　は、定量的、定性的を論理的、直感的と間違えてしまったわけだが、
プログラミング言語研究者でも、論文の日本語が怪しい奴時々いるよな。
そういう日本人が英語で無理やり論文書いてると、怪しささらに倍！って感じで。

506 ：デフォルトの名無しさん：2005/11/27(日) 17:49:35

Ｃでコンパイラのプログラム作ってみたんですが、どこが悪いのかわかりません。
四則演算の式をテキストファイルから読み込んで、字句解析→構文解析→コード生成って順序をたどるんですが、うまくいきません。
ソースをあげとくんで、どなたか見てもらえないでしょうか？
四則演算の式の例としては、
da+jk*h-3/(abc-def):=pq;
みたいな感じです。
ソース→http://read.kir.jp/file/read28666.zip

507 ：デフォルトの名無しさん：2005/11/27(日) 18:30:30

>506
おい！身勝手すぎるぞ！
なにがうまくいかないかもわからないし。

まずマジックナンバーをなくして、
関数名をちゃんとつけろ。
話はそれからだ。

508 ：デフォルトの名無しさん：2005/11/27(日) 18:37:52

>>506
関数名意味不明な上に、コメントは420行目の
/*スタックの初期化*/
だけですかｗ

とりあえずmainでfp2をオープンせずにfprintfしてるのだけはわかった。

509 ：デフォルトの名無しさん：2005/11/27(日) 18:46:25

毎回こんなプログラム書いてるの？
俺なら毎回どこが悪いのかわからなくなってうまくいきません

510 ：デフォルトの名無しさん：2005/11/27(日) 18:51:40

何だよ「goto owari」って。
「do～while(OP!='!')」とか「brake」じゃいかんのか。

もっと見たらもっとツッコミ所有りそうだけど、面倒だから見ない。

511 ：デフォルトの名無しさん：2005/11/27(日) 19:00:33

int lexical_analysis(void);
int H(void);
void E(void);
void E2(void);
void T(void);
void T2(void);
void F(void);
int code_generation(void);

はげわろす

512 ：デフォルトの名無しさん：2005/11/27(日) 19:01:52

iがグローバル変数ｗｗｗｗｗ

513 ：デフォルトの名無しさん：2005/11/27(日) 19:04:25

>>506
こいつ扇子がないなw
重箱角研究の弊害か？

514 ：デフォルトの名無しさん：2005/11/27(日) 19:07:08

>if(syntactic_result[0].result==(1||2)){

ここ必ず1と比較することになるけど、

if(syntactic_result[0].result==1 || syntactic_result[0].result==2)){

じゃないの？

515 ：デフォルトの名無しさん：2005/11/27(日) 19:11:23

っていうか、釣りだろこれ。
色んな部分がありえねぇ。

516 ：デフォルトの名無しさん：2005/11/27(日) 19:54:55

こんな独創的な書き方何をどうやったら学べるのかが分からん。
ちょっとどんな学習の仕方したか興味ある。

517 ：デフォルトの名無しさん：2005/11/27(日) 20:01:33

>>510の「brake」にも突っ込んでみたい。

518 ：デフォルトの名無しさん：2005/11/27(日) 20:14:29

C言語そのものと、作法（コメントをきちんと書く、関数名は意味が通じるものをつけるなど）を
身に着けるのが先じゃないか。＞作者さん。
俺の学生時代に、こういうプログラムソース書いていたら、即レポート再提出だったよ。

519 ：デフォルトの名無しさん：2005/11/27(日) 20:15:44

break;

520 ：デフォルトの名無しさん：2005/11/27(日) 20:29:45

コメントはさほど必要とは思わないがねぇ。

スクリプト言語のソース幾つも読んでるが、どれも少ないし。

521 ：デフォルトの名無しさん：2005/11/27(日) 20:33:13

関数名は良いんじゃない？
たぶん教科書通りになってるんでしょ。

522 ：デフォルトの名無しさん：2005/11/27(日) 20:35:03

まぁ言語のプログラムでTやFやEなんて、意味は決まってる品。

523 ：デフォルトの名無しさん：2005/11/27(日) 20:36:29

重箱のスミ研究の弊害に、もう１票

524 ：デフォルトの名無しさん：2005/11/27(日) 20:39:47

スレ違いな上に余計なお世話だと思うが、カーニハンとパイクの「プログラミング作法」が良書。
……釣られてる？　俺、釣られてる？

525 ：デフォルトの名無しさん：2005/11/27(日) 20:54:20

>「プログラミング作法」が良書。

はぁ？今時はぁ？

526 ：デフォルトの名無しさん：2005/11/27(日) 20:55:31

確かに古いが内容は現在でも充分有効だろ。

527 ：デフォルトの名無しさん：2005/11/27(日) 20:57:56

それ良書かなぁ？
いまでも通用すると思う？

528 ：デフォルトの名無しさん：2005/11/27(日) 21:02:04

>>521
そんな教科書捨てろよ

>>522
くわしく。
E=Evaluateはわからなくもないが、わかってやりたくない。
まさかT=Term、F=Factorですか？普通は関数名にしないだろｗ
Hは思いつかないな・・・

529 ：デフォルトの名無しさん：2005/11/27(日) 21:06:57

>>508と>>514くらいは分かるようになって欲しい。多分大学の宿題なんだろうけど。
後，無限ループはやめようよ。EOFまで読んだら止まるとかにした方がいんじゃね？

530 ：デフォルトの名無しさん：2005/11/27(日) 21:09:05

ｔ = temporaly
f = function

531 ：デフォルトの名無しさん：2005/11/27(日) 21:16:21

temporalyにはつっこんだほうがいいのかな？

532 ：デフォルトの名無しさん：2005/11/27(日) 21:17:41

T=term F=factor E=expression
だろうな。Ｈはワカンネ。

533 ：デフォルトの名無しさん：2005/11/27(日) 21:24:14

>>532
その理屈でいくとHにあたる部分はstatementのはずだよね。
ソースちょっと読んでみた感じでもセミコロンまでの部分を処理してるっぽいから文のはずだけどHって・・・？

534 ：デフォルトの名無しさん：2005/11/27(日) 21:32:50

>>527
たしかに内容自体は古臭いけど通用する
書かれている技術云々より著者の考えてることを文から読み取るだけでも勉強になるよ

535 ：デフォルトの名無しさん：2005/11/27(日) 21:33:58

H=Hyouka
俺はこれだと思うね。かなり自信あるよ。

536 ：デフォルトの名無しさん：2005/11/27(日) 21:37:08

H=アレだよアレ。

(*/∇＼*)ｷｬ恥ずかしい♪.

537 ：デフォルトの名無しさん：2005/11/27(日) 21:37:45

>>534
マジでいってんの？正気？

……釣られてる？　俺、釣られてる？

538 ：デフォルトの名無しさん：2005/11/27(日) 22:24:07

>>537
その文だけじゃ君が何を主張したいのかわからないんだが

539 ：デフォルトの名無しさん：2005/11/27(日) 22:38:12

>>537
著者の考えてる事云々辺りに対して言ってるのかなと予想。
後524!=534だから皮肉になってない。

540 ：デフォルトの名無しさん：2005/11/27(日) 22:42:20

業界で成功した人物の著書ぐらい素直に読んどけよ

541 ：デフォルトの名無しさん：2005/11/27(日) 23:02:40

そう言えば、うち新入社員にこんな宿題出してたなぁ（ｗ

542 ：デフォルトの名無しさん：2005/11/27(日) 23:03:13

いちいち反論しないと気がすまないガキかよ

543 ：デフォルトの名無しさん：2005/11/27(日) 23:06:05

すまん
反論というより、ただの反抗だな

544 ：デフォルトの名無しさん：2005/11/27(日) 23:12:54

いや～、すまん、すまん

545 ：デフォルトの名無しさん：2005/11/27(日) 23:39:50

>>506
一応超適当に動作するようにはした。
http://read.kir.jp/file/read28713.zip

546 ：デフォルトの名無しさん：2005/12/01(木) 08:41:18

Ｃ言語でbisonを使って構文解析をして構文木を作るとき、
コンパイルに成功するといいんですが
文法エラーがあったときに途中まで作ったノードが
メモリリークしてしまうんですが
どう解決してますか？

547 ：デフォルトの名無しさん：2005/12/01(木) 08:51:55

ノード生成時にbisonへ渡す物とルートからたどれる単方向リンクリストの両方に登録する。
成功した場合はソースの解析ツリーから全部たどれるからメモリが漏れないのだから、
失敗することの為に純然たる生成順のリストがあっても屁でもない。

548 ：546：2005/12/01(木) 10:41:06

thx!やっぱそうだよね

549 ：デフォルトの名無しさん：2005/12/01(木) 20:56:27

>>546
それって365日稼働する必要あんの？連続で

550 ：546：2005/12/01(木) 22:00:15

>>549
お前の意見なんか誰も聞いてねーよ
回線切って猿山に帰れ

551 ：デフォルトの名無しさん：2005/12/01(木) 22:26:32

何だこいつ？
そんなのリークとは言わんよw

552 ：デフォルトの名無しさん：2005/12/01(木) 22:57:07

>>551
えーと、もう話は解決してるようだけど
メモリプール使えだとか、これからつまんない話を披露する気なの？

553 ：デフォルトの名無しさん：2005/12/01(木) 23:26:06

>>550
粗れる原因つくってるいつもの香具師だ。
スルーよろ。

554 ：デフォルトの名無しさん：2005/12/01(木) 23:42:34

失敗したらすぐ終了してメモリの解放はOSまかせにすればいいって話だろ。
正味な話、ライフサイクルの短いプログラムでは
メモリの解放忘れがメモリリークにつながることは少ない。

555 ：デフォルトの名無しさん：2005/12/01(木) 23:49:00

メモリの解放忘れ＝メモリリーク
じゃないの？

556 ：デフォルトの名無しさん：2005/12/02(金) 00:10:41

>>554
はいはいうざいうざい

その手の話は聞き飽きた。

557 ：デフォルトの名無しさん：2005/12/02(金) 00:18:40

メモリリークって？
bison にバグがあったの？

558 ：デフォルトの名無しさん：2005/12/02(金) 00:23:23

なんでそんな文盲なんだよ

559 ：デフォルトの名無しさん：2005/12/02(金) 02:00:35

>>554
組み込みスクリプト用途を考えるとエラー停止しただけで
リークなんて考えられんけど。
おまえら作る時はリークチェッカ用意してテストぐらいしとけよ。

560 ：デフォルトの名無しさん：2005/12/02(金) 02:53:05

メモリリークごときで騒いでんじゃねぇよ肉体労働者

561 ：デフォルトの名無しさん：2005/12/02(金) 02:55:29

ふらぐめんて～しょん？

562 ：デフォルトの名無しさん：2005/12/02(金) 08:54:06

mallocしたあとfreeしなくてもry

563 ：デフォルトの名無しさん：2005/12/02(金) 09:19:38

重箱隅研究では大問題。
実際は、OSが（ry

564 ：デフォルトの名無しさん：2005/12/02(金) 09:28:06

実際は、コンパイラにもバグが（ry

まあ、これはたいがいは最適化オプション絡みだったりするから、
最適化オプションを外すだけで解決したりするけどな。
何処の製品とは言わんケド。

565 ：デフォルトの名無しさん：2005/12/02(金) 16:20:18

>>560
ばーかばーか
>>562
ばーかばーか

全員死んでこいや
お前らみたいなへたれがこのスレにいるってだけで吐き気がするぜ
あ？メモリリーク？そんなもんが怖くて中学生やってられっかってんだ
それよりもC言語教えてください

566 ：デフォルトの名無しさん：2005/12/02(金) 16:27:04

帰れ低能

567 ：デフォルトの名無しさん：2005/12/02(金) 21:34:48

こんなのリークいわんやろ？あほちゃうかw
現実を知らん馬鹿研究者ならでわなやw

568 ：デフォルトの名無しさん：2005/12/02(金) 22:04:19

> ならではなや

569 ：デフォルトの名無しさん：2005/12/03(土) 18:14:32

蛆研究乙w

570 ：デフォルトの名無しさん：2005/12/03(土) 18:15:55

ならではやな。やな！
ほな！失礼したどす～。

571 ：デフォルトの名無しさん：2005/12/03(土) 20:05:53

どちらかといえば、研究もタッチしてるのかもしれない洩れだけど、
そりゃ中田先生みたいに実務もバリバリこなせるような研究者にはあこがれるけど、
あれって、（先生の実力は本当にすごいと思うけど）案外運もあるんじゃないのかなぁ
とも思って自分を慰めてまつ。

トホホ、

572 ：デフォルトの名無しさん：2005/12/03(土) 23:33:12

>>571
立場や肩書きという物がどうしても必要な場面もあるし、いいたかないけど上が抜けてくれないとポストが空かない事実はどうしようもないのである意味運かもしれません。

573 ：デフォルトの名無しさん：2005/12/04(日) 12:34:37

コンパイラの作り方 (詳解
http://www.is.s.u-tokyo.ac.jp/~vu/97/jugyo/processor/compilerresume/

574 ：デフォルトの名無しさん：2005/12/04(日) 12:50:40

>>573
こゆ講義は楽しいだろうなぁ。俺もやりたい。

575 ：デフォルトの名無しさん：2005/12/04(日) 14:03:42

>>573
＞演習で実装する言語はSchemeのsubsetで

ここまで読んだ
というか、ここで読むのをやめた

576 ：デフォルトの名無しさん：2005/12/04(日) 15:11:36

>>573
その実習って、グループに分かれてFPGAを使用した独自アーキテクチャのCPU設計&実装、
そのアーキテクチャ用クロスコンパイラの製作、
その上で動くレイトレプログラムの実装、までやるんだよな。
さすが灯台だとおもた。

577 ：デフォルトの名無しさん：2005/12/04(日) 15:12:17

どっかでＯＳの作り方をやってくれんかな？……って、板違いか。ＯＳ板に逝ってくる。

578 ：デフォルトの名無しさん：2005/12/04(日) 15:50:48

>>573
早速印刷して、読んでみることにしたよ。うｐしてくれた人、ＧＪ！
三流痴呆国立大卒修士で、Ｓｃｈｅｍｅは少しかじってるので、何とか読めるかな。
学生時代、こういう面白い講義や実習はなかったもんなぁ。
灯台逝くほど頭良くなかったし。

579 ：デフォルトの名無しさん：2005/12/04(日) 16:45:49

http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html
多分SICP読んだ方が早いぞ。

580 ：デフォルトの名無しさん：2005/12/04(日) 17:04:33

SICPとは目指すものがかなり違うと思うが

581 ：５７８：2005/12/04(日) 17:07:16

ＳＩＣＰも購入して持ってるので、両方読みます。

582 ：デフォルトの名無しさん：2005/12/04(日) 18:56:03

やっぱり、東大の先生のような頭がいい人はschemeの良さがわかってるんだな。

583 ：デフォルトの名無しさん：2005/12/04(日) 20:00:11

schemeの良さというよりも、実装の容易性を重視しているのではないかね。

584 ：デフォルトの名無しさん：2005/12/04(日) 20:14:16

今はもうSchemeじゃなくて、MinCamlだよ。

585 ：デフォルトの名無しさん：2005/12/04(日) 20:38:48

やっぱり、東大の先生のような頭がいい人はlispの良さもわかってるんだな。

586 ：デフォルトの名無しさん：2005/12/04(日) 22:26:46

キチガイホイホイ言語

587 ：デフォルトの名無しさん：2005/12/04(日) 22:29:53

というか日本だと狭い世界だから研究してる人はこの人ととは知り合いだろう。
今も同じとこにいるのかは知らないけどさ。で，この分野の研究しててschemeは
避けて通れないよ。表示意味論的にクリーンな言語はやっぱ重宝する。MLとか
Haskellとかあるけど，やっぱ未だに基本はschemeって感じ。

588 ：デフォルトの名無しさん：2005/12/04(日) 22:55:27

研究してる人、って単数かよ。狭すぎるぞ。

未だに主流がSchemeかどうかは知らんが、
当分の間は避けて通れる道ではないのは同意。
ただ、最近ではMLやHaskellも避けては通れないぞ。

589 ：デフォルトの名無しさん：2005/12/04(日) 23:05:06

やっぱり、東大の先生のような頭のいい人は、rubyの（ry

590 ：デフォルトの名無しさん：2005/12/04(日) 23:09:59

釣りはいらん
とっとけ

591 ：デフォルトの名無しさん：2005/12/04(日) 23:32:16

Rubyが言語理論の研究に適切だと主張する馬鹿は、
さすがに見たことが無いな。

592 ：デフォルトの名無しさん：2005/12/04(日) 23:35:42

コンパイラとかの実装を話すときは、
Pascal, C/C++, Lisp/Scheme, Forth, ML, Haskell
あたりは抑えておくべき？

593 ：デフォルトの名無しさん：2005/12/04(日) 23:37:09

とりあえず、機械語は抑えておけ

594 ：デフォルトの名無しさん：2005/12/05(月) 00:58:12

「抑える」んだ

595 ：デフォルトの名無しさん：2005/12/05(月) 01:09:56

　　∧＿∧
　（*´∀｀）　了解だ！
　人　Y　/
　(　ヽし
　（＿）＿）

596 ：594：2005/12/05(月) 01:19:58

>>595
ﾜﾛﾀ

597 ：デフォルトの名無しさん：2005/12/05(月) 21:20:28

Lispってとにかく単純でとっつきやすいんだよな。
S式はパースが異常に簡単だし、末尾再起最適化とか考えなきゃ処理系も一瞬で実装できる。

598 ：デフォルトの名無しさん：2005/12/05(月) 21:25:05

>末尾再起最適化とか考えなきゃ
ちょｗｗｗおまｗｗｗ

599 ：デフォルトの名無しさん：2005/12/05(月) 22:08:58

>>591
お前は墓の研究でもしてろw
最先端言語の研究とは無縁だろ？

600 ：デフォルトの名無しさん：2005/12/06(火) 00:48:19

>599
Rubyが最先端言語とでも？？
RHG見れば解るけど、かなり泥臭い実装じゃない？

601 ：デフォルトの名無しさん：2005/12/06(火) 01:11:05

>>600
知ったか素人だまれ

602 ：591：2005/12/06(火) 01:43:38

>>599
うーん、開発現場の人ですよね。>>591で馬鹿って言ったのは、
「言語理論の研究者で、かつ、Rubyが研究に使えると思ってる人」です。
開発現場においては、Rubyは確かに最先端言語の1つですよね。

ただ、言語理論の研究では言語の性質の解析とか証明とかしなきゃならないんで、
実用的に便利な言語ってのはちょっと違うんですよ。
本質だけのシンプルな言語、誤解を恐れず言えば「低機能」な言語が重宝されるんです。
なので、Rubyは高機能すぎて、言語理論の研究にはちょっと向かないかな、と。

でも、今の世の中を支えているのは>>599さんのような現場の人ですから、
自信をもって生きてくださいね。応援してます。

603 ：デフォルトの名無しさん：2005/12/06(火) 05:58:09

高卒が搾取されてくれることでこの業界は成り立ってるしね。

604 ：デフォルトの名無しさん：2005/12/06(火) 19:38:30

>>603
そこに大卒組がドロップアウトしてくるようになってきた事で、状況は混乱気味でつ。

605 ：デフォルトの名無しさん：2005/12/06(火) 20:19:22

でも金かせいでるのは土方だしなw
研究成果が経済成果として繋がる例は極々わずか。
まぁ、それが研究というものの宿命でもあるわけだが、

606 ：デフォルトの名無しさん：2005/12/07(水) 01:50:47

土方の生んだ金は、どこに消えているのやら

607 ：デフォルトの名無しさん：2005/12/07(水) 02:41:43

>>606
土方の金の使い道の事？それとも金の出所の事？

608 ：デフォルトの名無しさん：2005/12/07(水) 02:43:41

>>606
中間搾取の事？

609 ：デフォルトの名無しさん：2005/12/07(水) 02:54:29

>>606
ちなみに普通は、半分から４／５は中間搾取で消えていく。
まあこれが、税金や社会保険による搾取だけならまだ納得できるが、
実際には、派遣会社が間に何社も入って掠め取っているだけだから、
ひどい話だとは思うけどな。

610 ：デフォルトの名無しさん：2005/12/07(水) 03:25:30

ふーん、派遣会社がそんなにねぇ。
なら、普通に雇う側の会社がホームページで
募集すればいいじゃん。

611 ：デフォルトの名無しさん：2005/12/07(水) 08:53:04

>>610
NEET or 学生さんですか？

社員として雇うのは、労働契約とか社会保険とか法令とか、そういうので面倒なんだよ。
さらに言うと、上のような理由も実は建前で、最大の理由は、用済みになったときに好きなようにクビ切れないってことだな。
なので、中間搾取のおかげで一見、能力/金額比が良くないように見えても、トータルで考えると安く上がっちゃうことも多い。
１人雇用するリスクをとらず、金で解決できるんだったら、そのほうがお得というこった。

612 ：デフォルトの名無しさん：2005/12/07(水) 10:42:19

>>604
不景気のせいで土建業由来の不正労働慣行があらゆる業種に蔓延し常態化していることに加えて
院卒が従来の大卒の業種・業態へドロップアウトしてくるようになったからな。

文科省が欧米諸外国並みに博士号持ちの数だけはそろえようと
博士課程や修士課程（博士課程前期）の定員を就職の受け口の見通しもないまま
闇雲に増やしたんで博士取れたヤツも取れなかったヤツも
従来の研究・教育職では吸収しきれずに普通に開発仕事につくようになり、
最近ではそれでも足りなくて派遣で仕事をするケースも増える傾向だ。
（そういうとき周囲に敬遠されないように院卒の経歴を隠して
「大学でちょっと遊んじゃって(^-^;」などと言うヤツもいる。）
大学の独立行政法人化と年俸制の任期（2-5年）の条件付募集が
標準になって30台以下の研究者が定期的に失職することがその傾向を加速している。

613 ：デフォルトの名無しさん：2005/12/07(水) 11:52:57

>>612
まぁ、ろくに成果の出せない研究者はいらないということだろうな。
土方サイドでは、経験がなにので用無しとなってるし。

研究者として生きて行くためには、（上にもあったが）抜きん出た実力と
独自の発想、それに、強運が必要だろうね。

614 ：デフォルトの名無しさん：2005/12/07(水) 11:58:24

>>613
運は*必要*とは言わないんだよ。

615 ：デフォルトの名無しさん：2005/12/07(水) 12:25:21

>>613
研究に夢を持ちすぎ。
天才の数は多くないので他業種同様に
圧倒的多数を占める凡人をうまく使う社会的な工夫が必要。
それなりに高度な教育しといて放り出すというのは人的資源の無駄遣いでしかない。

そもそも研究というのは大規模投資して本格開発するほどには
結果が明らかでない内容を論理と実験を手段として探りながら進む作業の総称だから
研究にも難易度、規模、価値について色々なものがある。
例えば>613が夢見るような先進的で独創的な研究があった場合、
その周辺には実用化や普及の前に片付けなければならないような
相対的に難易度の低い研究課題が沢山発生するのが常だが、
それを片付ける>613が言うような相対的に低能力の泡沫研究者の数も
本来はそれなりに必要なのだ。

ただ日本では>613のような古典的な夢を抱いて「研究」というものを見ている人間が
まだまだ多数派だがな。

616 ：デフォルトの名無しさん：2005/12/07(水) 12:27:26

研究も他業種同様多くの技能から成り立っている。
例えば、研究は独創的なことを思いつけば出来上がりではない。
計画を立て、先達の成果を調べ、論証し、実験し、評価し、論文を書いて発表しなければならない。
そしてその大部分は時間を消費する作業的な側面を持ち、
特殊な才能ではなく教育で身につく種類の技能に支えられている。

それを身に着けていることが研究者（大物でも泡沫でも）としての必要条件となるが、
それを研究者としての教育を受けていない人間が身に着けているわけではないし、
逆に身に着けてはいても世間で評価されるような大きな「成果」に恵まれないこともある。

例えば探索しなければならない範囲を狭めたという意味では失敗の報告も
有効なのだがどうしても世間ではどうしても成功のほうを高く評価するし、
特に日本では明治以降の歴史的経緯から独創性よりも完成度が評価される比重が高い。
それが欧米に対して日本では改良研究が多くなる理由でもある。
博士号を取ったり予算を獲得したりする際に多少独創性があるより
完成度が高い方が日本では圧倒的にウケがいいのだ。
（これは改良研究のほうが審査する側も評価しやすいせいもある。）

だから博士号を取った先輩は博士課程の後輩に
「あんまり理想を高く持って独創性のある高度なものにしようとせず、
恥を捨てて教授の温情にすがり、できるだけ簡単で瑣末な研究で博士号を取るようにしろ。
でないと3年では取れないぞ。」
などとまじめな顔で助言することになる。

617 ：デフォルトの名無しさん：2005/12/07(水) 14:20:54

>>613
＞まぁ、ろくに成果の出せない研究者はいらないということだろうな。
＞土方サイドでは、経験がなにので用無しとなってるし。

そうでもない。独学できっちりと勉強してるヤシは少なくないし、
汚いコードを書くヤシは少ないし、設計をみっちりとやってるヤシ
も少なくないから、耐久力のあるヤシは、わりと重宝されてる。

618 ：デフォルトの名無しさん：2005/12/07(水) 14:24:48

やっつけ仕事にほうり込むと、すぐに潰れるけどな。ｗ
混沌とした状況で生き延びる能力の無さを、何で補うかが課題だな。

619 ：デフォルトの名無しさん：2005/12/07(水) 14:43:01

中小零細ＩＴ企業は、やっつけ仕事の所が多いよな。あと、
大企業でもたま～に、やっつけ仕事の所があったりする。
何処とは言わないケド。

620 ：デフォルトの名無しさん：2005/12/07(水) 16:47:26

いいから黙って働け
シャッチョさんのために

621 ：デフォルトの名無しさん：2005/12/07(水) 17:55:27

なんだここは
コンパイラ・スクリプトエンジンのスレとは思えないな

622 ：デフォルトの名無しさん：2005/12/07(水) 19:46:55

>>619
たぶん脳内w
やっつけでコンパイラとか書くのなどあり得ない。

623 ：デフォルトの名無しさん：2005/12/07(水) 19:52:08

電脳土方ネタは別スレッドでやってくれ。明らかにスレ違いだろう。
64bitメモリ空間を馬鹿みたいに消費するアプリのための、Lisp
もどきを作りたいんだが。

624 ：デフォルトの名無しさん：2005/12/08(木) 01:25:32

>>623
おまえは板違いw

625 ：デフォルトの名無しさん：2005/12/09(金) 02:08:19

>>624
おまえは気違いw

626 ：デフォルトの名無しさん：2005/12/09(金) 03:18:00

>>625
おまえは勘違いw

627 ：デフォルトの名無しさん：2005/12/09(金) 09:17:35

>>626
おまえは腹違いｗ

628 ：デフォルトの名無しさん：2005/12/09(金) 10:46:09

>>627
おまえは立貝(タチガイ)ｗ

629 ：デフォルトの名無しさん：2005/12/09(金) 11:59:40

俺はフランクリンw

630 ：デフォルトの名無しさん：2005/12/09(金) 12:11:24

一行レスに嬉々として参加するようなバカが何でこのスレ覗いてるわけ？

631 ：デフォルトの名無しさん：2005/12/09(金) 12:38:37

それに対して、同じく一行レスで中身無し、しかも煽り、ってのはどうだろうなぁ。
自分が使ったバカの一語が、自分に最も当てはまっているのでは。

632 ：デフォルトの名無しさん：2005/12/09(金) 12:58:11

バ
カ

633 ：デフォルトの名無しさん：2005/12/09(金) 13:03:31

>>630
ネタが、ネタがなかったんだよ～～(T-T)

634 ：デフォルトの名無しさん：2005/12/09(金) 23:58:21

研究ネタも（ry

635 ：デフォルトの名無しさん：2005/12/10(土) 10:06:17

Dr.欲しくて、教授の機嫌を取らなきゃいかんことはよ～くわかるが、
「障子を開けてみよ。外は広いぞ」という言葉を貴殿に贈ろう。
蛸壺（失礼）から出て、興味の赴くままに外の世界を味わうことも大事。

636 ：デフォルトの名無しさん：2005/12/10(土) 10:59:52

貴殿！貴殿！貴～殿殿で殿殿！

637 ：デフォルトの名無しさん：2005/12/10(土) 14:54:50

>>636
ちょっとリズムに無理があるかな。

638 ：デフォルトの名無しさん：2005/12/10(土) 15:37:13

>>637
大丈夫。
休符を入れてから
きが始まる。
ん、貴殿！！！貴殿！貴～殿殿で殿殿

639 ：デフォルトの名無しさん：2005/12/10(土) 16:05:48

馬鹿じゃねーの

640 ：デフォルトの名無しさん：2005/12/10(土) 16:08:40

馬鹿じゃ、ねーの！
I'm not fool ! OK ?

641 ：デフォルトの名無しさん：2005/12/11(日) 00:02:50

ケンキューテーマと一緒で、大した話題がないなぁ～

642 ：デフォルトの名無しさん：2005/12/11(日) 12:51:50

処理系の研究してる人いるみたいだから聞きたいんだけど、今時はどんな研究が盛んなの？

643 ：デフォルトの名無しさん：2005/12/11(日) 13:11:24

>>642
> 処理系の研究してる人いるみたいだから聞きたいんだけど、今時はどんな研究が盛んなの？
俺、大学院の研究室がプログラミング言語関係の研究室だったから、この世界には多少つながり
がある。

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

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

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

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

644 ：デフォルトの名無しさん：2005/12/11(日) 14:34:24

テンプレの>>5をみればこの分野の流行はつかめると思う。

645 ：デフォルトの名無しさん：2005/12/11(日) 18:22:09

>>643
こんな香具師おおいの？
専攻分野と就職先がなさならないと言う意味で

646 ：デフォルトの名無しさん：2005/12/11(日) 18:29:18

むしろ直結してるほうが稀

647 ：デフォルトの名無しさん：2005/12/11(日) 18:36:25

>>645
大学院たって修士だろ。それじゃあ、専門家とは到底言い難いから、企業としては都合のよいソルジャー
扱いで、専攻も分野も関係なく配置するんじゃない。

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

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

648 ：デフォルトの名無しさん：2005/12/11(日) 18:40:34

つーか言語開発の仕事って例えば何？
SunとかMSとかBolandみたいに明らかに言語作ってる部隊以外に何がある？

649 ：デフォルトの名無しさん：2005/12/11(日) 18:55:21

>>648
> つーか言語開発の仕事って例えば何？

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

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

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

650 ：デフォルトの名無しさん：2005/12/11(日) 18:56:21

組み込み機器用にgccを移植するような地味な仕事から
簡単な業務処理用スクリプトを書いたりならしたことがあるが
コレといって”言語を作る”ってのはやったことないなぁ。

651 ：６４９：2005/12/11(日) 19:09:57

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

652 ：デフォルトの名無しさん：2005/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 ：デフォルトの名無しさん：2005/12/12(月) 08:11:40

>>649
マイコン価格の暴落と処理速度の改善で、その仕事の半分は無くなる予感。

654 ：デフォルトの名無しさん：2005/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 ：デフォルトの名無しさん：2005/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 ：デフォルトの名無しさん：2005/12/12(月) 11:29:28

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

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

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

657 ：デフォルトの名無しさん：2005/12/12(月) 11:29:54

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

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

658 ：デフォルトの名無しさん：2005/12/12(月) 11:35:09

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

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

659 ：デフォルトの名無しさん：2005/12/12(月) 11:40:42

このすれｽｻﾏｼﾞｽage

660 ：デフォルトの名無しさん：2005/12/12(月) 11:50:45

訳と解説乙。
次スレから、(個人的～の部分を省いて)テンプレにするといいと思う。
以下ツッコミ。間違ってたらごめん。

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

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

661 ：デフォルトの名無しさん：2005/12/12(月) 12:08:45

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

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

662 ：デフォルトの名無しさん：2005/12/12(月) 13:22:53

>>660 にだけ突っ込むけど、他意はないから許して
(>>654-657 を検証するような目で見るガッツがないもので…)

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

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

663 ：654-657、661：2005/12/12(月) 14:11:41

>>662
まぁ、mobile codeに関しては私もそっちが第一候補ではある。
でもembeddedと対になってたりするし、
曖昧な言葉ではあるので文脈がないとどっちにも取れる面はあるなと。

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

664 ：デフォルトの名無しさん：2005/12/12(月) 14:18:55

ACMのDigital Libraryでみつけた論文では
・high level representations
・directly interpretable representations
・directly executable representations
っていう分類してparse treeとか語ったりしてるのと、他にもwikipediaから
http://en.wikipedia.org/wiki/Dynamic_recompilation
の中で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：2005/12/12(月) 14:25:24

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

666 ：デフォルトの名無しさん：2005/12/12(月) 14:43:52

>>654
> (たとえばGCとか、もっと進んでヒープを使わないプログラミングの可能性とか。

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

667 ：デフォルトの名無しさん：2005/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：2005/12/12(月) 14:51:51

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

669 ：654：2005/12/12(月) 15:11:16

>>666(>>668続き）
PPL2003の招待講演だったNe（希ガス）
http://www.csg.is.titech.ac.jp/ppl2002/program.html

"Functional Programming without Garbage Collection"
Martin Hofmann (University of Muenchen)
[PSファイル]
http://www.csg.is.titech.ac.jp/ppl2002/proceedings/hofmann.ps

670 ：654：2005/12/12(月) 15:13:10

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

671 ：666：2005/12/12(月) 16:03:54

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

672 ：654：2005/12/12(月) 18:37:12

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

673 ：デフォルトの名無しさん：2005/12/12(月) 19:48:02

スレの質が急激に向上してまいりました

674 ：デフォルトの名無しさん：2005/12/12(月) 20:08:44

スレの質が急激に向上してきたようだね

675 ：デフォルトの名無しさん：2005/12/12(月) 20:27:22

スレの質が急激に向上しているようだな

676 ：デフォルトの名無しさん：2005/12/12(月) 20:41:15

上がってきたと見るや躊躇いなく下げようとしているなｗ

677 ：デフォルトの名無しさん：2005/12/12(月) 20:42:54

>>676
このダッチワイフ野郎。（くうきよめ）

678 ：デフォルトの名無しさん：2005/12/12(月) 21:51:48

PLDIは組み込みシステム向けの言語設計・実装の話題も範囲内だよ。
(過去にEmbedded Systemsってセッションが開かれるくらい)

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

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

679 ：デフォルトの名無しさん：2005/12/12(月) 22:40:59

そろそろPOPLの時期ですね。行く人はいますか？

680 ：デフォルトの名無しさん：2005/12/12(月) 23:48:13

>>678
PHPって埋め込みに入るのかな？
あれってタグの外側を標準出力に流してるだけでしょ。
「埋め込める」ってのは見た目の上だけで、Zendのただの宣伝文句に過ぎないと思うんだが。
専門の人とかはどう分類するんだろ？

681 ：デフォルトの名無しさん：2005/12/13(火) 00:23:09

>>679
落ちたので行けません。鬱

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

682 ：680：2005/12/13(火) 00:31:34

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

683 ：デフォルトの名無しさん：2005/12/13(火) 00:45:43

>>654ではないが、「他言語やデータへの埋め込みコード」って言ってるぞ。
HTMLのscriptとかがいわゆる「他言語への埋め込みコード」で
PHPがいわゆる「データへの埋め込みコード」というつもりだったんじゃないか。
(>>654がそこまではっきり意識して話したのかはわからないけどな)

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

684 ：デフォルトの名無しさん：2005/12/13(火) 00:52:08

>>683
正直、「データへの埋め込み」ってのがイマイチ意味がわかんないんだよなぁ。
できれば解説ｷﾎﾞﾝﾇ。
（あ、ちなみにPHPは<?php～?>の外側も含めた全体がPHPのソースなので、そもそも埋め込みではない思う）

685 ：デフォルトの名無しさん：2005/12/13(火) 01:14:20

>あ、ちなみにPHPは<?php～?>の外側も含めた全体がPHPのソースなので、そもそも埋め込みではない思う

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

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

686 ：681：2005/12/13(火) 01:20:12

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

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

687 ：デフォルトの名無しさん：2005/12/13(火) 01:41:20

ＬＩＳＰはなんなんですか

688 ：デフォルトの名無しさん：2005/12/13(火) 01:43:01

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

689 ：デフォルトの名無しさん：2005/12/13(火) 01:46:03

どうか>>687をスルーしてくれ

690 ：デフォルトの名無しさん：2005/12/13(火) 01:55:57

embedded ruby

691 ：デフォルトの名無しさん：2005/12/13(火) 03:42:12

たいていのプログラミング言語に対して正規表現が使えるけど、
あれは一種の埋め込み言語であると思う。

692 ：デフォルトの名無しさん：2005/12/13(火) 03:57:10

>>691
なるほど。確かに。
大抵は正規表現用に、言語自体の字句解析とかとは別口のモジュールで解析してるもんな。

693 ：デフォルトの名無しさん：2005/12/13(火) 04:06:40

たいていのプログラミング言語に対して整数が使えるけど、
あれは一種の埋め込み言語であると思う。

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

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

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

694 ：デフォルトの名無しさん：2005/12/13(火) 04:42:12

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

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

695 ：デフォルトの名無しさん：2005/12/13(火) 04:42:20

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

696 ：デフォルトの名無しさん：2005/12/13(火) 04:51:01

正直、仕様がつぎはぎになるまで使われる言語なんて全体の 0.1% にも満たないと思うんだが。

697 ：デフォルトの名無しさん：2005/12/13(火) 04:52:38

D言語は最初からつぎはぎでしたが何か？

698 ：デフォルトの名無しさん：2005/12/13(火) 04:53:02

まあいいじゃん。楽しく俺言語つくろうぜ。

699 ：デフォルトの名無しさん：2005/12/13(火) 04:54:28

>>697
つぎはぎってそういう意味なのか？

700 ：デフォルトの名無しさん：2005/12/13(火) 04:55:57

おまいら、>>695みたいな100%の釣りですらスルーできないのかよ…
>>680のような巧妙な釣り(後であからさまになったけど)ならともかく…

701 ：デフォルトの名無しさん：2005/12/13(火) 04:57:30

釣って釣られて盛り上がるのが醍醐味ですが何か？

702 ：デフォルトの名無しさん：2005/12/13(火) 04:57:59

>>700
自分たちでも理解できるレベルになったのが、
嬉しくてしょうがないんだろう。ほっといてやれ……

703 ：デフォルトの名無しさん：2005/12/13(火) 05:03:01

それじゃそろそろprogram representationsとインテンショナル・プログラミングの話をしようか

704 ：デフォルトの名無しさん：2005/12/13(火) 07:29:09

>>696
Ｃ言語の事でつか？

705 ：デフォルトの名無しさん：2005/12/13(火) 10:24:35

>>694
embeddedのIT業界でのデフォはそれで正解
ただ、ここは言語すれなので

706 ：654：2005/12/13(火) 11:07:54

期待されても大して何もでないぞ。

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

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

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

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

707 ：654：2005/12/13(火) 11:37:54

例をあげて考えてみる。

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

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

708 ：デフォルトの名無しさん：2005/12/13(火) 12:16:37

>>706-707
禿しく納得した。あんたにゃ脱帽。

709 ：デフォルトの名無しさん：2005/12/13(火) 13:23:05

>>654って例の、外国人とRubyに悩まされてる人か？
もしそうならかなり煮詰まってるな。

710 ：デフォルトの名無しさん：2005/12/13(火) 14:06:54

>>709
な、なぜそう思うのかな？

711 ：デフォルトの名無しさん：2005/12/13(火) 15:08:51

>>709の元ネタがよくわからん罠

712 ：デフォルトの名無しさん：2005/12/13(火) 15:12:04

ttp://pc8.2ch.net/test/read.cgi/prog/1127261540/924
と思われ。

713 ：デフォルトの名無しさん：2005/12/13(火) 15:12:40

いずれにせよ、Rubyに好意を持っていない所から類推すると、
研究畑の人間だと思われる。

714 ：デフォルトの名無しさん：2005/12/13(火) 15:14:23

>654は別にRubyについては何も書いてないよな。

715 ：デフォルトの名無しさん：2005/12/13(火) 16:12:53

>>713
研究の人はルビー嫌いなの？

716 ：デフォルトの名無しさん：2005/12/13(火) 16:22:54

>>715
いんや、少なくとも>>712のリンク先のそのまたリンク先のヨーロッパ人研究者には大好評のようだゾ。

717 ：デフォルトの名無しさん：2005/12/13(火) 16:32:43

日本の研究の人は、自分よりも名前が売れていることでRubyを妬んでいるのです

718 ：デフォルトの名無しさん：2005/12/13(火) 16:44:49

妬むかどうかはさておきRubyの人が（昔はリーマンしながら作ってたようだけども）
いまやオレ言語で食えているのがウラマヤシクないと言えば嘘になろう。

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

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

719 ：デフォルトの名無しさん：2005/12/13(火) 16:47:28

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

720 ：デフォルトの名無しさん：2005/12/13(火) 16:50:22

>>712の引用のしかたにﾜﾛﾀ
マ板経由かよｗ

721 ：デフォルトの名無しさん：2005/12/13(火) 16:51:47

別段Rubyに含むところはないが
Unitテストもなしに6万行もあるバギーな拡張ライブラリはキライｗ
特にキャストやテンプレートを濫用して型がスパゲティ化しているプログラムはｗ

722 ：デフォルトの名無しさん：2005/12/13(火) 17:16:30

Rubyとかそういう問題じゃないな。
他の言語でもそれは嫌だぞ。

723 ：デフォルトの名無しさん：2005/12/13(火) 17:28:21

>>722
まぁ、そういうことですよｗ
Rubyが使われてるプログラムの移植でヒドい目に合ってるからRubyの話題も出るけど
それは多分に使い方の問題であってRubyの問題じゃない。

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

以上誤解のないように。

724 ：デフォルトの名無しさん：2005/12/13(火) 17:30:15

謹んで訂正>>723

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

725 ：デフォルトの名無しさん：2005/12/13(火) 17:43:02

やっぱRubyじゃ巨大プロジェクトの開発は無理か。
せいぜい数千行程度？

726 ：デフォルトの名無しさん：2005/12/13(火) 18:25:20

さぁ？

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

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

727 ：デフォルトの名無しさん：2005/12/13(火) 18:27:04

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

728 ：デフォルトの名無しさん：2005/12/13(火) 18:30:33

精子コピペすか？

729 ：デフォルトの名無しさん：2005/12/13(火) 18:34:25

わかってはいるが、わかるわけにはいかん！
というやつだね。
墓穴は掘り終わりましたか？

730 ：デフォルトの名無しさん：2005/12/13(火) 18:41:06

>>727
遅くなるって言うけど
手軽さではなく早さが求められるようなプロジェクトで
Script言語を選んじゃう見識は問われないの？

731 ：デフォルトの名無しさん：2005/12/13(火) 18:51:28

言語というより、開発手法や設計のお話だな。

732 ：デフォルトの名無しさん：2005/12/13(火) 18:52:31

この件でRubyの拡張ライブラリがヤバイ事はよくわかった。

733 ：デフォルトの名無しさん：2005/12/13(火) 18:59:05

そういやRubyはVMにできないみたいな話が以前のスレにあった気がするけどあれってなぜ？

734 ：デフォルトの名無しさん：2005/12/13(火) 19:08:15

そろそろスレ違いに気づけ。
Rubyヤバイとかは専用スレがあるんだからそこで騒げ。

735 ：デフォルトの名無しさん：2005/12/13(火) 19:11:25

>>725
デカいプロジェクトだと開発以前に、運用で却下。
保守できる人間が少ないのは怖いし。
もっともここで話す問題ではないが。

736 ：デフォルトの名無しさん：2005/12/13(火) 19:29:06

そう思うなら余所逝けよ。

737 ：デフォルトの名無しさん：2005/12/13(火) 22:21:58

ちょっと勘違いしてるようだけど、数千行のRubyコードって
数十万行のLispコードに匹敵する処理内容が記述できるでしょ。
なので、スクリプト言語≒簡易処理というのは全くの思い違いだと思うよ。

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

738 ：デフォルトの名無しさん：2005/12/13(火) 22:24:27

オ～レ～～～。オ～レ～～～。ジャカジャカジャン！
ま・つ・け・ん・さあ～んば～～～

739 ：デフォルトの名無しさん：2005/12/13(火) 22:48:17

数十万行のC言語のコード、というならともかく・・・

740 ：デフォルトの名無しさん：2005/12/13(火) 23:16:02

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

741 ：デフォルトの名無しさん：2005/12/13(火) 23:27:55

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

742 ：デフォルトの名無しさん：2005/12/13(火) 23:55:27

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

Ruby
http://shootout.alioth.debian.org/benchmark.php?test=all&lang=ruby&lang2=ruby

Lisp
http://shootout.alioth.debian.org/benchmark.php?test=all&lang=cmucl&lang2=cmucl
http://shootout.alioth.debian.org/benchmark.php?test=all&lang=sbcl&lang2=sbcl

743 ：デフォルトの名無しさん：2005/12/14(水) 00:14:14

>>742
Rubyが速度で上回るのはstartupだけか。
ひでえなこりゃ。
Rubyってコンパイラ作れないの？

744 ：デフォルトの名無しさん：2005/12/14(水) 00:31:28

ハッキリ言ってしまえば、速度なぞ時間がすぐに解決するんだけどなw
リアル社会を知らない音質Lisperはアクキンにしる！

745 ：デフォルトの名無しさん：2005/12/14(水) 00:33:18

>>743
コンパイラは作ってもあまり意味がないというか、
そもそも作る人がいないという話だった気がする。

746 ：デフォルトの名無しさん：2005/12/14(水) 00:33:43

>>743
作れるはずだし、
作ってる人も（複数人）いるっぽい。
実用になったという話は聞いてないけど。

747 ：デフォルトの名無しさん：2005/12/14(水) 00:41:45

>>744
Ｒｕｂｙはそう言われてきたＪａｖａと事情がだいぶ違うし
言語仕様的に無理かも。
あと１０年待とうね。

748 ：デフォルトの名無しさん：2005/12/14(水) 00:44:51

プロセッサがマルチコア方向にシフトしてきてるっぽいので、
ネイティブスレッドに対応しないと辛いかもね。

749 ：デフォルトの名無しさん：2005/12/14(水) 00:49:15

>>742
おいおい、そこのコードは速度を上げるために
かなりチューニングしてるぞ。
少なくかけるところをあえて速度が上がるような
書き方してる。

750 ：デフォルトの名無しさん：2005/12/14(水) 00:49:52

だから、コード量は、本当はlispはめちゃくちゃ少ないよ。

751 ：デフォルトの名無しさん：2005/12/14(水) 00:50:18

PythonはPython自身で書かれたり他の言語やVMに変換して速くしたりできるっぽい
そういう意味ではPythonの方は将来期待できるかも

752 ：デフォルトの名無しさん：2005/12/14(水) 00:53:09

これなんて象徴的だよな。
本当は5行で終わるところを12行かけて書いてる。
コメントにその5行のコードが書いてあるｗ

http://shootout.alioth.debian.org/benchmark.php?test=ackermann&lang=cmucl&id=0

753 ：デフォルトの名無しさん：2005/12/14(水) 00:56:25

Pythonって構文をちょっと変えたLispそのものだからな

754 ：デフォルトの名無しさん：2005/12/14(水) 01:03:49

出来るだけタイプ量少なくすることで競うならperlが最強。

755 ：デフォルトの名無しさん：2005/12/14(水) 01:04:33

>>752
そのコメント部だけのコードでも動的言語の割には結構速度出るね。
やっぱこの差はネイティブコンパイルしてるからかね。

756 ：デフォルトの名無しさん：2005/12/14(水) 01:04:59

>>754
C++は最下位。

757 ：デフォルトの名無しさん：2005/12/14(水) 01:08:10

>>756
COBOLだろ

758 ：デフォルトの名無しさん：2005/12/14(水) 01:12:24

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

759 ：デフォルトの名無しさん：2005/12/14(水) 02:01:41

いや待て、言語同士を競争させるのにコアやライブラリを弄っちゃいかんだろ。

760 ：デフォルトの名無しさん：2005/12/14(水) 02:13:34

Smalltalkならいじるのが当たり前なんだが

761 ：デフォルトの名無しさん：2005/12/14(水) 02:31:30

ライブラリ弄っていいんだったらどの言語でも1～数行で終わって
比較する意味ないじゃん。

762 ：デフォルトの名無しさん：2005/12/14(水) 03:17:26

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

763 ：デフォルトの名無しさん：2005/12/14(水) 03:19:35

いやいや駄目でしょ。
Lispは結構知ってるし、Smalltalkもある程度は知ってるけどさ。
標準ライブラリで、標準のコアで勝負でしょ。

764 ：デフォルトの名無しさん：2005/12/14(水) 03:22:05

まあ拡張を定義した部分まで行数に入れるんだったら
もちろんいい。

765 ：デフォルトの名無しさん：2005/12/14(水) 03:23:18

他の言語じゃ不可能な時点で勝負にもなんないね。

766 ：デフォルトの名無しさん：2005/12/14(水) 03:23:25

あと、その言語として自然な記述で比べること。
7行プログラミングスレみたいな奇怪なコードならCでも短くなるけど、
そういうコードで比べるのも反則。

767 ：デフォルトの名無しさん：2005/12/14(水) 03:23:52

>>765
別に不可能じゃないよ。ライブラリなんてどの言語でも書ける。

768 ：デフォルトの名無しさん：2005/12/14(水) 03:27:34

>>766
ああいう奇怪なコードで書くのがPerlの自然な流儀ですが何か？

769 ：デフォルトの名無しさん：2005/12/14(水) 03:27:56

こんな夜中に何を必死になってんだ

770 ：デフォルトの名無しさん：2005/12/14(水) 03:46:42

>>767
知ってていってるならしょうがないが
開発環境と実行環境が一体化してるもんだから
単なるライブラリとは違う。

771 ：デフォルトの名無しさん：2005/12/14(水) 03:59:21

いくらそんなこと言ったって、同じにしなくちゃ駄目だろう。
やっぱりライブラリを作ってこれ使えば一行とか言ってるのと同じぐらい
反則に俺には感じる。

772 ：デフォルトの名無しさん：2005/12/14(水) 04:00:09

いい加減宗教戦争は勘弁して下さいよ、本当に。

773 ：デフォルトの名無しさん：2005/12/14(水) 04:56:09

スレの質が急激に低下してまいりました

774 ：デフォルトの名無しさん：2005/12/14(水) 05:33:44

>>1 に出てくる語句について教えてください。

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

775 ：デフォルトの名無しさん：2005/12/14(水) 05:54:04

>>773
おまえが上質なネタを投下しろよ

776 ：デフォルトの名無しさん：2005/12/14(水) 06:08:41

>>775
おまえが上質なネタを投下しろよ

777 ：デフォルトの名無しさん：2005/12/14(水) 06:51:03

>>774
>>1に聞けよ

778 ：デフォルトの名無しさん：2005/12/14(水) 08:16:38

HTML化されてる最初のスレはかなりレベル高かったみたいだね。
今の>>1-5のテンプレはいつごろからあったんだろ？

779 ：デフォルトの名無しさん：2005/12/14(水) 14:52:11

>>774
厳密にはともかく概ねそれで合ってんじゃない？

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

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

780 ：デフォルトの名無しさん：2005/12/14(水) 14:55:35

プログラムの長さ、記述量が問題になっていたようだが…

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

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

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

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

781 ：デフォルトの名無しさん：2005/12/14(水) 15:01:42

>>778
4からじゃね？

782 ：デフォルトの名無しさん：2005/12/14(水) 15:07:53

>>779-780
なげーよ
日記なら他所でやれ

783 ：デフォルトの名無しさん：2005/12/14(水) 15:20:39

言語の設計には必ず設計目的があり、
設計目的はその時点での背景がある。
そういうことを考えずに闇雲に優劣をつけようとするのは無意味なことだ。

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

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

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

784 ：デフォルトの名無しさん：2005/12/14(水) 15:21:25

また、言語は設計当時の技術水準を前提にして設計されているし、
当時重要であった課題を優先して解決するように設計されている。

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

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

785 ：訂正：2005/12/14(水) 15:24:35

解く意図する→得意とする

786 ：デフォルトの名無しさん：2005/12/14(水) 15:25:54

ここは公開オナニー劇場ですか

787 ：デフォルトの名無しさん：2005/12/14(水) 15:26:55

宗教戦争なんてしてたっけ。

788 ：デフォルトの名無しさん：2005/12/14(水) 15:27:18

>>782
日記など書く趣味はないよ。
言語戦争の発端のグチを>>654-の記事の一部にポロっと書いた責任を取って
正攻法で技術論に戻して収拾しようとしてるだけ。

789 ：デフォルトの名無しさん：2005/12/14(水) 15:33:02

ｳｻﾞｽ
２、３行で要約しろよ

790 ：デフォルトの名無しさん：2005/12/14(水) 15:36:33

冗長でも誤りを見つけやすくするため云々は一理あるけど、
冗長に書かないといけないせいで入るバグもあるから
トレードオフであることは意識しないとね。

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

791 ：デフォルトの名無しさん：2005/12/14(水) 15:41:37

>>787
顛末は例によってRubyが貶されて信者が暴れただけ。

792 ：デフォルトの名無しさん：2005/12/14(水) 16:10:36

>>783-784
知識の垂れ流し、結構なことです。
が、ここはお前の落書き帳じゃねーんですよ。
各言語の歴史的経緯についてなんかは言語仕様書の冒頭にでも
書いてありそうなことだし、こんな所で長々と解説されても信憑性も
疑わしいわでだんだん話が薄っぺらくなっていくだけですよ。
こちらとしては、そんなものより要点だけ数行でまとめて書いてくれると
読みやすいわ疲れないわでとてもありがたいわけですよ。

793 ：デフォルトの名無しさん：2005/12/14(水) 16:12:53

ｳｻﾞｽ
２、３行で要約しろよ

794 ：デフォルトの名無しさん：2005/12/14(水) 16:14:04

>>793
一行で要約できますた。
「ここはお前の落書き帳じゃねーんですよ。」

795 ：デフォルトの名無しさん：2005/12/14(水) 16:25:20

つまり過剰な冗長さは悪し、という例ですな。

796 ：デフォルトの名無しさん：2005/12/14(水) 16:29:39

長くなると（読解力が不足がち人には）ウザイってのはそうだろうけど
（なら読み飛ばせば？とも思うのではあるけども
読み飛ばしてもくれずわざわざウザイと書いてしまう
不思議な心理があるようですね。）
信憑性が薄くなるってのはよくわからないな。信憑性は内容の問題でしょ?
読解しきれないと内容が理解できないからそういう読み手にとっては
信憑性が薄く「感じられる」というなら納得。

ちなみに要約、要約と言ってるけど
要約というのも情報処理だから当然情報量が減るわけですが、
そこはわかってますか？
要約された梗概ばっか読んでたら
そりゃ目は楽だろうけども身のある話はできませんぜ？
要約なんてのは言わば骨格標本みたいなもので肉はないんだから。

それにこの程度のことで知識の垂れ流しと言われるのも心外。
議論のためのほんのとっかかりのつもりだし、
ちょっと年寄りの言語屋なら別に知るともなしに知ってるような話であって
自慢するほどの知識じゃない。

…と>>792を見た瞬間に思ったけども、>>794にある要約が>>792の真意なら
あまり意味はない単なる煽りなわけで無視したほうがいいのかな？

797 ：デフォルトの名無しさん：2005/12/14(水) 16:32:08

>>795みたいな茶々いれの冗長性はどんなもんすかね？

798 ：デフォルトの名無しさん：2005/12/14(水) 16:37:55

>>796
一行で要約できますた。
「無視したほうがいいのかな？」

799 ：デフォルトの名無しさん：2005/12/14(水) 16:42:58

梗概が読めなかった。「こうがい」って読むのか。

800 ：デフォルトの名無しさん：2005/12/14(水) 16:53:40

>>796
>自慢するほどの知識じゃない。
そう。
あなたの知識の垂れ流しは、言わばほとんど無駄な情報＝ノイズなわけですよ。
あなたの言う骨と肉で例えると、見るに耐えないブヨブヨです。
すなわち骨が入ってるのかどうかさえ確認するのは困難です。
それをいちいち探りながら読んでいると時間も掛かり頭痛も絶えないわけでして、
長文をお書きならもうちょっと読ます文章を心掛けて書いて頂けませんか？
ということですが、お分かりになられませんかね。

801 ：デフォルトの名無しさん：2005/12/14(水) 17:00:51

よし、１０行縛りにしようぜ

802 ：デフォルトの名無しさん：2005/12/14(水) 17:08:25

>>797
丸ごと読み飛ばされる冗長性に比べると、一行コメントぐらいの冗長性ですな。

803 ：デフォルトの名無しさん：2005/12/14(水) 17:15:34

3人の旅人がおりました。
ホテルを見つけて、そのホテルのオーナーに宿泊料金をたずねると、オーナーは「3人部屋で30ドルです」と答えました。
そこで、旅人はひとり10ドルずつ払って、そのホテルに泊まることにしました。
しばらくして、オーナーは3人の旅人の泊まっている部屋の料金は、本当は25ドルだったということに気付きました。
そこで、ボーイを呼んで「あの3人の旅人に、この5ドルを返してきておくれ」と頼みました。
ボーイは、3人に5ドルを返しても割り切れないと思い、自分のポケットに2ドルしまい込み、残りの3ドルを、３人の旅人に1ドルずつ返しました。
3人の旅人は、ボーイから1ドルずつ返してもらったので、9ドルずつ払ったことになり、9ドル×3人で27ドルです。ボーイのポケットの中の2ドルを足すと、29ドル。
さて、残りの1ドルはどこへいったのでしょうか？

804 ：デフォルトの名無しさん：2005/12/14(水) 17:33:35

＞9ドルずつ払ったことになり、9ドル×3人で27ドルです。
問題が間違ってますよ。30-5+3で3人で28ドルですが。
端数切捨てですか？

805 ：デフォルトの名無しさん：2005/12/14(水) 17:37:43

いや3人が払ったのは27ドルでしょ。27-2=25ドルがオーナーの受け取った金で。
と、おいらも釣られてみましたよ。

806 ：デフォルトの名無しさん：2005/12/14(水) 17:38:31

>>784
いや、一番最初のLISPの目標は計算モデルを記述すること(チューリングマシンの代替)だろ。
それはまた、自分自身の処理系を簡潔に記述できる構造であることを意味する。
だからメタな機構はLISPの根本だと思うよ。メタサーキュラーな処理系があれば
それを種にして何でも出来るんだから。マクロやMOPは使い勝手の上で
追加されたおまけみたいなもん。

807 ：デフォルトの名無しさん：2005/12/14(水) 17:40:19

>>781
このスレ6から読み始めたので、2～5のdatどれかしら持ってたらうｐしてもらえませんか？

808 ：デフォルトの名無しさん：2005/12/14(水) 17:43:32

論争　Rubyで大規模プロジェクト　採用企業４割拡張ライブラリ使わず
http://www.toyama.hokkoku.co.jp/_today/T20051210002.htm

あるチーフプログラマーは「日本人なら、Ruby。大規模プロジェクトでも拡張ライブラリは必要ない」と言い切り、
今後も拡張ライブラリとの併用はしない考えだ。

809 ：デフォルトの名無しさん：2005/12/14(水) 17:46:47

掲示板は書き手同士のコラボレーションで成り立ってるから、
そういうTPOとか特性を考えた上て書けってことだろ
そろそろこのスレの趣旨の話に戻せよ

810 ：デフォルトの名無しさん：2005/12/14(水) 17:53:38

>>808
この業界では技術に保守的なだけでもクズだというのに、
ついにナショナリストまで登場しているのか（笑）

811 ：デフォルトの名無しさん：2005/12/14(水) 17:59:31

>>808
ネタのつもりなんだろうけど、そういうまるっきりウソ流し続けてると
コミュニティ過激派から訴えられるかも知れんぞ

812 ：デフォルトの名無しさん：2005/12/14(水) 18:01:50

おれは2が欲しい

813 ：デフォルトの名無しさん：2005/12/14(水) 18:14:18

おれはお前が欲しい

814 ：デフォルトの名無しさん：2005/12/14(水) 19:13:58

>>803
真相をお話します。
オーナーはご想像の通り、物忘れが酷い人物ですが慈悲深く、
ボーイもまた欲深いという欠点を持つ人物ですが、それでも
ボーイはオーナーの人格を信頼して付き従っておりました。
さて、実はこのホテルのシステムは後払い方式なのですが、
オーナーの物言いにボーイは素直に頷き、オーナーから
預かった５ドルを欲深さからそのまま着服しました。
翌日オーナーは例外なくそのことを忘れており、
チェックアウトした旅人へ謝罪し２５ドルを受け取りました。
結局その時ホテルで５ドルの損失が発生したのですが、
オーナーはそれに気づかず運営を続け、やがて倒産してしまいました。
しかしその後ボーイは着服で貯めた金で大成し、
路頭に迷った元オーナーを雇ってあげたという話です。
経営者としてはボーイの方が格上だった、が正解です。

815 ：デフォルトの名無しさん：2005/12/14(水) 19:42:02

ﾋｿ(´д)(д｀)ﾋｿ

816 ：デフォルトの名無しさん：2005/12/14(水) 22:26:28

3人の言語オタがおりました。
このスレを見つけて、そこの住人に最高と思う言語をたずねると、
「RubyとLisp以外です」と答えました。

817 ：デフォルトの名無しさん：2005/12/14(水) 22:28:14

eagerな言語は使う気がしない

818 ：デフォルトの名無しさん：2005/12/14(水) 22:42:51

クロージャまわりのメモリ管理ってどうやってます？
・基本はスタック上で、捕捉されたらヒープにコピー
・コンパイル時にスタックに置くかヒープに置くか決めて、コピーしなくて良いように
・めんどいので全部ヒープに取ってGCまかせ
・その他

と、ネタ投下してみる。

819 ：デフォルトの名無しさん：2005/12/14(水) 23:13:26

>>807
http://makimo.to/cgi-bin/search/search.cgi?q=%83R%83%93%83p%83C%83%89%81%40%83X%83N%83%8A%83v%83g&andor=AND&sf=0&H=&view=table&D=tech&shw=2000

820 ：デフォルトの名無しさん：2005/12/14(水) 23:57:16

>>818
全部ヒープでやってる。速度は今のところ考えてない。
いずれはスタック使いたいんだけどね。
とりあえず論文読み中。

http://www.cs.indiana.edu/~dyb/pubs/3imp.pdf

821 ：デフォルトの名無しさん：2005/12/15(木) 01:12:12

>>818
>・基本はスタック上で、捕捉されたらヒープにコピー
捕捉されたらとは？生成のこと？
>・コンパイル時にスタックに置くかヒープに置くか決めて、コピーしなくて良いように
クロージャの生成構文を別々に設けるということ？
これらの意味は？

おれの見解ではクロージャを使うだけであればスタック、
クロージャを生成する際、親フレーム以下があれば
ヒープに落としてフレーム参照を繋ぎかえる、
この時既にヒープに落ちていれば何もしない、
という戦略がスマートというか、一般的じゃないかと。
使用回数＞生成回数という場合ね。
CPSやジェネレータみたいな使い方しかしない場合は
コピーが連続して不利になるけど、こんなことは
やろうと思わなければめったにない。

822 ：807：2005/12/15(木) 01:28:06

>>819
どもありがと。さいこー

823 ：デフォルトの名無しさん：2005/12/15(木) 02:53:00

>>818ではないですが面白そうな話題ですね。

>クロージャの生成構文を別々に設けるということ？
エスケープ解析とか？

>おれの見解では(略
すまん、理解不能。
といってもクロージャ変換で実装したことしかない俺の知識が足りないだけ。
興味あるので「一般的」の参照をくれるとうれしい。

824 ：デフォルトの名無しさん：2005/12/15(木) 04:31:04

>>803
○○○○○.○○○○○/○○○○○.○○○○○/○○○○○.○○○○○　最初に支払ったお金３０ドル
↓
●●●◎◎.○○○○○/○○○○○.○○○○○/○○○○○.○○○○○　３ドル返す　２ドルくすねる
└┼┘└┤└───────────┬─────────────┘
　 │　　　│　　　　　　　　　　　　　　　　 └ 主人の手元に２５ドル
　 │　　　└ ボーイの手元に２ドル　　　　　　　　　　　　　
　 │
　 └ お客の手元に３ドル

支払ったお金は２７ドル
　　９×３＝２７　９ドルずつを３人で払った
　　３０－３＝２７　３０ドル払って３ドル返してもらった
　　２５＋２＝２７　　主人に２５ドル、ボーイに２ドル払った

ボーイがくすねたお金２ドルは、客が支払ったお金（２５＋２）の一部
だから支払った２７ドルにさらに２ドルを足すことが間違い（２５＋２＋２・・・×）

最初の金額３０ドルを求めるには、実際に支払ったお金２７ドルに戻ったお金３ドルを足さなければならない

825 ：デフォルトの名無しさん：2005/12/15(木) 04:51:17

エスケープ解析というのを知らなかったのでぐぐってみたのですが、
関数等のスコープの中で定義した変数やクロージャの
利用がスコープの中だけで完結し、外には持ち出されないことを
調べるということでしょうか。

826 ：デフォルトの名無しさん：2005/12/15(木) 13:44:56

そうです。

827 ：デフォルトの名無しさん：2005/12/15(木) 17:01:53

>>783-784
おもしろい。長くてもいいからやってくれ。
くだらん短い書き込みより、長くてもおもしろいほうがいいや。
長いのがいやなら読まなきゃいいだけ。

>JavaはCが存在していて必要ならば使うことができることが前提だから
>比較的汎用指向の言語でありながら
>Cで書くことが適切であるようなハードウェアレベルの記述機能を
>潔くスッパリ切り捨てた設計ができている。

ここらへんはたぶん違ってて、Javaに低レベルの記述がないのは単にJavaがバイトコードインタプリタを採用したからであって、Cがあるから云々は関係ないと思う。
ポインタをなくしたのもGCを導入しやすくするためで、やっぱりCとは関係ない。

828 ：デフォルトの名無しさん：2005/12/15(木) 18:15:07

>>827
そのへんは、鶏が先か卵が先かみたいなもんじゃね？

>>780
>人の認知科学的な処理特性を無視することはできない。
認知科学的には、冗長だとミスが増える法則もあるので
トレードオフだよね。

>ユーザが把握しやすい動作モデルを提供する
同じ物でも「把握しやすさ」はユーザによって
ばらつきが大きいんだよね。
ここを意識しないと宗教戦争になる。

829 ：デフォルトの名無しさん：2005/12/15(木) 21:03:36

>>827
ポインタはあるよ。
論文ばかり読んでる○○研究者か？

830 ：デフォルトの名無しさん：2005/12/15(木) 21:05:42

>818
継続も使いたいから
>めんどいので全部ヒープに取ってGCまかせ
かね……

831 ：デフォルトの名無しさん：2005/12/15(木) 21:35:49

>>823
>興味あるので「一般的」の参照をくれるとうれしい。

図にすると下みたいなイメージだけど、その辺は「クロージャ」が
出てくる速い処理系のソースかドキュメントでも読んでよ。
今の所これ以外に速い実装は思いつかないが。

※ |****| はフレームの変数とかの中身
※ (矢印)はフレームポインタ

スタック　|******親1******|(←)|******親2******|(←)|　★クロージャ生成直前
ヒープ　　　　　ヒープはまだ空の状態

↓　ヒープに落としてフレーム参照を繋ぎかえる

スタック　|　　　　　親1　　　　|(↓)|　　　　　親2　　　　|(↓)|　★クロージャ生成完了
ヒープ　　|******親1******|(←)|******親2******|(←)|

エスケープ解析までするなら特定の親のみしかヒープのコピーは発生しない。
例えば親1のフレームしか参照しないのであれば親2のフレームは
そのままスタックに残しても良い。

スタック　|　　　　　親1　　　　|(↓)|*******親2*****|(←)|　★クロージャ生成完了
ヒープ　　|******親1******|(←)|　←─── 生成されたクロージャは直接親1を参照

832 ：デフォルトの名無しさん：2005/12/15(木) 22:12:03

>>829
参照のことをポインタだって言い張ってる人はいますね。

833 ：デフォルトの名無しさん：2005/12/15(木) 22:43:17

Javaでポインタがあるっていう人間は低脳。バイトコードの仕様書読み直してから来い

834 ：818：2005/12/16(金) 01:44:55

>>821
>>・基本はスタック上で、捕捉されたらヒープにコピー
>捕捉されたらとは？生成のこと？
「生成されたクロージャが、
　子孫のスタックフレームでないフレームに捕まえられたら。」かな。
例えばforeach的な関数にクロージャを渡してそのまま捨てるような状況なら
コピーは要らないわけです。
これをやると破壊的な処理がやたらと高くついたり、
いざコピーとなったときにやたらと高くついたり、
その他色々と面倒なことになったりしそうですが。

>>・コンパイル時にスタックに置くかヒープに置くか決めて、コピーしなくて良いように
>クロージャの生成構文を別々に設けるということ？
コンパイル時に絶対にコピーが要らないとわかったときのみ、
フレームはスタック上に置いて、
それ以外は最初から親フレームはヒープに置いておこうと。
「関数aはクロージャを引数に取るが、それはどこにも保存されない」
ということになればa以外を呼ばない関数のフレームはスタック上に置いて良いでしょう。
が、やっぱり色々あって面倒なことになったりしそうです。

どっちもクロージャより親フレームが長生きなら問題ないよねという方針。

835 ：デフォルトの名無しさん：2005/12/16(金) 18:53:57

Javaでポインタが無いと信じているアフォども、
せいぜい、振り込め詐欺やワンクリ詐欺に用心しておくこったなw
言われてることを、そのまま単純に信じているようでは、
おまえらいい鴨だよ。

836 ：デフォルトの名無しさん：2005/12/16(金) 19:38:44

個人的な主観かもしれないけど、
ポインタ演算が無いものは参照と呼ばないか？

837 ：デフォルトの名無しさん：2005/12/16(金) 20:21:09

例えば、Cのポインタをタンイポと呼ぶように2006年から改正したら、
2006年からポインタが無いことになるぞ。
ポインタだのタンイポだのと言われてることが全て。

838 ：デフォルトの名無しさん：2005/12/16(金) 20:41:20

ポインタをタンイポと呼ぶためには法改正が必要なわけだが、2006年からというのは早急すぎるな。
まずは有識者を集めた小委員会の設置を図った上で、再来年以降の国会提出でも十分だと思う。

839 ：デフォルトの名無しさん：2005/12/16(金) 20:44:35

配列のイテレーターと参照と参照ポインタとメモリアドレスのポインタとを
一括してポインタと呼ぶべきでない。

840 ：デフォルトの名無しさん：2005/12/16(金) 21:04:11

>>835
Javaでポインタが有ると信じているアフォども、
せいぜい、振り込め詐欺やワンクリ詐欺に用心しておくこったなw
言われてることを、そのまま単純に信じているようでは、
おまえらいい鴨だよ。

841 ：デフォルトの名無しさん：2005/12/16(金) 21:05:31

え、ポインタと参照の違いは常識だと思ってたのですが。
またトンデモ本の誕生ですか。

842 ：デフォルトの名無しさん：2005/12/16(金) 21:06:01

>>840
ほんたまですか？

843 ：デフォルトの名無しさん：2005/12/16(金) 21:06:22

塗るタンイポえくせぷしょん

844 ：デフォルトの名無しさん：2005/12/16(金) 21:06:32

懐かしい名前を出さないでください。せっかく忘れていたのに。

845 ：デフォルトの名無しさん：2005/12/16(金) 21:07:45

Pascalのポインタは演算できないけどポインタと呼ぶな
だから正解は>>837

846 ：デフォルトの名無しさん：2005/12/16(金) 21:10:09

でも一般的に見たら、参照とポインタの一般像みたいなもんはあるだろ。
Pascalは例外じゃないか？

847 ：デフォルトの名無しさん：2005/12/16(金) 21:12:33

PascalはInc, Decができるじゃん。

848 ：デフォルトの名無しさん：2005/12/16(金) 21:12:34

たしかにポインタの演算はできないけど数値にキャストできるから同じ事では。

849 ：デフォルトの名無しさん：2005/12/16(金) 21:21:12

みんなそんなにボロカスに言うなよ。
Mさんが可哀想じゃないかｗ

850 ：デフォルトの名無しさん：2005/12/16(金) 21:22:33

まあ少なくともJavaの参照はポインタではないことは確かだ。
名前が参照だから。

851 ：デフォルトの名無しさん：2005/12/16(金) 22:35:58

そんなの実際どうとかじゃなくて、
設計者がどう定義したかと、その思想によるだろう。
だから>>850が正しい。

852 ：デフォルトの名無しさん：2005/12/16(金) 22:41:17

名前はともかくとしても、実際の内容を素直に受け止めれば
いいと思うけど。なので >>835 が正解。

853 ：デフォルトの名無しさん：2005/12/16(金) 22:42:47

>>835とか>>852は、ポインタと読んでCのポインタを連想した上で書いてるわけっしょ？
だったらやはりCの言葉の定義に(ry

854 ：デフォルトの名無しさん：2005/12/16(金) 22:44:40

実際の所、Rubyにはポインタは存在するがLispには存在しない。

855 ：デフォルトの名無しさん：2005/12/16(金) 22:46:11

>>853 ポインタという言葉の定義or使用はＣが最初ですか？

856 ：デフォルトの名無しさん：2005/12/16(金) 22:48:01

RubyもLispもPascalも、同じ太陽を感じ、同じ月を見て. 同じ空気を吸っているのだから
ポインタの有無くらいで区別するのはよくないと思います。

857 ：デフォルトの名無しさん：2005/12/16(金) 22:50:26

しかし、ポインタの有無は実用性を大きく左右するんだよ。

858 ：デフォルトの名無しさん：2005/12/16(金) 22:51:20

うむ。

859 ：デフォルトの名無しさん：2005/12/16(金) 22:52:51

結局は宗教論争。
和平への道はアセンブラ原理主義しかない。

860 ：デフォルトの名無しさん：2005/12/16(金) 22:53:34

>>855
ALGOL60にPOINTERという型は既に存在したらしいぞ
ttp://www.99-bottles-of-beer.net/language-algol-60-24.html

861 ：デフォルトの名無しさん：2005/12/16(金) 22:55:01

Java ポインタの検索結果約 197,000 件中 1 - 10 件目 (0.03 秒)
http://www.google.co.jp/search?hl=ja&q=Java+%E3%83%9D%E3%82%A4%E3%83%B3%E3%82%BF&lr=
Java 参照の検索結果約 2,830,000 件中 1 - 10 件目 (0.24 秒)
http://www.google.co.jp/search?hl=ja&q=Java+%E5%8F%82%E7%85%A7&lr=

この様にJavaポインタ派は、Java参照派と比較するとごく少数です。
どうやら集団で勘違いされているみたいです。

>>856
Rubyにはポインタはありません。
ポインタに相当する機能は持ってますが、
それはポインタではありません。

862 ：デフォルトの名無しさん：2005/12/16(金) 22:58:05

実にくだらない話題に収束したな。

863 ：デフォルトの名無しさん：2005/12/16(金) 23:29:43

ポインタ演算とか、インクリメントとかデクリメントとか、数値へのキャストとかそういうのを
わざと制限したものは普通、ポインタじゃなくて参照って言わない？

864 ：デフォルトの名無しさん：2005/12/16(金) 23:33:18

>>857
同意。ポインタのある言語は領域破壊のバグが頻繁に紛れ込むが、
Javaのようにポインタのない言語はそうしたバグは非常に少なくなる。

865 ：デフォルトの名無しさん：2005/12/16(金) 23:33:48

いわないね。
Delphiだと明確に区別されてるし。

866 ：デフォルトの名無しさん：2005/12/16(金) 23:34:56

>>865
Delphiは言うじゃん。参照って。

867 ：デフォルトの名無しさん：2005/12/16(金) 23:37:26

つまり、865は「ポインタとは言わない」と言いたいちゃうんかと。

868 ：デフォルトの名無しさん：2005/12/16(金) 23:40:25

あぁ、863へのレスのつもりなのね。

869 ：デフォルトの名無しさん：2005/12/16(金) 23:52:19

>>857
つまりLispは実用的でない証明ってこと言いたいわけ？w

870 ：デフォルトの名無しさん：2005/12/17(土) 00:05:20

lispにポインタはありません。ポインタの無い言語は実用性で勝ります。864を参照。

871 ：デフォルトの名無しさん：2005/12/17(土) 00:10:12

Cにはポインタがあります。ポインタのある言語は自由度と汎用性で勝ります。864参照。

872 ：デフォルトの名無しさん：2005/12/17(土) 00:10:39

Lispにポインタはあるが、そういえば、Lispのポインタって完全にJava、Rubyなどで言う参照だよな。
結局その言語でそれをなんと呼ぶかってことだな。

873 ：デフォルトの名無しさん：2005/12/17(土) 00:11:26

>>871
確かにバグを出す自由度で勝りますねｗ

874 ：デフォルトの名無しさん：2005/12/17(土) 00:19:31

ようやくLispが出てきたか

やっぱこのスレの主役はLispだよな！

875 ：デフォルトの名無しさん：2005/12/17(土) 00:20:01

Lispこそがすべての源流であるということは認めざるを得ない。

876 ：デフォルトの名無しさん：2005/12/17(土) 00:23:32

そもそも「Javaでポインタ」って話は、C++使いにJavaの参照を教えるときに「C++の参照と違ってポインタみたいなもんですよ」って説明するだけの話じゃなかったっけ？
それ以外の時に普通Javaの参照はポインタとは言わない罠。
まあ「何かを指し示す」って意味に限定すればJavaの参照とCのポインタは一緒だから「存在しない」とまでは言う気ないけど。
ポインタ演算ができるかどうかなんてポインタの本質じゃないでしょ。

877 ：デフォルトの名無しさん：2005/12/17(土) 00:25:38

>>876
一般に参照とポインタの区別を云々する場合、ポインタ演算の有無こそが本質のうちの1つです。

878 ：デフォルトの名無しさん：2005/12/17(土) 00:26:56

>>877
そうなの？ポインタキボンヌ。

879 ：デフォルトの名無しさん：2005/12/17(土) 00:27:45

ポインタ演算があるのと無いのとではバグの量と種類に大きな違いが出るのだよ。

880 ：デフォルトの名無しさん：2005/12/17(土) 00:29:26

Cのポインタは、演算によって「値をずらす」ことができるだろ。

int a;
int *p = a;

p += 1; //←これ

参照はそれができない。

881 ：デフォルトの名無しさん：2005/12/17(土) 00:30:15

それはポインタ演算の有無の話であってポインタの有無の話ではないですね

882 ：デフォルトの名無しさん：2005/12/17(土) 00:31:08

間違った。

int a;
int *p = &a; //アドレスを代入

p += 1; //←これ

*p = 1; // 任意のアドレスのデータを破壊

参照はこれができない。

883 ：デフォルトの名無しさん：2005/12/17(土) 00:32:00

ポインタの有無の話ですよ。今や、それが出来ないものをポインタではなく参照とよぶことが多いんですから。

884 ：デフォルトの名無しさん：2005/12/17(土) 00:32:51

ポインタは任意のハードウェア例外を引き起こす。

*(int *)(0) = 0; // 不正なアドレスへの書込み

参照ではこれはできない。

885 ：デフォルトの名無しさん：2005/12/17(土) 00:33:23

これぐらいか？

●同じ点
Javaの参照もCのポインタも、どちらも間接参照を表すためのものである。

●異なる点
Javaの参照はヒープ上にあるオブジェクトしか指す事ができない。
Cのポインタはどこにあるオブジェクトも参照できる。

Javaで参照されているオブジェクトは決して消滅しない。
Cで指されているオブジェクトはいつの間にか消滅している可能性がある。
(そして、消滅したオブジェクトへの参照をたどった場合の動作は未定義である)

Javaの参照にはCのポインタ演算のような機能はない。
Cのポインタ演算は、配列の要素を指すポインタのみに使う事ができる。
それ以外の場合の動作は未定義である。

Javaの参照の動作はかなり厳密に定義されている。
Cのポインタに対する操作には「未定義である」という部分が多い。
それを利用して環境依存の色々な技が使えたりする。

886 ：デフォルトの名無しさん：2005/12/17(土) 00:34:20

Cのポインタが安全性を保証してないだけの話じゃん

887 ：デフォルトの名無しさん：2005/12/17(土) 00:35:50

クロージャの話しようぜ

888 ：デフォルトの名無しさん：2005/12/17(土) 00:37:11

>>887
まずクロージャを定義してださい。

889 ：デフォルトの名無しさん：2005/12/17(土) 00:38:20

ポインタは本来、「何かを指し示すもの」という意味でした。
この言葉は、アドレスやそれを格納した変数などにたいして用いられてきました。

しかし、時代が移り変わるにつれ、ポインタ演算によって、頻繁に深刻なバグが
発生することがわかってきました。ポインタ演算の有無が非常に重要だという
ことがわかってきたのです。

かくして、本来は本質でなかったポインタ演算の有無が、時代とともに重要視
され、ポインタの本来の意味が変わってきたわけです。

890 ：デフォルトの名無しさん：2005/12/17(土) 00:38:34

ださいとかいうなや

891 ：デフォルトの名無しさん：2005/12/17(土) 00:42:25

ポインタ演算を適用できる変数やアドレスの数値と、参照との区別を明確にするため、
前者のことを特にポインタと呼ぶようになったのです。
特に言語として、Cがダントツで有名になったこともこの背景にあります。

892 ：デフォルトの名無しさん：2005/12/17(土) 01:05:55

・ポインタ演算を元に考えればJavaやその他の言語にポインタはない。
・そうでなければいわゆる参照（C++の参照を除く）はポインタみたいなもん。
ってことでFA？

893 ：デフォルトの名無しさん：2005/12/17(土) 01:12:47

代入なんかをインスタンス化してしまう言語にはポインタがない、参照切れもない。

894 ：デフォルトの名無しさん：2005/12/17(土) 01:16:58

>>892
あと、
・その言語がポインタと呼んでいないものは、その言語ではポインタではない。

895 ：デフォルトの名無しさん：2005/12/17(土) 01:18:08

>>893
ポインタ演算ができないからでしょ。

>>894
そんなこと言ったらJavaScriptにはクロージャはないってことになるじゃん。

896 ：デフォルトの名無しさん：2005/12/17(土) 01:21:50

いろんな言語のポインタ、いろんな言語やハードのアドレスは、それぞれ別のものを
別々に定義可能。
それらの用語の使い方は仕様によって異なる。
時々これらを混同して、「アドレスはポインタか？」とかの議論で、おかしな議論を
展開しちゃってる人がいるけど。

897 ：デフォルトの名無しさん：2005/12/17(土) 01:23:05

>>895
クロージャを他の機能で代替してるだけなら、
厳密な意味ではクロージャはないんじゃないの？

898 ：デフォルトの名無しさん：2005/12/17(土) 01:25:39

ECMAScriptの仕様書のP144にクロージャ出てきますが何か？

899 ：デフォルトの名無しさん：2005/12/17(土) 01:25:40

厳密な意味ならね。

900 ：デフォルトの名無しさん：2005/12/17(土) 01:26:56

>>896
禿同。
このスレは変な議論で盛り上がるよなｗ

901 ：デフォルトの名無しさん：2005/12/17(土) 01:26:57

その言語がそれをクロージャと呼んでいないなら、クロージャじゃない。

902 ：デフォルトの名無しさん：2005/12/17(土) 01:29:06

>>898訂正
×P144
○P132

903 ：デフォルトの名無しさん：2005/12/17(土) 01:32:05

ああ、Cのポインタは実装によってマシンのアドレスと違うことがあるから、
アドレスはポインタではないとかいっちゃってる人いますね。
Cのアドレスとマシンのアドレスを混同しちゃってる例ですかね。

904 ：デフォルトの名無しさん：2005/12/17(土) 01:46:37

要はどっちでもいいだろって話でしょ。
Javaの言語仕様に関する議論で「ポインタは～」とか言ってたら指摘すべきだが、>>876みたいな文脈で「ポインタみたいなもん」って言ってるだけでつっこむとしたら揚げ足取り以外の何物でもない。

905 ：デフォルトの名無しさん：2005/12/17(土) 01:51:38

ポインタをマシン語のアドレスと思ってあつかうと
マルチコア、マルチタスク、マルチキャッシュなＣＰＵでは
競合が発生して、かなりわけわからんことになる昨今。

906 ：デフォルトの名無しさん：2005/12/17(土) 01:53:11

>>888
では混乱を無くすために
クロージャ＝Schemeのクロージャ（あるいはラムダ式、無名関数）
と定義するよん。他の言語も右に倣えだから意味論はほとんど同じ。

例えばクロージャのある言語ではnewのような特別な構文を
定義することなくオブジェクトの生成を記述できる。

(define new-point
　(lambda (x y) ;---メンバ変数に相当、隠蔽される
　　(lambda (message . args) ;---this、selfに相当
　　　(case message
　　　　((getx) x) ;--- getter
　　　　((gety) y)
　　　　((setx) (set! x (car args)) x) ;--- setter
　　　　((sety) (set! y (car args)) y)
　　　　(else (error "unknown method " message))))))

実際にやっていることはクロージャを生成するクロージャを
定義しただけ。それでも以下の様にオブジェクトとして扱える。

(define point (new-point 1 2))
;メンバ変数はどうやってもアクセサ経由でしか参照できない
(point 'getx)　;=>1
(point 'gety)　;=>2
(point 'setx 3)
(point 'getx)　;=>3

907 ：デフォルトの名無しさん：2005/12/17(土) 01:58:41

燃料投下

Javaでは、NullPointerExceptionっていう言語定義された例外が存在するんですがｗｗｗｗｗ

908 ：デフォルトの名無しさん：2005/12/17(土) 01:59:53

NullPointerExceptionを考えた馬鹿を吊るし上げればいいだけだお^^

909 ：デフォルトの名無しさん：2005/12/17(土) 02:01:45

>>906
なるほど
JavaScriptやlua、perlもそれと同じだね。

910 ：デフォルトの名無しさん：2005/12/17(土) 02:04:49

>>907
Javaにポインタがあるとか言ってる奴の主張はそれじゃなくて
参照のことだろ。

911 ：デフォルトの名無しさん：2005/12/17(土) 02:08:44

ttp://nantan.xrea.jp/tag/Java
「ポインタ(pointer)」と「参照(reference)」とは、同じようで微妙に異なる。
簡単にいうと、「参照」はデータを間接的に参照することで、「ポインタ」は
その実現方法。つまり「参照」は仕様であり、「ポインタ」は実装である。
よく「Javaにはポインタがない」「いや、Javaの参照変数はポインタ
そのものだから、Javaにもポインタがある」という論争があるけど、
前者は「Javaの言語仕様にはポインタがない」ことを後者は「Javaの
実装にはポインタが使われている」ことをそれぞれ言っている。
つまり話の焦点がずれているため、両者の議論はかみ合うはずがない。
ただまあ、「NullPointerException」という名前はよくなかったな

912 ：デフォルトの名無しさん：2005/12/17(土) 02:11:13

もし NullPointerException を改名するとしたら何にするのがよい？

913 ：デフォルトの名無しさん：2005/12/17(土) 02:12:26

NullpoException

914 ：デフォルトの名無しさん：2005/12/17(土) 02:14:25

CantDereferenceException

915 ：デフォルトの名無しさん：2005/12/17(土) 02:31:26

燃料の質が悪かったか。精進します。

916 ：デフォルトの名無しさん：2005/12/17(土) 02:36:52

NullReferenceException

http://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/cpref/html/frlrfsystemnullreferenceexceptionclasstopic.asp

917 ：デフォルトの名無しさん：2005/12/17(土) 03:54:34

で、そのポインタ論争がこのスレと何の関係があるんですか
マ板のぬるぽスレでも行って騒いでなさい

918 ：デフォルトの名無しさん：2005/12/17(土) 03:56:44

ポインタについては、このスレで議論することですか？

919 ：デフォルトの名無しさん：2005/12/17(土) 05:44:46

このスレで議論することは何ですか？

920 ：デフォルトの名無しさん：2005/12/17(土) 05:49:30

質(略)

921 ：デフォルトの名無しさん：2005/12/17(土) 05:50:09

次スレの準備かな。

922 ：デフォルトの名無しさん：2005/12/17(土) 05:51:33

まだ早いよ

923 ：デフォルトの名無しさん：2005/12/17(土) 05:53:08

元々クロージャの話だったからそれをギロンすればいい

924 ：デフォルトの名無しさん：2005/12/17(土) 06:00:54

じゃ、まずはおまいからギロンを始めてくれ。

925 ：デフォルトの名無しさん：2005/12/17(土) 10:10:43

ぎろーん

926 ：デフォルトの名無しさん：2005/12/17(土) 10:47:16

ポインタなどという用語を不用意に使うような糞言語は捨てですね
何も反省していないということがわかる

やっぱりLISPですね

927 ：デフォルトの名無しさん：2005/12/17(土) 11:01:35

昔の言語だったらしょうがないけど、今時ポインタという用語使う言語の方が珍しい。

928 ：デフォルトの名無しさん：2005/12/17(土) 12:15:13

>>911
>「ポインタ」は実装である。
これの一次情報ってどこなんだろう？
少なくともCの仕様書ではそうなってない。
言語はC言語で実装することが多いので、
参照を表すのにポインタが直接使えるだの使えないだのという話はするけど。

929 ：デフォルトの名無しさん：2005/12/17(土) 13:02:20

ポインタはCでは仕様、Javaでは実装ってことじゃね？

930 ：デフォルトの名無しさん：2005/12/17(土) 18:08:17

>>926
Emacs Lispのリファレンスマニュアルだと、全編を通じて
「ポインタ」という用語を使っているわけだが w

http://www.fan.gr.jp/~ring/doc/elisp-manual/elisp_81.html#SEC82

931 ：930：2005/12/17(土) 18:14:58

ごめん、URLはこっちとかの方が適切だね。
http://www.fan.gr.jp/~ring/doc/elisp-manual/elisp_84.html#SEC85

932 ：デフォルトの名無しさん：2005/12/17(土) 19:30:44

まあｃより古い言語なんだし、その辺は仕方ないんじゃない？
lispのポインタは今でいう参照だな。

933 ：デフォルトの名無しさん：2005/12/17(土) 21:10:48

だから、lispはポインタ無いって何度いえば（ry

934 ：デフォルトの名無しさん：2005/12/17(土) 21:23:52

もういいよ、その話題は。

935 ：デフォルトの名無しさん：2005/12/18(日) 00:32:13

だから、rubyはポインタ（ry

936 ：デフォルトの名無しさん：2005/12/18(日) 00:52:22

さて、そろそろ次スレの準備かな。
立てたい奴、テンプレのリンク切れてるのチェックしてきてくれよ。

937 ：デフォルトの名無しさん：2005/12/18(日) 07:04:06

4年前の発掘
http://pc.2ch.net/tech/kako/1004/10048/1004873294.html

938 ：デフォルトの名無しさん：2005/12/18(日) 23:03:22

コンパイラ作る人は、「デバッガ」を、どのくらい「親切モード」に
搭載しているんだろう。手取り足取りでは作る手間かかりすぎるし、素っ気
なさ過ぎると、それはそれで文句言う奴も出てくるはず。

939 ：デフォルトの名無しさん：2005/12/19(月) 18:04:56

コンパイラヤサンは、でばっがやさんとは捌

940 ：デフォルトの名無しさん：2005/12/19(月) 22:11:29

938が誰に何を聞きたいんだかさっぱりわからんのだが。
(VC++とかgccとかの)広く使われている処理系について、どのくらい親切な
デバッガが搭載されてるか、なんてことなら、938の使ってる処理系についてなら、
938自身がよく知ってることだろう。

そうじゃなくて、
「コンパイラを作るとき、デバッガをどの程度意識して作るものなのか。
　コンパイラ屋さんはたいして意識せず、デバッガ屋さんががんばるものなのか、
　それともコンパイラ作る段階で相当意識するものなのか。」

という疑問であるとか、

「なあみんな、処理系作るときどれくらいデバッガ意識してる?」

という問いかけであるのならわかるんだけど。

941 ：デフォルトの名無しさん：2005/12/19(月) 23:56:40

SmalltalkやObjectCの話を聞いたときには、「そのうちプログラムも部品化・汎用化されて
CADのように配置して、入出力を線で結んで作るようになるんだろうなぁ」とか
思ったんですが、
なんでエディタで変数名をマウスで触ると宣言が出てきたりとか、コード補完してくれるとか
そっちへ行ってしまったのだろうか。
キーボードの呪い？

942 ：デフォルトの名無しさん：2005/12/20(火) 00:08:13

>>941
CAD方式のほうがめんどくさいことがわかったからだ

943 ：デフォルトの名無しさん：2005/12/20(火) 01:30:21

>>941
VisualAge for JavaってのがIBMから出ててな、結構やすいからまだ手に入るなら試してみな。
そうすりゃどのくらい便利でどっからあたりでマンドクサイかよ～くわかるから。

944 ：デフォルトの名無しさん：2005/12/20(火) 01:57:01

graphical だと patch 作るの面倒そう。

945 ：デフォルトの名無しさん：2005/12/20(火) 02:08:54

>>944
そうでもないよ
画面からテキストへの写像でしかないから
UNIXから来た人は想像できなくて誤解も多いだろうけど

946 ：デフォルトの名無しさん：2005/12/20(火) 02:28:49

ん、一旦テキストに落とすの?

947 ：デフォルトの名無しさん：2005/12/20(火) 02:57:44

LispやSmalltalk界隈では普通に行われてるけど
他の言語では一般的にマーシャリングとかシリアライズと言われている機能かな
データ記述能力の低い言語ではXMLとかの別の構造に記録したりする

948 ：デフォルトの名無しさん：2005/12/20(火) 03:16:07

>>943
シンセのエミュで、フィルタとかを結線するのは見たことがある

949 ：デフォルトの名無しさん：2005/12/20(火) 03:18:14

SchemeやHaskellの話を聞いたときには、「そのうちプログラムも関数になって
参照透明に設計して、引数と返り値のやりとりだけで作るようになるんだろうなぁ」とか
思ったんですが、
なんでCの拡張のC++とか、Cの改良のJavaとかそっちへ行ってしまったのだろうか。
手続き型の呪い？

と同種の悩みなんだろうか。

950 ：デフォルトの名無しさん：2005/12/20(火) 06:38:49

開発が進むごとに関数が増え続ける言語では、
関数の数が多すぎて、管理しきれなくなるからだろ。
関数の使用目的や機能等で特定の関数が使用可能な領域を縛ったりすれば、
もしかしたら可能だったかもしれんが・・・

951 ：デフォルトの名無しさん：2005/12/20(火) 06:47:00

> 開発が進むごとに関数が増え続ける言語では
増えない言語ってあるの？

952 ：デフォルトの名無しさん：2005/12/20(火) 07:04:54

>>951
現在、検案中。

特定の関数の使用できる条件を、経由した関数名や
オブジェクト等で限定できるようにすれば、
関数の個数を減らす事は可能かな？とか考えてる所。

953 ：デフォルトの名無しさん：2005/12/20(火) 07:46:32

要するに、心当たりは無いが、将来的には存在するかもしれないって事か。

954 ：デフォルトの名無しさん：2005/12/20(火) 08:00:51

Cは開発が進むごとに関数が増え続ける言語だが
(Common Lispのパッケージのような名前空間すらない)、
結構大きなシステムが書かれてるよな。

>>950のいう「管理しきれなくなる」というのは
どれくらいの規模のソフトウェアなのかまず明らかにしろ。

955 ：デフォルトの名無しさん：2005/12/20(火) 08:30:42

しきれなくなるは言い過ぎかも知れんが管理がきわめて困難になるのは事実だろ。
だからCの後継言語に名前空間が存在するわけで。

956 ：デフォルトの名無しさん：2005/12/20(火) 08:38:35

>>955
> しきれなくなるは言い過ぎかも知れんが管理がきわめて困難になるのは事実だろ。
下調べもせずにこんな適当な思い込みで開発するのはいかがなものか

957 ：デフォルトの名無しさん：2005/12/20(火) 08:43:31

というか、949に対する答えとしては、950はおかしいぞ。
HakellやSchemeが「開発が進むごとに関数が増え続ける言語」で
C++やJavaが「開発が進むごとに関数が増え続けない言語」なのか？

958 ：デフォルトの名無しさん：2005/12/20(火) 08:57:04

C++やJavaは、関数が増え続けないように歯止めをかける事が可能な言語かと。ｗ
まあ、その機能を有効活用している例は少ないようだが。ｗｗ

959 ：デフォルトの名無しさん：2005/12/20(火) 10:42:50

ヘッダ＆変なプレフィクスが名前空間＆クラスになったと。
本質はあまり変わってないが言語機能でサポートされたから多少は楽に。

960 ：デフォルトの名無しさん：2005/12/20(火) 12:39:44

関数の数なんてソフトウェアの複雑性ではマイナーな問題だろう。

たかが関数が増えることよりも、クラスを一個定義するだけで
ポインタやらconstなポインタやら参照やらconstな参照やら
もちろんあと値渡しも、そしてconstなメンバ関数やらconstでない
それやら、関数ポインタやらメンバ関数ポインタやら……を考えないと
いけないC++の方がはるかに大変だ。
テンプレート使ってると特に。

961 ：デフォルトの名無しさん：2005/12/20(火) 12:40:37

えーと。
大概のLispやSchemeのような古い関数型言語には名前空間ないけど、
MLやHaskellなどちょっと新しい関数型言語には名前空間あるよ。
というつっこみを誰もしないのはなぜですか？

962 ：デフォルトの名無しさん：2005/12/20(火) 13:29:03

MLが新しいって?

963 ：デフォルトの名無しさん：2005/12/20(火) 13:44:57

すまん、全てのMLが新しいみたいに言っちゃったな。
といっても正直、古いLispや古いMLはろくに知らないんで、
少なくとも今生き残っているLisp、MLについては、ってことにしてくれ。

さらに自分で言っといてなんだけど、Schemeって名前空間ないんだよね？
オブジェクト指向っぽいメッセージパッシングなどを
エンコードする形で自力で書け、ってことなのかな。

964 ：デフォルトの名無しさん：2005/12/20(火) 15:45:28

LispやSchemeに名前空間がないつっても、Cと違って局所関数やクロージャ、
プロパティリストなどがあるからいくらでも階層構造に出来るしなあ。
その上大抵はベンダーがオブジェクト指向やモジュール機能
提供してるのがデフォだし。
つうか、オブジェクト指向機能を一番最初に搭載したのってLispでしょ？

965 ：デフォルトの名無しさん：2005/12/20(火) 16:04:57

オブジェクト指向とかそのへんはまた荒れるんで、とりあえず
関数型言語は関数が増えるから使い物にならない
か否か、だけにしとこうよ。

966 ：デフォルトの名無しさん：2005/12/20(火) 16:10:40

>>965
だからそのことについてだよ。
ようは、C++やJavaにクラス階層の名前空間があるから、
関数が増えても整理できるっていいたいんだろ？
だったら、Lispで出来るし、むしろLispが最初だってこと。

967 ：デフォルトの名無しさん：2005/12/20(火) 16:14:58

「大概のLisp」って何時のLispを指してるんだ?
Common Lispにはパッケージがあるぞ。
Schemeは処理系依存だが、次の規格で何か入るらしい。

968 ：デフォルトの名無しさん：2005/12/20(火) 16:16:16

>>967
CommonLispに加えて、Schemeも入れてたから。

969 ：デフォルトの名無しさん：2005/12/20(火) 16:18:05

つまり、関数が増えるからどうのというのはｍとんでもない勘違いでFA。

970 ：デフォルトの名無しさん：2005/12/20(火) 16:21:11

emacs-lispのイメージがあるんじゃないの？
あれ、なんらかの階層構造の機能を使って、増えた関数を整理するとかして
ないでしょ。
名前のつけ方を長くして階層的にしてるだけで。

971 ：デフォルトの名無しさん：2005/12/20(火) 16:24:30

あれはモード切り替えるから大丈夫なんじゃないか？
カレントディレクトリみたいなもんでしょ。

972 ：デフォルトの名無しさん：2005/12/20(火) 16:34:33

>>969
Common Lispには名前空間（パッケージ）やクラスがあるし、
Schemeにも処理系依存でそれらが存在する。
HaskellやMLにはもちろんあるでFA。

973 ：デフォルトの名無しさん：2005/12/20(火) 17:36:18

>>954
C言語はコンパイル単位というか、ファイルスコープやリンカが別になってて
元々環境が地続きではないから、そんなに困らなかったんじゃないかと。
干渉して困るのはプリプロセッサのマクロ定義をヘッダに置いた時とか。

974 ：デフォルトの名無しさん：2005/12/20(火) 18:59:09

Cは同じ名前の関数があったとしても型定義に違いがあれば誤用をある程度回避できるしな。
C++は多重定義を認めてるからそうはいかないけど。
それを考えると名前空間の採用はC++にとって必然だったんじゃないかね。

975 ：デフォルトの名無しさん：2005/12/20(火) 19:04:45

ス質急低

976 ：デフォルトの名無しさん：2005/12/20(火) 19:18:19

一気に下がったな。氷点下。

977 ：デフォルトの名無しさん：2005/12/20(火) 19:26:23

>>975-976
>>775

978 ：デフォルトの名無しさん：2005/12/20(火) 19:30:29

それより、質の高い話ってなんだろう・・・

979 ：デフォルトの名無しさん：2005/12/20(火) 19:32:45

ポインタの話から移ったと思えばむしろ質は向上しているよ
ついでにスレも物理的に上昇しておこうか

980 ：デフォルトの名無しさん：2005/12/20(火) 20:36:57

関数の数を減らせれば、CAD方式でも何とかなるのでは？
という話になると思ってたのは漏れだけか？
CAD方式の話は見事に忘れ去られているようだが。

981 ：デフォルトの名無しさん：2005/12/20(火) 20:42:01

950があまりにもとんちかんすぎただけだな。

982 ：デフォルトの名無しさん：2005/12/20(火) 20:51:26

スレタイからずいぶん距離のある議論になっているな

983 ：デフォルトの名無しさん：2005/12/20(火) 21:06:52

CAD方式のスクリプト、もしくは言語って、何がある？

984 ：デフォルトの名無しさん：2005/12/20(火) 21:07:44

CAD方式は機能が限定されているような狭い言語でないと、うまく行かないと
分かって来たからな。なので最近は（一部の研究を除いて）全く利用されていない。

985 ：デフォルトの名無しさん：2005/12/20(火) 21:17:47

LabViewがそうだったな。
漏れは使ったことないが、特定分野では成功してるみたいだよ。

http://www.asahi-net.or.jp/~WR9K-OOHS/Pages/Aboutlv/WWJ/WWJ03/wwj03.html

986 ：デフォルトの名無しさん：2005/12/20(火) 21:19:02

>>984
それって言い換えるなら、機能限定をうまく設定できればうまくいく、という事では？
ネームスペース以上に関数や変数等の摘要範囲を限定するような機能を設定できれば、
何とかなるのでは？

987 ：デフォルトの名無しさん：2005/12/20(火) 21:43:14

>>985
ほとんど電子回路だな。
漏れ的にはUMLのシーケンス図みたいなのを期待してたんだが……
CAD形式みたいなのは「作る人にとって」分かりやすい方式になりがちなのかな？

988 ：デフォルトの名無しさん：2005/12/20(火) 21:43:33

「コンパイラ・スクリプトエンジン」相談室9
http://pc8.2ch.net/test/read.cgi/tech/1135082582/

989 ：デフォルトの名無しさん：2005/12/21(水) 07:04:47

CAD方式は言語というよりもツールになのでは？とか思ったが、
GUI形式の言語という見方をするならば、たしかに言語かもしれんな。

990 ：デフォルトの名無しさん：2005/12/21(水) 08:03:14

複雑になっていくと、他の人や昔の自分が描いたソースを読めなくなりそうだ。
建築設計図ですら欠陥が見抜けないのに、ソフトウェアになったら…

991 ：デフォルトの名無しさん：2005/12/21(水) 08:52:00

いや、それはちゃんとコンポーネントを設計して、
ちゃんとコメントを残していけばいい話だろう。
テキスト形式の言語だって最初から完璧だったわけじゃない。
初期の言語で幾多の失敗を重ねたおかげで今の言語があるわけだ。

要はCAD方式言語は研究も経験も蓄積がなさすぎるだけ。
あと、俺らがすでにテキスト方式に慣れすぎてるというのもあると思う。

問題は、テキスト方式の蓄積を捨ててまで
CAD方式に乗り換えるメリットがあるかどうかだが…。

992 ：デフォルトの名無しさん：2005/12/21(水) 09:11:39

CAD形式を扱う場合のメリットは、UMLを扱う場合のメリットと同じかと。

図形にすると、処理の流れは分かりやすくなる。
しかし図形には、処理の論理が分かりにくいというデメリットもある。

993 ：デフォルトの名無しさん：2005/12/21(水) 09:39:02

UMLはUMLで、オブジェクト指向に関する政治的な駆け引きが色々と絡んで、
ややこしくなってる部分があるからなぁ……

その意味では、CAD形式言語に関しては、図形をいかに定義するかが焦点になりそうだな。

994 ：デフォルトの名無しさん：2005/12/21(水) 09:54:58

その場しのぎのやっつけ仕事の場合だと、
むしろCAD形式の方が楽かもしれんな。
世間の仕事の９割ぐらいは、やっつけ仕事だろ？

995 ：デフォルトの名無しさん：2005/12/21(水) 10:35:34

UMLはCAD形式の言語？

996 ：デフォルトの名無しさん：2005/12/21(水) 10:46:20

フローチャートもCAD方式の言語という事になるな

997 ：デフォルトの名無しさん：2005/12/21(水) 11:19:07

CAD型まではいかんが、MAX/MSPやPDは非テキスト型プログラミングの
試みとしては一番成功している部類だろう。