■■■いいとこ取り新言語の仕様を考るスレ■■■

C/C++, Baic, Perl, Object Pascal, Java のいいとこ取り。どうぞ。

目的は？

rubyはないのね。

Baicがわからんことにはどうにも。

Del厨がいなければ良スレに育つ予感

Baic ってなに？

C/C++, Object Pascal, Java までだと C# という気がするが。

1に出てくるのはBaic(謎とC以外全部オブジェクト指向言語だが
これでいいのか？

JavaScriptは？
Objective-Cは？

HaskellとPrologも入れとけ

糞スレの予感(;´Д`)

Parlってオブジェクト指向言語なの？

>>12
それってBaicと同じ・・・

>>12 Perl5からね。一応。

型の概念をなくそう。
新人に型の説明するのもいいかげん飽きてきた。
数学でも、変数の型は重要ではない。
重要なのは、その変数がどういう意味を持つのか　である。

>>15
コンパイラ作る人の身にもなると(以下略

>>15
どうやって？
文字列とかは？

>>1
貴様！！
M$の手先だな！！

perl 見たいに。
for 文でも省略を可能にしよう。

for 0 to 10
print;

このように。

Delphi∋C∪C++∪Baisc∪Perl∪Java

なぜBasicをちゃんと書ける奴がいないかな

Cの文法を持ったschemeが良いな。

構文１
for 0..10 do
　print $_;

構文2
for 0,1,2,3,4,5,6,7,8,9,10 do
　print $_;

構文3
for 0..5,4,5,22,4 do
　print $_;

標準でCOMPLEX型をサポート。
整数〜複素数の混在演算を許す。

引数が大量にある関数を呼び出す場面で、
後から見るとどの引数がどんな意味をもっているのか
その関数を知っていないと分からない。
そこで以下のような書き方を希望

従来
GetWindowText( GetTopWIndow(), *string, size )

新文法
GetWindowText(
　　#Handle: GetTopWindow() ,
　　#StringAddr: string,
　　#Size: size
);

smalltalkくせー>>25

Lispが一番

文字列の扱いはBASICだね。
サイズを明示的に指定したり
サイズが固定されたりするのはやだね。

複素数、文字列型、ベクトル、行列型の標準サポートを希望。
それから、Σ関数のサポートも。

二乗和なら
sum := sigma (k=0 to 100 do k^2);

加算はすべて
object s = Add(12,24,5,25)
のようにAdd(数値）にする。+（プラス）は禁止

>>30
メリットは？
カンマで区切るか、プラスで区切るかの違いにしか…
優先順位の問題か？

>>28>>29>>30
なにそれ・・・

減算は、-（マイナス）を使用。
ただし右辺から左辺を引くこと。

+ - 32 45 58

dim object s = sum 12,24,5,25;

このように変数宣言にはかならず接頭 dim をつける。→変数宣言である事を明示する。sum関数は、括弧を使用しなくとも良い。従って、
sum関数をネストする事は許されない。

大きな配列でも自由に切れる。
メモリの割当をOSに依頼する部分は言語側で吸収する。

左辺 . 右辺を、左辺を整数部、右辺を小数部として解釈する。

4.(5+3) は 4.8 と同じ。

糞言語間違いなしだね

>>35
変数の宣言に"dim"を使うの反対！
あれを見ると頭が痛くなってくる。
そもそもあれは配列宣言用の命令(?)で、"dimension"から来てるんだから。

じゃあ dim じゃなくて def ならどうよ。

var
obj
object
Dim
local
new

どれがいい？

変数は０次元の配列だからＤＩＭでも問題なし。

>>42
(;´Д`)

1次元だろ

変数にロック機能をつける。

dim a = 4;

a.lock;

ここの区間、aは読取専用
a.unlock;

a には代入可能

じゃあ def じゃなくて grep ならどうよ

>>45
変数やないやん・・・

０次元＝点　＝ dim a
１次元＝直線＝ dim a[10]
２次元＝平面＝ dim a[10,10]
問題ないじゃん。整合性はある。

grep s/[0-9]+//

dimは厨房用語

>>48
心で。

breakしないとそのまま下に制御が移ってしまうCのswitch文はダメ。
Pascalのcaseを採用。

>>52
そうか？
あれはあれでいいんじゃないのか？

>>45
Adaのランデブを勉強して来い。

>>52
ついでに列挙型も採用ってか。いらねー。

つーか、switch廃止に一票。
if文だけで最適化はコンパイラが頑張る。

if xxxx
elsif xxxx
elsif xxxx
.....................


糞コードだ(藁

>>52
さらに、begin end で囲まなくてもすむようにすれば吉。
あと case のラベルに
文字列を使用可能にしよう。
case message of
　'逝ってよし':
　　print "オマエモナー';
　'荒らし':
　　println 'このスレは';　　println 'めでたく';
　　println '終了しました';
　'誹謗中傷,'個人情報':
　　println 'あぼーん';
end;'

>>57
16読め。

>>56
んなこたねーっての。

オブジェクト指向な言語なら、switchなんていらん。
ふだんJavaだけどswitchなんてつかったことない。

>>59
ライブラリは糞になりそう・・・

基本的な三角関数やLog,Exp等の関数は
Includeなどの宣言をしないでいきなり使える。

MLも入れてくれ。
メタランゲージ最高！

Java並にライブラリ揃っててスクリプト言語みたいに書いて即実行出来るのがええな

>>60
Javaのライブラリの中にswitch文あるか数えてみ。
やったことないけどさ^^

JavaScript
名前は同じだが、中身Java(藁

ループ制御はBASICみたく

　　FOR - NEXT
　　WHILE - WEND
　　REPEAT - UNTIL

と、ループを閉じる命令を個別に用意する。
こうするとネスティングの対応が見やすい。

Cの

　　}
　}
}

