プログラミング言語 開発スレ(　´�D｀)

暇で本気な人はｶﾓｿ！

プラットフォームを決めれ。

もちろんオブジェクト指向だよな。

ポインタは右からかかってください。
矢印演算子もう要りません。
batman.kick()
p_batman*.kich()

環境はとりあえずWinで逝きたいと思います。
ポインタは取り入れます、久々に

オブジェクト指向はもうおなかいっぱい。
非OOでお手軽ご気楽に組めるのがいい。

コンパイラ実装なんて待ってられない。
Cのプリプロセッサみたいなのでいいよ。
軽く逝こうや。

HSPみたいなのでいい。
というかHSPみたいな糞仕様な言語が幅をきかせているのはおかしい。
対抗馬を作れ。

↑すべて１

List<e> {
　public List(head, tail) {
　　Head = head;
　　Tail = tail;
　}
　public property e Head {
　　get() { return e; }
　　set(value) { Head = value; }
　}
　public property List<e> Tail {
　　get() { return Tail; }
　　set(list) { Tail = list; }
　}
　public insert(value) {
　　Tail = List.new(value, Tail);
　}
}

こんな構文が通るようにしてくれ。
もちろん型推論で静的型付け言語な。

ちょっとミスった

List<e> {
　public List(head, tail) {
　　Head = head;
　　Tail = tail;
　}
　public property e Head {
　　get() { return Head; }
　　set(value) { Head = value; }
　}
　public property List<e> Tail {
　　get() { return Tail; }
　　set(list) { Tail = list; }
　}
　public insert(value) {
　　Tail = List.new(value, Tail);
　}
}

>>11
public insert(value) {
　Tail = List.new(Head, Tail);
　Head = value;
}
じゃないか？

Array String Integer Real Comprex Imaginary Bignum Type
がファーストクラスオブジェクトね。
もちろん全部Primitiveじゃなくてクラス

ワンライナでWinアプリつくれるやつが欲しい。

C:\> xxxx -@ 'window(<>){/*置き換え処理*/;}>>>eachfile'
例えばこれで引数のファイル全部を読んで、それぞれにに吐くとか。

C:\> xxxx -@ec 'window(<>){/*置き換え処理*/;}>>>edit|clip'
例えばこれでエディットボックスに出力吐いて、しかもクリップボードに転送済みとか。

ワンライナ<->可読書式
の、相互変換ユーティリティがあれば完璧かと。

CとHSPのニッチを狙え！

で、マルチスレッドは専用のクラスでもいいんだけど、
非同期メソッドコールをベースに簡略化するのがいいと思うぞ。

正規表現にコメントが無いとコンパイル通らないようにして

早くも>>1は逃げました

頑張ります(；´�D｀)

ポリシーは「それには簡単な、唯一の方法がある。」がいいな。
STLを使うような処理を簡単に書けて、なおかつ自動的にC++化してくれる、
神のような言語の出現を希望。

とりあえず、ポインタはいらない。
可変長配列と参照だけで問題あるまい？

>>20
C++化はまだマズイと思うなぁ。

日本語プログラミング言語がいいな。
ひまわりは糞。TTSﾏﾝｾｰ。

スマートでｶｯｺｲｲ言語ｷﾎﾞﾝ
関数型は難しすぎるので、手続き型でね。

開発言語（コンパイラ）は何を使う？

>>22
じゃあＣ化（ｗ
Windowsアプリさくっと書きたい。これはホンネ。
いくら簡単とはいえど、HSPでさっくり書けないものがある。

>>24
独自関数をCの関数に変換するってむずいのか？よくわからない…

みんなのアドバイス？(注文？)が多くて無知な僕一人では・・・
誰か手伝ってちょ〜

>>26
いや、関数型は難しすぎて漏れの頭のキャパシティに収まりきらないので困ると。

>>27　ネタスレ？

じゃなければ、言語仕様について頭にあることをはき出せ。
漠然としたイメージでもいいが、ポリシーはしっかり持っておけ

何気に>>17に同意。

コンパイラを作るのか、インタプリタを作るのか、どっちだ？？

コンパイラじゃないならこのスレは用済み

気の利きまくったプリプロセッサでいいんじゃない？
ソースの問題チェックして、関数からインクルード宣言を割り出して、最後にCファイルを吐く。
それでもHSPやVBより早いだろうし。

>>1さん、一緒にObject COBOL作りましょう！！！

正規表現使えば、Cに無い演算子の実装は可能だと思うけど。

>>35
？

>>36
少し構文解析すれば、「i**2;」の**演算子をpower関数に置き換えられる。
そうすればCに無い演算子があるように動作するのでは？

あらゆるソースに変換出来る言語ってのもイイな。
その言語で開発すれば、CにもJAVAにもVBにもCOBOLにも？変換できる様な。

>>37
何でそんなことするの？
マトモに使える物にするなら、yaccかbisonでパーザ書くでしょ
そうすれば好きな演算子定義し放題だけど

とりあえず30分以内に>>1がやりたいことを書けよ
HSP（もどき）を作りたいんでもいいし、新しいパラダイムの言語を提唱してもいいし
とにかく、雑談で終わるようにするな

新言語妄想系スレ

理想の or おすすめの or あったらいい 言語を書け
http://piza2.2ch.net/tech/kako/999/999958385.html
■■■いいとこ取り新言語の仕様を考るスレ■■■
http://piza2.2ch.net/tech/kako/998/998324855.html
コメントいらずの最終形態言語
http://piza2.2ch.net/tech/kako/995/995940761.html
２ｃｈが世に送る「氏ー言語」を作るぞ！
http://pc.2ch.net/test/read.cgi/tech/1008941525/
日本語ベースのプログラムを作ろう。
http://pc.2ch.net/tech/kako/1006/10067/1006761919.html
新言語を開発してやる！
http://pc.2ch.net/test/read.cgi/tech/1012050761/
完全日本語プログラム環境「う言語」
http://pc.2ch.net/test/read.cgi/tech/1008477170/
架空なプログラミング言語
http://pc.2ch.net/test/read.cgi/tech/1013278478/
2ch 指向言語を作るスレ
http://pc.2ch.net/test/read.cgi/tech/1014783034/
ジョジョの奇妙な言語誰か作ってくれ
http://pc.2ch.net/test/read.cgi/tech/1017967539/
【言語】diamondを作るスレ
http://pc.2ch.net/test/read.cgi/tech/1020596629/

>>39
そりゃ、言語を設計／実装するやつは定義し放題だわ。

ポインタ希望。
文字列は文字の配列として定義。

なんでもいいから早く2ch発の言語作ってくれよ・・

>>44
GikoBASIC/GikoForth があるじゃん。

>>44
多くの開発者はまともな物が出来たら2ch発とはしたくないはず

僕としては
・手早くGUIを使ったアプリが書ける
・ネットワーク使用も簡単に
・初心者でも難しくない仕様
・ｺﾝﾊﾟｲﾙして他の言語から使われることができる(?)
・ポインタを入れたい

>>47
・初心者でも難しくない仕様
これが他の全ての要件と反してる。

じゃあこうしたらどうだろう
＞・手早くGUIを使ったアプリが書ける
構文をシンプルかつスマートに。あるいは、略式構文を正規構文に変換。
＞・ネットワーク使用も簡単に
標準で関数を装備
＞・初心者でも難しくない仕様
インクルードorインポート処理は自動化
＞・ｺﾝﾊﾟｲﾙして他の言語から使われることができる(?)
ソースをXML化（？）
＞・ポインタを入れたい
…せめて>>4の意見を反映させてくれ。

ぜひ意見を求む

OOP でなきゃ名前空間のサポートくらいはしてくれ。
例えば MJ みたいなモジュール指向。
フラットに関数が増加していくのは Win32API や Perl だけでお腹一杯だ。

名前空間か…。

それって
A::cls();　B::cls();
を
A_NS_cls();　B_NS_cls();
と置き換えて誤魔化せるのではないか？

×誤魔化せる
○実現できる

１は夜更かししたのか？

>>1の「本気な人」は、本気で作ってくれる人だったのか…

>>1はどうしてポインタにこだわるの？

１　目指すは…最速!!!
２　最近ポインタを覚えた。
３　最近、ポインタに気が付いた。

どれなんだろう・・・

>>4
ポインタのときとそうでないときで、メンバ参照の演算子を変える必要があるの？
どっちも . だと不具合ある？

>>57
…無いかも。
確か、宣言から使用時まで辿れば良いのだったっけ。
「難しくない仕様」という１の方針に基づくなら、そのように決定？

人が少ない今のうちにつくれるところはつくっちまうか…。

既出だが、Cの宣言は初心者にはわかりずらいんじゃないかと思う。
//int型を指すポインタhoge
int *hoge;
//int型を返し、文字列の先頭ポインタを引数に取る関数を指すポインタfunc
int (*func)(char *str);
//char型のポインタを返し、文字列の先頭ポインタを引数に取る関数を指すポインタfunc
char *(*func)(char const *str);//ポインタはconst
なので、C形式の宣言文は却下したい。
ただ、１はポインタを使いたいと願っている。
つまり、上記より簡単なポインタ向きの宣言文を考えなきゃいけない。

//後ろにPを付けてみるテスト。
int Coffee P;
//int型を返し、文字列の先頭ポインタを引数に取る関数へのポインタ
int func P ( char str P );
//char型のポインタを返し、文字列の先頭ポインタを引数に取る関数へのポインタ
char P func P ( char const str P );//ポインタはconst

これで少しはましになったと思うがどうか？
見ている人がいたら意見を願う。

ん？
ポインタの位置がちがうからconstの動作を明確に定義せねばならんのか？
考えて無かった…const取り消しー。

>//int型を返し、文字列の先頭ポインタを引数に取る関数を指すポインタfunc
>int (*func)(char *str);

文字列の先頭とは限らないのでは？

ポインタ(仮にP)を実際にはどう表記するかはおいといて、
ひとまずconstを考えてみる。

//　constなcharを指す、constなポインタ。
//　これはポインタへの演算も、文字列への代入も出来ない。
char P Func P ( const char const str P );

//　charを指す、constなポインタ。
//　ポインタへの演算は不可。文字列への代入は可。
char P Func P ( char const str P );

//　constなcharを指す、ポインタ。
//　ポインタへの演算は可。文字列への代入は不可。
char P Func P ( const char str P );

これで初心者はしっくりくるのかな？
うーむ。よくわからんなー。

>>62
ごめん。そうだった。

>>56
多分4の
「ポインタは便利なものと勘違いしてる」
か
「低水準から抜け出せない男」
じゃないかなぁ(￣ー￣;)

ポインタを意識しないでプログラミング出来る言語の方が
親切でないかい？

どうしてもポインタがないと困る場面って？

無いほうがいいのかな？

じゃ、ポインタを激しく実行時チェックされる言語

どうもポインタは存在自体を論ずる必要があるようだ。
今度はそれとは別の仕様を考えてみる。制御文だ。

if文とwhile文とfor文は容易に想像しうる混乱を避けるため導入決定。
でもループ内での変数宣言などスコープ関連の言語仕様は後ほど。

break;とcontinue;はどうだろう？　確かPerlではラベル機能まで付加されてたが。
HSPにはあった気がするが…忘れてしまった。調べてみよう。
言語の簡単さと便利さ――――微妙な線だ。

ところで、do{}while;は本当に要るだろうか？
初心者が思わぬ使いかたをしそうな制御文、Ｎｏ．１な気がするのだが、気のせいだろうか。
うーむ。はじめのうちは教えなきゃいいのかな…。

ループ制御文は break next redo できぼん。
do while はなけりゃないでなんとかなるでしょ。

>>69
実装が面倒…でもないのかな？
初心者は実行時に落ちると混乱するからなー。どうしようか。
まあプラットフォームがWinだと聞いたから、
落ちても良いかなーと危険な手抜きを…ではだめか（ｗ

>>71
うむ。わかりやすい。ポケモン、君に決めた！（古
break;は現在のループからの脱出。gotoを仕様から排除する場合には、ラベル機能付きで。
next;は現在のループの末尾地点への移動。（もしあったと仮定するなら、）do{}while();も含めて、条件判断あり。
redo;は現在のループの先頭地点への移動。条件判断は、全くなし。
こんなもので良いかな？
しかし、予約語には古今東西のメジャーなキーワードを置いておきたい。
そうすると、ソースを読んでるときにcontinueなどという変数に出会わなくてすむはず。ｳﾏｰ

例外機構はほしいな。
Java みたいに全部 catch しないとコンパイルできないのも鬱陶しいけども。
無言で落ちるよりはスタックトレースでも吐いてくれた方が精神的によろしい。

>>73
＞しかし、予約語には古今東西のメジャーなキーワードを置いておきたい。
本当に*予約*語ですね？ :)

例外機構か…。HSPにも無い機能か…。Cでの代替手段がアレな機構か…。
うーむ。実装の手抜き、という１にも秘密な裏コンセプトから遠ざかっていく…。

＊予約語＊
つかっちゃうとこちらが混乱しそうです。

ストラウストラップはdo{}while;がお嫌いのご様子だったな。

新言語製作すれがまたーりしている‥‥‥！

>>77
　　　　　　（　´∀｀）　

//モナ増殖

//クラス無し
char P KillFunc ( char const str P) {
　　int lc; // LoopCount
　　const int mc; //MaxCount
　　for(lc = 0; lc != mc ++lc) {
　　　　StandardMonaLibraly::strcat ( str , "（　´∀｀）" );
　　}
　　return str;
}

//基本的な型のクラスあり
MonaString KillFunc ( MonaString str) {
　　int lc; //LoopCount
　　const int mc; //MaxCount
　　for(lc = 0; lc != mc; ++lc) {
　　　　Str += "（　´∀｀）";
　　}
　　return str;
}

一見、これのどこが新言語なのかと（以下略

/* ム板の皆様。こんな言語を作りたいので、協力してください */

１．Cをパクり、利用の簡単さを最優先させたような言語(GUI対応)です。
　オブジェクト指向、テンプレート、
　ガベージコレクション、実行時型チェック、と望みは多いかと思いますが、
　まずCをベースに仕様の決定と実装を優先させてみます。
２．すいませんコンパイラ作りません。
　構文解析=>Cのソースにコンバート。というだけの言語にします。
　単純に、Cのソースを吐くだけです。比較的、実装は簡単だと思います。
　ただし、処理速度はお手持ちの開発環境の最適化能力に依存します。
３．そこまで出来たら、ライブラリ作ります。
　「Win版、GUI対応簡易ツール == 十数行」にするために、簡単に使えるGUIライブラリを作ります。
　Cへの変換を行うついでに、言語特有の特徴にみせかけていた機能を勝手にソースに埋め込みます。

最終的には、メジャーな他言語コードを吐く、簡易記述言語を目指します。
そこで、ム板の皆様。当面の課題として、言語名を考えてください。お願いします。

ポインタの宣言は、

int* (*func)( int* (*proc)( int, int), int);

に対して、

*int *func( *int *proc( int, int), int);

とすればいいんじゃないか？もうちょっとPascal風にひねって、

*func( *proc( int, int) : *int, int) : *int;

とすれば、

pointer to function( pointer to function( int, int) returns pointer int, int) returns pointer to int;

という風に素直に読み下せる。

>まずCをベースに仕様の決定と実装を優先させてみます。

悪いとは言わないが、これをやっちゃうと後で構文拡張（つぎはぎ）で
どんどん汚くなるよ、perlしかり。
仕様部分ははじめからきっちり決めておくべきだと思う。
オブジェクト指向は後で考えるじゃなくて、実装するかしないかは今の時点で考えるべき

どうせ新しく作るんなら構文も斬新に。like this.

classHoge.funcHoge(foo, bar){
　(isTrue)?{　　　　　　　　　　　　// if
　　(0-9)~{　　　　　　　　　　　　　// for
　　}
　}:{　　　　　　　　　　　　　　　 // else
　　(tilTheEnd)~{　　　　　　　　　　// while
　　　><;　　　　　　　　　　　　　　　// break;
　　　<;　　　　　　　　　　　　　　　 // redo
　　　>;　　　　　　　　　　　　　　　 // next
　　}
　}
　retVal;
}

こいつ、Smalltalkerだな…

利用と実装が簡単で速度を度外視してもいいんなら型なしスクリプトが楽だろう。

そういえばあったね、VBScriptとかいうほとんど何でも記述できる凄い言語が。

とりあえず、構文を決めてくれ。
そうすりゃbisonでパーザを書いてやる。

>>10みたいなのは激しく面倒なので却下だが

個人的には宣言文がこうで、
*int *func(char const *str, const char *str);
*int hoge , hoge;
int *hoge , *hoge;
クラス(構造体)の定義がこんなかんじ、
class TypeName{ //<=これはどうだろう？
　*int
　　*func( *int *proc( int, int), int);
　int
　　nomber;
　*char
　　string;
}
使うときは、
TypeName xpbox;
で宣言して、
debugout(xpbox.nunber);
*TypeName pxpbox = &xpbox;
debugout(pxpbox.string[8]);
とかやって使う感じで考えてるのだが。
自分で言っててつっこみどころ満載だな（ｗ

＞　*int
＞　　*func( *int *proc( int, int), int);
*int
　　*func( *int *proc( int a, int b), int c);
間違った。ここはこう書く。

その激しくかっこわるいアスタリスクと意味不明な構文はなんだ？

*int hoge , hoge;
int *hoge , *hoge;
これなんか激しく無意味だと思うんだが。
最小の言語仕様になるように切りつめろ

int *hoge , *hoge; //うぁ。確かにこの構文、要らないじゃん（汗

酔っ払ってるか？

*int *func(char const *str, const char *str);
ほんとにこれでいいのか？
*char const str : str が const
*const char str : str への const ポインタ
tokajanainoka?

訂正。
+はポインタ*があるorないのどちらでもよいことを示す。
[]はカンマ区切りで並ぶこともができる要素。
…は[]の要素がいくつでも置けることを示す。

変数宣言時：
+型名 変数名[変数名]…;
関数宣言時：
+戻り値の型名 +関数名([引数型名]…);
これで戻り値にvoidがあれば、大丈夫かな…。

>>94
すみませんCに従います。引数の中で反逆しても良いこと無いしな…。

>>95 すみませんCに従います。引数の中で反逆しても良いこと無いしな…。
例外的な規則をいくつも作ることになり、
言語仕様がシンプルじゃなくなるって話だよ

ではconstの件は保留ということでひとつ｡
だとすると引き数も切り詰めるべきでしょうか？

const の話は、

*const char == const char *
const *char == char * const
const * const char == const char * const

こうだろう。

型クラスと型変数が使えるようにしといてくれ。

しぬな！
もちなおせ！

正規表現
イテレータ
テンプレート
スマートポインタ
自己記述性(lisp)

がﾎｽｨ

>>101
知ってる言葉を並べただけ？
自己記述性があるなら総称（テンプレート、Generics）はいらないし
そんな言語はGCが無いとやってられないから、スマートポインタもいらない。

そもそも、イテレータはともかく、スマートポインタなんてライブラリレベルでの話

諸悪の根源たるポインタはなくそうよ。

>>101
＞正規表現
＞イテレータ
＞テンプレート
本体に組み込まずライブラリで提供を推奨。

beginとendをサポートしてください。

テンプレートをライブラリで提供ってどうやるの？

そろそろ、パーザが書けるレベルまで仕様を上げてくれ

2chObj.ReadThreadとWriteThreadをサポートしてください。

ライブラリのような話はしてはいけなかったのか、、、
自己記述性とテンプレートがあっても良いと思うんだけど、駄目なのね
スマソ、、、

>>108
ダメじゃないと思うけど・・・

1 ライブラリは、言語仕様もマトモに決まってないのに議論のしようがない
2 自己記述性、テンプレート 採用するならどっちか一つだと思うが？

2については、両方サポートして便利なところある？
自己記述性はテンプレートも内包しちゃうので（ループとSchemeの継続の様な関係）
両方をサポートする意味が無いと思うんだけど。

もしよければ、Lispにどのようにテンプレートを使うと便利だと感じるか、
擬似コード書いてみて

うーん、lispベースなのではなくて、CあるいはC++ベースで。ある程度の自己記述的な部分は欲しいと思うのです。
例えば
int hoge = new int[5];
hoge.size
で、hogeの配列サイズを取得できたりとかね。

そうなると結局はすべてがオブジェクト言うことになるのかな？

もしかしたら、自己記述性ではなくて、自己記述的が正しいのかの知れないです、、、
無知でスマソ、、、

ポインタよりイテレータのほうがいいのか？・・

>>110
hoge の型情報を得られるのならリフレクションかもしれんが、
サイズは微妙だな。

サイズは new をオーバーライトして-4バイトに書き込む。

ポインタはやめれよ。

>>114
1がどうにもポインタに幻想を持っているらしいので、
必須のようだぞ？
擬似コードによる構文もポインタ使いまくりだし（藁

ちくしょう、生ポインタなんてあったらGC搭載出来値ーじゃんかよ！

1 なんかどうでも良いんだけどどっかに

ttp://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%2D1998

落ちてないかなー。

>>116
http://photon.poly.edu/~hbr/cs903/c++/C++-ansi.pdf

