1 :
*.ini:
C/C++, Baic, Perl, Object Pascal, Java のいいとこ取り。どうぞ。
2 :
デフォルトの名無しさん:2001/08/21(火) 01:28
目的は?
rubyはないのね。
Baicがわからんことにはどうにも。
Del厨がいなければ良スレに育つ予感
6 :
デフォルトの名無しさん:2001/08/21(火) 01:34
Baic ってなに?
C/C++, Object Pascal, Java までだと C# という気がするが。
1に出てくるのはBaic(謎とC以外全部オブジェクト指向言語だが
これでいいのか?
JavaScriptは?
Objective-Cは?
HaskellとPrologも入れとけ
糞スレの予感(;´Д`)
12 :
デフォルトの名無しさん:2001/08/21(火) 01:40
Parlってオブジェクト指向言語なの?
15 :
デフォルトの名無しさん:2001/08/21(火) 01:46
型の概念をなくそう。
新人に型の説明するのもいいかげん飽きてきた。
数学でも、変数の型は重要ではない。
重要なのは、その変数がどういう意味を持つのか である。
19 :
デフォルトの名無しさん:2001/08/21(火) 02:01
perl 見たいに。
for 文でも省略を可能にしよう。
for 0 to 10
print;
このように。
20 :
デフォルトの名無しさん:2001/08/21(火) 02:03
Delphi∋C∪C++∪Baisc∪Perl∪Java
なぜBasicをちゃんと書ける奴がいないかな
Cの文法を持ったschemeが良いな。
23 :
デフォルトの名無しさん:2001/08/21(火) 02:12
構文1
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 $_;
24 :
デフォルトの名無しさん:2001/08/21(火) 02:14
標準でCOMPLEX型をサポート。
整数〜複素数の混在演算を許す。
25 :
デフォルトの名無しさん:2001/08/21(火) 02:19
引数が大量にある関数を呼び出す場面で、
後から見るとどの引数がどんな意味をもっているのか
その関数を知っていないと分からない。
そこで以下のような書き方を希望
従来
GetWindowText( GetTopWIndow(), *string, size )
新文法
GetWindowText(
#Handle: GetTopWindow() ,
#StringAddr: string,
#Size: size
);
26 :
デフォルトの名無しさん:2001/08/21(火) 02:20
Lispが一番
28 :
デフォルトの名無しさん:2001/08/21(火) 02:20
文字列の扱いはBASICだね。
サイズを明示的に指定したり
サイズが固定されたりするのはやだね。
29 :
デフォルトの名無しさん:2001/08/21(火) 02:25
複素数、文字列型、ベクトル、行列型の標準サポートを希望。
それから、Σ関数のサポートも。
二乗和なら
sum := sigma (k=0 to 100 do k^2);
加算はすべて
object s = Add(12,24,5,25)
のようにAdd(数値)にする。+(プラス)は禁止
>>30 メリットは?
カンマで区切るか、プラスで区切るかの違いにしか…
優先順位の問題か?
減算は、-(マイナス)を使用。
ただし右辺から左辺を引くこと。
+ - 32 45 58
dim object s = sum 12,24,5,25;
このように変数宣言にはかならず接頭 dim をつける。→変数宣言である事を明示する。sum関数は、括弧を使用しなくとも良い。従って、
sum関数をネストする事は許されない。
36 :
デフォルトの名無しさん:2001/08/21(火) 02:33
大きな配列でも自由に切れる。
メモリの割当をOSに依頼する部分は言語側で吸収する。
左辺 . 右辺を、左辺を整数部、右辺を小数部として解釈する。
4.(5+3) は 4.8 と同じ。
糞言語間違いなしだね
39 :
デフォルトの名無しさん:2001/08/21(火) 02:38
>>35 変数の宣言に"dim"を使うの反対!
あれを見ると頭が痛くなってくる。
そもそもあれは配列宣言用の命令(?)で、"dimension"から来てるんだから。
40 :
デフォルトの名無しさん:2001/08/21(火) 02:40
じゃあ dim じゃなくて def ならどうよ。
var
obj
object
Dim
local
new
どれがいい?
42 :
デフォルトの名無しさん:2001/08/21(火) 02:41
変数は0次元の配列だからDIMでも問題なし。
1次元だろ
45 :
デフォルトの名無しさん:2001/08/21(火) 02:43
変数にロック機能をつける。
dim a = 4;
a.lock;
ここの区間、aは読取専用
a.unlock;
a には代入可能
46 :
デフォルトの名無しさん:2001/08/21(火) 02:44
じゃあ def じゃなくて grep ならどうよ
48 :
デフォルトの名無しさん:2001/08/21(火) 02:44
0次元=点 = dim a
1次元=直線= dim a[10]
2次元=平面= dim a[10,10]
問題ないじゃん。整合性はある。
grep s/[0-9]+//
dimは厨房用語
52 :
デフォルトの名無しさん:2001/08/21(火) 02:46
breakしないとそのまま下に制御が移ってしまうCのswitch文はダメ。
Pascalのcaseを採用。
>>52 そうか?
あれはあれでいいんじゃないのか?
55 :
デフォルトの名無しさん:2001/08/21(火) 02:53
>>52 ついでに列挙型も採用ってか。いらねー。
つーか、switch廃止に一票。
if文だけで最適化はコンパイラが頑張る。
if xxxx
elsif xxxx
elsif xxxx
.....................
糞コードだ(藁
57 :
デフォルトの名無しさん:2001/08/21(火) 02:59
>>52 さらに、begin end で囲まなくてもすむようにすれば吉。
あと case のラベルに
文字列を使用可能にしよう。
case message of
'逝ってよし':
print "オマエモナー';
'荒らし':
println 'このスレは'; println 'めでたく';
println '終了しました';
'誹謗中傷,'個人情報':
println 'あぼーん';
end;'
59 :
55:2001/08/21(火) 03:02
>>56 んなこたねーっての。
オブジェクト指向な言語なら、switchなんていらん。
ふだんJavaだけどswitchなんてつかったことない。
61 :
デフォルトの名無しさん:2001/08/21(火) 03:02
基本的な三角関数やLog,Exp等の関数は
Includeなどの宣言をしないでいきなり使える。
MLも入れてくれ。
メタランゲージ最高!
Java並にライブラリ揃っててスクリプト言語みたいに書いて即実行出来るのがええな
64 :
55:2001/08/21(火) 03:05
>>60 Javaのライブラリの中にswitch文あるか数えてみ。
やったことないけどさ^^
JavaScript
名前は同じだが、中身Java(藁
66 :
デフォルトの名無しさん:2001/08/21(火) 03:10
ループ制御はBASICみたく
FOR - NEXT
WHILE - WEND
REPEAT - UNTIL
と、ループを閉じる命令を個別に用意する。
こうするとネスティングの対応が見やすい。
Cの
}
}
}
とかPascalの
end
end
end
だと対応関係を見つけるのが大変。
OpelaterOver"Ride"
演算子をオーバーライド
本気にするなよ(藁
69 :
デフォルトの名無しさん:2001/08/21(火) 03:15
>>67 いや、全然楽だって。閉じてる命令が違うと。
if~fi、case~esacみたいなのはいやだぞ
71 :
67:2001/08/21(火) 03:17
おれは、Cで慣れちゃったから・・・
ちゃんとしてればそこまで気にならないとおもう・・・
72 :
デフォルトの名無しさん:2001/08/21(火) 03:17
function
switch
case x
〜
end switch
end function
のほうが楽。
並列処理も楽に書ける(or 並列処理にしてくれる)ようにしてくれ。
KL1参考にして。
76 :
デフォルトの名無しさん:2001/08/21(火) 03:36
配列は実行時にサイズを確定する。
(DIM文に制御が来た時にサイズを確定してメモリを確保)
ソースの段階で確定しなくてよい。
(BASICと同じ)
言うは易し、行うは難し
VB厨が多数いる予感。
79 :
デフォルトの名無しさん:2001/08/21(火) 04:17
オブジェクト指向なScheme
ついでに、Delphiのような開発環境も欲しい
…なんか、それぞれの長所というよりは、
短所をしょいこんだ言語が生まれそうだな
80 :
デフォルトの名無しさん:2001/08/21(火) 04:56
>>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:
に置き換えるだけでよい。
.
82 :
◆3DelPhIM:2001/08/21(火) 08:20
やっぱり大事なのは機能よりバランスだと思う
文法がRubyでIDEがDelphiな奴で良いや。
84 :
デフォルトの名無しさん:2001/08/21(火) 09:15
>>25 そんなの開発環境の入力支援でやれば良い。
85 :
:2001/08/21(火) 09:39
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の状態を目の前に晒す発想だ。
87 :
デフォルトの名無しさん:2001/08/21(火) 10:18
>25
TOWNSで動いてたHI-Cでは(書き方は違うけど)実現してた。
88 :
無名λ式:2001/08/21(火) 11:09
89 :
デフォルトの名無しさん:2001/08/21(火) 11:20
型無しの方がいいな
90 :
デフォルトの名無しさん:2001/08/21(火) 11:38
制御構造を表すのにインデントを文法に取り入れてる言語あったよね?
仮に
>>1のいうように、いいとこ取りの言語ができても
Scheme なんかのほうがよさげ。
94 :
デフォルトの名無しさん:2001/08/21(火) 13:11
いっそのこと、最悪な言語仕様を考えるのはどうだろう
>>94 HSPにオブジェクト指向
作者が作れば間違いなしさ(藁
96 :
デフォルトの名無しさん:2001/08/21(火) 15:17
省略形の一切できない言語が業務的にうれし。
関数や命令の範囲がどこまであんねんってのがわからなきついんでカッコ分化マンセー
あと、変数の頭に必ず指定の接頭詞つけなきゃコンパイルエラーとか。
厨の多くはこれで抑制できる
↓と
(°д°)ウマー
97 :
perl perler perlest:2001/08/21(火) 15:35
>>96 > 省略形の一切できない言語が業務的にうれし。
ガ━━(゜д゜;)━━ン!
>>96 パスカルってもともとは設計思想がそんなカンジだったような。
RUBYのスコープ=接頭辞ってのはわりと良いアイデアだと思う
99 :
デフォルトの名無しさん:2001/08/21(火) 20:28
Eiffelの契約による設計希望。
ここって考えるだけ?
みな赤面して何も言えないようだw
無名関数があると何かと便利な気がする予感…
無名関数が無いとハッキリ言って糞な予感…
>>100 今 漏れは言語を作っているのだが、不幸なことにそれは「いいとこどり」なものではない。
漏れのかわりに誰かいいとこどりなのを作ってageてくれぃ。
…
実際は、いいとこどりなんて無茶な発想だ、と皆が判っているので、手をつけてないだけだろ。
2つの言語の「いいとこ」が必ずしも仲良く合体できるとは限らないし、
人によって「いいとこ」の捉え方もばらばらだから、
>>1だけにとってヨイ言語が出来るだけだろう。
105 :
1:2001/08/22(水) 14:13
ありがとう。とりあえず、俺の知らない他の言語の特徴を見ることが出来た。
俺のためにみんな、ありがとう。後は勝手にやってくれ。
>>105 別にアンタのタメにやってたわけじゃないだろう。
まず行番号を実装する必要があるな。
109 :
デフォルトの名無しさん:2001/08/22(水) 21:16
すでにある言語を元にしないで、どの言語の書き方とも違う言語じゃないと
皆がいいと思うものはできないと思う。
というわけで、斬新なアイディアで新しい言語を考えよう。
じゃ、縦書きで。
111 :
デフォルトの名無しさん:2001/08/22(水) 21:30
とりあえず、コードを書いたら、自動的におまけで仕様書が勝手にできあがるような仕組みにしよう。
いや、仕様書から自動的にコードが生成されるような仕組みに…
113 :
デフォルトの名無しさん:2001/08/22(水) 21:47
会話にも使えるプログラム言語
用途を定めず字面の話ばっかしててもねぇ
115 :
デフォルトの名無しさん:2001/08/22(水) 21:56
2ちゃんねらー専用プログラム言語「2ch言語」をみんなで
作ろう。
117 :
デフォルトの名無しさん:2001/08/22(水) 22:22
英語に非常に近い形で例えばHelloWorldも
I write "HelloWorld".
とかいう風にするとか。
変数の定義は
I make 型 変数名.
て感じで・・・・・・
こんなアイディアでどうでしょう。
非常に書きやすく、読みやすくなると思うのですか。
118 :
デフォルトの名無しさん:2001/08/22(水) 22:23
119 :
デフォルトの名無しさん:2001/08/22(水) 22:26
HSPを超える言語は無いだろ
>>114 科学技術計算用。(OSとかドライバとかは書けなくていい)
121 :
デフォルトの名無しさん:2001/08/22(水) 22:28
>>117 プリプロセッサ使えばできると思うんだが・・・
つか、あまり書きやすくも読みやすくもないと思うぞ・・・
123 :
デフォルトの名無しさん:2001/08/22(水) 22:45
125 :
デフォルトの名無しさん:2001/08/22(水) 22:53
結局、ほかにアイデアはなしですか?
あるけど言いたくない。
作成中だから
修正。
言語を作成中だから
>>130 作成中なら、この場でみんなで語りあってよりいっそういいもの
にしませんか。
133 :
デフォルトの名無しさん:2001/08/23(木) 05:19
>とりあえず、コードを書いたら、自動的におまけで仕様書が勝手にできあがるような仕組みにしよう。
>いや、仕様書から自動的にコードが生成されるような仕組みに…
仕様書そのものが言語になるようにする。
フォーマットに従い仕様書をつくったら、そのままコンパイラへGO
>>133 自分で客先に行って必要事項をまとめてくれる自律型仕様書きぼーん
>>134 それが更に進歩すると自律型お客様+自動作成ソフトになって、
プログラマやSEがシツギョーン。
136 :
デフォルトの名無しさん:2001/08/23(木) 16:59
マジな提案です。
明示的でないイテレーションていうと 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)
...みたいな。
同じ関数が値にも集合にも使えるというのはどうだろう?
集合を引数にとって集合を返す関数にそのような機能を
自動的に適用しようとすると、おかしなことになりそう
な気がする。
138 :
デフォルトの名無しさん:2001/08/23(木) 17:42
>>136 Lisp/Scheme風にいうと
(define hoge (lambda (n) (...)))
(map hoge listm)
もしくは
(map (lambda (n) (...)) listm)
139 :
138:2001/08/23(木) 17:46
137とかぶった上に
137が自分より建設的で高級な提案をしてるよ
Hazukasi〜Yo〜
>>138 map系の関数は知ってまふが、暗黙にできるとこがミソなのですが。
ダメかな・・・。
>>137 > Schemeあたりすぐに実装できそうな気が。
なるほど make-maped-function てのがあるんですね。
> 集合を引数にとって集合を返す関数にそのような機能を
> 自動的に適用しようとすると、おかしなことになりそう
> な気がする。
確かに Lisp, Ruby など型付けの弱い言語では混乱が起こる
のですが、Java, C++ などの強い型の言語ならば問題ないの
てはないかと・・・。
あ 137=140 です。
>>141 > あ 137=140 です
間違い。 136 = 140。
明示的に map で十分。
>>136 >これが可能であるためには、Java のような型の強い言語でなきゃダメだし、
>また配列だけでなくコレクションクラスを統一的に扱える必要があるかも。
(ソースだけじゃなくバイナリレベルで)統一的に扱うためには、
型が強かったら却って不都合じゃないの?
混乱を強型で防げるのかなあ。再帰的な構造のデータを突っ込まれたときに、
どっちの挙動をすべきか?の判断は、型だけでは結局判断できないよね。
>>145 > ソースだけじゃなくバイナリレベルで)統一的に扱うためには、
> 型が強かったら却って不都合じゃないの?
うーん、どうでしょう。あまりその辺ははっきりイメージしてないけど。
例えば全てのコレクション(配列も含めて)はクラス Collection から
派生するようにして、list や set クラスは、Collection への暗黙の
型変換を可能にすれば C++ や Java で実現してる程度のことはできる
のではないでしょうか。あるいは Java のように Collectionable イン
ターフェースを実装したクラスがコレクションと見なされる、というように。
> 混乱を強型で防げるのかなあ。再帰的な構造のデータを突っ込まれたときに、
> どっちの挙動をすべきか?の判断は、型だけでは結局判断できないよね。
最悪、ネストは1レベルだけのマッチングに限定するとか(使いモンに
ならない?(^^;)そして 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 なんか
では起こらないのかも)、まあ、これは決めの問題でどうにでもなるでしょう。
それと曖昧性でもう1つ気がつきまし。
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>
とマッチするのかやはり曖昧になります。
まぁ、これも最外側マッチングのルールとか決めればいいのかな。
だんだん苦しくなってきたかも (^^;
149 :
デフォルトの名無しさん:2001/08/24(金) 08:25
150 :
デフォルトの名無しさん:01/09/02 05:54 ID:3bXnTTWA
VISIOでフローチャート書く
↓
そのままコンパイル
↓
(゚д゚)ウマー
>>150 > VISIOでフローチャート書く
フローチャートはやめとけ(笑
ただいわゆる完全なグラフィカルプログラミングってのも興味あるのだが。
LabView とか、その作りというか発想はなかなか画期的だとは思う。
でも、実は使いにくいのよねん。
152 :
デフォルトの名無しさん:01/09/03 21:25 ID:wy3QSGS6
じゃあ、「いいとこ取り」という視点でマジ提案。
関数型言語は非常に多機能だから、関数型言語からλ抽象(無名関数)、高階関数、
抽象データ型、遅延評価、パターン評価、などなどの特徴を取り入れる。
んで、C++のSTLのようなことするために関数型言語から多相型を取り入れる。その代わり、
オブジェクト指向を取り入れたいので、副作用は有りにする。モナドとか言っても
誰もわかってくれないだろうし。
Schemeみたいにしたいのはやまやまなんだけど、リストによる記法が見難いので、
普通の命令型のような中値記法を取り入れる。そのかわり、プログラムはリスト
として扱えるし、マクロも取り入れる。ちょうどDylanのような感じかな。
型有り、型無しのそれぞれの特徴を生かすため、宣言があれば型有り変数、無ければ
型無し変数ということにする。Perl6がそうなるらしいね。
あとは、C#のボクシングとか、オブジェクト指向の機能とかを取り入れていけば
いいんじゃないかなあ。
153 :
デフォルトの名無しさん:01/09/04 00:38 ID:FYWyf6W.
いささか些事ではあるけど
>>152 > 型有り、型無しのそれぞれの特徴を生かすため、宣言があれば型有り変数、無ければ
> 型無し変数ということにする。
変数宣言を必須にする動機の1つに、変数名のスペルミスをコンパイル時に
検出するためってのがあると思うんだけど、宣言のない変数を暗黙に型無し
変数として有効にしちゃうと、それができなくなって型有り言語のメリットが
薄れるんじゃないかな。
>>153 スペルミスは、なにもコンパイル時にチェックする必要は無いじゃん。
スペルミスチェッカーでも別に付けとけば?
155 :
デフォルトの名無しさん:01/09/04 01:00 ID:7wOQam5w
PL/I の理想と挫折、再び。
つーかschemeでいいじゃん
>>153 そうだね。そうだとすると、型無しだと宣言する方がいいね。
158 :
デフォルトの名無しさん:01/09/04 02:23 ID:ih5eONCo
やっぱり2ch言語は
goto文が「逝ってよし」だったり、
default文が「名無しさん」だったり、
return文が「あぽ〜ん」だったりするのだろうか。
159 :
デフォルトの名無しさん:01/09/04 02:35 ID:JE/PAhhI
10: I ← 2
14: 数値←キー入力
15: もしも(数値 が1)ならば80へ逝ってよし
20: もしも(数値 MOD Iがゼロ)ならば
30: 数値=数値÷I
40: 表示(数値+スペース)
50: そうでなければ
60: I=I+1
70: 15へ逝ってよし
80: 糸冬了
160 :
153:01/09/04 03:56 ID:z5/49YHM
>>154 > スペルミスチェッカーでも別に付けとけば?
まーね。要するに、その言語をどういう用途に使うかっていうポリシーの
問題だから。色々なアプローチがあってもよいとは思う。
多人数で分担して大規模なシステムを開発するような場合は、コンパイル時に
厳密にチェックできるようにした方がよいだろうし、そうでないならお気楽な
方がよいって考えもあるわけで。
外部のチェッカはアラームを上げることまでしか出来ない。似たよな変数名が
あったとき、意図的にそういう名前を付けてるのか typo なのかは作った人間に
しか最終的な判断はできないわけで、コンパイル時にエラーにできる構文なら
実行時までバグが見逃される危険が減るのは確か。
161 :
デフォルトの名無しさん:01/09/04 04:39 ID:F8eDitgE
>>153 宣言と初期化を同時にするのはどうでしょう?
162 :
153:01/09/04 05:45 ID:z5/49YHM
>>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 を初期化する
必要はないと判断してムダなコードを生成しないようにできるかもしれない
けど…、どうかな。
163 :
153:01/09/04 05:46 ID:z5/49YHM
×意義なし
○異議なし
164 :
153:01/09/04 05:49 ID:z5/49YHM
よく考えると、いきなり EOF の場合もあるから、lastChar = 0 は
ムダじゃないなぁ。例が悪かったゴメソ。
165 :
デフォルトの名無しさん:01/09/04 22:48 ID:ddDwxAtA
これからはコーディングレス言語の時代だよ。
画面上で電子ブロックみたいな部品を配置するやつってあったよね?
166 :
デフォルトの名無しさん:01/09/04 23:23 ID:OYi1KVOE
>>152 副作用ありの遅延評価か。デバッグ楽しそうだね。ついでだからスレッドについ
てはADAのランデブとJavaのモニターともうちょっとプリミティブな奴を好きに
組合せて使える。もちろん、ユーザレベルスレッドとカーネルレベルスレッドと
混合のどれでも同じように動いてくれる。
それから、SQLもCORBAもライブラリじゃなくて言語レベルで組みこんじまえば完
璧だね。perlがこれだけ流行っても誰も使わないあの謎のレポート機能も欲しい
な。
こんな言語のコンパイラを本気で開発したら、もの凄い工数が必要になって日本
の失業率下がるぞ。
>>166 Schemeも副作用ありの遅延評価だけど・・・
169 :
デフォルトの名無しさん:01/09/05 02:57 ID:jFtajofc
>166
>それから、SQLもCORBAもライブラリじゃなくて言語レベルで組みこんじまえば完璧だね。
なおさらScheme(というかlisp)の思想の様な気がするけど?
170 :
sage:01/09/05 14:12 ID:6PT9EWiQ
ていうか Lisp って特殊だよね。もともと S式以外に構文らしいものを
持ってないわけだから、機能を追加してもパーサに手を入れる必要が
ほとんどない。
どんなに機能を追加しても Lispという言語のアイデンティティに何ら
影響しないってのは、考えてみればスゴイ言語だ。
でもCommonLispにコンパイル時型チェックや継続や遅延評価などを仕様をいじらず
追加しようとしたって無理だよね。
後者二つはSchemeにあるけど、仕様としてはじめから組み込まれてるものだし。
173 :
171:
いや、そりゃ処理系を全く書き換える必要もないって意味じゃなくて
syntax レベルでは Lisp には S式しかないってことなんで
> でもCommonLispにコンパイル時型チェックや継続や遅延評価などを仕様をいじらず
この辺は semantics のレベルなんじゃないかな。