とかPascalの

　　end
　end
end

だと対応関係を見つけるのが大変。

>>66
それは慣れじゃないかと・・・

OpelaterOver"Ride"
演算子をオーバーライド

本気にするなよ(藁

>>67
いや、全然楽だって。閉じてる命令が違うと。

if~fi、case~esacみたいなのはいやだぞ

おれは、Cで慣れちゃったから・・・

ちゃんとしてればそこまで気にならないとおもう・・・

>>70
激同意。

function
　　switch
　　　　case x
　　　　〜
　　end switch
end function

のほうが楽。

並列処理も楽に書ける（or 並列処理にしてくれる）ようにしてくれ。
KL1参考にして。

>>74
言語自体見直す必要が・・・

配列は実行時にサイズを確定する。
(DIM文に制御が来た時にサイズを確定してメモリを確保)
ソースの段階で確定しなくてよい。
(BASICと同じ)

言うは易し、行うは難し

VB厨が多数いる予感。

オブジェクト指向なScheme
ついでに、Delphiのような開発環境も欲しい

…なんか、それぞれの長所というよりは、
短所をしょいこんだ言語が生まれそうだな

>>58
switch case を文字列に対応させるなんて　めっちゃ簡単だよ。
プリプロセッサ使って、
case V of
A: begin 処理A end;
B: begin 処理B end;
C: begin 処理C end;
end

を、
if V=A then 処理A goto L1; endif;
if V=B then 処理B goto L1; enfif;
if V=C then 処理C goto L1; endif;L1:

に置き換えるだけでよい。

.

やっぱり大事なのは機能よりバランスだと思う

文法がRubyでIDEがDelphiな奴で良いや。

>>25
そんなの開発環境の入力支援でやれば良い。

ObjectPascalのpropertyと
C++のtemplate
は便利。

>>16
コンパイラなんか作らなきゃいいんだよ。smalltalkやrubyみたいにする、と。
型の概念は変数じゃなくObjectの中に(暗黙のうちに)存在する。
気にせんで済まそうと思えば済ませられる。

>>22

Cなんぞの文法を採用したらSchemeの存在意義が消し飛ぶだろ。
無名関数(へのポインタ)も作れない言語だぞCは。
それとも、「CそのものじゃないがCに似た」のがよいということなら、
LUAっていう言語なんぞを見ておくと吉。

>>25-26
たしかにその悩みはSmalltalkで一発解決するわな。
その手の悩み持ってる人は、悪いこと言わぬから、一度(だけ)Smalltalk見ておけ。

>>29
そんなもの、イテレータさえあれば、もっと器用で有用なことが一杯やれるぞ。
とりあえずrubyあたりの眺めておけ。

>>36
そんなの珍しくもなんともないな。Cしかやったことないの？
#そのCですら、mallocはシステムコールのラッパー(+α)だが。

>>42
勘弁してくれ。配列をデフォだと思うのは。
>>44
点(広がりが無い)を0次元って呼ぶんだってば。覚えとけ。

>>66
その考えは、「同じ種類の」ループをネストした途端に、破綻するぞ。
同じ終了単語が並ぶことになるから、元の木阿弥な問題が発生するだけのこと。
viみたいに「対応するカッコを一発で探す」機能のついた(Programing用の)マトモなエディタを
常用していれば、そういう下らない発想は沸いてこない。

厨房は多分、ループの種類ってのは言語仕様に含まれたたかだか数個しか存在しない、と
信じているんだろうな。あんなもん、ちょっと柔軟性のある言語なら、
「幾つでも自作できる」んだぜ。そういう世界で終了単語をいろいろこね回していると
穴掘って埋める刑務所仕事みたいな気分になってくるぜ。

>>79
OOPと関数型って、合体きつくない？
ましてGUI RADは、Objectの状態を目の前に晒す発想だ。

>25
TOWNSで動いてたHI-Cでは（書き方は違うけど）実現してた。

>>79
> オブジェクト指向なScheme
goops
http://www.gnu.org/software/guile/gnu-guile-projects.html#Core

型無しの方がいいな

制御構造を表すのにインデントを文法に取り入れてる言語あったよね？

>>90 パイソン

>>90 Haskellのオフサイドルール

仮に>>1のいうように、いいとこ取りの言語ができても
Scheme なんかのほうがよさげ。

いっそのこと、最悪な言語仕様を考えるのはどうだろう

>>94
HSPにオブジェクト指向
作者が作れば間違いなしさ(藁

省略形の一切できない言語が業務的にうれし。
関数や命令の範囲がどこまであんねんってのがわからなきついんでカッコ分化ﾏﾝｾｰ
あと、変数の頭に必ず指定の接頭詞つけなきゃコンパイルエラーとか。
厨の多くはこれで抑制できる
　↓と
(°д°)ｳﾏｰ

>>96
> 省略形の一切できない言語が業務的にうれし。

ガ━━（゜д゜;）━━ン！

>>96 パスカルってもともとは設計思想がそんなカンジだったような。
RUBYのスコープ=接頭辞ってのはわりと良いアイデアだと思う

Eiffelの契約による設計希望。

ここって考えるだけ？

みな赤面して何も言えないようだｗ

無名関数があると何かと便利な気がする予感…

無名関数が無いとハッキリ言って糞な予感…

>>100
今 漏れは言語を作っているのだが、不幸なことにそれは「いいとこどり」なものではない。
漏れのかわりに誰かいいとこどりなのを作ってageてくれぃ。

…

実際は、いいとこどりなんて無茶な発想だ、と皆が判っているので、手をつけてないだけだろ。
2つの言語の「いいとこ」が必ずしも仲良く合体できるとは限らないし、
人によって「いいとこ」の捉え方もばらばらだから、
>>1だけにとってヨイ言語が出来るだけだろう。

ありがとう。とりあえず、俺の知らない他の言語の特徴を見ることが出来た。
俺のためにみんな、ありがとう。後は勝手にやってくれ。

>>105
別にアンタのタメにやってたわけじゃないだろう。

まず行番号を実装する必要があるな。

>>107
スパゲッティプログラムの読み方
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=997717227
の人ですか？

すでにある言語を元にしないで、どの言語の書き方とも違う言語じゃないと
皆がいいと思うものはできないと思う。
というわけで、斬新なアイディアで新しい言語を考えよう。

じゃ、縦書きで。

とりあえず、コードを書いたら、自動的におまけで仕様書が勝手にできあがるような仕組みにしよう。

いや、仕様書から自動的にコードが生成されるような仕組みに…

会話にも使えるプログラム言語

用途を定めず字面の話ばっかしててもねぇ

２ちゃんねらー専用プログラム言語「２ｃｈ言語」をみんなで
作ろう。

>>115
本気ならお前がアイデア出せ。

英語に非常に近い形で例えばHelloWorldも
I write "HelloWorld".
とかいう風にするとか。
変数の定義は
I make 型 変数名.
て感じで・・・・・・
こんなアイディアでどうでしょう。
非常に書きやすく、読みやすくなると思うのですか。

>>117
COBOLつかえ。

HSPを超える言語は無いだろ

>>114
科学技術計算用。（OSとかドライバとかは書けなくていい）

>>120
APLつかえ。

>>117
プリプロセッサ使えばできると思うんだが・・・
つか、あまり書きやすくも読みやすくもないと思うぞ・・・

>>121
APL ってこれか
http://member.nifty.ne.jp/ysaigusa/jp/apl/guide/intro/index.html

>>121

すみません、勘弁して下さい。

ttp://member.nifty.ne.jp/ysaigusa/jp/apl/guide/index.html

っていうのを見てみましたが
私にはとても使えそうにありません。（読めねーっ。）

結局、ほかにアイデアはなしですか？

あるけど言いたくない。

>>126
何故

作成中だから

>>123-124
んじゃこりゃーーーーー

修正。
言語を作成中だから

>>130
作成中なら、この場でみんなで語りあってよりいっそういいもの
にしませんか。

>>131
正気？

>とりあえず、コードを書いたら、自動的におまけで仕様書が勝手にできあがるような仕組みにしよう。

>いや、仕様書から自動的にコードが生成されるような仕組みに…

仕様書そのものが言語になるようにする。
フォーマットに従い仕様書をつくったら、そのままコンパイラへＧＯ

>>133
自分で客先に行って必要事項をまとめてくれる自律型仕様書きぼーん

>>134
それが更に進歩すると自律型お客様＋自動作成ソフトになって、
プログラマやＳＥがシツギョーン。

マジな提案です。

明示的でないイテレーションていうと Lisp の map系関数とか、同じことが
Smalltalk や Ruby のブロックでできるけど、もっと過激なやつでこういう
のはどうでそ。

例えば三角関数 sin(x) は実数を引数に取って実数を返す関数ですよね。
これに実数を要素とする配列などの任意のコレクションを与えると、暗黙に
イテレートされて復帰値としては結果が格納された配列が返るようにする。
Java 風に書くと

double[] x = {0.1, 0.2, 0.3};
double[] y = Math.sin(x);

もちろん組込み関数だけじゃなくて、ユーザが定義した関数やメソッドも
自動的にこの機能が使えることにする。

int hoge(int n) { .... }

int[] m = {1, 2, 3, 4};
int[] n = hoge(m);

これが可能であるためには、Java のような型の強い言語でなきゃダメだし、
また配列だけでなくコレクションクラスを統一的に扱える必要があるかも。

実はこれ MATLAB や Speakeazy 系の数値計算パッケージでは以前から
やってることだけど、なぜか一般の高級言語では見たことない。
便利だと思うんですけどね。それともすでに可能な言語あるのかな？

>>136
新しい関数を自動生成する方式でよかったら、
Schemeあたりすぐに実装できそうな気が。

(define maped-sin (make-maped-function 'sin))
(maped-sin aCollection)

...みたいな。

同じ関数が値にも集合にも使えるというのはどうだろう？
集合を引数にとって集合を返す関数にそのような機能を
自動的に適用しようとすると、おかしなことになりそう
な気がする。

>>136 Lisp/Scheme風にいうと
(define hoge (lambda (n) (...)))
(map hoge listm)
もしくは
(map (lambda (n) (...)) listm)

137とかぶった上に
137が自分より建設的で高級な提案をしてるよ
Hazukasi〜Yo〜

>>138
map系の関数は知ってまふが、暗黙にできるとこがミソなのですが。
ダメかな・・・。

>>137
> Schemeあたりすぐに実装できそうな気が。

なるほど make-maped-function てのがあるんですね。

> 集合を引数にとって集合を返す関数にそのような機能を
> 自動的に適用しようとすると、おかしなことになりそう
> な気がする。

確かに Lisp, Ruby など型付けの弱い言語では混乱が起こる
のですが、Java, C++ などの強い型の言語ならば問題ないの
てはないかと・・・。

あ 137=140 です。

>>141
> あ 137=140 です
間違い。 136 = 140。

明示的に map で十分。

>>143
うぐぅ(;_;)

>>136
>これが可能であるためには、Java のような型の強い言語でなきゃダメだし、
>また配列だけでなくコレクションクラスを統一的に扱える必要があるかも。

(ソースだけじゃなくバイナリレベルで)統一的に扱うためには、
型が強かったら却って不都合じゃないの？

混乱を強型で防げるのかなあ。再帰的な構造のデータを突っ込まれたときに、
どっちの挙動をすべきか?の判断は、型だけでは結局判断できないよね。

>>145
> ソースだけじゃなくバイナリレベルで)統一的に扱うためには、
> 型が強かったら却って不都合じゃないの？

うーん、どうでしょう。あまりその辺ははっきりイメージしてないけど。
例えば全てのコレクション(配列も含めて)はクラス Collection から
派生するようにして、list や set クラスは、Collection への暗黙の
型変換を可能にすれば C++ や Java で実現してる程度のことはできる
のではないでしょうか。あるいは Java のように Collectionable イン
ターフェースを実装したクラスがコレクションと見なされる、というように。

> 混乱を強型で防げるのかなあ。再帰的な構造のデータを突っ込まれたときに、
> どっちの挙動をすべきか?の判断は、型だけでは結局判断できないよね。

最悪、ネストは１レベルだけのマッチングに限定するとか(使いモンに
ならない？(^^;)そして C++ のテンプレートのように無限の再帰定義を
不可能にする。例えば変数は

list<int> li1
list<list<int>> li2;
list<list<list<int>>> li3;

のように型を明示して宣言されなければならない。ここで

Collection<int> hoge(Collection<int> ci)

という関数があったとき、Collection<int> ≡ list<int> がマッチング
するんだけど、li3 は一皮剥いたときに list<int> にならないから
hoge には渡せない。li1 はそのまま渡され、li2 は暗黙にイテレート
されて渡される、とか。

>>136
Adaなら引数の型が違えば別の関数として認識してくれるから
同じ名前で引数の異なる関数が複数作れるけど。

function sin(x: vector) return vector is
...
end sin;

function sin(x: matrix) return matrix is
...
end sin;

これじゃダメ？

>>147
はい、強い型の言語はこういうことができますね。C++ でも可能です。
ただ今回の話は明示的にではなく暗黙にやってほしいということです。

で、それで気がついたんだけど、こういう多重定義を許すと hoge(int)
と hoge(list<int>) が両方とも明示的に定義されていた場合、

list<int> ls;
hoge(ls);

はどっちの hoge が呼ばれるのかという曖昧性がありますね。
まあ、こういう多義性に関わる曖昧さは、ある程度暗黙の型変換を許す
C++ なんかだと baka(char) と baka(long) があったとき baka(10)
という呼び出しは曖昧になるわけで（型付けが極めて強力な Ada なんか
では起こらないのかも）、まあ、これは決めの問題でどうにでもなるでしょう。

それと曖昧性でもう１つ気がつきまし。
Object というクラスは全てのクラスの基底クラスであるとすると

hogehoge(Collection<Object> co)

という関数に対して >>146 の li3 は

list<list<list<int>>> li3;

だったから

hogehoge(li3) という呼び出しは可能なんですが、このとき直接

list<list<list<int>>> ≡ Collection<Object>

とマッチするのか、一皮剥いて(外側の list<> が暗黙にイテレートされて)

list<list<int>> ≡ Collection<Object>

とマッチするのかやはり曖昧になります。
まぁ、これも最外側マッチングのルールとか決めればいいのかな。
だんだん苦しくなってきたかも (^^;

D言語はどうでしょうか？
http://slashdot.org/developers/01/08/15/234223.shtml

VISIOでフローチャート書く
↓
そのままコンパイル
↓
(ﾟдﾟ)ｳﾏｰ

>>150
> VISIOでフローチャート書く

フローチャートはやめとけ(笑
ただいわゆる完全なグラフィカルプログラミングってのも興味あるのだが。
LabView とか、その作りというか発想はなかなか画期的だとは思う。
でも、実は使いにくいのよねん。

じゃあ、「いいとこ取り」という視点でマジ提案。
関数型言語は非常に多機能だから、関数型言語からλ抽象（無名関数）、高階関数、
抽象データ型、遅延評価、パターン評価、などなどの特徴を取り入れる。
んで、C++のSTLのようなことするために関数型言語から多相型を取り入れる。その代わり、
オブジェクト指向を取り入れたいので、副作用は有りにする。モナドとか言っても
誰もわかってくれないだろうし。
Schemeみたいにしたいのはやまやまなんだけど、リストによる記法が見難いので、
普通の命令型のような中値記法を取り入れる。そのかわり、プログラムはリスト
として扱えるし、マクロも取り入れる。ちょうどDylanのような感じかな。
型有り、型無しのそれぞれの特徴を生かすため、宣言があれば型有り変数、無ければ
型無し変数ということにする。Perl6がそうなるらしいね。
あとは、C#のボクシングとか、オブジェクト指向の機能とかを取り入れていけば
いいんじゃないかなあ。

いささか些事ではあるけど
>>152
> 型有り、型無しのそれぞれの特徴を生かすため、宣言があれば型有り変数、無ければ
> 型無し変数ということにする。

変数宣言を必須にする動機の１つに、変数名のスペルミスをコンパイル時に
検出するためってのがあると思うんだけど、宣言のない変数を暗黙に型無し
変数として有効にしちゃうと、それができなくなって型有り言語のメリットが
薄れるんじゃないかな。

>>153
スペルミスは、なにもコンパイル時にチェックする必要は無いじゃん。
スペルミスチェッカーでも別に付けとけば？

PL/I の理想と挫折、再び。

つーかschemeでいいじゃん

>>153
そうだね。そうだとすると、型無しだと宣言する方がいいね。

やっぱり2ch言語は
goto文が「逝ってよし」だったり、
default文が「名無しさん」だったり、
return文が「あぽ〜ん」だったりするのだろうか。

10:　Ｉ ← 2
14:　数値←キー入力
15:　もしも（数値 が１）ならば８０へ逝ってよし
20:　もしも（数値 ＭＯＤ Ｉがゼロ）ならば
30:　　　数値＝数値÷Ｉ
40:　　　表示（数値＋スペース）
50:　そうでなければ
60:　　　Ｉ＝Ｉ＋１
70:　１５へ逝ってよし
80:　糸冬了

>>154
> スペルミスチェッカーでも別に付けとけば？

まーね。要するに、その言語をどういう用途に使うかっていうポリシーの
問題だから。色々なアプローチがあってもよいとは思う。

多人数で分担して大規模なシステムを開発するような場合は、コンパイル時に
厳密にチェックできるようにした方がよいだろうし、そうでないならお気楽な
方がよいって考えもあるわけで。

外部のチェッカはアラームを上げることまでしか出来ない。似たよな変数名が
あったとき、意図的にそういう名前を付けてるのか typo なのかは作った人間に
しか最終的な判断はできないわけで、コンパイル時にエラーにできる構文なら
実行時までバグが見逃される危険が減るのは確か。

>>153
宣言と初期化を同時にするのはどうでしょう？

>>161
> 宣言と初期化を同時にするのはどうでしょう？

意義なしだけど…。C++ みたくブロックの途中で変数宣言できるようにすれば
さらに嬉しいでしょうね。

でも宣言時の初期化を必須にするという意味？
それだと効率至上主義の人から文句が出ることがあるかも。
例えば C/C++ の場合

int c = 0;　/* 初期化は必須？ */
char lastChar = 0;　/* 初期化は必須？ */

while((c = getchar()) != EOF) {
　　lastChar = (char)c;
}

if (lastChar == ....) {
　　....
}

変数 c の宣言は、まあ構文をなんとかすれば while のところでできるかも
しれないけど、最終入力文字を格納する変数 lastChar は、whileブロック内で
宣言すると その下の if 文ではスコープから外れるので、どうしても whileの
外で宣言せざるを得ない。この場合 lastChar = 0 という初期化はムダなわけ
だよね(書き方によっては回避できるかもしれないけど)。

コンパイラの最適化処理が十分賢ければ、前もって lastChar を初期化する
必要はないと判断してムダなコードを生成しないようにできるかもしれない
けど…、どうかな。

×意義なし
○異議なし

よく考えると、いきなり EOF の場合もあるから、lastChar = 0 は
ムダじゃないなぁ。例が悪かったゴメソ。

これからはコーディングレス言語の時代だよ。
画面上で電子ブロックみたいな部品を配置するやつってあったよね？

>>152

副作用ありの遅延評価か。デバッグ楽しそうだね。ついでだからスレッドについ
てはADAのランデブとJavaのモニターともうちょっとプリミティブな奴を好きに
組合せて使える。もちろん、ユーザレベルスレッドとカーネルレベルスレッドと
混合のどれでも同じように動いてくれる。

それから、SQLもCORBAもライブラリじゃなくて言語レベルで組みこんじまえば完
璧だね。perlがこれだけ流行っても誰も使わないあの謎のレポート機能も欲しい
な。

こんな言語のコンパイラを本気で開発したら、もの凄い工数が必要になって日本
の失業率下がるぞ。

>>165
> 画面上で電子ブロックみたいな部品を配置するやつってあったよね？

昔 LabView を 2,3ヶ月使った感じでは、主な用途は計測制御用ではあるものの
汎用言語としての記述力も十分で、システムとしては画期的。これ作った人尊敬
する、のだけど…

視覚的で分かりやすいのはプログラムが単純な場合で、ちょっと複雑になると
途端にゴチャゴチャしてきてメンテナンス性も低下するという欠点がある。
おそらくビジュアルプログラミング一般に共通する問題じゃないかな。
まあ今後に期待したいとこではある。

参考までに既存ビジュアルプログラミング環境のリンクを揚げとく。
他にも沢山あると思うが。

LabView
http://www4.airnet.ne.jp/quattro/char.html

VisualControl
http://www.kealyn.com/vcgra.htm

AVS
http://www.kudpc.kyoto-u.ac.jp/Services/AVS/Guide/node7.html

SoftWire
http://www3.astrodesign.co.jp/softwire/softwiretop.html

IntelligentPad
http://www.pads.or.jp/ip/tutorial/timer02.html

必ずしもオフィシャルでもトップページでもなく、スクリーンショット
のあるページ。

>>166
Schemeも副作用ありの遅延評価だけど・・・

>166
>それから、SQLもCORBAもライブラリじゃなくて言語レベルで組みこんじまえば完璧だね。
なおさらScheme（というかlisp）の思想の様な気がするけど？

>>169
Common Lispの思想かなあ？

ていうか Lisp って特殊だよね。もともと S式以外に構文らしいものを
持ってないわけだから、機能を追加してもパーサに手を入れる必要が
ほとんどない。

どんなに機能を追加しても Lispという言語のアイデンティティに何ら
影響しないってのは、考えてみればスゴイ言語だ。

でもCommonLispにコンパイル時型チェックや継続や遅延評価などを仕様をいじらず
追加しようとしたって無理だよね。
後者二つはSchemeにあるけど、仕様としてはじめから組み込まれてるものだし。

いや、そりゃ処理系を全く書き換える必要もないって意味じゃなくて
syntax レベルでは Lisp には S式しかないってことなんで

> でもCommonLispにコンパイル時型チェックや継続や遅延評価などを仕様をいじらず

この辺は semantics のレベルなんじゃないかな。