せっかく教えてくれたのに申し訳ないけど、落ちてこないよぉ(;_;

http://www.cis.temple.edu/~ingargio/refman.pdf
じゃ、こっち

ｷﾞｺBASICはどうなった？

>>1よ出てきてくれ。

仮引数リストと変数宣言の形式が違うのはどうして？
あと、可変長引数の実装も言語仕様に取り入れてくれ

可変長引数なんて、バグの元だろ。
そんなのより、Eiffelみたいな表明でも実装しれ。

>>121
汎用リストみたいなので代用しない？

>>122-123
Argument Objectとして、型情報と引数を同時に渡せると便利だな、と。
もちろん、実行時じゃなくてコンパイル時に型チェックを。

>>119、 蟻蛾�d

116はいったい何なんだ

>>10-12

>>127 ?

age

移植性のあるビットフィールド希望

>>130
元ネタがわかりやすいなｗ

for(int i;i != n;++i)
を
afor(int i != n)
に

>>132
構文を自分で書けるように設計すれば、
そんなの標準で用意する必要がないと思う

ってか、>>1は逃げたか？

キーワードstaticは関数内の静的変数宣言だけで使いたい
クラス変数とかは別構文がいいナ

>>1戻ってこいage

関数の宣言にnosideeffectキーワードを付けると、
副作用が無い事を明示出来るようにしてくれ。

んで、それを最適化に活かせれ。

>>136
そういうプロパティやアトリビュートってつけだしたらきりがないから
public/private
const
だけでいいと思うけどなー

ん？誰か呼びましたか？

>>98
const=定数=参照先の変更が出来るが、参照先の変数に書き込めない。
hold=??=参照先の内容は帰れるが、そのポインターの参照先を変えることは出来ない。
と分けて見ては如何？
意味が違うのに同じconstを割り当てているC++の設計者はセンスを疑う。
（でも策定時に議論済みなんだろうなー。どういう議論になったか知りたい。）

>>138
はいはい。偽１さーん。
さっさと夜逃げしてください。

>>139
>hold=??=参照先の内容は帰れるが、そのポインターの参照先を変えることは出来ない。
hold=参照先固定=参照先の内容は変えれるが、そのポインターの参照先を変えることは出来ない。
で委員じゃない？

>>139
いや、意味は違わないよ。
constである対象が宣言時のconstの位置によってわかりづらくなってるのが問題なだけ。

char const * const * a;

(((char const) * const) * const) a;

こうすれば、何がconstかわかるでしょ？
const char *・・・って書くからわかりづらいだけ

クラス内の属性宣言は何がデフォルトですか？
そして宣言が全部 p から始まるのはもうイヤです。

>>142
んじゃ、全部ブロックにするの？

alluse
canuse
notuse
みたいに、頭文字変えて文字数を揃えたい
宣言を見易くしたいのよ

言語名はObjectiveRubyがいい

MmnagoodC

↑Mona…鬱だ…

Object Monacalとか

クラス変数
インスタンス未生成で使える数学系関数
のサポートとナイスな修飾語きぼー

あの括弧の嵐に慣れればLisp系の言語使うだけで片がつくんじゃねーの？
自分で関数作ってなんちゃって独自スクリプト作るの余裕じゃん。

2ch発の
GUI対応で
簡単かつ
エレガントな
OOPL
（ポインタ付き）
神？

漏れは、ライブラリまでは面倒見れないけど、

>2ch発の
>エレガントな
>OOPL

仕様を上げてくれたら、
ネイティブコンパイラと、バイトコードコンパイラと、デバッグ要VMは作ってやる。
要するに言語処理系のベースになるところまでな。

>>152
マジ？そのネイティブコンパイラってオプティマイザ込み？

>>153
共通項の括り出しとか、末尾再帰の最適化程度なら出来るかもしれんが。
普通の商用コンパイラ並みのオプティマイズは無理だな

なるほど。
ネイティブバイナリの出力フォーマットはPE？ELF？
それともコンパイル済みのコードをリソースとして保持して
実行ファイルにはローダを作り込む？

Win用のバイナリで、
COFFにするか、直接PEを吐くかはまだ決めていない。
COFF/OMFが吐ければ便利だけど、他言語との連携を考えないといけないからな。

そうか。COFFを吐けばいいわけか。
エレガントなOOPLね。オブジェクト指向周りの設計が難しいな。
実際の所、プロトタイプベースの言語以上の柔軟性って思いつかないし、
実行パフォーマンスとのバランスを考慮すればC++が最良の解に思える。
でもそういう既成言語を踏襲するだけじゃエレガントの内には入らないんだよね？(ｗ

>>157
んー、漏れが考えているのはC#程度まではシンプルになった
C++がいいかな、とは考えているんだが。
ファイルベースのモジュールじゃなくて、シンボルベースにしたり、
今のC++の古いところを取り除いて。
ああ、それから、GCをネイティブで搭載したいな、とも。

C#かぁ。C#だと property とか delegate があるね。
delegate なんかは俺はエレガントとは思えないんだけど、便利ではある。
あと attribute もエレガントとは思えない。
でも、そういう特徴を除いちゃうとDじゃんって話になる。
もちろんそのまま取り入れるだけだったらC#じゃんって話になる。
そこはやっぱり差別化しなくちゃいけないよね。
templateの有無なんかはどう見てる？

まぁ、Dでもいいんだけどね。
それを言ったら言語を作る意味がなくなっちゃうしな。

attributeは泥臭いと思うし、delegateもいいアイデアがあれば違う形で、と。
別にC#を踏襲するつもりは全くないです
っていうか、言語仕様をこのスレで話し合ってくれ〜って事なんですが。

それから、静的型付けﾏﾝｾｰなんで、templateは導入したいけど、
C++そのままというのはちょっとイヤだから、いろんな言語を見て研究、と。
Java Genericsもイマイチピンと来ないし。

delegateは無くてもいいからeventはほしいなぁ。
フラグ値と列挙値は区別して。
プリミティブは従来のshort,longじゃ無くてint16,int32のように。

templateの魅力はinline展開されてこそだと思うけどその辺はどう思う？

eventってのはBCBの__closureみたいもののこと？
templateのinline展開は必ずしもコンパイル時にやらなくても、
JITを使うとして実行時の処理に任せるというのも手だと思うな。

templateの魅力ってインラインじゃなくて、
オブジェクト参照やvoid*を使ったポリモーフィズムじゃなくて、
タイプセーフを保ったまま総称を実現出来る事じゃないかなぁ

インラインで処理しない場合、バイトコード周りの仕様決めが難しくならない？

>>163
コンテナではそれも大きいんだけど（キャストうざい＆コンパイル時チェックできない）。
アルゴリズム側から見ると、ポリモーフィズムでも別にいいじゃん、って話にならない？

GenericProgrammingスレで出ているような技を見ると
templateがポリモーフィズムだけでお終いってことはないと思う。

>>162
delegateは関数ポインタのお化け（型）でeventはフィールド・・かな？
delegate型のメンバも作れるけど代入演算子が使えるとか、問題が多いからeventでラップする。

C#ってdelegate作った後にevent作らなきゃいけなくて、なんか2度手間のように感じてしまう・・・いい方法無いかな？

>>164
それはならないでしょう。
タイプごとに別に関数・クラス実体を作成するから、たいした問題では無いと思う

>>165
プログラマ側からの実現手段はどうでもいいんだけど・・・
特にインライン展開を導入するメリットが感じられないし、
そもそも、それが足かせになるようなクリティカルな要求に耐えうる
処理速度は実現できないだろうし。

それから、万が一オプティマイザを搭載する事になったら、
そのときに自動判断で展開するようにすればいい。
templateを無条件インラインにしちゃうと、
inlineキーワード追加しないとならないし、どんどん言語仕様がシンプルじゃなくなるでしょ

>templateがポリモーフィズムだけでお終いってことはないと思う。
それでも、テンプレートの本質はこれでしょ？
あのスレの話題はそれを発展させたトリックであると言うだけで。

ポリシーという考え方は新鮮だった、大いに取り入れさせてもらってるよ。

>>169
一般化された概念としてのポリモーフィズムとしてはそうだね。
C#/Java/C++などで言われるところのポリモーフィズムでは不足。
でもその辺を追究していくとHaskellになっていくような・・・。

文字列は言語側で用意？ライブラリ側？
Cのような単なるchar配列というのもなんだか使えないし。
C++のbasic_stringはSTLとあわせると強力だけど、パフォーマンス的にあれだし。
JavaやC#のように行くの？

>>171
テンプレートについては私自身勉強不足な点は多いんで、
何かいいことがあればどんどん書いてほしいと思いますが

>>172
本当にでbasic_stringのパフォーマンス悪いと思いますか？
参照渡しじゃなくて、コピー渡しを多用していませんか？

string型の実装は基本的にクラス（ライブラリ側）で、
言語によるサポート有りのC#/Javaの様な物を考えてます

そもそも、こういうミクロな話じゃなくて、
もっと言語のポリシーや構文を決定するマクロな話からしたほうがいいかと。
基本的に、質問じゃなくて、アイデアを提案してください
私が仕様を決定するのではなく、私は単なる１実装者でありたいので。

マクロな話としては、シンプルな実用言語、を希望かな。
新しいフィーチャーはなくてもいいから実用十分な機能があって使いやすいのがいい。
結局は、C#と似たり寄ったりになるんだろうけど、もっと文法はシンプルな方がいい。

とりあえず、言語にあわせてクラスライブラリを作るんじゃなくて
GUIフレームワークを最初に作り、それに親和性の高い構文を持つ言語とする
と言うのが理想かな。
どうせ2chの烏合の衆じゃ一般化された素晴らしい言語仕様なんて作れないだろうから

>>175
はい、喧嘩売るなら自分で実装してからにしてくれ。

>>175
前半部は同意
窓をサクっと書きたいね

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　循環するもの

これやってよ
http://pc.2ch.net/test/read.cgi/prog/961558082/l50

>>179
そういう方向に進むなら漏れの出番はないです

aforがあるならforeachもありだろ

結局誰もマトモに作ろうとはしてないってことで
★☆★☆★☆　糸冬　了　☆★☆★☆★☆

レスを見ながら各言語構文の要点整理をして案を練ってる私は一体…
暇人は帰れってことですか？（泣

とりあえず継承の構文はまだですよね？

>>183
継承って単一継承か、Javaの用に実装一つインターフェース複数にするか、
それすらも決まってないようです。

>>10-12の型推論は面白そうだけど、実装がちょっとめんどくさそうですね。
MLの型推論に関する文章読んでます。

mix-inできる静的型付け言語キボンヌ

>>185
mix-inの概念がよくわからないので、詳細ｷﾎﾞﾝ

制限された多重継承です。
多重継承と同じでインターフェースと実装を継承できます。
mix-inされるモジュールは通常のクラス定義と同じように
インスタンス変数とメソッドを定義できますが、モジュールは
スーパークラスを持たず、また、単体ではインスタンスを生成
できないと言う制限が付きます。
クラスは一つのスーパークラスと複数のモジュールを継承できるので
クラスを横断するような実装を再利用しやすくなります。

‥‥といふのが私の認識ですが間違ってたらつっこんでやってください。

class AClass {
public:
　foo();
}

class IClass {
public:
　bar();
}

class Class : IClass {
public:
　mix-in(Aclass)
}

こうするとClassは
Class : IClass
+foo()
+bar()
こんな感じになるって事？

>>187
mix-inの実装されてる言語の構文は良くわからないけど、こんな感じ？

// 継承不可能、インスタンス変数もメソッドの実装も可能
module SomeModule
{
hoho(){ write("HOHO"); }
}

// インターフェイスだけ継承可能、メソッドの実装は不可能
interface SomeInterface : OtherInterface
{
huhu();
}

// classは単一継承、他はなんでも可能
class SomeClass : OtherClass, SomeModule, SomeInterface
{
huhu(){ hoho(); }
}

>>188
>>189

両方よろしいかと思います。

>>188はRubyがそんな感じ（includeだったと思うけど）

多重継承と同じく名前の衝突の問題が出てくるのですが、
CLOS流：
　クラスやモジュール間に優先順位を持たせる。
Eiffel流：
　明示的にRenameする。
のやり方があると思います。

……個人的にはCLOS流が好きですが、静的型付けの好きなタイプの
ひとはEiffel流を好むような気がします。

言語仕様がちょっと無駄に複雑になる気もしますが・・・

名前がぶつかるところはどのクラスやインターフェイスから継承したのか明示的に指定するのはどうかな。

interface First{ void hoge(); }
interface Second{ void hoge(); }

class Class : First, Second
{
　void First.hoge(){ /* first hoge */ }
　void Second.hoge() { /* second hoge*/ }
}

みたいに。

>>192
C++流やね

>>191
ほんとの多重継承だとスーパークラスの探索がツリーになるので
イヤな感じですが、mix-inの場合はスーパークラスを持たないので、
クラスとスーパークラスの間にリニアに挿入するだけで済むと思います。
つまり単純継承とそんなに違わない。たぶん。
（でもインスタンス変数のベースアドレスのオフセット計算は必要か。）

>>192
Renameをいちいち書くのは面倒だし優先順位のやり方だとアクセスできない
メソッドやインスタンス変数が出てくる場合があるのでナイスなアイデアかも。

>>181
多重継承のせいで同じ基本クラスが複数含まれてしまう問題と、
インターフェイス内でメソッドの実装が行えない問題の
両方に対してなかなかいい答えを出してくれると思う。

class // 参照型、インスタンス化可能
struct // 値型、インスタンス化可能
interface // インプリメントするクラスによって変わる、インスタンス化不可能
module // インクルードするクラスによって変わる、インスタンス化不可能？
enum // 値型、{0,1,2,3,4}、演算結果はint（再代入不可能）
flag // 値型、{1,2,4,8,16}、ビット演算の結果はflag（再代入可能）、それ以外はint

これくらいあるとうれしい。
え？多すぎる？

クラス定義の構文なんかもいろいろな流儀がありそうだね。

>>196
漏れは>>10の様にclassキーワードをつけないのが好みだったり

つけないとコンパイラが大変じゃない？
漏れは変数にはvar、関数にはfuncつけたほうがいいとか思ったり、でもそれは面倒だとも思ったり。

未定義の識別子から始まる構文をもし使うなら、頻度から考えて
メソッド定義の場合に限定するとかしないと、
class
interface
module
なんかの区別がうまくできない気がします。

ところでstructってやっぱり必要？

たしかに>>10だとクラスのテンプレートメソッドと混乱しそうだなぁ。
でも、コンパイラ制作者ががんばれば出来ないことも無いと思うが

>>199
C#みたいにintやlongをstructとするといろいろ幸せなことが多いです。
確かintを継承したり出来ますよね。
あ、そうそう、演算子のオーバーロードもほしい、オーバーライドもあるとなおうれしい。

moduleの有用性がわからない。
classをmix-inすればいいんでないの？

>>202
mix-inされるクラスは他のクラスを継承してはいけないとか制限があるから、
ただわかりやすくするため、程度に。

メソッドの宣言しか出来ないクラス（に似たもの）をinterfaceと呼ぶのと同じ気分で。

演算子オーバーロードはいらないと思うな。
シンプルで敷居の低い言語であってほしい
何でもかんでもごちゃごちゃ入れちゃうと、
C++っぽくつぎはぎだらけに・・・

複素数や巨大な数を扱うクラスにはやっぱり演算子オーバーロードがホスィ・・・。
（こいつらの使用頻度自体が低いことはおいといて・・・）

お前ら本気で作る気かよ。
コンパイラ作るには仕様ががちっと決まっている必要があるぞ。
何スレ目までかかることやら・・・。

>>205
複素数や巨大な数のクラスは言語標準でサポートすれば

>>206
500過ぎても構文が決まらなかったらwikiを設置しよう

そう言われると500までに仕様を固めたくなるのだよ…ふふふ

>>207
言語仕様は小さいほうがいいなぁ。

>>209
禿て同感

>>209
複素数を言語でサポートするのと
オペレータオーバーロードを導入するの、
セーフティプログラミングの観点から見て、どっちがいいと思う？

言語名は是非guajavaで。

もちろん 2ch.NET で。

>204
スマートポインタも作れないよぉ。
他にもPOINT とか SIZE とか演算子が欲しくなるようなクラスが沢山。
演算子が使えないのはやっぱり嫌だなぁ。

>211
セーフティ．．．
演算子のオーバーロードってそんなに危険？
型変換演算子以外は別に問題ないと思うけど。


ところでこの言語のコンセプトって何？

個人的にはテンプレートライブラリが作りやすい言語がいいな。

スマートポインタって・・・ポインタありなの？

>>214
39はGC搭載したいとか言ってなかったか？
生ポインタはそもそも入れるつもり無いと思われ

>セーフティ．．．
多人数開発での保守性といった方がいいのかな

>>215
ん？ポインタ無し？

まあ、それでもイテレータが使えれば十分なんだけど
演算子が定義できなきゃそれも無理だ。

演算子は算術演算とビット演算だけオーバーロードできるようにすれば
それほどの問題はないんじゃないかな？
cout<<みたいな変な使い方さえしなければ。

インデクサもあればコレクションが作りやすいけど。

age

パーサ書くのと文法考えんの面倒だから前置か後置にしよう。

パーサは39が書くから構文をみんなで考えようって話じゃないのか？

後置ならDiamondスレでやってるからがんばれ

前置や後置は初心者にやさしくない。
それより GUI フレームワークを考えるべきだと思う。
Windows 限定なのか Swing などのようにマルチプラットフォームを目指すのか。

>>223
Win限定でいいんじゃないかな、とか。
いや、わたしゃWinしか知らないもので。

Window a;
このくらいの打鍵数で窓を開けさせてくれ！
初心者はこれくらいが限界だよ！

となると Windows のコントロールを使いやすいようにラップするのが基本的な作業になるね。
個人的には VCL ライクだと使いやすくていいけど(ｗ

一番問題なのはスレッディングモデルかね。
ウェジェットにスレッド化の属性を付けてやって
クリック一つでマルチスレッド処理ができればいいが
そんなに簡単なパターンばかりじゃないしな。

VB/Delっぽいかなぁ・・・
GUIビルダとそれを接続するイベントモデルを作って、
コード上から(Windowsの)コントロールを操作するコードを
完全に切り離すというのはどうだろう。
ってそれは幻想だよなぁ。

結局ソースからさわる必要も出てくるだろうし・・・

>>142-144

Classname BaseClassname {
　　allcls int data1; // == public static int data1;
　　canins int data2; // == protected int data2;
　　notins int data3; // == private int data3;
}

？？？？？？

class Class
{
　public // ブロックも可能
　{
　　int field;
　　void method();
　}

　private char field2; // もちろん1行も可能
}
ダメ？

あと書き込みはprotected、読み込みはpublicな属性もほしい。
俺はreadonlyって呼んでたけど、C#で別の意味で使われちゃったね。

「宣言の文字数が全部そろってて」
「頭文字が違う」
の実演テストしてみただけです…。
でもpublicとかに慣れてるせいか自分じゃ見やすいのかよくわかんない…。
しかも等幅じゃないからインデント崩れてるし…。

別にallclsキーワードは本気ではないですよ。
ただちょっとstatic宣言の代用にclsとinsを思いついたので。

javaファイルを吐き出す簡単なＣもどき作ってます。
*a++ = 0;
*a = 1;
と
a[0] = 0;
a[1] = 1;
の上って必要？あんまり上が必要になったことないのだけど・・・
下だけじゃだめ？

http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html
ここにJVMをターゲットにした言語山ほどありますね。。。

>>231
そっくりなコードをさっき別スレで見た気がする・・・
場合によって違うじゃん。
C++的にはイテレータって概念が浸透してるから上のほうが主流だろうけど、
C的にはどっちも同じくらいの頻度で使うんじゃないの？
ランダムアクセスが必要なら当然下になるし。

すみません。jvmをターゲットにしてるのにポインタ操作っておかしいですね。
（下の話につなげたかっただけ）
ほんとは8086ファミリーがターゲットです。。。

>>232
やっぱみんな下よく使うんですね。
私はランダムアクセスは別に変数用意＋キャストしてやってる気がする・・・

>>232
はう、混乱してる。上だとおもってしまた。上が必要な時は
変数用意＋キャストしてプログラミングしてる気がします。
下だけじゃ駄目っすか？

別に下があれば上はなくても文法上は困らないけど。
読みにくくなることはあるだろうね。

>>236
なる〜ｻﾝｷｭ。じゃあ、下だけにしよっと。

今までちょっと作ってみた感じでは
Ｃへのトランスレータ＞8086インタプリタ＞＝JVMコンパイラ
＞8086コンパイラ
の順で楽だと思います。これからは.NET対応が一番幸せになれそう。

>>229
propertyでset/getでgetしか定義されてないなら読みとり専用。
これじゃダメなの？

>>237
何が言いたいのかｻﾊﾟｰﾘわからんのだが
8086インタプリタってナニ？
エミュレータ？
しかも、楽とか・・・
何が言いたいのかわからん

>>229
ああ、ごめん、読み書きで属性変えたいのね。

public property int i {
　public get {
　}
　protected set {
　}
};

こんな感じって事？

>>238
んや、それで桶です。
おれっちの考えたのにはプロパティはなかったんで。

ところで
int hoge( string arg ){ return hage; }
void before hoge( string arg ){/*hogeの呼び出し前に呼ばれる*/}
void after hoge( int ret ){/*hogeの呼び出し後に呼ばれる*/}

みたいなのは、どうでしょうか。
hogeをサブクラスでオーバーライドしたときは、
そのサブクラスのhogeが呼び出される前後にbefore hogeとafter hogeが呼ばれるです。

>>241
それってクラス定義がかなり汚染されませんか？
inner関数やlambdaを導入するとかで解決できそう。

>>240
241の前半は勘違いなんで無視してください。
そういう記述が出来ればなおいいです。

>>241
ああ、違うか、ごめん
DのDBCですか？

なあ、もうallinsでよくないか？

>>244
あんまり深く練ってなかったんで、
あったらdebugとか便利かなと思ったんですけど、
> hogeをサブクラスでオーバーライドしたときは、
> そのサブクラスのhogeが呼び出される前後にbefore hogeとafter hogeが呼ばれるです。
この部分は撤回です、挙動がおかしくなるです。

DBCは、機能自体は知ってるんですけど、
実際どのように実装されているんでしょう？

DBCの表現方法は言語によってまちまちですね。
debug時にだけ有効になるassertがあれば、特に他に言語サポートは必要ないんじゃないでしょうか。

>>247
http://pc.2ch.net/test/read.cgi/tech/1003674814/21
記述形式がこれと似ていたのでそうかなって

C系の関数の書き方だとこちらのほうが受け入れやすいかも。
漏れは別にいらない気もするけど。

int func()
{
　in{}
　out( ret ){ assert( ret>0 ); }

　// 本体

　return 1;
}

>>241
いっそのことaspectキーワードを入れてしまうとか。

>>249
それだと、継承後時にfuncをオーバーライドしたら失われてしまうでしょ

>>247
D 言語がよりモダンな構文だと思う。

D言語ドラフト一応読んだよ
http://pc.2ch.net/test/read.cgi/tech/1003674814/

returnやめてEiffel式に暗黙のresult変数への代入にしませんか。

・returnだと値を返すためだけにジャンプの使用を強制される
・複雑になると戻り値用の変数はどうせ宣言しないといけないので面倒
・構造体などで呼び出し元が領域を確保した場合それをそのまま使えて効率イイ

関数からの脱出はラベル付きbreakの一種にしてbreak 関数名; にしてしまえばreturnは不要に。
何なら「result = X; break 関数名; 」の構文糖として「return X; 」も残せばいいし。

いろんな言語に精通している人が仕様をまとめてくれないかなぁ、と思います。
マジで

>>253 break 関数名;
これはいいかもなぁ
スタックフレームを一段上に上ると言う意味で統一も出来てるしね。
resultへ代入はどうなんだろ。
予約語がどんどん増えていくよな・・・

>>253
Pascal 式 VB 式とも言う。
初心者向けを考えるとよいかもね。

＞構文糖として「return X; 」
これは要らないと思う。二重標準は良くない。

ラベル付きbreakというか、ラベルってあった方がいい？

int func()
{
　goto l;
　foreach (...) {
　　int i = 0;
l:
　　print(i)
　}
}

こういうブロックの内側へのgotoやbreakの実装がめんどくさそうです
というか、今のところうまい手が想像つきません

81と253を取り入れた関数の例。

Max (X: int, Y: int): int
{
　if(X > Y)
　　result = X;
　else
　　result = Y;
}

ぶら下がりif問題を除くためAda風にしてみる(w ←半分冗談です

Max (X: int, Y: int): int
{
　if(X > Y) {
　　result = X;
　else
　　result = Y;
　} if;
} Max;

>>255
resultは予約語である必要性はありません。
関数がvoid以外のときだけ有効な暗黙に宣言されるローカル変数ってことで。

Ada 好きだけどタイプ量が増えるのが難点。
あなたとランデブー。

>>257

ブロックの中から直後に移動するbreak
ブロックの中から直前に移動するretry (←Eiffel風。Ruby風ならredo)
ループを進めるcontinue

これらを全てラベル付きでも使えるように、
つまりラベル付きブロックで囲えばretry/breakで脱出限定で好きな位置に戻れる/進めるようにして
尚且つそれらの構文糖としてgotoを脱出方向のみ認めればいいと思うのですが、いかがでしょう。
( ローカル変数よろしくラベルもブロックの外からは見えなくしてもいいかも )

gotoは無いとyacc等のコード自動生成が困りそう。

>>260の
>gotoは無いとyacc等のコード自動生成が困りそう。
の意味がわからないんですが。
なんで、困るの？

この言語を対象としたyacc系コード自動生成が面倒ってことでしょ。
遷移しまくるから。

単にgotoで状態遷移を行うソースを吐くタイプのyaccを知っているってだけなんですが…
そういうゲームブック形式のコードを考えると必要な気がして。

goto L2;
L1:
goto L3;
L2:
goto L1;
L3:

これを先に述べたbreak/retryだけで書こうとしても辛い気が…

A: {
　B: {
　　break B;
　　C: {
　　　break A;
　　}
　}
　retry C; //これはCブロックの内側に置かないといけない
}

あ、やっぱ脱出文だけではgotoの代わりにならない気がしてきた。

しかし、Java版yaccも存在するということは、無くてもいいのかな、
というか、明らかにスパゲッティなので無くした方がいいのでしょうけれど…

>>260
脱出方向のみで進入禁止なら楽ですね
breakとretryについては、ラベル付きなら同意語になると思うんだけど、
breakなら後方、retryなら前方と限定するということですか？
別の語でまとめてもいい気がするけど。

>>263
あー、なるほど。
ラベル付きbreakってブロックに名前を付けるんですか。
てことは、任意の位置にラベルを挿入できないと考えていいんですよね

>>264
ええ、「ラベル付きブロック」は、ブロック全体に名前を付ける意で、
ラベル付きretry/breakは、そのブロックの内部でのみ有効、って感覚で書きました。

参考までに、Adaなら、ラベル付きブロックは 「LABEL: ブロック」 で、goto用のラベルは 「<<LABEL >>」と書き分けます。

ifとかforとかwhileとかのブロックの名前はどうすんだ？

LABEL: if(...) {...} か if(...) LABEL: { } のどっちかでしょう…
Adaに倣うなら前者でelse節も含めてif文全体に名前が付く感じかな？

>>251
遅レススマソが。
俺も最初はオーバーライド可能にしたほうがいいと思ってた、
でもよくよく考えると、オーバーライド後も条件が同じとは限らないし、
そんなときにベースクラスの条件がしゃしゃり出てくるのはどうかと。

たとえば、正の数しか受け取れないメソッドを拡張して、
負の数を受け取れるようにすることもあるかもしれない。

>>269
んー、継承後も要件を満たすことが保証されているかが重要なんじゃないかな
そもそも、オーバーライド後に動作が変わるなら前件・後件なんか設置しないでしょ

これって>>1は作らんのか？

>>1が逃げたからスレ再利用中です

ラベルの記述方法ですが、
label (ラベル名) 名前がつけられるコード
を提案したいです。
ifやfor同様に”名前がつけられるコード”は単文でも複文でもかまいません。

label( OUTER_LABEL )
　if (...) label( IF_LABEL ) {}
　else label( ELSE_LABEL ) {}

少しくどいですが、ifやforなどと同じ構文で扱えたほうが文法上の一貫性も取れるしコンパイラも楽じゃないかと思います。

gotoを実装するかどうかはわかりませんが、
goto NAME;
とすると
label ( NAME ) hoge
　　　　　　　↑ここにジャンプ、hogeが空文でなければ実行される。
という感じで。
この場合gotoはラベルに飛ぶというよりも、名前がつけられたコードに実行を移すイメージになります。

>>273
if節とelse節に別の名前を付ける意図がわからないです

>>258のAda風の
if (xxx) {
　;
else
　;
}

これならlabelを自然に入れられるね。
こうなるとifの構文をちょっと考えたいかな。

>>270
たとえばあるライブラリで、double Power( double x, double y );
が x>=0 && y>1という条件を課していた場合、
気に入らないからこれをオーバーライドして yに任意の実数が与えられるようにする、ということは出来ないということですか？

>>274
if節とelse節に別の名前をつけてるというより、
ifとelseで実行されるコードにそれぞれ別の名前をつけてるんです。

label ( OUTER_LABEL )
　if (...)
　　label( IF_LABEL )
　　{
　　　retry IF_LABEL; ブロックのはじめからやり直し。
　　　retry OUTER_LABEL; ifのはじめからやり直し、比較も行い、場合によってはelse節へ。
　　}

>>241
それってテンプレートメソッドパターン使えばいいんじゃないの？

named_statement : symbol ':' statement
named_statement : symbol_id '(' symbol ')' statement

どっちでもいいんじゃないかなって思います

>>274
追記です。
別に特殊なことをしてるわけじゃなくて、
Adaの文法はよくわかりませんが、

OUTER_LABEL: if(...)
{
　IF_LABEL:{
　}
　else
　ELSE_LABEL:{
　}
}

これと同じことです。
やることは同じなんですけど、
LABEL:
よりも
label(LABEL)
のほうがコンパイラも楽だし文法上も一貫してない？というだけの話です。

>>278
279は一歩出遅れ（＾＾；
突然新しいシンボルが来るよりも"label"が来たほうがコンパイラは作り安くないですか？

labelの表記方法は特に問題じゃなくて、

名前を
・ブロックに付けるようにするのか
・文につけるようにするのか
こっちの方が重要かな、とか思ったり

>>281
文に1票

文に１票入れたいところだけど、

名前をブロックに付けるようにすると、
それを一般化して関数もブロックの一種として扱えるし、
ブロック自体をオブジェクトとして扱うのに便利・・・かな。

なにか、結局は今あるＣの構文＋ｎ重ループの脱出＋アンワインドプロテクトくらいで落ちつきそう。

>>283
面白そうだけど、inner関数作ったとして

void hoge()
{
　void hage(){}

　hage(); // hageを呼ぶ。
}

名前つきブロックは書かれた位置で必ず実行される。
inner関数は呼ばれなきゃ実行されない。
という違いをどう乗り越えたらいいだろう。

continuationがｷﾀ━━━(ﾟ∀ﾟ)━━━!!!
ってところでしょうか

ブロックはすべてinner関数に展開されるようにして、
if (...) then : {
　retry then;
}

と言う記述は

void then() {retry then;}
if (...) then();
のsyntax-sugarとする、とかはどうかな。

ブロックと単文を一切区別しない文法がいい。

try hoge;
catch(...) huge;

とか

int func(void) return 10;

とか。
もちろん文法上可能というだけで、可読性からみてブロックにしたほうがいいところは自主的にブロックにするだろうけど。
ラベルも、ブロックといわず一切の文に適用できたほうがいい。

>>287
ブロックをインナー関数にするより
インナー関数をブロックにしたほうが良くないかな。
void inner_func( int a ){}
は
if (false) label(inner_func){ int a/* = pop() みたいな*/; }
のシンタックスシュガー

>>287
それはどうだろう
関数はそのままブロックの機能すべてを包括できるけど、
ブロックは常に真とは限らない。
たとえば、引数や戻り値がある物とか。

どちらか、では無く、ラベルはブロックと文の両方に付けられるようにすればいいのでは？
プラスして関数名でも break/retry可能にしておけば特に困らない気が。
( 関数名でbreakできるなら戻り値はresult変数で… ←まだ言うか )

そのブロックですけど、Ada式だと全ての制御文が end XXX; で終わるので、
C/Pascal式の「{ }で囲ったところが単文扱い」では無く
「{ } も含めて制御文の構文」となって、{ } は強制でかつ「ひとつの制御文に一組だけ」になりますね。
>>288とは逆になりますが、こちらの方がぶら下がりelse(catchも?)問題が無く安心できます。

if( ... ) { ... else if ( ... ) ... else ... };
try { ... catch( ... ) ... };

しかしこれだと開始の { が冗長なので、Adaの方が(タイプ量は別にして)スマートに思えて来ます…。

if ... then ... elsif ... else ... end if;
begin ... exception when ... => ... end;

ブロックも文として
if ( ... )
　文;
elsif ( ... )
　文
end if;

これなら比較的シンプルでスマートかな

ifとelseは対等なのか(C系表記)、それともelseはifに従うのか(Ada系表記)ってこと？
Ada系のほうがよさそうだけど、それを無理やり{}に押し込めるのは難しいね。

test(exp)
{
　true:{}
　false: test(exp2)
　{
　　true:{}
　　false:{}
　}
}

とか問題外かな。

>>293
それだったら、条件式は
cond (boolean-expression)
{
true : syntax
false : syntax
}
１つだけになるのがいいのかな。

cond(bool)でif〜else
cond(int)で従来のswitch〜case

面白そうだけど、ちょっとした条件式がえらく長くなりますな。

test
{
　if (exp0):
　if (exp1):
　else:
}
上から順番に調べて最初にexpがtrueになったところから実行。
switchと統合できないからだめか・・・

switchも考えた方がいいかも。Cのそれはラベル扱いなので書き間違えてもコンパイル通るし。
294-295は、Pascalのcase文風ってこと？どちらにしても条件式≠ラベルにして欲しい。

参考までにAdaだとこんな感じ。複数の文が来ても問題無いようwhenが付いてます。
case ... is
when ... => ...; ...;
when others => ...; ...;
end case;

cond(EXPRESSION){
when(CONSTANT)
　...;
when(...)
　...;
}

何か冗長…Cの制御文は条件式に ( ) が付くけど、あれ無くせませんか…？

:label: cond EXPRESSION
when CONSTANT
　single-syntax
when CONSTANT
　single-syntax
others
　single-syntax
end cond;

別に、whenじゃなくてもいいけど。
ブロックが式なら複文を受け取る必要性が無いと思うので、
こんな感じでどうか。

else ifさえ考えなければ

if ... { ...; else ...; };
cond ... { when ...: ...; else ...; };

でおっけーな気もしますが、else ifを考えると

if ... { ...; else if ... { ...; else ...; }; //複数開始括弧が
if (...) { ...; else if (...) ...; else ...; }; //意味的に同レベルの条件式が中括弧の中と外に

…ので、難しい…Pascal/Adaだってendと対応するものが複数ありますが、中括弧を使うと浮き彫りになってしまいます。
>>297式がいいような気もして来ました。

----if----
if {
　when X == 1 : ...;
　when X == 2 || X == 3 : ...;
　else: ...;
};
----switch----
if X {
　when 1 : ...;
　when 2, 3 : ...;
　else: ...;
};

複文を受け取らないのはもう一つ理由があって、
条件を非fall-throughにするためだったり

てか、やっぱりifはcond/switchとは別に必要ってことで

fall-throughってbreakを書かないと下まで行ってしまう奴ですか？
僕もwhen節/else節はどれか一つしか実行されないつもりでいましたけど…。
Adaがwhenを明記することで複文記述可能とbreak不要を実現している以上真似しない手は無いかと。

if X {
　when 1 :
　　puts("○");
　when 2, 3 : //X = 2 の時 ×と□だけが表示される
　　puts("×");
　　puts("□");
　else: ...;
　　puts("△");
};

>>298
みんな:は便宜上使ってるだけで、必ずしもラベルのように扱うとは限らないと思う。
実際やるとしたら
case 0:
が
case (0) {}
だろうが、わかりやすいほうになると思われ。
C#のようにラベルとして扱いつつもbreakを忘れるとエラーという道も。

漏れが送信エラーで20分もかかってる間にとっくに話は進んでた・・・鬱

>>303 はどれか一つしか実行されないつもりでいましたけど…。

それは承知しています。
ただし、ブロック化していない複数の式を一つの処理単位として扱うのは不自然な気がするので。

>when 2, 3 : //X = 2 の時 ×と□だけが表示される
>　　puts("×");
>　　puts("□");
>　else: ...;
>　　puts("△");

puts("□"); の後、暗黙で（Cでいう）breakしちゃうのはどうかと思うので。
各節は一つのsyntax/blockを受け取る様にすれば自然かな、と。

>>306
了解です。
しかし、Pascalのcase文がまさにそれなのですが、実際使うとbeginとendがうざいです。

case X of
1:
　Write("○");
2, 3:
　begin
　　Write("×");
　　Write("□");
　end;
else
　Write("△");
end;

同じレベルの処理のはずなのに、複数の文があるというだけでインデントされ前後に2行無駄な行が…

caseにbreakの機能を追加
そして
case A or B
を許してくれ

>>307
なるほど・・・
確かにウザイですね。

when 〜:
　puts("1");
when 〜:
　puts("2");
　puts("3");

だとパーザ書くの大変でない？

俺は普段から
case 0:
　{
　}
　break;

だから、break書かなくていいだけでも十分楽チンとか思っちゃうんだけど。

when XXX : の XXX の部分も考えると面白いかと。
Pascal/Adaみたいに複数書き並べられてさらに部分範囲も可能なのがイイですね。

when 2, 3, 5..10 :

個人的に考えているのは、switch文をクラスの種類判別に使えないか？ということ。
仮にOBJECTが全ての基底クラスであるObjectクラスへのポインタもしくは参照として>>303風に書くと

if OBJECT {
　when Integer :
　　cout << (OBJECT as Integer).ToString;
　when String :
　　cout << (OBJECT as String);
　else:
　　cout << OBJECT.ClassName;
}

ifならwhenよりisのほうがしっくり来るとおもへり。

if XXX {
　is 0:
　　doSomething();
　is 1:
　　doAnything();
　else:
　　doNothing();
}

>>313
>>300のような記述（ifとswitchをそっくりに）を許すならisはあわないと思われ。

// 従来のif
test //漏れはtestがいいです（；´Д`）
{
　when exp:
　when exp:
　else:
}

// 従来のswitch/select/case
test( exp ) // 任意のオブジェクトが可能。
{
　when value:// 定数でなくても可能。たとえば文字列
　when value:
　else:
}

"is" "as" は型キャスト演算子に取っておきたいです…C#とかObjectPascalと同じように。

test 式　{ when 値: ...
if 式 { when 値: ...
case 式 { when 値: ... Ada風
select 式 { case 値: ... BASIC風
switch 式 { case 値: ... C風

書き並べて見ましたけど、やはり"if"がしっくりと。でも他の言語で使われている組(下3つ)のどれかでもいいな

個人的にはswitch/caseが・・・（C派なので・・・）

if文とswitch文は統合することになったの？

C系言語なら

if - {
} else if - {
} else{
}

switch - {
　case A
　　;
　case B or C
　　;
　default
　　;
}

とかがいい。breakいらない。だから、たのむから、下に落ちないで。

ifならwhenじゃなくてthenだとか言ってみる

とりあえず、test〜は却下かと
手抜きUnitTestを書くときtestメソッドで全部やりたいよ

いま検討しているswitch文だと、そのブロックを特殊な物として扱うことになるね
ブロックの中まで制御構文なんで、
そのブロックをオブジェクトとして扱えない ＝ 状況に応じて取り替え出来ない
とか思ったり。

>>320
Testメソッドにしてください。

>>321
ここまでの流れを見て
ようやくCのcaseがラベルなのか分かったよ

文字ケースって決まってました？

・文字ケース同一視(Pascal/BASIC) or 区別(C系)
・命名規則 AbcDef(Pascal) or Abc_Def(Ada) or abcDef(Java) or abc_def(C/C++)

文字ケースを同一視する or JavaかC/C++の命名規則を用いる場合、"Test"で逃げるわけにもいきませんよね…

無知でｽﾏﾝが文字ケースってなに？

命名規則は・・・人に出すときはPascal式、
自分の文はAda式で書いてるかな

>>324
大文字小文字は区別がイイ。
命名規則は公開はPascal、内部やローカルは勝手にしなさいって感じ。

・先頭が小文字だった場合大文字に
・アンダーラインの直後を大文字に
・小文字と大文字が並んでいたらアンダーラインを挿入
( 全部小文字で予約語が書かれていた場合、それは変換しない )

内部的にこういう変換をかけてくれたら、>>324の4つの命名規則のどれで書いてもいいことになり(内部ではAda式で保持)
他人のライブラリを使う時命名規則でイライラすることが無くなる…とか提案してみる。

大文字小文字区別して、命名規則はガイドラインでいいんでない？

もし.NETクラスライブラリを使うつもりならそれにあわせたほうがいいと思う。

なんで.NETが出てくるんだ

>>330
手っ取り早く再利用。

.NET対応にしちゃうと言語のモデルがある程度限定されちゃうんじゃない？
Eiffel#が多重継承できないとか言う話もあったし

この時期新しい言語の話をすると必ず.NET対応しろって言うﾔｼが出てくるな

.NETのせいで話が止まってしまったのでネタ振り。

メソッド定義は void Func(int Arg); よりも Func(Arg: int): void; がいいです。
根拠は、実装箇所でクラス名を付ける時 Class::Func(Arg: int): void と先頭に付ければいいから。
ObjectPascalで procedure Class.Func(Arg: Integer); ってわざわざprocedureの後に書かないといけないのは嫌です。
( "::"やめて"."で統一すべきかも )

加えて>>81で書かれているように、*とconstを全て左からかかるようにすれば、非常に素直に読めます。
C言語ポインタ完全制覇の受け売りですけどね。

例: Func(A: * (X: int): real, B: const string): * (X: int): real;
( Funcは「整数を取り実数を返す関数へのポインタ」と「定数の文字列」を引数に取り「整数を取り実数を返す関数へのポインタ」を返す )

>>334
よくわかんないんだけど、このスレって流れいくつあるの？
ポインタを推進してた>>1は逃げたし、
実装すると名乗り出ている>>39はポインタなしでGC搭載でしょ

>*とconstを全て左からかかるようにすれば
Cと微妙に違うくせに似てるのがｲﾔﾝな感じ

age

ageてなかった

>>334
JavaやC#のように宣言と定義を同時に行う形式じゃダメなのかな？
ObjectPascalの様に分ける必要ある？

procious.1


this.(:)3|project(i)　4(i)=5(i)
　〜 この生続き 〜　

　　この前の朝の NHK教育 みんなの手話、よかったよ。よかったらみてください。
　再放送は 月曜日午後 1 : 05 〜 1 : 30 。  感化を深めて、さんこうにしてください。

ｵﾜｯﾀﾅ（;´Д`)y-~~

まだだ、まだおわらんよ。

結局、この手のスレは積極的にコーディングする奴が牽引してかないと
各々自分の理想を語って終わりになるような。

1はどこいった？

復活を期待して…あげ

>>343
　　　　　　つくってくれるひとはいそうだけど、どんなんつくるか、まだあまりきまってない

>>343
でも今のままでは、言語仕様が統一される気配もない。
作れる奴がまず言語仕様と実装を提案する形で公開すれば、もっと具体的な
議論ができる。
今までの経験からいって、「みんなで作ろう」型プロジェクトがうまくいった
試しがない。
「こんなん出来たけどどうよ？」型プロジェクトだけが現物を手にできる。

39がもっと仕切ってもいいと思う

ごめんねー、39も結構名無しで言いたい放題言ってます。
ただ、あんまりいろんな言語に明るくないので、
そんなに発言が出来ないだけナリ

>>347
とりあえず、いろんな言語で「〜がある・ないからダサイ」っていう発言結構あるじゃない
皆さん、言語仕様とかにこだわりがある人も多いようなんで。
だったら悩みを（ある程度解消できる）素晴らしい言語仕様を考え出せるんじゃないかな、と。
日本初の言語はおもちゃがほとんどなんで、せめてメジャー所と張り合える位には素晴らしい物を。

ちなみに、私はC++/C#/Scheme/Perl位しかマトモに扱えないんで、
どうしても考えがC#よりに偏りがちです

315からの続きで、
こんなの提案
switch
{
　when exp0:
　when exp1:
　else:
}

switch文内にwhenが1つか無い状況の省略記法として
if (exp) // elseは使えなーい
も残してもいいかと

早い目に決めといた方がいいのは

ターゲット
ポインタ有りvsＧＣ有り
静的型付けvs動的
文法Ｃ風味vsオリジナル
定義宣言同時vsヘッダーとソース分離

決めない方がアイデアはいっぱいでてくるけど・・・

>>352
漏れはポインタは無くていいと思う。
C++で十分満足してる。

GC/静的/*/同時 で。

GC：単に実装してみたいから
静的：好み

が理由です。

>>351
そのswitch構文だと、後に続く{}はブロックじゃないんですよね？
ラベルとしてもブロック内側へのジャンプはなしの方向なので、
実現できないし。
switch構文だけ特殊化するの？

>>355
forと同じでswitch部分はブロック内にあると思ったらいいかも

>>353
ポインタが非ＯＯ言語とＯＯ言語の境目な気がする。

>>354
genericsの話もでてきてるし、このスレの人は静的好みなのかな？

問題はラベルだとFall throughになっちゃいます。
やっぱりあきらめて特殊構文として扱う必要があるのかな

>>358
#define when break;case
でいいんじゃない？

>>359
なんだそれは

>>360
Ada風ってこと

#defineのことだ

>>362
Cで言うなら

GC/静的/Cベースオリジナル風味/同時

って言うか俺はネイティブコンパイラ作る知識も経験も無いから、
おおむねで39の要望どおりで

宣言の順序が、Pascal/Ada風( Var: Type ) なのか C風 ( Type Var ) なのかも早いうちに決めた方がいいかと。
上で色々言われているように各種メリットはPascal/Ada風が上。しかしC風に慣れている人は多いかな？
僕はPascal/Ada風を推します。

ちなみに352のアンケートには「GC/静的/外見C実質Ada/同時」を希望。

>>365
Pascal/Ada風だと、UMLマッチ度も高いね
でもstaticとかreadonlyみたいな修飾子はどんな形でつくの？
あと、別スレで見たんだけど、同じ順番のVB（Var as Type）は変数を複数同時に宣言したときの初期化が面倒らしいんだけど、解決の方法はあるかな。

a, b, c : Integer
宣言と初期化を同時に行うのは

a = SomeClass.new : SomeClass;
となるのかな？

Adaなら A, B : Integer := 0; ってやると両方ゼロに初期化されます。VBだとできないんでしたっけ？

修飾子は…constはAdaなら A, B: constant := 10; (Integerであることは推論される) でした。
constant Integerって明記してもいいですけど。

readonlyみたいなのは…前か後しか無いでしょうね。

readonly A: Integer := 10;
A: Integer := 10 readonly;

Pascal/Ada風には宣言が常に名前で始まり名前の桁が揃うというメリットもあるので、それを活かすなら後ろかな。

うう〜〜名前がそろうのは魅力的だけど修飾子がうまくつかないねぇ〜〜

readonlyはconstで代用できるんじゃ？
A, B : Integer := 0;
この形式はどうだろうねぇ。
クラスだったらA,Bは同じ一つのインスタンスを刺す参照？

名前が揃うメリットを活かそうと思えば、アクセス制御はC# or Java式を止めてC++式にする必要が。

protected:
　Name: String;
　Info: SomeClass;
public:
　Execute: (Data: Pointer) Integer; //よくわからんが関数はこんな感じ？

protected Name: String;
protected Info: SomeClass;
public Execute: (Data: Pointer) Integer;

どちらがいいか明らか。

RTTIとかリフレクションはどの程度まで？

なんだか : より as のほうが見やすいような気がしてきた・・・（特にメソッドの仮引数リスト）

宣言・初期化は

Name as const String = "Mona Monao";
Age　as int = 10;

とかどうでっしゃろ。
・・・C#erの漏れにはどちらにしろ見にくいでつが・・・・（汗
複数同時宣言はあんまり使うもんでもないと思うし、もしこのタイプ（Var:Type）で行くのなら、出来ないことにしてはどうでせう。

アクセス制御は>>371に同意、その際

shared protected:
　Hage as SomeClass = new SomeClass();
instance public:
　Hoge as String; // default is null
　Method( param as int ) as int;

みたいに出来たら幸せかと思うんだけどどうでしょ？

Pascalerな僕としては : が…まあ、好みでしかないですけど。

メソッドは、どちらがいいかな？

Method: (Arg: int) int; //引数は型情報の一部
Method(Arg: int): int; //Pascalのfunctionに近い

( ) の後に記号無しで戻り値の型が来るのが変ならここにasを用いてこんなのもありかもしれません。

Method: (Arg: int) as int;

…intじゃなくてIntegerと書きたいな…整数型が予約語である必要は無いわけですし。まあこれは別の話ですね。

instance/sharedは、インスタンスorクラスに付くかということですか？それは幸せっぽい。
でも、何も書かないのがインスタンスで、クラスはclass public: がいいです。

Method: (arg: Integer)->Int
とか

>instance/sharedは、インスタンスorクラスに付くかということですか？それは幸せっぽい。
>でも、何も書かないのがインスタンスで、クラスはclass public: がいいです。

意味が分からない（汗

Method = (arg: Integer)->result: Integer {
　if (arg != 0)
　　result = arg * 10;
}

こうすれば、resultを暗黙の変数としなくてもいいし、
戻り値が何であるかも分かってイイかも

>>377
＞->result
冗長すぎない？

代入演算子は別がいいか・・・

>>375

public: // ただのpublic/private/他はインスタンスメンバ
class public: // class がついたらクラスメンバ
ということだと予想

でも、この場合インナークラス（実装するとして）の可能性もあってコンパイラが混乱するから
classキーワードを使うことは出来ないと思われ

>>377
かなーり記号的な言語になりそうな予感

>>378
returnを消して暗黙の変数resultに代入すると言う案があったから。
->index: Integerとか戻り値に名前を付けられる

>>382
ああ、それなら納得。

>>380

クラス宣言(型宣言)も、名前を先にすればおっけー。(isはAdaより)

SomeClass is class: SuperClass
{
class public:
　ClassAttr: Integer;
　ClassMethod: (Arg: String) -> Result: Integer; //←この形に一票
　InnerClass is class
　{
　　...
　};
};

一票取り消し。型情報の中に括弧で囲ってすらいない : があるのは…やっぱResultは暗黙でいいです。
よって Method: (Arg: String) -> Integer; に一票。

ついでに派生を class: SuperClass と書いたけど、ここの : も型情報の中の括弧で囲っていない : と考えると気になってきたので
ObjectPascalみたく class(SuperClass) を

…気にしすぎかな

->がちょっとなぁ。

>>385
クラスメンバ扱いの InnerClass って、どうやって外側のクラスのメンバにアクセスするの？
インスタンスメンバにはアクセスできないって事？

>ClassMethod: (Arg: String) -> Result: Integer; //←この形に一票
これでいいとおもうけどなぁ

method: (arg: string) -> (result: int, status: int) { }

やろうと思えば複数戻せる

>>388 …ごめんなさい。何も考えてませんでした。

SomeClass is class(SuperClass)
{
class public:
　ClassAttr: Integer;
　ClassMethod: (Arg: String) -> Integer; //->はasでも他の記号でも何も書かなくても
public:
　InnerClass is class
　{
　　...
　};
};

>>387
よく (int,int,int)->int 型の関数とか表記するでしょ？

複数の変数を返値として返したい。

length: arg: string -> length: int

int len;
length < "string" > len;

find: (base: string, part: string) -> (index: int, len, int)

int index, len;
find < ("this is a pen.", "is") > (index, len);

>>389
呼びだし側はどうやって複数の返値を受けとるの？
a, b := method(""); とかは想像付くけど、式の途中で呼ばれたら？

>>394
そう言う使い方想定してないでしょう。
使用者も制作者も。

んー…悪いんですけど今ひとつメリットが見えてきません。
C#のoutパラメータの方が使い勝手いいような。

if(Method(A, B, out C) == true)
{
　...Cを使う...
}

式の途中で呼べないのなら、こういう使い方もできないことになりませんか？

if (method("").status != 0) {}ﾄｶ

>>396
返値　＝　func（引数）

の関係を保ちたかった。

outパラメータはあまり好きじゃない
引数と返値をごちゃ混ぜにするから

う〜〜んvar: typeにはなじめない・・・

あと100レスでwiki

uvaって複数返せるって聞いたけど・・・

method size as Integer, Integer :
return width, height;
end

width, height = box.size;
みたいに使うみたい。

> ClassMethod: (Arg: String) -> Result: Integer;
より
ClassMethod(Arg: String) -> Result: Integer;
のほうが良くない？
呼び出し元と近い記述が出来て見目麗しいと思う。

でも出来れば -> Result はキーワードresultみたいなのを使用するように変更したほうがいいと思う
メソッドの1行目って、対人宣言としての意味もあるわけで、
ドキュメント化されたり、他の理由でメソッドの使用者が見ることもあるだろうけど、
そこにメソッドの内部で使用されるだけの変数名が出てくるのはやめたほうがいいと思う。

GetIndexOf( substr: String ) -> index : Integer;

とかいくつか考えてみたけど、その変数名が見えてもあんまりメリット無いし。

あと、暗黙のresultなどの変数に代入したものが戻り値になるのは、
{
　int result = 0;
　// 処理いろいろ
　if (hoge) result = 1;

　return result;
}
などのような方法に比べてどのようなメリットがあるのでしょうか？

>>404 ClassMethod(Arg: String) -> Result: Integer;
引数も型と見なせるから
ClassMethod: (Arg: String)->Integer
でいいとおもう。
シンボルClassMethodは(string)->int型の関数を意味する
って感じかな

>resultみたいなのを使用するように変更したほうがいいと思う
>メソッドの1行目って、対人宣言としての意味もあるわけで、

一人で使う分には名前を付けられた方がメソッド内部の実装に便利だけど、
多人数だったりするとそうでもないか。
しかし、多人数で使える物にするのかぁ？

> 見目麗しい

なんて読むの？

ClassMethod(Arg: String) as Integer
ClassMethod: (Arg: String)->Integer

意味を考えると、後者の書式で->をasと置き換えるのはよくないと思う。
(Arg: String)はIntegerではないのだから、toとかの方が適切か

みめうるわしい

>>409
ありがとう。

「名前: 型; 」という統一を考えた場合、引数は型に含めるべき(関数ポインタのようなものを考えると特に)
…と思うので、僕は Method: (...) -> ... 派。(記号 "->" については考えてもいいと思いますが)
使用箇所と宣言を同じに見せるという考えで作られたCのポインタの宣言が結局変なのは周知の事実な訳で
使用と宣言は違うと割り切った方がいいかも。

>メソッドの内部で使用されるだけの変数名
仮引数名だってそうですけど…引数は複数渡せますからね。
結局、複数の返り値か、outパラメータか…で、複数の返り値の場合は、返り値に名前を付ける意味が出てくるのだと思います。

result変数のメリットは>>253。
戻り値が構造体の時、r = m(); を内部で m(&r); として取り扱って、
渡されたアドレスをそのままresultに見せる最適化は実際にDelphiで行われています。

ダメだ！！:が気になって。
慣れなのか？慣れれば気にならなくなるのか？

>>412
とりあえずPascal(ObjectPascalでも可)とAdaとEiffelと、変種なところでHaskellやJScript.NETなどのソースを沢山読んでみるとか(w

define
ClassMethod;
in
Arg as String;
out
Result as Intger;
defend

やっぱり引数は型に含めるべきなんですかね。

>>411
> 仮引数名だってそうですけど…引数は複数渡せますからね。

それと、引数の名前が持ってる情報量は戻り値の名前が持ってる情報量より多いように感じた。
普通メソッドの戻り値って、何らかの値の取得か、実行結果みたいなのが多いと思うけど、
前者（たとえばGetFileName:()->fileName）は、もともと戻り地が何を表しているかを分かってて使うものだし、
後者（たとえばExecute:()->errorCode）は、結局ドキュメントを見ないと何のことやら分からない。
でもパラメータはそれを読む人に、ヒントを与えられる。
で、戻り値の名前は不要かな、と思ったしだいです。

resultについて、参考になりました。
最適化に使えるんですね。

議事録を作ってみました。抜けや番号ミスがあったらごめんなさい。

全般
　>>152>>155>>156>>157>>158>>352>>364
型
　種類
　　>>195>>199>>201
　mix-in
　　>>187>>188>>189>>190>>192>>194
　文字列
　　>>172>>173
　template
　　>>160>>163>>166
　アスペクト指向
　　>>241>>242>>246>>250

宣言
　命名規則
　　>>324>>325>>326>>327>>328
　クラス
　　>>197>>199>>385>>388>>390
　アクセス制御
　　>>144>>228>>229>>230>>371>>373>>374>>380>>385
　変数
　　>>365>>366>>367>>368>>369>>370>>373
　ポインタ
　　>>60>>61>>81>>88>>89>>91>>92>>94>>95
　constant
　　>>63>>98>>139>>141>>370
　プロパティ
　　>>240
　メソッド
　　>>334>>374>>375>>377>>386>>389>>392>>393>>394>>395
　　>>396>>397>>398>>399>>404>>405>>406>>408>>415
　宣言と定義が同時か分割か
　　>>338>>364

制御文
　条件分岐
　　>>258>>274>>292>>293>>294>>295>>297>>298>>299>>300
　　>>301>>303>>304>>306>>307>>309>>310>>311>>312>>313
　　>>314>>315>>316>>318>>319>>320>>321>>351>>355>>356
　　>>358
　後判定反復
　　>>70
　ブロック/脱出/goto/ラベル
　　>>71>>73>>255>>257>>260>>263>>264>>265>>266>>267
　　>>268>>273>>274>>276>>278>>279>>280>>281>>283>>285
　　>>287>>288>>289>>291
　assert/表明
　　>>247>>249>>251>>269>>270>>275
　Result
　　>>253>>256>>258>>404>>411

演算子
　ポインタ演算子
　　>>4
　オーバーロード
　　>>204>>205>>214>>218
ライブラリ
　Windows
　　>>226>>227
その他参考になりそうな発言(独断と偏見)
　>>10>>11>>12>>13>>83>>136>>402>>403

おーすげー
おつかれ！

お疲れー
しかし、どれもこれもアイデアの列挙で全然まとめに入ってないよな

ところで言語名は？

Giko#

for文がまだ出ていないようですので、とりあえず言いたいこと言っておきます。

機能的にPascal or Ada式を希望。
C式だと for(BYTE I = 0; I < 256; ++I) /*←終わらない*/ のように全ての値を使えません。
「継続条件式」では無く終了時の値を直接示すことで、BYTEなら0から255まで全て使えます。
ついでにAdaのようにループ変数は常に新しく宣言される形で型は書かなくても初期値と終了値から自動的に決めてくれれば楽。

Adaの for I in 1 .. 10 loop … end loop; をC風の構文に直すなら for( I in 1 .. 10 ) { … }; かな？
forをやめてloopにすれば loop( I in 1 .. 10) { 一定回数繰り返し }; と loop { 無限ループ }; を兼用させても自然だなあ、とか。

>>424
単純な列挙にはC#のforeachに近い構文を使用してはどうでしょう。

using System;
using System.Collections;

class Range : IEnumerable
{
public Range( int first, int last ){ First = first; Last = last; }
public IEnumerator GetEnumerator() { return new Enumerator( First, Last ); }

public readonly int First, Last;

class Enumerator : IEnumerator
{
public Enumerator( int first, int last ) { First = first; Last = last; current = first-1; }
public bool MoveNext(){ return (++current<Last); }
public void Reset() { current = First-1; }
public object Current { get { return current; } }

public readonly int First, Last;
int current;
}
}

class Foo
{
static int Main()
{
foreach( int i in new Range( 10, 20 ) )
{
Console.WriteLine( i );
}
return 0;
}
}

Doremi#

なんかタダのコピーっぽいな・・・

小金井市中町4-14-3西村コーポラス205
神奈川？？？・阿倍野区橋本町6-30
オー・ムムム・ゴーサン・クニムイ
鵜沼　安希雄と風本純男（年収１０００マン！）

>>428
ウザイ。　

　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　

>>425
これまでの話で出てきた構文に当てはめるなら foreach(i: int in Range(10, 20)) { ... } って感じですか？
動的なRangeオブジェクトよりも静的な部分範囲型が好きなので
やっぱ foreach(i: int in 10 .. 20) { ... } がいいな…

あと、わざわざIEnumeratorみたいなものを作らなくても、++ と比較演算子をオーバーロードしておけば
それが使われる、でいいと思います。

内部ではこんな風に展開されるということで…(こうするとBYTEなら255まで使える)

if(初期値 <= 終了値)
{
　I = 初期値;
　for(;;){
　　...
　　if(I == 終了値) break;
　　++I;
　}
}

どちらにしろforeachで統一できそうな感じですね。

わかりにくい

>>431
俺は何かと<=より<のほうがいいなぁ。
で、こうすると<=のほうがｲｲ！いや<のほうがｲｲ！って争いになって、
結局中とって自分で選べるC風がｲｲって話になるんよ。
そもそも>>424はカウンタにBYTE使うのがおかしいと思う。

えーと、BYTEが変なのは認めますが(w、範囲の最後の値まで使い切ることの例として出したまでです。
列挙型を使うことを考えてみてください。

enum T { A, B, C };

for(T i = A; i < C; ++i) { ... // 最後の値(C)を使えない
for(T i = A; i <= C; ++i) { ... // i が範囲外の値を指さないと終わらない

C風ではどうしても有効範囲の最後まで使えないんです。
Cの列挙型は整数定数と大差ありませんけど、まともな列挙型を持つ言語としては欠陥と思います。
で、これを避けるために、Pascal風とか、Rangeオブジェクトとか、そういう話をしたいわけで…。

PascalやAdaは、列挙型を配列のインデックスにできるため、ループ変数に列挙型を使う機会が多いように思います。
この言語では配列はどうか知りませんが、flag型が提案されているので、やはり必要に感じます。

う〜〜ん俺はそれで困ったことない。
>>431の場合最後のループ中にbreakしたのか、それとも最後まで実行されたのか判断できないよね。

for (int i = start; i < start + num; i++) {}

>>436
ラベル付きbreakが使えそうなのでこんなのもありかも。

L: {
　for(まあ記法は置いておいて){
　　...
　　break L;
　　...
　}
　最後まで実行された時だけ実行される
}

或いはPythonみたいにforにelse節を書けるようにするとか

(kazu)**は当然ながら "2乗" の意味にしてくらさい。

ダサ過ぎる

やっぱりラベルはトリッキーな使い方になりがちだから廃止に一票。
それよか言語仕様としての例外処理を充実させた方がいい。

それじゃ、多重ループを抜けるのにgoto？

throwしろよ。
gotoは廃止。

何で正常ケースでもthrowしないといけないんだ？

下方向だけじゃなく、折角上方向(retry/redo)について議論があったのに、それも切り捨てるわけ？
というか話題はラベル付きbreakがメインじゃなく、forを最後まで実行したか、途中で抜けたかの判断方法なのですから
>>438がトリッキーと思うならPythonのfor-elseとか、他の方法とかを考えればいいと思います。
( >>438を例外処理で書き換えたら、そっちの方がトリッキーと思うのですけど )

>>439
**はAdaやHaskellでn乗演算子。例: 2 ** 3 = 8
これに関してはBASICの ^ の方が好きですね。

正常終了はループの終了条件を適切にしとけば済むのでは？
どうしてもループの底から脱出したくなったらthrowしてループの外側でcatch。

というかラベル付きbreakとgotoの違いって何よ？？

例えば

for(int i = 0; i < a.length; ++i) //forの書式は例によってひとまず置いておく
{
　if(a[i] == 探しているもの)
　{
　　r = a[i];
　　break;
　}
}

で、探しているものが見つからなかった時に実行したいことがある。
i == a.length で判断する方法も考えられるが、列挙型などでは i が有効範囲を超えることができないので却下。
使えそうな方法は

・フラグ変数を用いる(流れ制御のために変数を増やすのは嫌だ)
・ラベル付きbreak(トリッキー？)
・Pythonのようにforにelseを設ける(一番正当な解法と思われるが言語仕様が増える)

・見つかった時例外をthrow

「見つからなかった時」こそ例外を投げたいと思われるのに…
それでも見つかった時(むしろこっちが正常な流れと思われる)に例外を投げろと？

そういう場合は、終了条件を（a[i] == 探しているもの）にした制御構造を
使うべき。で、インデックスが範囲を超えたときに例外を投げるなりナンナリ
した方が良いと思われ。

あ、良く読んだら却下されてた（w

ラベル付きbreakと例外の違いもわからなくなってきました…。

( i が常に 0 以上 a.length 未満であるよう気をつけるとして) こんな感じですか？

if( a.length > 0)
{
　i = 0;
　while(a[i] == 探しているもの)
　{
　　if(i = a.length - 1)
　　{
　　　見つからなかった時の処理;
　　　throw 見つからなかった例外;
　　}
　　++i;
　}
}

配列ならこれでいいけど foreach を使いたい時はどうすれば…

しまった、a.length == 0 の時も例外を投げないと…。

if( a.length == 0)
　throw 見つからなかった例外;
else
{
　i = 0;
　while(a[i] == 探しているもの)
　{
　　if(i = a.length - 1)
　　　throw 見つからなかった例外;
　　++i;
　}
}

……………………Pythonの解法に一票

いや、そういうときは無理に投げなくても‥‥‥。
Pythonかー。

for-elseどんな用法があるの？

452をPython風に書くなら

for i in range(count(a)):
　if a[i] == 探しているもの:
　　r = a[i]
　　break
else:
　raise 見つからなかった例外

要するにbreakされなかった時に実行される節で、これなら foreach でも while でも同じように付けられます。
( …ってラベル付きbreakが使えればそれでいい気もするんですけどねー)

ループ文のelse節って、ループが完了しなかった（breakで中断された）
時に実行するようにも見えるから、名前を変えたほうがいいと思う。

>>456
同意、漏れはrangeが空だった時に実行されるように見える
finallyはどうかな？

finallyは例外用に残そうよ

atendとか

ラベル付きbreak/retry/continueに未練あり。
というか皆さん本当にこれらが無くなっていいの？

39としては入れたいです
gotoの様に無節操な使い方は出来ないし、
問題ないと思います

いずれにしろ中断の判断はできるようになったので、>>435から続けますか。
今のところ解決法は次のふたつ。

・Pascal/Ada風の書式にする
・Rangeオブジェクトとforeachにする

個人的には、部分範囲型を導入したいところです。
C#のようにバイト数で型を分けるのでは無く、使える範囲を明確に指定して型を作れるようにする。
で、それをRangeオブジェクトのように扱えるようにして…駄目？

　　
　　
自然に成す順

Dylan‥‥‥うつくしひ。

for ( clauses [Special Form]
[{until | while} end-test]
)
body
[finally result-body]
end [for]
=> values

forは１つまたはそれ以上のclausesをとることができる。 各clauseは繰り返しを通してひとつの反復変数(iteration variable)を制御する。 end-testは省略可能で、繰り返しが続くか終了するかの制御を行い、反復変数を制御する ことはない。

引用元：
http://www02.so-net.ne.jp/~komuro/Mutsumi/DylanInfo/ControlConstructs/IterationConstructs.html

for()は無くてもいいね。
実行順序が重要なら別のloop構文を用意して、
iterationにはforeachを使う。
foreachならコンパイラが勝手にマルチスレッドに展開しやすいかも

>>464
Pascalのfor文で、ひとつのforに制御変数が複数置けるようになって、なおかつwhileも併用可能な感じですか。豪華ですね。
to、downtoよりもabove、belowのほうがわかりいいかも。

C式のforは要りませんよね。
無限ループはwhileで作れますし、foreachとPascal(Ada/Dylan?) 式のforがあれば。

foreachに逆順で回る構文を追加すれば、Rangeオブジェクト or 部分範囲型 と併用することでPascalのforをカバーでき、
ループはwhileとforeachだけにできそう。

逆順は新しい構文を追加するんじゃなくて逆方向イテレータを作って何とかならないかな？

イテレータが、自分の次のイテレータを取得するメソッドと、自分の前のイテレータを取得するメソッドを持っているとして…

・常にforeachは順方向を用い、逆順を使いたい時は逆方向イテレータを間に挟む
・foreachに順方向か逆方向を選ぶ構文を追加する

んー、どっちでもいいとは思いますけど、強いていうなら、順方向と逆方向に優劣は無いと思うので、構文、かな？

　　自分をみうしわない、いきることを見失わない　　……生きた電脳、 ﾌﾟﾘｰｽﾞ。
　それを追求するなら何ｽﾚ、何年かかってもよい ……助けて　　誰か 助けて…　　

>>469

　　　　コンピュータの真理　　

イテレータはimmutableにして++演算子やめて自分の次を取得するメソッド or 演算子を新設希望
(classじゃなくstructになるとしても) i++ より i = i.next のほうがいい気がする

そういえばnewキーワードって必須ですか？
C++/Adaのようにインスタンスを動的と静的の両方に配置できるなら必須ですけど、
C#のようにclassは動的、structは静的と決まっているなら、「 型名( ) 」だけで意味が通じる気が。

structは動的・静的どっちもいけないとおかしいと思うんだけど？
違いは値型か参照型か

>>473
一瞬納得しかけたけれど、C#では値型もコンストラクタを呼ぶ時にnewは絶対必要みたいです。
int a = int(); はエラーになり int a = new int(); は通りました。
structが参照型になる時はBoxingのみだから、やっぱ要らない気がしますけど、なんか間違ってます？

>>465が言っている「別のloop構文」が気になってしかたがない。
実行順序重視でforでもforeachでもないループ文…どんなの？

俺の肛門も開発されそうです。

>>476　　汗をかいて生きろ。　　　　　　

　　　　　　　　　
　　　　　　　　　
　　　　　　　　　

やっぱりモノが出ないとモチベーションが続かないなぁってことでさ、
現在でてる中からよさげな仕様をピックアップして、まとめちゃわないか？

賛成です。でも39さんがいないと…

配列について、ちょっと思いついたことが。
Adaで IntArray is array (range <>) of Integer; って宣言しておいて TheArray is IntArray(1..10); って範囲を指定したら
IntArrayとTheArrayは派生関係みたいになるでしょ？
これ、C#のBoxingと組み合わせられないかなあって。具体的には前者を参照型、後者を値型扱いにして

type IntArray is [ ] int; //参照型
type TheArray is [1..10] int; //値型

Arr: TheArray; //値型インスタンス(new不要で実体が作成される)
Arr[3] = 10;

PArr: IntArray = Arr; //Boxing
PArr[2] = PArr[3]; //Boxingしたまま使える
One: int = PArr[2]; //One = 10

Arr2: TheArray = PArr as TheArray; //Unboxing

そう言えば VAR: TYPE; 型の変数宣言ですけど、ローカル変数の場合ラベルとどう区別するのでしょうね？
すぐに思いつくあたりだと

・BASICみたいにvarを付ける

　Func: (X: int) -> int
　{
　　var Local1: int;
　　…
　　var Local2: int;
　　…
　}

・Pascal同様最初でしか宣言できない

　Func: (X: int) -> int
　　Local1: int;
　　Local2: int;
　{
　　…
　}

・Adaみたいに最初で宣言＋途中宣言用の文を用意

　Func: (X: int) -> int
　　Local1: int;
　{
　　…
　　declare
　　　Local2: int;
　　{
　　　…Local2はここでだけ有効…
　　}
　}

39さーん、一部まとめにかかっていいですかー？返事くださーい。

>>483
あ、はい。よろしくお願いします
実装中に問題が出そうな仕様があったらちょっとずつ指摘させてもらいます。

まとめにかかるなら必要と思われるので議事録(差分)。前の議事録は>>416>>417>>418>>419

型
　イテレータ
　　>>425>>471
　配列
　　>>481
制御文
　繰り返し(for, foreach)
　　>>424>>425>>431>>433>>434>>435>>462>>464>>465>>466
　　>>467>>468
　ループ脱出とその判定
　　>>436>>438>>441>>442>>443>>444>>445>>446>>447>>448
　　>>449>>450>>451>>452>>453>>454>>455>>456>>457>>458
　　>>459
演算子
　n乗
　　>>439>>445
　new
　　>>472>>473>>474

…前のを作ってからあまり経過していないと思ったらけっこうありますね。

だれか、Integer等の標準クラスのメソッド規定してくれ

型システムを詰めた方がいいのでは？

>>195より、基本はC#で、mix-in用モジュールと、Pascalみたいに集合を加える。
(部分範囲型は…あるとint, longなんてのを統一できていいと思うけど…どうでしょ)
GCがあるみたいなのでポインタは無しかな。ついでに>>481も加えさせてもらうとこんな感じでしょうか。

参照型
　class
　　array(範囲指定無し)
　　　string
　　delegate
　interface
　mix-in-module

値型
　struct
　　enum(部分範囲型？を含む)
　　　整数
　　　char
　　flag(集合)
　　実数
　　array(範囲指定有り)
　　　string(リテラル(長さがわかっているから))

で、この頂点にObjectクラスが来る…と。
stringは配列の一種とみなしてツリーを作ってみましたが、別にした方がいいかもしれません。

objectを頂点に持ってくると、
generics導入の意義が薄れないか？
既存のJava/C#なんかとほとんど変わらないだろう

それにメソッドを規定するためにはメソッド宣言が決まって無いと…
まだ戻り値が複数かどうか、ref、outパラメータを認めるかどうかに決着がついてなかったような。
構文も戻り値のところが曖昧なまま…

　NAME: (ARG: TYPE) -> RTYPE; //"Result"は暗黙の変数
　NAME: (ARG: TYPE) -> RESULT: RTYPE; //戻り値を返すための変数に名前を付けられる
　NAME: (ARG: TYPE) -> (RESULT1: RTYPE2, RESULT2: RESULTTYPE2); //複数の戻り値を認める場合

>>488

>>163で言われているようにタイプセーフだけでもgenericsの意義はあると思いますけど…
というか代案があるならそれをまとめてみてくれませんか？

変数のアラインメントを決める特殊構文とかも用意した方がいいかな

v: double align(16);
struct x align(16), padding(4)
{
x: int;
y: int
}

>>490
タイプセーフは確かにメリットだけど、
objectが頂点のツリーを形成すると、それをコンパイル時に解決できないでしょ？
いや、解決できるかもしれないけど、collectionがobjectを継承するメリットが無くなる

賛成。でも指令は指令っぽい構文がいいです。型も変数同様に名前を先にしてこんな感じを希望。

v: Real #align(16);
x is struct #align(16) #padding(4)
{
　x: int;
　y: int;
};

>>488
> objectを頂点に持ってくると、
> generics導入の意義が薄れないか？

そうなの？
クラス定義時に必ずobjectを継承しる！というのはウザイけど、
クラスライブラリの構成としてオブジェクトの標準的な振る舞いを
ルートクラスに置いておくのは普通かな、と。
そういうのもgenericsで記述すべき？

>>489
戻り値が複数っていうの本当に便利？
リストやベクターをファーストクラスオブジェクトにして、
それらのオブジェクトを一個返せば十分じゃない？

決まって無いと言っただけで…じゃあ、上ふたつならどっちがいいです？僕は最初の。

>>495
ごめんごめん。
二番目。

39 ◆6K2ziZrM か 483 がその辺調停取ってくれるだろう

スレ前半は静的マンセーな香りがしたけど、
後半は結局何の変哲もないありふれた言語になりつつあるな。

>>498
どのへんをもって「静的」とおっしゃってますか？
ちょっと聞いてみたかったり。

Objectクラスが必要になるか、genericsで書いてしまえるかは、genericsがどんな形になるのかにも依存しますよね。

静的で総称が使える言語はAda, Eiffel, C++, Java(予定), C#(予定) ってとこですか。
JavaとC#は知りませんけど、C++が比較的自由に使えるのに対し、Adaなんかは総称に条件が付きまくってた気が…。

genericsの仕様を先に決めるべき？

>>500
そうかも。
良さげなのを提案してみてください。

…実は自分はAdaは半端な生かじり、Eiffelは概要を読んだだけ、みたいな状態なので、自分が提案してもいいのはできないと思います。
というわけで詳しそうな488=492?さん、お願いします。

Java/C#の総称は動的解決みたいだよ
例外が飛んでくるらしい

http://objectclub.esm.co.jp/JavaGenerics/ でJavaの総称の解説を発見しました。
JVMの互換性を保つためとはいえ、型情報が失われるのは嫌ですね…。
実行時例外が起きるなら、結局ダウンキャストの手間を省いているだけのような…。

しかし、コードサイズが型毎に増えずにすむのも事実。
内部ではObjectクラスにBoxingしてコードは共有、型識別子みたいなものは別々に作るみたいに
…駄目だ、それでもパラメータとして与えられた型を実体化できない…。

やっぱコードサイズは犠牲にするしか無いのでしょうか。

　　　めもりを共有できるのではないか
　　　　　　　　　

Ada、Eiffelの総称もほんの少し見てみたので書いておきます。
Adaは、型の種類や持っているメソッドを事細かく指定しないといけません。型ではなく関数orパッケージが単位でちょっと他と違う感じです。
Eiffelは、普通に使えるみたいですが、(Javaの総称みたいに)パラメータ型が継承すべきクラスを指定できるようです。

>>505 もっと詳しく説明していただけますか？

やはり、型クラスだな。

昨日無責任な事を言ってしまったので一日考えていたのですが…

Eiffel or Java式のgenericsだと、パラメータ型の制限を派生もとを指名することで行うので、
するとその場合全てのクラスを示すObjectクラスがあった方が自然じゃないか、と。
しかし、インターフェースや親クラスを指名してメソッドの存在を保証するタイプのgenericsは、
肝心のメソッドが仮想関数になるのであまりgenericsのありがたみが無いような。やはりC++式がいいのかな…？

…で、仮にObjectクラスが無かった時の場合を考えてみたのですが、Objectクラスが無くても、
as演算子でインターフェースを問い合わせられれば手間はともかく「機能的には」困らない気がします。
しかし、as、is演算子がある以上、表に出てこなくても「全てのオブジェクト」を表す何かが
あるのは確かなので、Objectクラスはあった方がわかりやすいのではないか、と…。

非Java式の、つまり継承と無関係に同名のメソッドがあれば呼べるC++的なgenericsを活かすためには、
Objectクラスは(C#やJavaのような仮想メソッド沢山というのを避け)可能な限りシンプルにすべきと思いました。
最低限必要なのはGC時呼ばれるデストラクタとRTTI取得メソッドでしょうか。

Object is class
{
public:
　Destructor: ( ) virtual;
　GetType: ( ) -> Type;
};

…自分でも突っ込みどころ満載なのは認識してますが、議論再開のきっかけになれば幸いです。

age

継承と無関係に同名のメソッドを呼べることに、どんなメリットがあるの？
厨的質問スマソ。（CでOOっぽくプログラミングしてるのでgenericsは分からない)
Eiffelで派生元を制限できるのって聞いた時かなり感動したんだけど・・・

与えられた型がXの時はX::Func(X Arg)、Yの時はY::Func(Y Arg)を呼ぶことができる…でしょうか。
もし継承が前提なら、両方ともX::Func(Object Arg)、Y::Func(Object Arg)にしなければいけないので、
型チェックのありがたみが薄れる…のだと思います。(自分も詳しく無いです)

↑書いて思いつきましたが、型パラメータになるための要件を列挙したインターフェースもどき？なんてどうでしょうか。

VectorElement is parameter : Object //継承する必要があるクラスやインターフェースを列挙
{
public:
　constructor: ( ); //引数無しのコンストラクタが必要
class public:
　operator >: (X, Y: VectorElement) -> Boolean; // 自身の型を引数に取る ">" 演算子が必要
};

で、総称の定義でこれを明示する、と。

Vector is generic<Element is VectorElement> class { ...

そうすればVectorElementで書かれた要件を満たしたクラスのみVector<Integer>みたいにできる、と。
Vectorの定義の中ではVectorElementで書かれた要件のみ使える、と。
型チェックが楽になりませんか？…面倒くさいかも。

無知を承知で提案しているので、どうぞ叩いて下さい。

同時に、書きながら思った別の提案…
・コンストラクタは型名ではなく予約語"constructor"を使うことにしませんか？型名がメンバー名を汚染しなくて済みます。
・Vector<Vector<Integer>>が通るように、">>"演算子か、型パラメータを囲む"<" ">"をどちらか変えませんか？

>>512
なんで<〜>なんて構文にするのか疑問。
C++のテンプレート構文は後付けだから*しかたなく*そうした面があるけど。

無意識にC/C++の記号を使っていました。すいません。何かいい構文希望。

class Array[T]
　implements Collection
　　add: (v: T) -> Boolean = self.add;
　　remove: (v: T) -> Boolean = self.remove;
　　...
　implements OtherInterface
　　add: (v: T) -> Boolean = self.add;
　　find: (v: T) -> Boolean = self.find;
　　...
　creators
　　create: {};
　　copyfrom: (v: Array[T]) {};
　feature
　　add: (v: T) -> Boolean = { }
　　remove: (v: T) -> Boolean = { }
　　find: (v: T) -> Iterator[T] = { }

Array[T] a = Array[T]`create;
Array[T] b = Array[T]`copyfrom(a);

クラス宣言にcreators節を設けて、
クラス生成には専用の構文を用意するというのは？
genericsは<>だから問題あるんだから、Eiffelに習って[]とか。

>>511
なるほど。厨的には、親クラスを指定して制限かけるほうがいいかな。
でも実装方法は自動的にキャストしてくれるだけ？のerasureっていうのより
C++みたいに個別にソースを作ってくれるほうがいいかもしれない。

java genericsの欠点(504のリンク先より)
・Genericクラスの中で，型パラメータ(<T>)をnewできない． -- new T はだめ
・Genericクラスの中で，型パラメータ(<T>)にキャストができない． -- (T)object はだめ
・Genericクラスの中で，型パラメータに対する instanceof ができない．-- object ・instanceof T はだめ
・Genericクラスを型パラメータ(<T>)から継承できない．
・intなどの基本型を統一的に扱えない．
・例外クラス(Throwableのサブクラス)としてGenericクラスを定義できない．

っていうのは大きそう。
構文は[ ]を使っては？って515も書いてるしw

>>515
面白いですね、それ。(ところでprotectedにしたいコンストラクタはどう書くのですか？)

type IntVector is Vector[Integer]; //generics実体化

type IntArray is [ ] Integer; //参照型
type TheArray is IntArray[1..10]; //値型(いきなり [1..10] Integerでも可)

なんて書ければ配列とgenericsが似せられていいかな…

>find: (v: T) -> Boolean = self.find;
Booleanは間違いでIterator[T]だね。

型が一致する場合のみ関数実体を参照・転送出来るのをイメージ
複数のインターフェースで同一メソッドがあるとき便利だから。
それと、>>515の書き方だとどのメソッドを実装しているのか一目で分かる

Arrayで総称を使うならCollectionを継承する意味が全くなかったり。
しかし、ArrayをFCOとするならCollectionを継承してたほうが何かと都合が良いんで
Java的な動的解決のGenericsしか選択肢無いような気がする。

>>517
>ところでprotectedにしたいコンストラクタはどう書くのですか？
分かりません（汗
メソッド定義がこの形になったんで、
アクセス識別とかpropertyとかどうやって宣言するのかサッパリ想像つかないです

http://web.kyoto-inet.or.jp/people/haselic/pi/pi113-96.mid

>>518
>しかし、ArrayをFCOとするならCollectionを継承してたほうが何かと都合が良いんで
C++の配列は何も継承していなくてもSTLで使えますけど、Collectionって必要ですか？
むしろそういうのを不要にできるのがgenericsと思ってたのですが…。

>>521
んー、言われてみればそうだね。
FCOはすべて１つ(Object)から継承しないと行けないわけじゃないよね
やっぱり継承されてると美しいとは思うけど。

バランスなんだよな。この辺優れた感覚を持った人の意見が聞きたいところ。

>>519
アクセス識別というのはpublicとかprotectedとかのことですか？
なら>>371>>373>>380>>385の辺りに議論が。C++風で落ち着いたのかな…？

プロパティは>>240ぐらいしか出て無いのでこれを名前が先に書き変えるとすれば
i: property int { public get { ... } protected set { ... } }; ？？

　　ものを大切にするこころ

　　みんないきている　　　　

正直、C++の仕様でルーズにしてあるところを固めて記法だけ分かりやすくすればそれで十分。

> この辺優れた感覚を持った人の意見が聞きたいところ
同意です。

・全てのスーパークラスとなるObjectクラスが必要 or 不要
・genericsはC++のように無制限 or Eiffelのように派生元などを制限可能
・genericsはC++のように静的 or Javaのように動的
・ICollectionやIComparableを用いる or STLみたくgenericsを用いる
・配列はFirst Class Object or ライブラリ

ちなみに自分は、(必要/制限可能/静的/generics/First Class Object)

>>525
それはDに任せて

Objectからの派生なんざ、結局voidポインタなみに使えない、とか主張してみる。

>>528
ToString()は何かと役に立つ、とか反論してみる。

概念（要件リスト）の記述方法ってこんなイメージになります？

// 前方向反復子の要件
interface IForwardIterator[ class T ]
{
instance:
　Next: ()->bool; // 次に移動、次が無ければfalseを返す
　Current: T; // 値へアクセス
}

// 両方向反復子の要件
interface IBidirectionIterator[ class T ] : IForwardIterator[ T ]
{
instance:
　Prev: ()->bool; // 前に移動、前が無ければfalseを返す
}
// ランダムアクセス反復子の要件
interface IRandomAccessIterator[ class T ] : IBidirecctionIterator[ T ]
{
instance:
　Advance: ( distance: int )->bool; // 前に移動
　Disadvance: ( distance: int )->bool; // 後ろに移動
}

// コレクションの要件
// テンプレート引数の Iterator は最低限 IForwardIterator[ T ] を実装する必要が在る
interface ICollection[ class T, interface Iterator : IForwardIterator[ T ] ]
{
instance:
　new: ( source: ICollection[ T ] ); // 他のコレクションからコピー可能
　Add: ( newValue: T ); // 要素を追加
　Count: int{ get; }; // 要素数を返す
　GetIterator: Iterator; // 最初の要素をさす
}

// インデックスを指定して値にアクセスできるコレクションの要件
interface IDictionary[ class IndexType, class T, interface Iterator : IForwardIterator[ T ] ]
　: ICollection[ T, Iterator ]
{
instance:
　GetAt: ( index: IndexType )->T;
　SetAt: ( index: IndexType, newValue: T );
}

// 配列
class IArray[ class T ] : IDictionary[ int, T, IRandomAccessIterator : IForwardIterator[ T ] ]
{
instance:
　new: ( initialSize: int ); // 初期値を指定して作成可能
}

そろそろさあ、単に仕様について話すだけじゃなくて効率的な実装が
可能かどうか、という所も話題にした方がいいんじゃない？

個人的にはGenericsとオブジェクト指向のポリモルフィズムは同じ所を
目指した別々の場所からのアプローチだという気がしている。

ポリモルフィズムは柔軟性をとった結果、動的な実装になり、
Genericsは効率性を目指した結果、静的な解決を目指す、みたいな。

>>530
そうか、interfaceをgenerics化した記法が要件リストに使えるのか…目から鱗。

>>531さんは>>526(って僕が書いたのですが)はどれがいいと思います？
僕の意見はこんなとこです。
・Objectクラスは機能的に不要でも意味的には欲しい
・genericsは静的に解決する
・実行時にチェックが必要になりそうなICollectionやIComparableは不要、全てgenericsで行う
・配列は性能重視でFirst Class Object、それとは別に伸縮可能なVector[T]を設ける

プログラミング言語ＭＪってどうよ？
http://www.etl.go.jp/~epp/jp/mj/

>>533
packageやunitに対して静的にoverrideや機能追加ができる感じですか。面白いですね。
(コンパイラ作るのが大変そう…)

ObjectPascalのimplements指令(as演算子の結果に自分では無く他のオブジェクトの
実装しているインターフェースを返す)って結構重要と思っているのですが、
これにもう一歩加えて、あるクラスに後から勝手にmix-in-moduleを追加できると
>>533のリンク先ほどでなくても近いものができるかな…と思ったり。

type TreeNode is class { ... }; って既にあるところに、モジュールを後から
type MyData is module for T { Data: String; }; なんて挿入できて
その結果 TreeNode as MyData が有効になったりすると、TreeNode.Tag なんてのは不要になって…どうです？

mix-inの後付けのメリットがあんまり思いつかない・・・

新しい言語作るより、HSPのネイティブコードコンパイラ作ってくれよ。

>>536
あんな腐った言語のコンパイラ作る気にならんだろ

HSPのネイティブコードコンパイラなら
>・手早くGUIを使ったアプリが書ける
>・ネットワーク使用も簡単に
>・初心者でも難しくない仕様
>・ｺﾝﾊﾟｲﾙして他の言語から使われることができる(?)
>・ポインタを入れたい

この仕様を満たす最も現実的な案だと思う。
HSPが糞な理由の実行速度も解決できるだろ。

>>538
HSPが糞なのは速度以上に言語仕様だろ

39さんが、ここでなされた議論を読んで、どの機能を入れるつもりで、どの機能を除くつもりなのか
現在の心の内を書いてくれたらなあと思ったりして。
そうしたら、それを前提にまだ決まっていない部分の話に移れるのではないかと思います。

>>539
初心者にわかり易い言語仕様だろ

Genericsがあるなら、mix-inは代用できるからわざわざつける必要ないだろと言ってみる

>>542
具体的なソースきぼんぬ。

mix-inて自動コピペでしょ？
C++で書くなら

class Mod {
public:
　foo();
};
template<class T>
class Class {
public:

};

class Mod {
public:
　foo();
};
template<class T>
class Class__ {
public:
　T mod1;
};

typedef Class<Mod> FooClass;

FooClass a;
a.mod1.foo();

>>545
コンポジションにしたクラスを自動生成するだけのコードに見えますが‥‥？
このやり方で任意の数のModを付加したい場合もダイジョブ？
C++をあまり知らないので‥‥。

>>546
この状況でって？
Rubyだってmixinはクラス定義の中に書かなきゃダメでしょ？

class Mod1{};
class Mod2{};
template<class M1, class M2>
class Class_ {
public:
　M1 mod1;
　M2 mod2;
};

typedef Class<M1, M2> FooClass2;

オブジェクトを参照する構文ってどんな感じ？
classは参照型だから問題ないけど、int等は値型だから、
コレクションクラスに入れたときイテレータでいじくり回すためには
参照を返せないとダメでしょ

>>547
FooClass2 a;

a.mod1.foo();
a.mod2.bar();

という感じでアクセスすることになるんだよね？

a.foo();
a.bar();

でアクセスしたかったり‥‥。ダメですか？

ここで提案されているmix-inは、自動コピペでは無く、(菱形継承が起こらないようにした)多重継承ですよ。
「継承はクラスに取り込まれる時だけ」「メソッドもフィールドも持てる」、だったかと。
>>547のやり方ですと、mix-in-moduleで定義された仮想関数をoverrideできない気が。

>>534は流石に不要。でもimplementsは入れて欲しいです。

Foo is class : Super delegate Intf, Mod
{
　GetIntf: ( ) -> Intfを実装しているクラス implements Intf;
　Field: Modを継承しているクラス implements Mod;
};

とか書くと、Foo自体はIntf, Modの実装を持たないが、as演算子の結果として
メソッドの結果や所有するフィールドを返せるようなのを希望。(ってObjectPascalのまんまですが)

押しつけができると、使いたい機能はこのオブジェクトにasで問い合わせてくれ、みたいな
集中管理オブジェクトを作るのが楽なのです。
C#の例でメンバーのメソッドを呼ぶだけのメソッドの羅列を見た時は、面倒な上メンテナンス性悪そうだと思ったし。

俺の感覚で勝手なこと言わせてもらうが

〜 is class 系の宣言で継承を : だったり、微妙に記号的な言語の要素と
そうでない物が入り交じってたりあんまり美しくないよね。
統一しちゃおう。

個人的には[〜 is][〜 implements]の様な記述は視覚的にメリハリがないのでイヤ。
かといってperlまで行っちゃうと行き過ぎだから、ML位な感覚が丁度良いと思う

クラス宣言をどう書くか…

Ada95 | type SUB is new SUPER with 〜
ObjectPascal | SUB = class(SUPER) 〜
Eiffel | class SUB inherit SUPER
Ocaml | class SUB object inherit SUPER 〜
C++ | class SUB : public SUPER { 〜
C# | class SUB : SUPER { 〜
Java | class SUB extends SUPER { 〜

Eiffelの様に型宣言がクラスしかないならともかく、struct, enumなど他にもあるので
「変数宣言同様名前が先」かつ「classキーワードは明示すべき」とは思う。
総称のパラメータ型を受け取る記述も必要だし、
ObjectPascalの委譲機能(implements)を採用するなら継承はするが実体は持たないことを明示する必要もある(かも)。
( ObjectPascalの場合インターフェースだけだがmix-inがあるので )
メソッド定義が METHOD : (ARGS) -> RESULT とかなり記号的なので、
記号的なのがいいかな。でも = より is が意味的に正しいと思う…。

SUB[GENERICS] is class : SUPER, MIXIN, INTERFACES | MIXIN, INTERFACES { 〜

":" が継承、"|" が委譲…ダメ？誰かもっといい形考えて

実はmix-inがあればinterfaceこそ要らない気が…
mix-inモジュールで全てのメソッドをpure virtualにしたらそれがinterfaceでは？
mix-inモジュールも単一継承だけは認めて、でinterfaceは廃止、菱形継承はコンパイルエラー…何も問題ない気が

>>553
>>530を見れ。

>>530
をみてて思ったんだけど、
テンプレート引数への条件ってテンプレート引数内に書くの？
つまり
> // テンプレート引数の Iterator は最低限 IForwardIterator[ T ] を実装する必要が在る
> interface ICollection[ class T, interface Iterator : IForwardIterator[ T ] ]

この部分だけど、これだと Iterator に複数の条件（IteratorはIForwardIteratorとIHogeの両方を実装しなければいけない、とか）をつけたくても出来ないよね。

そこで漏れはクラス定義は
class Class : ( SuperClass, Interface1, Interface2, Mix-In-Module ){}

を提案したい。
C++/C#の書き方を括弧で囲んだだけだけど。
関数の書き方とも親和性がよく（？）ついでに、上のテンプレート引数への複数の制限の問題も解決してくれる・・・かも

個人的には
Hoge is classより
class Hoge
のほうがいいです
英単語が続くとぱっとしなくてみ難い事や
is class を後にすることのコンパイラに対するわずかな負担増こそあれメリットが感じられないからです。

>class Class : ( SuperClass, Interface1, Interface2, Mix-In-Module ){}
>>530は総称（テンプレート）構文なので、
クラスの継承の構文とどういう関係があるのか分かりません。

>関数の書き方とも親和性がよく（？）ついでに

構文解析にはyaccを使うので、ある程度の無理は利きますし、
そもそも関数宣言と構文を統一するメリットは全くありません。
Lisp系のように極端なまでに統一するなら構文解析が要らなくなっていいんですが、
そういう処理系にしても意味がないと思います。
視覚的に綺麗、もしくは意味のある構文にする方が良いと思います。

ここって凄いのか自分の考えを満足するまでぶちまけちゃうのかわからん

こんなんどうでしょ

// 変数
名前 : variable 型 = デフォルト値;

// メソッド
名前 : method [ テンプレート引数リスト ] ( 引数リスト )->型 { 実装 };

// クラス
名前 : class [ テンプレート引数リスト ] ( 継承リスト ) { メンバリスト }

variable,methodについてはあいまいさがないので省略可能、ということで。
一貫性があっていい感じだと思いますが。

>>556
>>530はテンプレートの引数に対して制限（何を実装していなければいけないか）をしています
そこに複数の条件をつけるとしたら破綻してしまう、という話で。

>>559
もしかして括弧はテンプレートの宣言ですか？

>>560
いえ、継承です。

>>530はテンプレート引数への制限として、何かを継承していなければいけない、という制限をしていますよね。
その際の記述とクラスを定義したときの継承の記述は同じようになるべきだと思います。
代替案があるならそれでいいとは思いますが。

自分は、実体を持つもの(アドレスを持つもの、変数、手続き)と持たないもの(型) との区別のために
is を使ったのですが、558さんのはイイと思います。
ただ、isの場合型の別名定義(必要ですよね？)が NEWNAME is EXISTINGNAME; で可能なのに対し、
>>558の場合は、NEWNAME: alias EXISTINGNAME; みたいに
変数宣言と区別するため別途キーワードを必要とするのではないか？と疑問が。
( 別名定義は特殊構文無しに行いたい…と思っていたので )

しかし、考えてみれば、aliasみたいなキーワードは、むしろ存在した方が、
変数や関数にも別名を定義できていいのではないか？…とも思いました。

という理由で558さんに賛成。

( ついでに、常に省略可能なら、"variable"、"method"は不要と思います )

>>548
JavaのIntegerみたいなクラスが必要かな？

>>548
C#のようなBoxingを希望♪

>>563
プロパティつかえば
aIterator.Current = 100;
でたぶん桶かと

Eiffelの様に型がクラスしかなく、
メンバの名前が衝突したときは名前を変更する方が
個人的にはいいな〜。

class SUB
inherit
　　SUPER1 rename hoge as hoge1 end
　　SUPER2 rename hoge as hoge2 end
feature
　　hoge is do ... end
end

sub: SUB
create sub
sub. hoge 　　-- SUB::hoge
sub. hoge1　　-- SUPER1::hoge
sub. hoge2　　-- SUPER2::hoge

s1: SUPER1
s1 := sub
s1. hoge　　-- SUPER1::hoge

s2: SUPER2
s2 := sub
s2. hoge　　-- SUPER2::hoge

クラスのメンバ関数の定義と
関数の中身の記述が離れたところに書けないようにしてくれ

>>567
どういう意味？

>>566
名前の変更は賛成。

でも列挙型は欲しいよ…。菱形継承も嫌なのでmix-inやインターフェースも必要だし…。
…となってくると、型の種類のほうは増え続けるのです(w

>>567
わかった！

Eiffelはクラスのメンバ関数の定義と
関数の中身の記述が離れたところに書けないよ。

面倒なので省略した。スマン。

別名定義　　　　　 : alias 既に存在する何か;
変数　　　　　　　　 : variable 型 = 値; //variableは普通省略
定数　　　　　　　　 : constant 型 = 値;
プロパティ　　　　　: property 型 get {実装} set {実装}; //getは"Result"、setは"Value"が暗黙に存在
メソッド　　　　　　　: [総称] ( 引数リスト ) -> 型 {実装}; //返り値を持つ時"Result"が暗黙に存在
メソッドポインタ型 : delegate [総称] ( 引数リスト ) -> 型 {実装};
列挙型　　　　　　　: enum { 要素リスト } ; //整数と文字型含む
部分範囲型　　　　: range 最小値 .. 最大値 ; //列挙型はそのままでも部分範囲型
フラグ型　　　　　　: set [ 部分範囲型 ] ;
参照型の配列型　: [ ] 要素型 ; //総称と同じ様に "型名 [ 部分範囲型 ]" で値型の配列を作れる
値型の配列型　　 : [ 部分範囲型 ] 要素型 ; //要素型が同じ参照型の配列にBoxing可
参照型のクラス　 : class [総称] ( 継承リスト ) { メンバリスト } ;
インターフェース　: interface [総称] ( 継承リスト ) { メンバリスト } ;
mix-inモジュール : module [総称] { メンバリスト } ;
値型のクラス　　　: struct [総称] { メンバリスト } ;

○型定義と変数宣言を同時に行いたい時はvariable明示(やはり型は記号を別にした方が?)
(例1) 変数 : variable enum {X, Y, Z};
(例2) 変数 : variable [1..10] Integer;

○オーバーライド時はスペルミス防止で明示的にoverrideと書く
メソッド : [総称] ( 引数リスト ) -> 型 override {実装};

○継承した型間で名前が被った時はクラス中のメソッド定義でaliasを併用して変更。
メソッド : [総称] ( 引数リスト ) -> 型 alias 継承した型のどれか.旧名;
メソッド : [総称] ( 引数リスト ) -> 型 alias 継承した型のどれか.旧名 override {実装};

○インターフェースやmix-inを他のオブジェクトに委譲するのはクラス中のプロパティ定義で行う
プロパティ : property 型 get {実装} delegate 継承した型のどれか;

…他に何かありましたっけ？(疲れた…C#寄りですけど叩き台にはなるでしょ)

訂正。メソッドポインタ型の "{実装}" は不要です

>>571
>>572
バーカ。
Rubyにはかなわず。

>>571
そこまで統一しちゃうなら省略可能なmethodキーワードも入れちゃった方がよさげ。

継承した型間で名前が被った時は
継承した型のどれか.メソッド : [総称] ( 引数リスト ) -> 型 override {};
のような形もご一考を。
名前のバッティングの解決のために別の名前をつけるってのはあんまり好きくないので。

delegateは、作るとしたらシングルキャストで、
マルチキャストはeventとか別キーワードを作るか専用のコンテナを。

あと、メソッドやクラスもすべて;で終わってるのは意図したものだよね。
特にプロパティは;がないとどこまでかわからないし。

forth

名前の衝突回避については、>>192を参考に。
特殊構文を入れたり、ユーザー（継承クラス制作者）が勝手にリネームするのは、
あんまりフールプルーフであるとは言えないと思います。

メソッドの仮引数ってどんな感じ？

method: (x : Integer, y : Integer, color : COLOR) -> Boolean {}
なのか、
method: (x, y: Integer; color : COLOR) -> Boolean {}
なのか。
(x, y : Integer, color : COLOR)はちょっとイヤ

>>566の様に、EiffelやObjectPascalは名前を変える方を選んでますし、
結局、定義からずっと同じ名前で使いつづけることができないのが嫌(C++, C#)、か、
常に オブジェクト.メソッド の形式で使えないのが嫌(Eiffel, ObjectPascal)、かの
選択になるのではないでしょうか？

>method: (x, y: Integer; color : COLOR) -> Boolean {}
>method: (x : Integer, y : Integer, color : COLOR) -> Boolean {}

前に、a, b: Integer = 0; みたいな初期化を認めるか？という話があって、
「複数同時の変数宣言は無くてもいい」ような意見を見た記憶が。

普段も複数同時宣言を認めるなら前者、認めないなら後者、でいいかと。

複数同時宣言は引数やローカル変数とかで確かに便利ですけど
型が同じだけで用途の全く異なる変数の宣言をまとめてしまうとか多々あるので
禁止することにも意味があるような、って感じで、僕はどっちでもいいです。

>>569
名前の変更は菱形継承にも使えるよ。

class SUPER
feature
　　a is do ... end
　　b is do ... end
end

class SUPER1 inherit SUPER redefine a end
feature
　　a is do ... end
end

class SUPER2 inherit SUPER redefine a end
feature
　　a is do ... end
end

class SUB inherit
　　SUPER1 rename a as a1 end
　　SUPER2 rename a as a2 select a2 end
end

sub: SUB
create sub
sub.a1　　-- SUPER1::a
sub.a2　　-- SUPER2::a
sub.b 　　-- SUPER::b
super: SUPER
super := sub
super.a　　-- select a2 なので SUPER2::a

>Eiffelの様に型がクラスしかなく、
>メンバの名前が衝突したときは名前を変更する方が

そんじゃEiffel使えば良いんじゃないかと言う気もするが。
名前変更の是非はともかく、型がクラスしかないと言うのは
明らかにやりすぎだし、実用的とは言い難いと思うが。
ストイックなまでにポリシーを貫く（ex Eiffel SmallTalk Lisp 初期のML等)
のも、言語としては悪くないけど、アプリケーションプログラム言語としてはどうかと。

と言うか、早く物を出そうと言う流れにしようとしたのに、
また案出しばかりになっているな。

とりあえず、案を出すのはやめて>>1-580に出た案の中から
採用、不採用を決めていかないか。
矛盾や足りないところも出てくるだろうから、
それについては問題が浮き彫りになったところで考えるか後回しに。

まず、言語のフィーチャーを決めてから構文決定に入ろう。
出来れば、標準ライブラリの基礎となるところも決めておいた方が良いと思う。

.NET/Javaの様なツリーを形成するのか
C++の様な離散的な物にするのか

前者だと言語仕様から強くライブラリのサポートが必要になるから、
基礎部分だけでも決定しなければならない。
後者だと、言語にあわせてライブラリを作っていく形になるから、
よほど仕様を練らないと汚い実装やつじつま合わせが必要になってくる

ツリーにしようよ。intやfloatもちゃんとObjectのサブクラスに。

classは参照型だから、intやfloatをクラスにしちゃうのはまずくない？

質問です。
コピーされるとメモリに情報が格納されます。
そのコピーされたメモリの情報の中の文字コードを
見るにはどうすればいいですか？
ちなみに言語はVCです。


やりたい事はVCの
ｍａｉｌｅｒでの文章をコピーし
ＶＣで作成されたウィンドウ上で貼り付けを行ったとき
その文字コードをみるソースをつくりたいんです。

ご存知の方アドバイスお願いします。

>>586 は誤爆なのでレスしないでください

結局SmalltalkやSchemeでおなじみの機能を
C風構文で実現できればいいって感じ？

拡張構文定義を実現できるなら、だけど
using syntax-namespace 'C-like'
とかで、複数の構文を使い分けできたらいいと思う。
デフォルトは個人の自由にして。

拡張構文を許すなら、switchとかはifの構文唐でいい気がする。
多分switchはジャンプテーブル最適化を掛けたいんだろうけど、
この手の最適化はifに展開しても間に合う気がするし。

>>558
うわ、しばらく見てなかったら、今作ってる自作言語の構文規則がもろに出てしまっている。
ひとりで厨房ライクにほくそえんでたのにー!!

やっぱ、似たような事は誰でも考え付くな...欝だ。

>>590
こんな奇妙な構文普通はあんまり考えやすいとは思えないから、
たぶんにこのスレの影響を受けて多と思われ

>>589
そういうの勘弁してください、yaccが使えなくなりそう。
タダでさえ、Genericsでの継承元の制限とかややこしくなりそうなので頭を悩ましてたり。
switchはifのシンタックスシュガーで良いと思います
case節に定数しか設定できないのは不便なので、どうせ逐次判定する実装になると思います。

厨房ライクに反論するけど、これを考えたのは去年の10月ごろか、その近辺。
でも、もう書き込まれちゃった以上、特許と同じだーね。

どーせ、おいらは敗北者さ。まじ欝。

とりあえず、実装をここより早く作る事を考えよう...

>>593
関数の引数も返値もセットで型情報とか、
その辺ほんとに一人で仕様作ってたならすごいと思うからがんばって作ってくれ。
俺はその案が出たとき なるほど、良いかも なんて思ってたヘタレだが。

別に勝利敗北なんて関係ないんで、気にするな。
しかしココは言語開発スレだから、自作言語の宣伝をするなら
良いと思う仕様やアイデアを説明してくれた方が趣旨に添っている。

一緒に参加してくれるなら大歓迎！
自慢したいだけならｶｴﾚ!
と言ったところだ。

C#のBoxingはあんまり使いたくないです
型情報が失われてしまうのは痛い

↓こういうのがいいなぁ

valVariable: int = 10;
refVariable: int* = valVariable; //refVariableは参照型

すべてのstruct/enumなんかの値型は後ろに*をつけることで
参照型にすることが出来ます
上の例はint型をint*型にBoxingしています。

イメージは↓のように

IBoxed: interface[ T: struct ]
{
　Value: property get{} set{};
}

BoxingClass : class[ T: struct ] ( T, IBoxed[ T ] ){}

int* : alias BoxingClass[ int ];

valVariable: int = 10;
refVariable: int* = new int*( valVariable ); //refVariableは参照型

int*はintとほとんど同じように扱うことが出来ますが、
代入やパラメータに渡すときに参照型の特徴が出てきます
比較はC#のstring同様値比較だと何かと幸せです（が問題もあります）。
代入が参照先の変更になるので、元の値を変更するためのValueプロパティを持ちます。

int*はintへの暗黙の変換を許します（Unboxing）
（型情報は失われていないので安全です）

以下例

val1: int = 100;
ref1: int* = val1;
ref2: int* = ref1;
ref3: int* = ref2;

ref2 = 200; //ref2の参照先を別のint*オブジェクトにします。val1/ref1/ref3には影響ありません

ref3.Value = 300; // ref3の参照先の値を300にします。ref1も300になります。val1には影響しません

Unboxingの際に参照先がnullの場合は例外が出されます

問題は、Boxing/Unboxingがあまりにシームレスに行われてしまうので、
Unboxingの際のnullアクセスのミスを犯しやすくなるかもしれません。

Boxing演算子&とUnboxing演算子*を導入して

ref4: int* = &val;
val2: int = *ref4;
//（C++に似てますがやってることはちょっと違う）

などとすると注意も促せるかと
（ただし、値型と参照型を同じように扱えなくなるのでtemplateは作りにくくなるかもし得れません）

>代入やパラメータに渡すときに参照型の特徴が出てきます
代入はともかく、クライアント側での変数定義が関数側に影響が出るのはどうかと。
確かに、ref/outの様なキーワードは必要なくなるけど、
値型を受け取る関数は常に２つのインスタンスを生成することになるんじゃないかな

>>596
intとint*は同じインターフェイスを持つだけのまったく別物になると思ってください。
intを受け取るメソッドにint*を渡すことは出来ないし、
int*を受け取るメソッドにintを渡すことは出来ません。
（暗黙の変換を許可するなら可能ですが）

そうなるので、必ずしもref/outとして扱うことは出来ないと思います

//メソッド定義
swap: ( left: int*, right: int* )->void
{
　tmp: int;
　// tmp = left; left = right; right = tmp; ではダメ
　tmp = left.Value; left.Value = right.Value; right.Value = tmp;
}

//呼び出し元
a: int = 10;
b: int = 20;
swap( &a, &b ); // a, bの値は変更されません
// &はアドレス演算子ではなくBoxingを行います

ra: int* = &a;
rb: int* = &b;
swap( ra, rb ); // ra, rb の値が変更されます

>>597 解説ｻﾝｸｽ、ちょっと勘違いしてただけだった。

そのー、なんで参照型だけしかクラスになれないんでしょ？
そうでない言語もあるし、型付き言語なら別に効率も悪くならないと
思うんですが。

>>599
GC搭載したりするのが面倒だから。
スタック中のオブジェクトをスキャンしたり、
例外処理発生時のアンワインドを導入したり、ね。

GC搭載したりするのが->に

>>595
int*はJavaのIntegerクラスを自動生成するようなものですね。

参照と実体関連はC#が一番エレガントな気がする。

>>603
どの辺が？

>>595
型付きBoxingはいいかも。Objectクラスと両方用意しても何も不都合ありませんし。
( でも、C/C++式のポインタ演算子の順序は問題ありなので
定義は A: Integer*; では無く、A: *Integer; がいいし、
Unboxingは、*A では無く、A* がいいです。理由は何度も既出 )
Boxing/Unboxingは暗黙でいいと思いますけどね。

…しかし、これを許すとclass/structを分ける必要は無くなり、全部structでいいのではないかという考えが。
ルートになるObjectをまさか値型にするわけにもいかないので、逆はどうですか？

つまり、全ての型は基本的に参照型であり、列挙型や実数型、固定長配列、Object以外何も継承していないclassなど
一部の型を、値型として宣言できる、という寸法です。(structは廃止)

A: Integer; //参照型
B: ! Integer; //値型("!"はてきとー)

比較演算子は常に値の比較(演算子オーバーロードのメソッドが呼ばれる)として、
それとは別にアドレス比較演算子(オーバーロード不可、参照型のみ)を設けたらどうでしょ。

名前の衝突の件ですけど、僕は「常に オブジェクト.メソッド の形で使いたいので名前を変える」
方がいいと思ってはいますが、流れ的に オブジェクト.親の型.メソッド になりそうなので
防衛ラインみたいなものをはっておきます(w

この言語の場合、主流(Objectからclassとして継承してくる流れ)と伏流(mix-inやインターフェース)
が明らかなので、衝突した時も、型を明示しないといけないのは伏流から継承したやつだけにしてください。
要するに、WindowクラスにFocusメソッドがあったとして、同じくFocusメソッドを持つHighlightインターフェース
と多重継承してHighlightListBoxみたいなのを作った時、単にFocusと書いたら
C++のようにエラーを出すのでは無く、Window.Focusを意味するものであって欲しいということです。

あくまで防衛ラインで、本命は名前変更(やはり伏流の方を変える形で)希望ですけど。

>>582
アイデアの取りまとめ人が必要では？
定期的に決定事項と未決事項をまとめてくれる人が。
今のところ39さんしかいないが、39さんが誰かに委任してもいいと思う。
( 自分の好みを捨てられる人で無いと務まらないと思うので、私は資格無いですけど )

>>604
boxingとか、intとかも継承できるところ
structでユーザー定義の値型を作れるところとか。
まあチラッと仕様書みてサンプルコンパイルするくらいしか触ってないけど。
実用性第一に考えると値型は拘ったほうがいいと思う。いかにも静的言語って感じになるし。

追加
intとかも実はSystem.Int16の別名で値型はstructで統一されているところ。
値型にもメッセージを送れるところ。(123.ToString()とか)
値型の配列を用意してきたところ。

あ、でも595, 605の案気に入りました。今読んで空気読めましたゴメソ。

値比較 A = B
アドレス比較 A == B
代入 A := B

を提案。やっぱ = は値比較以外に考えられません。

>>605
実は同じ事考えました。
ですが、C++erとしては直感的じゃなかった事と、
値型->参照型の時と違い、参照型->値型にすると、
値型にされちゃまずい参照型まで値型にできてしまう問題があるように思います。
（ふつう参照型にされてはまずい値型は無いので）

// Form は class (参照型), *Form は値型とする
myForm: *Form;
myForm.Text = "いろいろ";
myForm.Show();

this.AddChildForm( myForm );
// このメソッドは Form オブジェクトを受け取るので、
// （明示・暗黙はともかくとして）Boxingが行われる
// Boxing は内容を複製するので、ウィンドウがもう1つ表示される？

というわけで、>>595 のような型つき Boxing を導入しても、
struct/class の区別の必要性がなくなることは多分無いと思います。


あと、参照先の比較は従来どおり == を使い、値比較演算子を導入したほうがいいのではないかと思います。

== は値型であろうが参照型であろうが変数の中身の比較、として、
=~ は値型であろうが参照型であろうがオブジェクトの中身の比較、としてはどうでしょうか。
（記号は適当）

aInt == otherInt; // 変数同士の比較、値型なので結果的に値比較
aForm==otherForm; // 変数同士の比較、参照型なので結果的に参照先が同じかどうか比較

aInt =~ otherInt; // 変数のさしているオブジェクト同士の値比較、値型なので == と同じ
aForm=~otherForm; // 変数のさしているオブジェクト同士の値比較

（あくまで =~ は説明のために適当に考えたもの）

>>606
> 衝突した時も、型を明示しないといけないのは伏流から継承したやつだけにしてください。

もちろんそうなるとべきだと思います。
名前変更は、39さんがあまり乗り気ではないようなのでどうなるか分かりませんが、
名前: alias 旧名
という構文もつくる方向らしいので、
それを使用して同じことが出来るのではないでしょうか。

私は名前変更について乗り気でないと言うより、
安全じゃないんじゃないかな、と考えているだけです。
基本ライブラリの class.method1 を、
利用者または中間ライブラリの作者が class.method2 に名前を変更した場合、
そのクラスを利用する人が名前を変更されていることを知らなければ、
わざわざクラス定義を見に行かなければならなくなりますよね。

class.InterfaceName.method()だと、クラス名が衝突しない限り
完全に一意の名前になりますしね。
これが大して問題にならないなら良いと思います。

エイリアスはあると便利だと思うので、>>606のように実装継承
してきた側のメソッドが自動的に使用されるようにしたいとは思いますけど。

Boxingはどちらにしろ必要になりそうですが、構文は考えたほうが良さそうですね。
C風の構文で値型からBoxingへの代入に暗黙にコピーが生成されたり、するのは
ちょっと直感的じゃないです。

それから、>>605の案は無理だと思います。
継承して無くてもクラスオブジェクトをメンバに持つクラスの場合
スタック中のオブジェクトの中をスキャンしないと参照のリンクを完全に把握出来ません。

それから万が一C++と同じデストラクタを導入した場合、
キッチリスコープエンドで破棄される必要が出てくるので、
巻き戻し中のデストラクタ呼び出しチェーンを作らないといけないので、
例外処理もやたらと遅い物になると思います。

>>612
基本は参照アドレス、ハッシュ値の比較で同一オブジェクトの比較のみ自動定義で、
値の比較はクラスごとに意味合いが違ってくる可能性もあるので、

同値比較は.equals等のメソッドで行うようにガイドラインを作るだけで良いと思います。
stringクラスあたりで比較がちょっと面倒になっちゃうのが問題だと思いますが・・・

同値比較はクラスごとに定義しないといけない場合がほとんどなので、
=~は人間が定義することになるし、オペレータオーバーロードを導入することになる。
また、オペレータオーバーロードを導入するとしたら、
==の意味づけはダレでも勝手に再定義出来ちゃうので、無意味かと。

バイナリスキャンして勝手に比較した方が良いのかな。

>>616
演算子オーバーロード欲しい派の私としては
+, -, *, /, %, &, |, ^, ~, <<, >>, <, <=, =~
のみをオーバーロード可能にして、
（>は<の左右入れ替え、等残りは自動的に生成できるはず）
==はオーバーロード不可能にしてはどうでしょう。

参照型のとき、==は同じオブジェクトをさしているかどうかを調べて、
値型のときは、内部的に=~を呼び出す。（=~が定義されていないときはエラー）

もちろん=~ではなくequalsでもいいのですが（記述が違うだけでやることは同じですから）、
Javaなんかでstringにequals使うの忘れて誤作動なんて経験があるので、
専用の演算子があったほうが私はいいかなと思います。

オーバーロードは
+ - * / の２項演算子バージョンだけに限定していい気がする

あとは同値判定の=~（暫定）か。

== と != はオーバーロード不可の参照比較「専用」として(右辺左辺どちらかが値型ならエラー)、

比較演算子は、

operater = :(A, B: SAMETYPE) -> Integer

か

operater = :(A, B: SAMETYPE) -> Boolean

のどちらかの形で定義し、
上のときは = > < >= <= /= が使えるようになり、
下のときは = /= だけが使えるようになる。ダメですか？

代入は、<- または := がいいと思います。

>>615
structはメンバーに参照を持てないということですね。了解しました。

ということは、値型の配列も同様か…。
(少し考える)…長さ固定の配列は、データテーブルとか
APIに渡すバッファーぐらいにしか使って無い気がするし、
そもそも値型の配列は参照型の配列で完全に代用できる…

うん。値型の配列の要素に参照が使えなくても問題無さそうですね。

値型のインスタンスもスコープエンドでdestructされる必要が無いなら問題ないかな。
と言うことで、デストラクタって必要だと思う？>all

>>620
代入式、単項インクリメント、デクリメントの戻り値はnil/voidが良いと思います。
それから、式中の関数、メソッド呼び出しも何らかの形で制限した方が。

シーケンスポイントの問題が出てきそうです

>>622
ObjectクラスにprotectedでvirtualなDestructorメソッドを用意しておいて、
参照型はGCで回収される時、
値型はスコープエンドで、それが呼ばれる、とか。
値型にもデストラクタがあるならstructも参照型のメンバーを持てますし。
…ただ、効率とのトレードオフになるので、
割り切って値型は参照を持てずデストラクタも無しというのも有りと思います。

ところで、メソッド定義がこの形になった今、voidって必要ですか？

Method: (Arg: String) -> void { ... } ;
Method: (Arg: String) { ... } ;

後者でいいと思うのですが。というよりもそこまでCを引きずる必然性が疑問。
( 最後のセミコロンの理由は >>574 )

>>623
言っていることには賛成します。
でも620では = は値の比較演算子のつもりなのですけど、誤解してません？

Javaのように算術演算子の呼び出しでは文を終われない、とかしてもいいかも。

可

A <- B; //代入
++ A;
-- A;

不可

A + B;
A = B; //比較
A == B; //参照比較
- A;

うーむ、折角genericsがあるのですから、++と--は要らない気が…。

Next: [T: 列挙型] (Var: ref T) { Var <- Var + 1 } ;

Next(A);

多値を返すとかできない？
つーか意味無い？

考えてみれば、値型が参照を持てないということは、structがStringを持てないということになるような…。
いや、それ以前に自分が>>622を誤読していた気が…。
ということで624の前半は無視して下さい。

やっぱり言葉足らずだったか。
値型がデストラクタを持つなら、スコープエンドで呼び出されるのが自然なので、
関数呼び出しの深い位置で例外が起こると当然キャッチされるまで
スタック中オブジェクトの回収で、>>615で言ってるように
呼び出しリストを照会しながらデストラクタコールが必要になるから、
例外処理も大変になるような。

スタックのオブジェクトもスコープエンドじゃなくてGCで回収されるなら
この問題はなさそう。

>>620
== は値型でエラーといわずに C++ の == と同じ意味であって欲しいです。
参照(C++のポインタ）なら p1 == p2; // p1 と p2 が同じオブジェクトをさしているかどうか
値なら v1 == v2; // v1 と v2 の値が同じかどうか

ところで、演算子はいいかげん決めるべきと思いますが、
代入は = であって欲しいです。
代入はプログラム中でも登場回数が最も多い演算子の1つかと思いますが
:=, <- など2文字打つのはちょっと面倒です。

現在の課題（？）

・ボクシングの構文
・メソッド名衝突時の解決方法
　・名前の変更
　・エイリアスで代用、主流（実装継承）以外の名前は、
　　明示的にエイリアスを書かない限り隠れる
　　元モジュール名.メソッド名() として呼び出す
・スタックオブジェクト回収のタイミング

宣言形式については概ね出てきている形式で決定の方向で
>Class: class[generics](super, interfaces, modules) {}

= 演算子については、いっそ廃止と言うのはどうでしょうか？
Cの代入、Adaの比較のように複数の意味で使われているので、
どっちにしろ混乱はあると思うので。

代入は
a := b
a <- b

比較はC++の
a == b

これなら他の意味にはとらえづらいと思いますが。

む、>>620=625の通りで値比較として、明示的に定義しないと使えないのなら混乱も無いか。

Eiffelの構文は分からないので柔軟なエイリアスで十分同じことが出来る気がしてしまって、

名前の変更で行った場合どのような記述になるのか、教えてもらえますか？

age

mix-inモジュールの場合、実装を持っているから、interfaceと違って、
メソッド名が同じだからといってモジュール名が同じとは限らない。
だからモジュール名を明示的に書かなければならないやり方だと、
多態したいときにやっかいなことになると思われ。
そして毎回エイリアスを書かなければならないとなると、
mix-inを継承するだけでインターフェースと実装を再利用できるという
良さが失われてしまう。
衝突しないときはやはりObject.method()式に呼び出したいです。

個人的にはメソッド名の衝突の解決には、CLOS風のモジュール間に優先順位を
持たせるやり方が好きです。
メソッド名が衝突した場合、優先順位の高い方のモジュールのメソッド名として
解決。優先順位の低い方のメソッドを呼び出したいときだけ、モジュール名を
明示したらいいと思うのですが。

衝突しないときのObject.method()にはダレも反対する奴は居ないと思うけど。

優先順位はこんな感じで

1.自クラス内で定義したmethodと明示的にaliasしたもの
2.親クラス
3.module/interface

3のmodule/interface間は優先順位を定義せずに、あいまいなときはエラーを出すべきだと思います。
（そういう時は明示的にaliasするべき）

明示的にエイリアスしなかったら？
Object.module.method();
それとも、見えなくする？

　　薄い色は濃い色に染まりやすいが、気持ちを和らげてくれる。　　　　
　　　アメリカやヨーロッパばかりゆきずらせてはならないのだ。　　

　　和をもって尊しとなす

>>638
C++のように継承にprivateやpublicつけます？
経験的にpublicがほとんどなので、つけるとしたらデフォルトでpublicがいいでしょうけど。

>>638
Object.method();

>>641
638はモジュール間で名前がぶつかった場合の話じゃなかろうか

>>629
値比較と参照比較を混同できるような仕様は、バグの元と思うのですけど…。
それに、自分は = は値が等しいという意味(イコール記号の本来の意味)であって欲しいと強く思います。
で、そうするとC++の　== が宙に浮くので、それは参照比較、と。

代入の <- は、関数定義が -> なので、意味的にちょうどいいかなぁと思って。

これって一旦他のOO言語やCにトランスレートするの？
それともいきなりアセンブラやオブジェクトコード吐いたりする？
できればCに落としてほしいです。
gcが入ると厄介かもしれませんが。

>>642
Object.module.method();

>>640
それは…それなら、aliasしないと衝突エラーを出すか、
Object.Module.Methodのどちらかでいいと思いますけど。

>>643
値型の値比較と参照型の参照比較は混同するものではなく、そもそも同一のものなんです。
参照型の変数の値を比較するということは、すなわち同じオブジェクトを指しているかということです。

>>647
それは理解しています。
しかし、オブジェクトの比較は個々でオーバーロードするべきであり、
参照変数の比較は常にアドレスを比較しなければいけない(オーバーロードを許してはならない)という特徴があります。
さらに、ふたつの参照が指している中身を値比較したいばあい、値比較と参照比較が同じ記号だと、
明示的にUnboxingを行わないとオーバーロードした値比較演算子が呼べないのではないか？という疑問もあります。
他のメソッドも演算子も値と参照で同じように呼べるのに、比較演算子だけ気を遣わないといけないのは、
むしろそちらの方がデメリットではないかと。

私が提案したいのは、
値比較 <-> 参照比較
という区別ではなく、
変数比較 <-> オブジェクトの中身比較
という区別にしてはどうか、ということです。

たとえば>>643の意向を汲んで変数比較を==、オブジェクト比較を=とすると、

==は参照型に対しては、同じオブジェクトを指しているかどうか、
値型に対しては独自にオーバーロードした=が成立するかどうか、
ということになりオーバーロード不可能。

=は、参照型だろうと値型だろうとオブジェクトの中身が同じかどうか、
ということでオーバーロードしなければいけません。

基本的な主張は>>648と同じで、
ただ値型に対しても==が使えるようにするべき、というだけです。

ああ、そういう意味でしたら納得です。
参照でも値でも同じように a + b や a.Method が使えるのに、
比較だけC++のように、a == b と *a == *b を使い分けないと駄目なのか？と思ったので。

operator = を意図した時は常に = を用い、変数そのものを比較したい時は常に == を用いる、と。
それなら、Unboxingを仮に*aとすると、
「a = b」 と 「*a == *b」 が同じ意味となり、何となくC++の==の意味も生きているっぽいかな…

そうです。（ご理解thx）
変数比較==（仮）はC++の==と同じ意味で変数同士を比較し、
オブジェクト比較=（仮）はJavaのequalsと同じ意味でオブジェクト同士を値比較します。
（あくまで提案ですが）

>>581
> そんじゃEiffel使えば良いんじゃないかと言う気もするが。
そうですね。
これからは提案ではなく参考意見としてレスします。

>>595
Eiffelのクラスは参照型と値型(expanded type)があります。

値型の INTEGER と REAL は
参照型の NUMERIC と COMPARABLE のサブクラスです。

NUMERICやCOMPARABLE に INTEGERやREAL を代入すると
参照型の INTEGERやREAL に変換されます。
型情報は失われません。
(参照型のオブジェクトは型情報を持っています)

値型の変数として宣言できるクラスとできないクラスがあります。
(クラス定義で指定します)

val: expanded FOO　　-- 参照型のクラスを値型として宣言


また、制限ありの総称の場合
class FOO inherit COMPARABLE　　-- FOOは参照型

class BAR[T ->COMPARABLE]

[T ->COMPARABLE] は仮総称パラメータで
COMPARABLEを継承しているクラスに制限するという意味。

a: BAR[INTEGER]
b: BAR[REAL]
c: BAR[FOO]

みたいに、参照型と値型のパラメータを一緒に制限することができます。

INTEGERやREAL は expandedを宣言に付けなくても値型になるように
クラス定義されています。

a: INTEGER　　-- 値型の INTEGER
b: REAL　　-- 値型の REAL

>>652
Eiffelは参照型のものを値型に変換できるのですね。
Boxingとは逆の考え方で>>605と同じ感じですね。
で値型に出来ないように制限することが出来る、
ということで>>612の問題は回避しているわけだ。

総称の制限は
[ T: typename( COMPARABLE ) ]で T は COMPARABLEを継承している型に制限、という形がいいんじゃ無いかと思います。
[ T: class( COPMARABLE ) ] で T は COMPARABLEを継承しているクラス
[ T: struct( COMPARABLE ) ] で T は COMPARABLEを継承している構造体

[ T: typename( COMPARABLE, COUNTABLE ) ] で T は比較できて、数えられる型、
という風に複数の制限をつけられます

[ M: delegate( p1: int ) ] として、M はint型の引数を1つ取るdelegate、なんていう制限方法も出来るかと。

>>614
名前の変更を誤解しているみたいなので。
俺の勘違いだったらスマン。

class A
feature
　　f is do .. end　　-- *1
end

class B
inherit A rename f as g end　　-- 名前を f から g に変更
end

a: A
b: B

create a　　-- コンストラクタ
a.f　　-- *1 が呼び出される

create b　　-- コンストラクタ
b.f　　-- コンパイル・エラー
b.g　　-- *1 が呼び出される

a := b　　-- A型の変数にB型のオブジェクトを代入
a.f　　-- *1 が呼び出される
a.g　　-- コンパイル・エラー

　　　　　　　　　　　　　　　
　　　　　
a [@:d]　　　　　　a -> d
d + a　[@:a]　　　 d + a -> a

a(-)d
a<->d　　　　　　a  =  b
a(=)d
a<=>d　　　　　　a == b

<a d>

　@ がいいよ
^^　押しやすいし‥‥
　　
　　

>>655
名前の変更と、aliasはほとんどの場合同じことですよね。
違ってくるのは上位クラスのメソッドがvirtualだったときで、

A: class
{
　f: virtual ()->void{}; // *1 virtual の書き方は知ったこっちゃ無い
}

I: interface
{
　f:()->void;
}

// 名前変更の場合
B: class ( A, I )
{
　g: renameof A.f; // A.f を g と名前変更する

　f: ()->void{}; // A.f は別名に変更されたので、単に f と書いても A.f はオーバーライドされない、ここでは単純に I.f を実装する

}

// alias の場合
B: class ( A, I )
{
　g: alias A.f; // g を A.f と同じ意味とする

　f: ()->void{}; // 単に f と書くと A.f をオーバーライドしたことになる、I.f は実装したことになるのか？
}

>>655
解説どうも。
しかし、たとえばclass Bでfを定義すると、
A.fとは全く別の物になりますよね？

クライアントがclass Aのfを期待して呼び出したつもりが、
全く別のfが呼ばれていると言うことになりますよね？

分割コンパイルについて、テキストではなく
中間コード形式のバイナリで保存するのを考えていますので、
場合によってはクライアントが実装の宣言を見ることが出来なくなります。
こうなってくると、ドキュメントを完全に信じないといけないことになりますので。

分割コンパイルというか、モジュールの配布方法ですね。

代入を、
name <- value;
にするんだったら、関数宣言もこうすんのはどうよ。
method result <- name(arg: type): type;

以下は、適当ﾅﾝﾀﾞｹﾚﾄﾞﾓ。

class hoge(Interface1, Interface2, Mix-In-Module): SuperClass {
private:
constant MAX <- 256: integer;
variable count <- 0: integer;
method result <- getHoge(arg: integer): integer;
method setHoge(arg: integer);
public:
property hoge: integer get getHoge set setHoge;
}

何かｶｺﾜﾙｲな。
数学でも左向きの表記はしないだろう

言語名は SendohOhkushiteFuneYamaNoboru = SOFYN に一票。

言語名は是非 natto で

<- より <= のほうが書きやすいのですがダメですか？

比較演算子が・・・
<-じゃなくて := で良いと思うんだけどなぁ

>>665
modula方式ですな。

<->
  ->
  <-　　　　　　というか

辞書みたいなんはないんですか？

ってゆーか<-はおかしいだろ
+=や-=はどうすんだよ
+<-
-<-
ですか？
代入は:=にして
:=
+=
-=

variableとか記述的なクソ長い名前なんとかなんない？
varでいいだろvarで。
propertyはpropだろ。
代入は=。 :=は打ちにくいから却下。
比較は==。eqでもいいけどな。
あと、個人的には大文字小文字入り乱れてるソースは読みにくいから、
ライブラリとかは全部小文字にして_(アンスコ)で区切ってくれ。

>>669
ヤダ♪

打ちやすさより読みやすさの方がずっと大事だろ。

>>670
言うこときけ

>>671
>>660みたいなのは読みにくいよ

>>669
variableは省略可能だろ。
大文字小文字入り乱れてるソースが読みづらいのは個人的に同意。
しかし、世間の流れがそういう方向じゃないので却下だろう。

>>669
小文字化については、はげしく同意。
例えばgetHogeだと、小文字から始まってるのにいきなりHで大文字になるから
一瞬Hなのかl-lなのかわかんなくなる。
get_hogeが妥当でしょ。

GetHogeだろゴルァ！

<-
↑これって、昔のSmalltalk？
それともHaskellのﾓﾅﾄﾞかな？

まあ大文字小文字論争は他のスレでやろうや。

今>>678が良いこと言った！
って言おうとｵﾓﾀが、くだらないレスつけすぎて駄スレ化思想だから思いとどまった。

大文字で書くか小文字で書くかは趣味で良いと思うが、
GetHomeとgetHomeとgethomeを同時に使うような馬鹿が
出現しないように、名前の大文字小文字は区別しない
ことは必須だと思う。

>>680
だからget_hogeにすれ。
gethogeだと一見、なんだかわからん。

とりあえず>>657の最後の？マークについての意見をお聞かせください

>>680
case-sensitiveには対応すべき。
対応してないとpascalやschemeみたく教育用に成り下がる恐れがある。
DelphiではDLLのAPI呼んだりするときに結構問題だったでしょ。
モードで切り分けできればいいけど。

大文字小文字って、XMLは区別するんだよね。
HTMLは区別しなかったのに。

書く方はGetHomeでもget_homeでも好きに書けばよいじゃないか。
処理系側は区別しない方が良いと思う。

処理系が区別すると言うことは、
GetHomeとgetHomeとgethomeを同時に別の名前に使える(そういう
使い方を支援する)ってことだ。
それは害があって利益がないと思う。

<a> / 3 + 4

ディレクトリ風って感じで、
< > でかこったのが変数、
そのあとの / はディレクトリの記号。
その右側のが、計算して、a に代入される値。
<a> の変数には、3 + 4 で、7 が代入される。

<a>/ a + b /
<b>/ 6 -(a + d) /2 c

とかだと、<a>は a + b と <b> の合計になって、
ときには <a> の部分(a+b) だけとり出せたりとか。
んで、<b> には、 6 -(a + d) /2 c の答えが入ったりするって感じ。

　変数をかっこでかこってもいいし、式をかっこでかこってもいいし、
/ が割り算とややこしかったら別の記号にしてもいいし。

　まあいろいろやりやすいように、やってみてくださいﾁｭﾝ♪　　(●＞ 　　　

>>686
誤爆？

>>644
GCの実装の話もでてるから独自VMだと思う。その方がVMを都合よく設計できて楽かもね。
既存のライブラリとの接続はDLL呼べればいいし。

>>688
じゃあVMの設計もやるんですか？

>>685
>処理系が区別すると言うことは、
>それは害があって利益がないと思う。

case-insensitiveであるべきという考えですか？


>>688
今考えているのは、x86/win32ネイティブのみですよ。
VMはデバッグ用やその他アプリ組込用なんかのために後から作ります。

>>689
設計というか、ほぼまるまる手本になるVM(JVM)があるんで、
それを参考に車輪の再発名でもやりますよ。
.NETのようにVMレベルでセキュリティチェックしたりするほど
大がかりな物じゃないんで、ここで設計するまでもないです。
簡単なスタックマシンで実装するって事で。

>>690
そう。case-insensitiveにしておけばそういう無意味な
ことはできなくなるでしょ？

標準ライブラリなどの大文字小文字表記の慣習はまた
議論で決めれば良いが、どうしても納得が行かない人は
従わないこともできる(case-insensitiveにしておけば)。

>>690
そうなんですか。39さんパワフルなＰＧみたいなのでこれは期待できるかも。

GetHoge getHoge get_hoge
case-insensitiveでも前２つしか対応できない。
前２つのスタイルの違いはあまり問題にならないが、
重要なのは前２つと３つ目の違いだと思われ。

んー、case-insensitive/sensitive
はコンパイラオプションによって警告を出す程度にしておけば問題ないのかな。

>>694
良く主張がわからない。
getHome等とget_homeも同時に使えないような言語仕様にしろと言うこと？
それとも、GetHome, getHome, gethome, gEThOme等を防ぐだけだと
「満点じゃないから０点」ということ？

case-sensitiveにするメリットは別にないんだから、満点じゃなくても
case-insensitiveにして損はないと思う。

(ところで些細な話だけど、GetHomeとgetHomeとget_homeだけじゃなくて
localtimeとかgethostbynameとかの流儀もあるんだよ。)

>>687　いや

「名前の中の_は無視する」というのは良いかも知れないな。
そうすればgethomeとget_homeを同時に定義する馬鹿もなくせる。

>>696
メリットがないと言い切る根拠は？
現在メジャーである言語のほとんどがcase-sensitiveを採用していることから
何らかのメリットはあるんじゃないの？
原初のBASICはcase-insensitiveだったんだし、それを引き継がないでいるんだから。
漏れには全く具体例が上げられないけど

>>698
そんな奇妙な加工をしたら _ に意味を持たせることが出来なくなるじゃないか。

>>696
誰もメリットが挙げられないならメリットはないんじゃないの？
それに「ほとんどのメジャーな言語」ってC, C++, Javaとかの
C系の言語(つーかUnix文化)がメジャーだからそう思うだけでは。

別に「case-sensitiveの方が優れているから最近そうなった」わけ
じゃない。C以後もcase-insensitiveな言語は多く出てきている
(Modula-2, Oberon, Ada, Common Lisp, Schemeなどは全部ci。)

Unixの「case-sensitive everywhere」ってのは、どちらかというと
おちょくられているのを良く見かける。「そーか、gEThOmEと
GethOmeとgeTHoMeと...を全部作りたいんだね？」みたいに、わざと
caseをばらばらに書いたプログラムを見たことがある。

>>699
case-sensitiveは、無用な_を防ぐという目的から広まっていると思う。
プライベートなフィールドにtext、パブリックなプロパティにTextなんて使い方が行われるからね。

あとcase-insensitiveは、

system.io.path.getfullpath

みたいに、全部小文字で書いちゃったりしてOOPLとの親和性が低いんじゃなかろうか。

getHomeよりGetHomeが好きなのでライブラリがgetHomeだと萎えるし
そういうの自由だから最近だと逆にcase-insensitiveの方がいいかもしんない。

textとTextとTEXTを別の意味に使うってのがまた欝なところだよな。

> あとcase-insensitiveは、
>
> system.io.path.getfullpath
>
> みたいに、全部小文字で書いちゃったりしてOOPLとの親和性が低いんじゃなかろうか。

え、逆だろ？ case-sensitiveだと、決めたcaseで書くことを
「強制される」。case-insensitiveなら
system.io.path.getFullPathのように書く自由が与えられる。

>>702
でもローカル変数でnameって使ったら属性のNameは隠れるのか・・・それは嫌かも。

>>704
その自由が、自分で書くときはメリットになるが、他人が書いたのを読むときにはデメリットになる。

OOPLを全部小文字で書かれたら激しく読みにくいと思われ。

>>706
そういう「ありもしない可能性」で言うなら
gEThOmEとかgeTHoMeとか書かれる方が読みにくいと思うが？

>>707
全部小文字はぜんぜん「ありもしない可能性」じゃないだろ。

だから書き方の慣習は標準で決めておけば良いじゃないか。
AdaだってModula2だってそうしてる。

厨房は「case-insensitiveだから全部小文字で書ける」なんて
いうことに気が付かないだろう。

わざわざ逆らうやつは、それだけの理由(主張)があるやつだろ
う。「逆らう自由」を奪って「getHomeとGetHomeを同時に使う」
ことを奨励するなんておかしいよ。

>>708
getHomeとGetHomeを混ぜるのだってありもしない可能性じゃないぞ．
実際にその手のCソースは何度も見た。
(openFileとopenfileとOpenFileが同じファイルにあった。)

あーあ。別スレでやれって忠告してやったのに。
こんなの結論出ないんだから。
実装について考えれば些細な問題だろーが。

>>701
>(Modula-2, Oberon, Ada, Common Lisp, Schemeなどは全部ci。)
言語仕様はおいといて、製品として出てる様な処理系は外部との
インターフェースのためにcase-sensitiveに対応してるよ。
例えばACLとかはモード切り替えでね。
DelphiはDLLに対してのラッパーを作るとか。

読みにくくするもしないも、その人の責任だと思う。言語の責任じゃない。

とりあえず、オプションで選択できるようにして、
標準は折を見て決めると言うことでci/csの議論は終わりませんか
何か不毛だし。

確かにAdaで

with Ada.IO_Exceptions;
with Ada.Streams;
with System;
with System.File_Control_Block;
with Ada.Text_IO

なんてのを全部小文字で書いてるやつは
見たことがない。

俺は郷に入っては郷に従え派なんで、
getHogeだろうがGetHogeだろうがget_hogeだろうがかまわないけど、
case-insensitiveで書く人によって記述が変わるのはちょと勘弁願いたい。

>>711

>言語仕様はおいといて、製品として出てる様な処理系は外部との

今決めてるのは言語仕様じゃないの？

>インターフェースのためにcase-sensitiveに対応してるよ。
Cとのインターフェース用だろ。やっぱcsを広めたCがアホだな。

>>715
記述が変わるとなぜ思う？
実例からするとそんなことは起きてないが。

>>716
記述が変わらないならなぜcase-insensitive？
getHogeが嫌だから自分で勝手にGetHogeにしたいってのが
case-insensitive派の主張じゃないの？

といっても、漏れもこの問題は不毛と思うので後回しで。

>>716 もうやめとけ。続けるなら別スレ立てろ。

>>711
ciな言語とのインターフェースだけ
ciな仕様にすれば問題ないよね。

マジこの話やめない？
今までのどの仕様検討よりも明らかに流れが速いし、レス消費も異常。
どこで議論しても平行線だし、勿論多少は意味があるだろうけど、
ほとんど各人が好みをいつまでも言い続けておわっちゃうからさ。

>>717
>>685

──────不毛な論争は終結しました──────
（続けたい人はスレ立ててね）

スコープルールだが、
「local変数は外側の変数を隠す」っていうのは良くないと思う。
CLUやJavaのように、名前がぶつかったらエラーにするべきだ。

グローバル名前空間から検索する時getHomeが無かったら→GetHomeも探すってすればいいかも。

>>723
もっと厳しい提案も聞いたことがあるな。
「global変数はimportしないとメソッドの中で使えない」

>>723
なにいってんの？
それはコーティングスタイルが悪いってことなんじゃない？

Javaに慣れた俺には>>723は自然に思えるが>>725は勘弁。

>>726
良くないからエラーにすべきってことでわ

「コーディングスタイルを語るスレ」でも立ててくれ。

不毛な論争についてはスレ立てときました。

「case-sensitive vs. case-insensitive論争」
http://pc.2ch.net/test/read.cgi/tech/1022352006/

>>726
うん。確かに、
{ int x;
　...
{ float x; ...
みたいなコーディングスタイルは良くないよね。

だから「内側の変数が暗黙の内に外側を隠す」というルールは
入れなくて良いだろう、と言うこと。

「ひとつの場所で、すでに宣言済みの名前は宣言できない」
だけで、「内側優先」という例外を入れないほうがシンプルだし、
上のようなコーディングを防げる。これは取り入れても良いと
思う。

Javaってそうだったのカー
Cとおんなじかと思ってたYO

確かに不毛だけど結局この言語ではどっちにするの？39さんに決めてもらう？

>>732
C#もそうだった、気づかず書きまくったせいで、
コンパイルエラーでてから1つも逃さず置換するのは大変ﾀﾞﾀｰﾖ。
（置換し忘れてもコンパイル通っちゃうんで）

>>733
>>713
ということで。

>>733
まだ実装段階が目に見えていないのに、そう急ぐこともないだろう。
今決めることでもないし、もしかすると分岐したスレで良い意見が聞けるかもしれないから、
他のところを考えましょう。

実装・仕様ともに大きく響いてきそうなデストラクタやインスタンス回収のタイミングとか、

>>736
＞実装・仕様ともに大きく響いてきそうなデストラクタやインスタンス回収のタイミングとか、
タイミングはガベコレのときじゃないの？
ファイルとかのリソースのクローズは明示的に呼ぶしかないでしょう。

>>736
考えてください。
漏れはくちばしを突っ込めそうにないので暖かくROMらせてもらいます。

>>737
スタックに生成したインスタンスね。
上の方でスコープエンドでデストラクタを呼び出してくれって話が少し出た。

スタック上のインスタンスへの参照なんてナシだよね？
じゃないとGCの意味がなくなりそう。

C#みたいに、参照型のインスタンスはすべてヒープに
置かれる(Boxingするとnewされる)で良いよね？

>>740
もち

　　さて、

　　なにができる言語にしますか？　　　　　　　　　
　　　　　　　　　　　　　　　　　　

おいしいカレーうどん

java,pythonみたいなソースのファイル名とかディレクトリ名が名前空間に関係しているタイプか
そうでないタイプどっちにしますか？

仕様は500までにきめるんじゃなかったっけ？

>>745
500までに決まらなかったのでwikiを設置しようよ。
オレはやりかたわからんのでパスするけど。
このスレでその辺は作ってしまったほうが良いよ。

>>668

+<- -<- …この手の演算子を考えてませんでした。すみません。
"<-" 自体は関数定義の "->" を流用した提案で深く考えて無かったので取り下げてもいいです。
( でも個人的には、 := を使うとしても、 A := A + 1; または Inc(ref A); などと書く方が好みだったり )

>>660
名前をclassやvariableなどの先に書くようになった理由を把握してますか？
定義でも "<-"を用いるにしても name: method result: type <- (arg: type) { ... }; かと…
…やっぱ嫌です(w

遅レスごめんなさい