プログラミング言語 開発スレ( ´ⅴ｀)
レス数が900を超えています。1000を超えると表示できなくなるよ。
0001デフォルトの名無しさん
NGNG0002デフォルトの名無しさん
NGNG0003デフォルトの名無しさん
NGNG0004デフォルトの名無しさん
NGNG矢印演算子もう要りません。
batman.kick()
p_batman*.kich()
00051
NGNGポインタは取り入れます、久々に
0006デフォルトの名無しさん
NGNG非OOでお手軽ご気楽に組めるのがいい。
0007デフォルトの名無しさん
NGNGCのプリプロセッサみたいなのでいいよ。
軽く逝こうや。
0008デフォルトの名無しさん
NGNGというかHSPみたいな糞仕様な言語が幅をきかせているのはおかしい。
対抗馬を作れ。
0009デフォルトの名無しさん
NGNG0010デフォルトの名無しさん
NGNGpublic 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);
}
}
こんな構文が通るようにしてくれ。
もちろん型推論で静的型付け言語な。
0011デフォルトの名無しさん
NGNGList<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);
}
}
0012デフォルトの名無しさん
NGNGpublic insert(value) {
Tail = List.new(Head, Tail);
Head = value;
}
じゃないか？
0013デフォルトの名無しさん
NGNGがファーストクラスオブジェクトね。
もちろん全部Primitiveじゃなくてクラス
0014デフォルトの名無しさん
NGNGC:\> xxxx -@ 'window(<>){/*置き換え処理*/;}>>>eachfile'
例えばこれで引数のファイル全部を読んで、それぞれにに吐くとか。
C:\> xxxx -@ec 'window(<>){/*置き換え処理*/;}>>>edit|clip'
例えばこれでエディットボックスに出力吐いて、しかもクリップボードに転送済みとか。
ワンライナ<->可読書式
の、相互変換ユーティリティがあれば完璧かと。
0015デフォルトの名無しさん
NGNG0016デフォルトの名無しさん
NGNG非同期メソッドコールをベースに簡略化するのがいいと思うぞ。
0017デフォルトの名無しさん
NGNG0018デフォルトの名無しさん
NGNG00191
NGNG0020デフォルトの名無しさん
NGNGSTLを使うような処理を簡単に書けて、なおかつ自動的にC++化してくれる、
神のような言語の出現を希望。
0021デフォルトの名無しさん
NGNG可変長配列と参照だけで問題あるまい？
0022デフォルトの名無しさん
NGNGC++化はまだマズイと思うなぁ。
0023デフォルトの名無しさん
NGNGひまわりは糞。TTSﾏﾝｾｰ。
0024デフォルトの名無しさん
NGNG関数型は難しすぎるので、手続き型でね。
0025デフォルトの名無しさん
NGNG0026デフォルトの名無しさん
NGNGじゃあＣ化（ｗ
Windowsアプリさくっと書きたい。これはホンネ。
いくら簡単とはいえど、HSPでさっくり書けないものがある。
>>24
独自関数をCの関数に変換するってむずいのか？よくわからない…
00271
NGNG誰か手伝ってちょ～
0028デフォルトの名無しさん
NGNGいや、関数型は難しすぎて漏れの頭のキャパシティに収まりきらないので困ると。
0029デフォルトの名無しさん
NGNGじゃなければ、言語仕様について頭にあることをはき出せ。
漠然としたイメージでもいいが、ポリシーはしっかり持っておけ
0030デフォルトの名無しさん
NGNG0031デフォルトの名無しさん
NGNG0032デフォルトの名無しさん
NGNG0033デフォルトの名無しさん
NGNGソースの問題チェックして、関数からインクルード宣言を割り出して、最後にCファイルを吐く。
それでもHSPやVBより早いだろうし。
0034デフォルトの名無しさん
NGNG0035デフォルトの名無しさん
NGNG0036デフォルトの名無しさん
NGNG？
0037デフォルトの名無しさん
NGNG少し構文解析すれば、「i**2;」の**演算子をpower関数に置き換えられる。
そうすればCに無い演算子があるように動作するのでは？
0038デフォルトの名無しさん
NGNGその言語で開発すれば、CにもJAVAにもVBにもCOBOLにも？変換できる様な。
0039デフォルトの名無しさん
NGNG何でそんなことするの？
マトモに使える物にするなら、yaccかbisonでパーザ書くでしょ
そうすれば好きな演算子定義し放題だけど
0040デフォルトの名無しさん
NGNGHSP（もどき）を作りたいんでもいいし、新しいパラダイムの言語を提唱してもいいし
とにかく、雑談で終わるようにするな
0041デフォルトの名無しさん
NGNG理想の 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/
0042デフォルトの名無しさん
NGNGそりゃ、言語を設計／実装するやつは定義し放題だわ。
0043デフォルトの名無しさん
NGNG文字列は文字の配列として定義。
0044デフォルトの名無しさん
NGNG0045デフォルトの名無しさん
NGNGGikoBASIC/GikoForth があるじゃん。
0046デフォルトの名無しさん
NGNG多くの開発者はまともな物が出来たら2ch発とはしたくないはず
00471
NGNG・手早くGUIを使ったアプリが書ける
・ネットワーク使用も簡単に
・初心者でも難しくない仕様
・ｺﾝﾊﾟｲﾙして他の言語から使われることができる(?)
・ポインタを入れたい
0048デフォルトの名無しさん
NGNG・初心者でも難しくない仕様
これが他の全ての要件と反してる。
0049デフォルトの名無しさん
NGNG＞・手早くGUIを使ったアプリが書ける
構文をシンプルかつスマートに。あるいは、略式構文を正規構文に変換。
＞・ネットワーク使用も簡単に
標準で関数を装備
＞・初心者でも難しくない仕様
インクルードorインポート処理は自動化
＞・ｺﾝﾊﾟｲﾙして他の言語から使われることができる(?)
ソースをXML化（？）
＞・ポインタを入れたい
…せめて>>4の意見を反映させてくれ。
ぜひ意見を求む
0050デフォルトの名無しさん
NGNG例えば MJ みたいなモジュール指向。
フラットに関数が増加していくのは Win32API や Perl だけでお腹一杯だ。
0051デフォルトの名無しさん
NGNGそれって
A::cls(); B::cls();
を
A_NS_cls(); B_NS_cls();
と置き換えて誤魔化せるのではないか？
0052デフォルトの名無しさん
NGNG○実現できる
0053デフォルトの名無しさん
NGNG0054デフォルトの名無しさん
NGNG0055デフォルトの名無しさん
NGNG0056デフォルトの名無しさん
NGNG２ 最近ポインタを覚えた。
３ 最近、ポインタに気が付いた。
どれなんだろう・・・
0057デフォルトの名無しさん
NGNGポインタのときとそうでないときで、メンバ参照の演算子を変える必要があるの？
どっちも . だと不具合ある？
0059Coffee
NGNG0060Coffee
NGNG//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
これで少しはましになったと思うがどうか？
見ている人がいたら意見を願う。
0061Coffee
NGNGポインタの位置がちがうからconstの動作を明確に定義せねばならんのか？
考えて無かった…const取り消しー。
0062デフォルトの名無しさん
NGNG>int (*func)(char *str);
文字列の先頭とは限らないのでは？
0063Coffee
NGNGひとまず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 );
これで初心者はしっくりくるのかな？
うーむ。よくわからんなー。
0066デフォルトの名無しさん
NGNG親切でないかい？
0067デフォルトの名無しさん
NGNG0068Coffee
NGNG0069デフォルトの名無しさん
NGNG0070Coffee
NGNG今度はそれとは別の仕様を考えてみる。制御文だ。
if文とwhile文とfor文は容易に想像しうる混乱を避けるため導入決定。
でもループ内での変数宣言などスコープ関連の言語仕様は後ほど。
break;とcontinue;はどうだろう？ 確かPerlではラベル機能まで付加されてたが。
HSPにはあった気がするが…忘れてしまった。調べてみよう。
言語の簡単さと便利さ――――微妙な線だ。
ところで、do{}while;は本当に要るだろうか？
初心者が思わぬ使いかたをしそうな制御文、Ｎｏ．１な気がするのだが、気のせいだろうか。
うーむ。はじめのうちは教えなきゃいいのかな…。
0071デフォルトの名無しさん
NGNGdo while はなけりゃないでなんとかなるでしょ。
0072Coffee
NGNG実装が面倒…でもないのかな？
初心者は実行時に落ちると混乱するからなー。どうしようか。
まあプラットフォームがWinだと聞いたから、
落ちても良いかなーと危険な手抜きを…ではだめか（ｗ
0073Coffee
NGNGうむ。わかりやすい。ポケモン、君に決めた！（古
break;は現在のループからの脱出。gotoを仕様から排除する場合には、ラベル機能付きで。
next;は現在のループの末尾地点への移動。（もしあったと仮定するなら、）do{}while();も含めて、条件判断あり。
redo;は現在のループの先頭地点への移動。条件判断は、全くなし。
こんなもので良いかな？
しかし、予約語には古今東西のメジャーなキーワードを置いておきたい。
そうすると、ソースを読んでるときにcontinueなどという変数に出会わなくてすむはず。ｳﾏｰ
0074デフォルトの名無しさん
NGNGJava みたいに全部 catch しないとコンパイルできないのも鬱陶しいけども。
無言で落ちるよりはスタックトレースでも吐いてくれた方が精神的によろしい。
>>73
＞しかし、予約語には古今東西のメジャーなキーワードを置いておきたい。
本当に*予約*語ですね？ :)
0075Coffee
NGNGうーむ。実装の手抜き、という１にも秘密な裏コンセプトから遠ざかっていく…。
＊予約語＊
つかっちゃうとこちらが混乱しそうです。
0076デフォルトの名無しさん
NGNG0077デフォルトの名無しさん
NGNG0079デフォルトの名無しさん
NGNG//クラス無し
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;
}
一見、これのどこが新言語なのかと（以下略
0080Coffee
NGNG１．Cをパクり、利用の簡単さを最優先させたような言語(GUI対応)です。
オブジェクト指向、テンプレート、
ガベージコレクション、実行時型チェック、と望みは多いかと思いますが、
まずCをベースに仕様の決定と実装を優先させてみます。
２．すいませんコンパイラ作りません。
構文解析=>Cのソースにコンバート。というだけの言語にします。
単純に、Cのソースを吐くだけです。比較的、実装は簡単だと思います。
ただし、処理速度はお手持ちの開発環境の最適化能力に依存します。
３．そこまで出来たら、ライブラリ作ります。
「Win版、GUI対応簡易ツール == 十数行」にするために、簡単に使えるGUIライブラリを作ります。
Cへの変換を行うついでに、言語特有の特徴にみせかけていた機能を勝手にソースに埋め込みます。
最終的には、メジャーな他言語コードを吐く、簡易記述言語を目指します。
そこで、ム板の皆様。当面の課題として、言語名を考えてください。お願いします。
0081デフォルトの名無しさん
NGNGint* (*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;
という風に素直に読み下せる。
0082デフォルトの名無しさん
NGNG悪いとは言わないが、これをやっちゃうと後で構文拡張（つぎはぎ）で
どんどん汚くなるよ、perlしかり。
仕様部分ははじめからきっちり決めておくべきだと思う。
オブジェクト指向は後で考えるじゃなくて、実装するかしないかは今の時点で考えるべき
0083デフォルトの名無しさん
NGNGclassHoge.funcHoge(foo, bar){
(isTrue)?{ // if
(0-9)~{ // for
}
}:{ // else
(tilTheEnd)~{ // while
><; // break;
<; // redo
>; // next
}
}
retVal;
}
0084デフォルトの名無しさん
NGNG0085デフォルトの名無しさん
NGNG0086デフォルトの名無しさん
NGNG0087デフォルトの名無しさん
NGNGそうすりゃbisonでパーザを書いてやる。
>>10みたいなのは激しく面倒なので却下だが
0088Coffee
NGNG*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]);
とかやって使う感じで考えてるのだが。
自分で言っててつっこみどころ満載だな（ｗ
0089Coffee
NGNG＞ *func( *int *proc( int, int), int);
*int
*func( *int *proc( int a, int b), int c);
間違った。ここはこう書く。
0090デフォルトの名無しさん
NGNG0091デフォルトの名無しさん
NGNGint *hoge , *hoge;
これなんか激しく無意味だと思うんだが。
最小の言語仕様になるように切りつめろ
0092Coffee
NGNG0093デフォルトの名無しさん
NGNG0094デフォルトの名無しさん
NGNGほんとにこれでいいのか？
*char const str : str が const
*const char str : str への const ポインタ
tokajanainoka?
0095Coffee
NGNG+はポインタ*があるorないのどちらでもよいことを示す。
[]はカンマ区切りで並ぶこともができる要素。
…は[]の要素がいくつでも置けることを示す。
変数宣言時：
+型名 変数名[変数名]…;
関数宣言時：
+戻り値の型名 +関数名([引数型名]…);
これで戻り値にvoidがあれば、大丈夫かな…。
>>94
すみませんCに従います。引数の中で反逆しても良いこと無いしな…。
0096デフォルトの名無しさん
NGNG例外的な規則をいくつも作ることになり、
言語仕様がシンプルじゃなくなるって話だよ
0097デフォルトの名無しさん
NGNGだとすると引き数も切り詰めるべきでしょうか？
0098デフォルトの名無しさん
NGNG*const char == const char *
const *char == char * const
const * const char == const char * const
こうだろう。
0099デフォルトの名無しさん
NGNG0100デフォルトの名無しさん
NGNGもちなおせ！
0101デフォルトの名無しさん
NGNGイテレータ
テンプレート
スマートポインタ
自己記述性(lisp)
がﾎｽｨ
0102デフォルトの名無しさん
NGNG知ってる言葉を並べただけ？
自己記述性があるなら総称（テンプレート、Generics）はいらないし
そんな言語はGCが無いとやってられないから、スマートポインタもいらない。
そもそも、イテレータはともかく、スマートポインタなんてライブラリレベルでの話
0103デフォルトの名無しさん
NGNG>>101
＞正規表現
＞イテレータ
＞テンプレート
本体に組み込まずライブラリで提供を推奨。
0104デフォルトの名無しさん
NGNG0105デフォルトの名無しさん
NGNG0106デフォルトの名無しさん
NGNG0107デフォルトの名無しさん
NGNG0108101
NGNG自己記述性とテンプレートがあっても良いと思うんだけど、駄目なのね
スマソ、、、
0109デフォルトの名無しさん
NGNGダメじゃないと思うけど・・・
1 ライブラリは、言語仕様もマトモに決まってないのに議論のしようがない
2 自己記述性、テンプレート 採用するならどっちか一つだと思うが？
2については、両方サポートして便利なところある？
自己記述性はテンプレートも内包しちゃうので（ループとSchemeの継続の様な関係）
両方をサポートする意味が無いと思うんだけど。
もしよければ、Lispにどのようにテンプレートを使うと便利だと感じるか、
擬似コード書いてみて
0110101
NGNG例えば
int hoge = new int[5];
hoge.size
で、hogeの配列サイズを取得できたりとかね。
そうなると結局はすべてがオブジェクト言うことになるのかな？
もしかしたら、自己記述性ではなくて、自己記述的が正しいのかの知れないです、、、
無知でスマソ、、、
0111デフォルトの名無しさん
NGNG0112デフォルトの名無しさん
NGNGhoge の型情報を得られるのならリフレクションかもしれんが、
サイズは微妙だな。
0113デフォルトの名無しさん
NGNG0114デフォルトの名無しさん
NGNG0115デフォルトの名無しさん
NGNG1がどうにもポインタに幻想を持っているらしいので、
必須のようだぞ？
擬似コードによる構文もポインタ使いまくりだし（藁
ちくしょう、生ポインタなんてあったらGC搭載出来値ーじゃんかよ！
0116デフォルトの名無しさん
NGNGttp://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%2D1998
落ちてないかなー。
0117デフォルトの名無しさん
NGNGhttp://photon.poly.edu/~hbr/cs903/c++/C++-ansi.pdf
0118116
NGNG0119デフォルトの名無しさん
NGNGじゃ、こっち
0120デフォルトの名無しさん
NGNG0121デフォルトの名無しさん
NGNG仮引数リストと変数宣言の形式が違うのはどうして？
あと、可変長引数の実装も言語仕様に取り入れてくれ
0122デフォルトの名無しさん
NGNGそんなのより、Eiffelみたいな表明でも実装しれ。
0123デフォルトの名無しさん
NGNG汎用リストみたいなので代用しない？
0124デフォルトの名無しさん
NGNGArgument Objectとして、型情報と引数を同時に渡せると便利だな、と。
もちろん、実行時じゃなくてコンパイル時に型チェックを。
0126デフォルトの名無しさん
NGNG0128デフォルトの名無しさん
NGNG0129デフォルトの名無しさん
NGNG0130デフォルトの名無しさん
NGNG0131デフォルトの名無しさん
NGNG元ネタがわかりやすいなｗ
0132デフォルトの名無しさん
NGNGを
afor(int i != n)
に
0133デフォルトの名無しさん
NGNG構文を自分で書けるように設計すれば、
そんなの標準で用意する必要がないと思う
ってか、>>1は逃げたか？
0134デフォルトの名無しさん
NGNGクラス変数とかは別構文がいいナ
0135デフォルトの名無しさん
NGNG0136デフォルトの名無しさん
NGNG副作用が無い事を明示出来るようにしてくれ。
んで、それを最適化に活かせれ。
0137デフォルトの名無しさん
NGNGそういうプロパティやアトリビュートってつけだしたらきりがないから
public/private
const
だけでいいと思うけどなー
01381@夜逃げ寸前
NGNG0139デフォルトの名無しさん
NGNGconst=定数=参照先の変更が出来るが、参照先の変数に書き込めない。
hold=??=参照先の内容は帰れるが、そのポインターの参照先を変えることは出来ない。
と分けて見ては如何？
意味が違うのに同じconstを割り当てているC++の設計者はセンスを疑う。
（でも策定時に議論済みなんだろうなー。どういう議論になったか知りたい。）
0140デフォルトの名無しさん
NGNGはいはい。偽１さーん。
さっさと夜逃げしてください。
>>139
>hold=??=参照先の内容は帰れるが、そのポインターの参照先を変えることは出来ない。
hold=参照先固定=参照先の内容は変えれるが、そのポインターの参照先を変えることは出来ない。
で委員じゃない？
0141デフォルトの名無しさん
NGNGいや、意味は違わないよ。
constである対象が宣言時のconstの位置によってわかりづらくなってるのが問題なだけ。
char const * const * a;
(((char const) * const) * const) a;
こうすれば、何がconstかわかるでしょ？
const char *・・・って書くからわかりづらいだけ
0142デフォルトの名無しさん
NGNGそして宣言が全部 p から始まるのはもうイヤです。
0143デフォルトの名無しさん
NGNGんじゃ、全部ブロックにするの？
0144デフォルトの名無しさん
NGNGcanuse
notuse
みたいに、頭文字変えて文字数を揃えたい
宣言を見易くしたいのよ
0145デフォルトの名無しさん
NGNG0146デフォルトの名無しさん
NGNG0147デフォルトの名無しさん
NGNG0148デフォルトの名無しさん
NGNG0149デフォルトの名無しさん
NGNGインスタンス未生成で使える数学系関数
のサポートとナイスな修飾語きぼー
0150デフォルトの名無しさん
NGNG自分で関数作ってなんちゃって独自スクリプト作るの余裕じゃん。
0151デフォルトの名無しさん
NGNGGUI対応で
簡単かつ
エレガントな
OOPL
（ポインタ付き）
神？
015239
NGNG>2ch発の
>エレガントな
>OOPL
仕様を上げてくれたら、
ネイティブコンパイラと、バイトコードコンパイラと、デバッグ要VMは作ってやる。
要するに言語処理系のベースになるところまでな。
0153デフォルトの名無しさん
NGNGマジ？そのネイティブコンパイラってオプティマイザ込み？
0155デフォルトの名無しさん
NGNGネイティブバイナリの出力フォーマットはPE？ELF？
それともコンパイル済みのコードをリソースとして保持して
実行ファイルにはローダを作り込む？
015639
NGNGCOFFにするか、直接PEを吐くかはまだ決めていない。
COFF/OMFが吐ければ便利だけど、他言語との連携を考えないといけないからな。
0157デフォルトの名無しさん
NGNGエレガントなOOPLね。オブジェクト指向周りの設計が難しいな。
実際の所、プロトタイプベースの言語以上の柔軟性って思いつかないし、
実行パフォーマンスとのバランスを考慮すればC++が最良の解に思える。
でもそういう既成言語を踏襲するだけじゃエレガントの内には入らないんだよね？(ｗ
015839
NGNGんー、漏れが考えているのはC#程度まではシンプルになった
C++がいいかな、とは考えているんだが。
ファイルベースのモジュールじゃなくて、シンボルベースにしたり、
今のC++の古いところを取り除いて。
ああ、それから、GCをネイティブで搭載したいな、とも。
0159デフォルトの名無しさん
NGNGdelegate なんかは俺はエレガントとは思えないんだけど、便利ではある。
あと attribute もエレガントとは思えない。
でも、そういう特徴を除いちゃうとDじゃんって話になる。
もちろんそのまま取り入れるだけだったらC#じゃんって話になる。
そこはやっぱり差別化しなくちゃいけないよね。
templateの有無なんかはどう見てる？
016039
NGNGそれを言ったら言語を作る意味がなくなっちゃうしな。
attributeは泥臭いと思うし、delegateもいいアイデアがあれば違う形で、と。
別にC#を踏襲するつもりは全くないです
っていうか、言語仕様をこのスレで話し合ってくれ～って事なんですが。
それから、静的型付けﾏﾝｾｰなんで、templateは導入したいけど、
C++そのままというのはちょっとイヤだから、いろんな言語を見て研究、と。
Java Genericsもイマイチピンと来ないし。
0161デフォルトの名無しさん
NGNGフラグ値と列挙値は区別して。
プリミティブは従来のshort,longじゃ無くてint16,int32のように。
templateの魅力はinline展開されてこそだと思うけどその辺はどう思う？
0162デフォルトの名無しさん
NGNGtemplateのinline展開は必ずしもコンパイル時にやらなくても、
JITを使うとして実行時の処理に任せるというのも手だと思うな。
016339
NGNGオブジェクト参照やvoid*を使ったポリモーフィズムじゃなくて、
タイプセーフを保ったまま総称を実現出来る事じゃないかなぁ
0164デフォルトの名無しさん
NGNG0165デフォルトの名無しさん
NGNGコンテナではそれも大きいんだけど（キャストうざい＆コンパイル時チェックできない）。
アルゴリズム側から見ると、ポリモーフィズムでも別にいいじゃん、って話にならない？
0166デフォルトの名無しさん
NGNGtemplateがポリモーフィズムだけでお終いってことはないと思う。
0167デフォルトの名無しさん
NGNGdelegateは関数ポインタのお化け（型）でeventはフィールド・・かな？
delegate型のメンバも作れるけど代入演算子が使えるとか、問題が多いからeventでラップする。
C#ってdelegate作った後にevent作らなきゃいけなくて、なんか2度手間のように感じてしまう・・・いい方法無いかな？
016839
NGNGそれはならないでしょう。
タイプごとに別に関数・クラス実体を作成するから、たいした問題では無いと思う
>>165
プログラマ側からの実現手段はどうでもいいんだけど・・・
特にインライン展開を導入するメリットが感じられないし、
そもそも、それが足かせになるようなクリティカルな要求に耐えうる
処理速度は実現できないだろうし。
それから、万が一オプティマイザを搭載する事になったら、
そのときに自動判断で展開するようにすればいい。
templateを無条件インラインにしちゃうと、
inlineキーワード追加しないとならないし、どんどん言語仕様がシンプルじゃなくなるでしょ
016939
NGNGそれでも、テンプレートの本質はこれでしょ？
あのスレの話題はそれを発展させたトリックであると言うだけで。
0170デフォルトの名無しさん
NGNG0171デフォルトの名無しさん
NGNG一般化された概念としてのポリモーフィズムとしてはそうだね。
C#/Java/C++などで言われるところのポリモーフィズムでは不足。
でもその辺を追究していくとHaskellになっていくような・・・。
0172デフォルトの名無しさん
NGNGCのような単なるchar配列というのもなんだか使えないし。
C++のbasic_stringはSTLとあわせると強力だけど、パフォーマンス的にあれだし。
JavaやC#のように行くの？
017339
NGNGテンプレートについては私自身勉強不足な点は多いんで、
何かいいことがあればどんどん書いてほしいと思いますが
>>172
本当にでbasic_stringのパフォーマンス悪いと思いますか？
参照渡しじゃなくて、コピー渡しを多用していませんか？
string型の実装は基本的にクラス（ライブラリ側）で、
言語によるサポート有りのC#/Javaの様な物を考えてます
そもそも、こういうミクロな話じゃなくて、
もっと言語のポリシーや構文を決定するマクロな話からしたほうがいいかと。
基本的に、質問じゃなくて、アイデアを提案してください
私が仕様を決定するのではなく、私は単なる１実装者でありたいので。
0174デフォルトの名無しさん
NGNG新しいフィーチャーはなくてもいいから実用十分な機能があって使いやすいのがいい。
結局は、C#と似たり寄ったりになるんだろうけど、もっと文法はシンプルな方がいい。
0175デフォルトの名無しさん
NGNGGUIフレームワークを最初に作り、それに親和性の高い構文を持つ言語とする
と言うのが理想かな。
どうせ2chの烏合の衆じゃ一般化された素晴らしい言語仕様なんて作れないだろうから
0176デフォルトの名無しさん
NGNGはい、喧嘩売るなら自分で実装してからにしてくれ。
0177デフォルトの名無しさん
NGNG前半部は同意
窓をサクっと書きたいね
0178
NGNG循環するもの
0179デフォルトの名無しさん
NGNGhttp://pc.2ch.net/test/read.cgi/prog/961558082/l50
0181デフォルトの名無しさん
NGNG0182デフォルトの名無しさん
NGNG★☆★☆★☆ 糸冬 了 ☆★☆★☆★☆
0183デフォルトの名無しさん
NGNG暇人は帰れってことですか？（泣
とりあえず継承の構文はまだですよね？
018439
NGNG継承って単一継承か、Javaの用に実装一つインターフェース複数にするか、
それすらも決まってないようです。
>>10-12の型推論は面白そうだけど、実装がちょっとめんどくさそうですね。
MLの型推論に関する文章読んでます。
0185デフォルトの名無しさん
NGNG0186デフォルトの名無しさん
NGNGmix-inの概念がよくわからないので、詳細ｷﾎﾞﾝ
0187185
NGNG多重継承と同じでインターフェースと実装を継承できます。
mix-inされるモジュールは通常のクラス定義と同じように
インスタンス変数とメソッドを定義できますが、モジュールは
スーパークラスを持たず、また、単体ではインスタンスを生成
できないと言う制限が付きます。
クラスは一つのスーパークラスと複数のモジュールを継承できるので
クラスを横断するような実装を再利用しやすくなります。
‥‥といふのが私の認識ですが間違ってたらつっこんでやってください。
0188デフォルトの名無しさん
NGNGpublic:
foo();
}
class IClass {
public:
bar();
}
class Class : IClass {
public:
mix-in(Aclass)
}
こうするとClassは
Class : IClass
+foo()
+bar()
こんな感じになるって事？
0189デフォルトの名無しさん
NGNGmix-inの実装されてる言語の構文は良くわからないけど、こんな感じ？
// 継承不可能、インスタンス変数もメソッドの実装も可能
module SomeModule
{
hoho(){ write("HOHO"); }
}
// インターフェイスだけ継承可能、メソッドの実装は不可能
interface SomeInterface : OtherInterface
{
huhu();
}
// classは単一継承、他はなんでも可能
class SomeClass : OtherClass, SomeModule, SomeInterface
{
huhu(){ hoho(); }
}
0190185
NGNG>>189
両方よろしいかと思います。
>>188はRubyがそんな感じ（includeだったと思うけど）
多重継承と同じく名前の衝突の問題が出てくるのですが、
CLOS流：
クラスやモジュール間に優先順位を持たせる。
Eiffel流：
明示的にRenameする。
のやり方があると思います。
……個人的にはCLOS流が好きですが、静的型付けの好きなタイプの
ひとはEiffel流を好むような気がします。
0191デフォルトの名無しさん
NGNG0192デフォルトの名無しさん
NGNGinterface First{ void hoge(); }
interface Second{ void hoge(); }
class Class : First, Second
{
void First.hoge(){ /* first hoge */ }
void Second.hoge() { /* second hoge*/ }
}
みたいに。
0193デフォルトの名無しさん
NGNGC++流やね
0194185
NGNGほんとの多重継承だとスーパークラスの探索がツリーになるので
イヤな感じですが、mix-inの場合はスーパークラスを持たないので、
クラスとスーパークラスの間にリニアに挿入するだけで済むと思います。
つまり単純継承とそんなに違わない。たぶん。
（でもインスタンス変数のベースアドレスのオフセット計算は必要か。）
>>192
Renameをいちいち書くのは面倒だし優先順位のやり方だとアクセスできない
メソッドやインスタンス変数が出てくる場合があるのでナイスなアイデアかも。
0195189
NGNG多重継承のせいで同じ基本クラスが複数含まれてしまう問題と、
インターフェイス内でメソッドの実装が行えない問題の
両方に対してなかなかいい答えを出してくれると思う。
class // 参照型、インスタンス化可能
struct // 値型、インスタンス化可能
interface // インプリメントするクラスによって変わる、インスタンス化不可能
module // インクルードするクラスによって変わる、インスタンス化不可能？
enum // 値型、{0,1,2,3,4}、演算結果はint（再代入不可能）
flag // 値型、{1,2,4,8,16}、ビット演算の結果はflag（再代入可能）、それ以外はint
これくらいあるとうれしい。
え？多すぎる？
0196デフォルトの名無しさん
NGNG0197デフォルトの名無しさん
NGNG漏れは>>10の様にclassキーワードをつけないのが好みだったり
0198デフォルトの名無しさん
NGNG漏れは変数にはvar、関数にはfuncつけたほうがいいとか思ったり、でもそれは面倒だとも思ったり。
0199デフォルトの名無しさん
NGNGメソッド定義の場合に限定するとかしないと、
class
interface
module
なんかの区別がうまくできない気がします。
ところでstructってやっぱり必要？
0200デフォルトの名無しさん
NGNGでも、コンパイラ制作者ががんばれば出来ないことも無いと思うが
0201デフォルトの名無しさん
NGNGC#みたいにintやlongをstructとするといろいろ幸せなことが多いです。
確かintを継承したり出来ますよね。
あ、そうそう、演算子のオーバーロードもほしい、オーバーライドもあるとなおうれしい。
0202デフォルトの名無しさん
NGNGclassをmix-inすればいいんでないの？
0203デフォルトの名無しさん
NGNGmix-inされるクラスは他のクラスを継承してはいけないとか制限があるから、
ただわかりやすくするため、程度に。
メソッドの宣言しか出来ないクラス（に似たもの）をinterfaceと呼ぶのと同じ気分で。
0204デフォルトの名無しさん
NGNGシンプルで敷居の低い言語であってほしい
何でもかんでもごちゃごちゃ入れちゃうと、
C++っぽくつぎはぎだらけに・・・
0205デフォルトの名無しさん
NGNG（こいつらの使用頻度自体が低いことはおいといて・・・）
0206デフォルトの名無しさん
NGNGコンパイラ作るには仕様ががちっと決まっている必要があるぞ。
何スレ目までかかることやら・・・。
0207デフォルトの名無しさん
NGNG複素数や巨大な数のクラスは言語標準でサポートすれば
>>206
500過ぎても構文が決まらなかったらwikiを設置しよう
0208デフォルトの名無しさん
NGNG0209デフォルトの名無しさん
NGNG言語仕様は小さいほうがいいなぁ。
0210デフォルトの名無しさん
NGNG禿て同感
0211デフォルトの名無しさん
NGNG複素数を言語でサポートするのと
オペレータオーバーロードを導入するの、
セーフティプログラミングの観点から見て、どっちがいいと思う？
0212デフォルトの名無しさん
NGNG0213デフォルトの名無しさん
NGNG0214デフォルトの名無しさん
NGNGスマートポインタも作れないよぉ。
他にもPOINT とか SIZE とか演算子が欲しくなるようなクラスが沢山。
演算子が使えないのはやっぱり嫌だなぁ。
>211
セーフティ．．．
演算子のオーバーロードってそんなに危険？
型変換演算子以外は別に問題ないと思うけど。
ところでこの言語のコンセプトって何？
個人的にはテンプレートライブラリが作りやすい言語がいいな。
0215デフォルトの名無しさん
NGNG0216デフォルトの名無しさん
NGNG39はGC搭載したいとか言ってなかったか？
生ポインタはそもそも入れるつもり無いと思われ
>セーフティ．．．
多人数開発での保守性といった方がいいのかな
0218デフォルトの名無しさん
NGNGそれほどの問題はないんじゃないかな？
cout<<みたいな変な使い方さえしなければ。
インデクサもあればコレクションが作りやすいけど。
0219デフォルトの名無しさん
NGNG0220デフォルトの名無しさん
NGNG0221デフォルトの名無しさん
NGNG0222デフォルトの名無しさん
NGNG0223デフォルトの名無しさん
NGNGそれより GUI フレームワークを考えるべきだと思う。
Windows 限定なのか Swing などのようにマルチプラットフォームを目指すのか。
0225デフォルトの名無しさん
NGNGこのくらいの打鍵数で窓を開けさせてくれ！
初心者はこれくらいが限界だよ！
0226デフォルトの名無しさん
NGNG個人的には VCL ライクだと使いやすくていいけど(ｗ
一番問題なのはスレッディングモデルかね。
ウェジェットにスレッド化の属性を付けてやって
クリック一つでマルチスレッド処理ができればいいが
そんなに簡単なパターンばかりじゃないしな。
022739 ◆6K2ziZrM
NGNGGUIビルダとそれを接続するイベントモデルを作って、
コード上から(Windowsの)コントロールを操作するコードを
完全に切り離すというのはどうだろう。
ってそれは幻想だよなぁ。
結局ソースからさわる必要も出てくるだろうし・・・
0228デフォルトの名無しさん
NGNGClassname BaseClassname {
allcls int data1; // == public static int data1;
canins int data2; // == protected int data2;
notins int data3; // == private int data3;
}
？？？？？？
0229デフォルトの名無しさん
NGNG{
public // ブロックも可能
{
int field;
void method();
}
private char field2; // もちろん1行も可能
}
ダメ？
あと書き込みはprotected、読み込みはpublicな属性もほしい。
俺はreadonlyって呼んでたけど、C#で別の意味で使われちゃったね。
0230228
NGNG「頭文字が違う」
の実演テストしてみただけです…。
でもpublicとかに慣れてるせいか自分じゃ見やすいのかよくわかんない…。
しかも等幅じゃないからインデント崩れてるし…。
別にallclsキーワードは本気ではないですよ。
ただちょっとstatic宣言の代用にclsとinsを思いついたので。
0231_
NGNG*a++ = 0;
*a = 1;
と
a[0] = 0;
a[1] = 1;
の上って必要？あんまり上が必要になったことないのだけど・・・
下だけじゃだめ？
http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html
ここにJVMをターゲットにした言語山ほどありますね。。。
0232デフォルトの名無しさん
NGNGそっくりなコードをさっき別スレで見た気がする・・・
場合によって違うじゃん。
C++的にはイテレータって概念が浸透してるから上のほうが主流だろうけど、
C的にはどっちも同じくらいの頻度で使うんじゃないの？
ランダムアクセスが必要なら当然下になるし。
0233231
NGNG（下の話につなげたかっただけ）
ほんとは8086ファミリーがターゲットです。。。
0236デフォルトの名無しさん
NGNG読みにくくなることはあるだろうね。
0237231
NGNGなる～ｻﾝｷｭ。じゃあ、下だけにしよっと。
今までちょっと作ってみた感じでは
Ｃへのトランスレータ＞8086インタプリタ＞＝JVMコンパイラ
＞8086コンパイラ
の順で楽だと思います。これからは.NET対応が一番幸せになれそう。
0239デフォルトの名無しさん
NGNG何が言いたいのかｻﾊﾟｰﾘわからんのだが
8086インタプリタってナニ？
エミュレータ？
しかも、楽とか・・・
何が言いたいのかわからん
024039 ◆6K2ziZrM
NGNGああ、ごめん、読み書きで属性変えたいのね。
public property int i {
public get {
}
protected set {
}
};
こんな感じって事？
0241229
NGNGんや、それで桶です。
おれっちの考えたのにはプロパティはなかったんで。
ところで
int hoge( string arg ){ return hage; }
void before hoge( string arg ){/*hogeの呼び出し前に呼ばれる*/}
void after hoge( int ret ){/*hogeの呼び出し後に呼ばれる*/}
みたいなのは、どうでしょうか。
hogeをサブクラスでオーバーライドしたときは、
そのサブクラスのhogeが呼び出される前後にbefore hogeとafter hogeが呼ばれるです。
0245デフォルトの名無しさん
NGNG0246229
NGNGあんまり深く練ってなかったんで、
あったらdebugとか便利かなと思ったんですけど、
> hogeをサブクラスでオーバーライドしたときは、
> そのサブクラスのhogeが呼び出される前後にbefore hogeとafter hogeが呼ばれるです。
この部分は撤回です、挙動がおかしくなるです。
DBCは、機能自体は知ってるんですけど、
実際どのように実装されているんでしょう？
0247229
NGNGdebug時にだけ有効になるassertがあれば、特に他に言語サポートは必要ないんじゃないでしょうか。
024839 ◆6K2ziZrM
NGNGhttp://pc.2ch.net/test/read.cgi/tech/1003674814/21
記述形式がこれと似ていたのでそうかなって
0249デフォルトの名無しさん
NGNG漏れは別にいらない気もするけど。
int func()
{
in{}
out( ret ){ assert( ret>0 ); }
// 本体
return 1;
}
0250デフォルトの名無しさん
NGNGいっそのことaspectキーワードを入れてしまうとか。
0252デフォルトの名無しさん
NGNGD 言語がよりモダンな構文だと思う。
D言語ドラフト一応読んだよ
http://pc.2ch.net/test/read.cgi/tech/1003674814/
0253デフォルトの名無しさん
NGNG・returnだと値を返すためだけにジャンプの使用を強制される
・複雑になると戻り値用の変数はどうせ宣言しないといけないので面倒
・構造体などで呼び出し元が領域を確保した場合それをそのまま使えて効率イイ
関数からの脱出はラベル付きbreakの一種にしてbreak 関数名; にしてしまえばreturnは不要に。
何なら「result = X; break 関数名; 」の構文糖として「return X; 」も残せばいいし。
0254デフォルトの名無しさん
NGNGマジで
0255デフォルトの名無しさん
NGNGこれはいいかもなぁ
スタックフレームを一段上に上ると言う意味で統一も出来てるしね。
resultへ代入はどうなんだろ。
予約語がどんどん増えていくよな・・・
0256デフォルトの名無しさん
NGNGPascal 式 VB 式とも言う。
初心者向けを考えるとよいかもね。
＞構文糖として「return X; 」
これは要らないと思う。二重標準は良くない。
025739 ◆6K2ziZrM
NGNGint func()
{
goto l;
foreach (...) {
int i = 0;
l:
print(i)
}
}
こういうブロックの内側へのgotoやbreakの実装がめんどくさそうです
というか、今のところうまい手が想像つきません
0258デフォルトの名無しさん
NGNGMax (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以外のときだけ有効な暗黙に宣言されるローカル変数ってことで。
0259デフォルトの名無しさん
NGNGあなたとランデブー。
0260デフォルトの名無しさん
NGNGブロックの中から直後に移動するbreak
ブロックの中から直前に移動するretry (←Eiffel風。Ruby風ならredo)
ループを進めるcontinue
これらを全てラベル付きでも使えるように、
つまりラベル付きブロックで囲えばretry/breakで脱出限定で好きな位置に戻れる/進めるようにして
尚且つそれらの構文糖としてgotoを脱出方向のみ認めればいいと思うのですが、いかがでしょう。
( ローカル変数よろしくラベルもブロックの外からは見えなくしてもいいかも )
gotoは無いとyacc等のコード自動生成が困りそう。
0261デフォルトの名無しさん
NGNG>gotoは無いとyacc等のコード自動生成が困りそう。
の意味がわからないんですが。
なんで、困るの？
0262デフォルトの名無しさん
NGNG遷移しまくるから。
0263260
NGNGそういうゲームブック形式のコードを考えると必要な気がして。
goto L2;
L1:
goto L3;
L2:
goto L1;
L3:
これを先に述べたbreak/retryだけで書こうとしても辛い気が…
A: {
B: {
break B;
C: {
break A;
}
}
retry C; //これはCブロックの内側に置かないといけない
}
あ、やっぱ脱出文だけではgotoの代わりにならない気がしてきた。
しかし、Java版yaccも存在するということは、無くてもいいのかな、
というか、明らかにスパゲッティなので無くした方がいいのでしょうけれど…
026439 ◆6K2ziZrM
NGNG脱出方向のみで進入禁止なら楽ですね
breakとretryについては、ラベル付きなら同意語になると思うんだけど、
breakなら後方、retryなら前方と限定するということですか？
別の語でまとめてもいい気がするけど。
0266260
NGNGええ、「ラベル付きブロック」は、ブロック全体に名前を付ける意で、
ラベル付きretry/breakは、そのブロックの内部でのみ有効、って感覚で書きました。
参考までに、Adaなら、ラベル付きブロックは 「LABEL: ブロック」 で、goto用のラベルは 「<<LABEL >>」と書き分けます。
0267デフォルトの名無しさん
NGNG0268デフォルトの名無しさん
NGNGAdaに倣うなら前者でelse節も含めてif文全体に名前が付く感じかな？
0269249
NGNG遅レススマソが。
俺も最初はオーバーライド可能にしたほうがいいと思ってた、
でもよくよく考えると、オーバーライド後も条件が同じとは限らないし、
そんなときにベースクラスの条件がしゃしゃり出てくるのはどうかと。
たとえば、正の数しか受け取れないメソッドを拡張して、
負の数を受け取れるようにすることもあるかもしれない。
0270デフォルトの名無しさん
NGNGんー、継承後も要件を満たすことが保証されているかが重要なんじゃないかな
そもそも、オーバーライド後に動作が変わるなら前件・後件なんか設置しないでしょ
0271デフォルトの名無しさん
NGNG0272デフォルトの名無しさん
NGNG0273デフォルトの名無しさん
NGNGlabel (ラベル名) 名前がつけられるコード
を提案したいです。
ifやfor同様に”名前がつけられるコード”は単文でも複文でもかまいません。
label( OUTER_LABEL )
if (...) label( IF_LABEL ) {}
else label( ELSE_LABEL ) {}
少しくどいですが、ifやforなどと同じ構文で扱えたほうが文法上の一貫性も取れるしコンパイラも楽じゃないかと思います。
gotoを実装するかどうかはわかりませんが、
goto NAME;
とすると
label ( NAME ) hoge
↑ここにジャンプ、hogeが空文でなければ実行される。
という感じで。
この場合gotoはラベルに飛ぶというよりも、名前がつけられたコードに実行を移すイメージになります。
027439 ◆6K2ziZrM
NGNGif節とelse節に別の名前を付ける意図がわからないです
>>258のAda風の
if (xxx) {
;
else
;
}
これならlabelを自然に入れられるね。
こうなるとifの構文をちょっと考えたいかな。
0275デフォルトの名無しさん
NGNGたとえばあるライブラリで、double Power( double x, double y );
が x>=0 && y>1という条件を課していた場合、
気に入らないからこれをオーバーライドして yに任意の実数が与えられるようにする、ということは出来ないということですか？
0276デフォルトの名無しさん
NGNGif節とelse節に別の名前をつけてるというより、
ifとelseで実行されるコードにそれぞれ別の名前をつけてるんです。
label ( OUTER_LABEL )
if (...)
label( IF_LABEL )
{
retry IF_LABEL; ブロックのはじめからやり直し。
retry OUTER_LABEL; ifのはじめからやり直し、比較も行い、場合によってはelse節へ。
}
0277デフォルトの名無しさん
NGNGそれってテンプレートメソッドパターン使えばいいんじゃないの？
027839 ◆6K2ziZrM
NGNGnamed_statement : symbol_id '(' symbol ')' statement
どっちでもいいんじゃないかなって思います
0279276
NGNG追記です。
別に特殊なことをしてるわけじゃなくて、
Adaの文法はよくわかりませんが、
OUTER_LABEL: if(...)
{
IF_LABEL:{
}
else
ELSE_LABEL:{
}
}
これと同じことです。
やることは同じなんですけど、
LABEL:
よりも
label(LABEL)
のほうがコンパイラも楽だし文法上も一貫してない？というだけの話です。
028139 ◆6K2ziZrM
NGNG名前を
・ブロックに付けるようにするのか
・文につけるようにするのか
こっちの方が重要かな、とか思ったり
0282デフォルトの名無しさん
NGNG文に1票
0283デフォルトの名無しさん
NGNG名前をブロックに付けるようにすると、
それを一般化して関数もブロックの一種として扱えるし、
ブロック自体をオブジェクトとして扱うのに便利・・・かな。
0284デフォルトの名無しさん
NGNG0285デフォルトの名無しさん
NGNG面白そうだけど、inner関数作ったとして
void hoge()
{
void hage(){}
hage(); // hageを呼ぶ。
}
名前つきブロックは書かれた位置で必ず実行される。
inner関数は呼ばれなきゃ実行されない。
という違いをどう乗り越えたらいいだろう。
0286デフォルトの名無しさん
NGNGってところでしょうか
0287デフォルトの名無しさん
NGNGif (...) then : {
retry then;
}
と言う記述は
void then() {retry then;}
if (...) then();
のsyntax-sugarとする、とかはどうかな。
0288デフォルトの名無しさん
NGNGtry hoge;
catch(...) huge;
とか
int func(void) return 10;
とか。
もちろん文法上可能というだけで、可読性からみてブロックにしたほうがいいところは自主的にブロックにするだろうけど。
ラベルも、ブロックといわず一切の文に適用できたほうがいい。
0289デフォルトの名無しさん
NGNGブロックをインナー関数にするより
インナー関数をブロックにしたほうが良くないかな。
void inner_func( int a ){}
は
if (false) label(inner_func){ int a/* = pop() みたいな*/; }
のシンタックスシュガー
0290デフォルトの名無しさん
NGNGそれはどうだろう
関数はそのままブロックの機能すべてを包括できるけど、
ブロックは常に真とは限らない。
たとえば、引数や戻り値がある物とか。
0291デフォルトの名無しさん
NGNGプラスして関数名でも 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;
0292デフォルトの名無しさん
NGNGif ( ... )
文;
elsif ( ... )
文
end if;
これなら比較的シンプルでスマートかな
0293デフォルトの名無しさん
NGNGAda系のほうがよさそうだけど、それを無理やり{}に押し込めるのは難しいね。
test(exp)
{
true:{}
false: test(exp2)
{
true:{}
false:{}
}
}
とか問題外かな。
0294デフォルトの名無しさん
NGNGそれだったら、条件式は
cond (boolean-expression)
{
true : syntax
false : syntax
}
１つだけになるのがいいのかな。
0295デフォルトの名無しさん
NGNGcond(int)で従来のswitch～case
0296デフォルトの名無しさん
NGNG0297デフォルトの名無しさん
NGNG{
if (exp0):
if (exp1):
else:
}
上から順番に調べて最初にexpがtrueになったところから実行。
switchと統合できないからだめか・・・
0298デフォルトの名無しさん
NGNG294-295は、Pascalのcase文風ってこと？どちらにしても条件式≠ラベルにして欲しい。
参考までにAdaだとこんな感じ。複数の文が来ても問題無いようwhenが付いてます。
case ... is
when ... => ...; ...;
when others => ...; ...;
end case;
cond(EXPRESSION){
when(CONSTANT)
...;
when(...)
...;
}
何か冗長…Cの制御文は条件式に ( ) が付くけど、あれ無くせませんか…？
0299デフォルトの名無しさん
NGNGwhen CONSTANT
single-syntax
when CONSTANT
single-syntax
others
single-syntax
end cond;
別に、whenじゃなくてもいいけど。
ブロックが式なら複文を受け取る必要性が無いと思うので、
こんな感じでどうか。
0300デフォルトの名無しさん
NGNGif ... { ...; 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: ...;
};
0301299
NGNG条件を非fall-throughにするためだったり
0302デフォルトの名無しさん
NGNG0303300
NGNG僕もwhen節/else節はどれか一つしか実行されないつもりでいましたけど…。
Adaがwhenを明記することで複文記述可能とbreak不要を実現している以上真似しない手は無いかと。
if X {
when 1 :
puts("○");
when 2, 3 : //X = 2 の時 ×と□だけが表示される
puts("×");
puts("□");
else: ...;
puts("△");
};
0304デフォルトの名無しさん
NGNG>>298
みんな:は便宜上使ってるだけで、必ずしもラベルのように扱うとは限らないと思う。
実際やるとしたら
case 0:
が
case (0) {}
だろうが、わかりやすいほうになると思われ。
C#のようにラベルとして扱いつつもbreakを忘れるとエラーという道も。
0305304
NGNG0306デフォルトの名無しさん
NGNGそれは承知しています。
ただし、ブロック化していない複数の式を一つの処理単位として扱うのは不自然な気がするので。
>when 2, 3 : //X = 2 の時 ×と□だけが表示される
> puts("×");
> puts("□");
> else: ...;
> puts("△");
puts("□"); の後、暗黙で（Cでいう）breakしちゃうのはどうかと思うので。
各節は一つのsyntax/blockを受け取る様にすれば自然かな、と。
0307デフォルトの名無しさん
NGNG了解です。
しかし、Pascalのcase文がまさにそれなのですが、実際使うとbeginとendがうざいです。
case X of
1:
Write("○");
2, 3:
begin
Write("×");
Write("□");
end;
else
Write("△");
end;
同じレベルの処理のはずなのに、複数の文があるというだけでインデントされ前後に2行無駄な行が…
0308デフォルトの名無しさん
NGNGそして
case A or B
を許してくれ
0309デフォルトの名無しさん
NGNGなるほど・・・
確かにウザイですね。
0310デフォルトの名無しさん
NGNGputs("1");
when ～:
puts("2");
puts("3");
だとパーザ書くの大変でない？
0311デフォルトの名無しさん
NGNGcase 0:
{
}
break;
だから、break書かなくていいだけでも十分楽チンとか思っちゃうんだけど。
0312デフォルトの名無しさん
NGNGPascal/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;
}
0313デフォルトの名無しさん
NGNGif XXX {
is 0:
doSomething();
is 1:
doAnything();
else:
doNothing();
}
0314デフォルトの名無しさん
NGNG>>300のような記述（ifとswitchをそっくりに）を許すならisはあわないと思われ。
// 従来のif
test //漏れはtestがいいです（；´Д`）
{
when exp:
when exp:
else:
}
// 従来のswitch/select/case
test( exp ) // 任意のオブジェクトが可能。
{
when value:// 定数でなくても可能。たとえば文字列
when value:
else:
}
0315デフォルトの名無しさん
NGNGtest 式 { when 値: ...
if 式 { when 値: ...
case 式 { when 値: ... Ada風
select 式 { case 値: ... BASIC風
switch 式 { case 値: ... C風
書き並べて見ましたけど、やはり"if"がしっくりと。でも他の言語で使われている組(下3つ)のどれかでもいいな
0316デフォルトの名無しさん
NGNG0317デフォルトの名無しさん
NGNG0318デフォルトの名無しさん
NGNGif - {
} else if - {
} else{
}
switch - {
case A
;
case B or C
;
default
;
}
とかがいい。breakいらない。だから、たのむから、下に落ちないで。
0319デフォルトの名無しさん
NGNG0320デフォルトの名無しさん
NGNG手抜きUnitTestを書くときtestメソッドで全部やりたいよ
0321デフォルトの名無しさん
NGNGブロックの中まで制御構文なんで、
そのブロックをオブジェクトとして扱えない ＝ 状況に応じて取り替え出来ない
とか思ったり。
0322デフォルトの名無しさん
NGNGTestメソッドにしてください。
0323デフォルトの名無しさん
NGNGここまでの流れを見て
ようやくCのcaseがラベルなのか分かったよ
0324デフォルトの名無しさん
NGNG・文字ケース同一視(Pascal/BASIC) or 区別(C系)
・命名規則 AbcDef(Pascal) or Abc_Def(Ada) or abcDef(Java) or abc_def(C/C++)
文字ケースを同一視する or JavaかC/C++の命名規則を用いる場合、"Test"で逃げるわけにもいきませんよね…
0325デフォルトの名無しさん
NGNG命名規則は・・・人に出すときはPascal式、
自分の文はAda式で書いてるかな
0326デフォルトの名無しさん
NGNG大文字小文字は区別がイイ。
命名規則は公開はPascal、内部やローカルは勝手にしなさいって感じ。
0327デフォルトの名無しさん
NGNG・アンダーラインの直後を大文字に
・小文字と大文字が並んでいたらアンダーラインを挿入
( 全部小文字で予約語が書かれていた場合、それは変換しない )
内部的にこういう変換をかけてくれたら、>>324の4つの命名規則のどれで書いてもいいことになり(内部ではAda式で保持)
他人のライブラリを使う時命名規則でイライラすることが無くなる…とか提案してみる。
0328デフォルトの名無しさん
NGNG0329デフォルトの名無しさん
NGNG0330デフォルトの名無しさん
NGNG0331デフォルトの名無しさん
NGNG手っ取り早く再利用。
0332デフォルトの名無しさん
NGNGEiffel#が多重継承できないとか言う話もあったし
0333デフォルトの名無しさん
NGNG0334デフォルトの名無しさん
NGNGメソッド定義は 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は「整数を取り実数を返す関数へのポインタ」と「定数の文字列」を引数に取り「整数を取り実数を返す関数へのポインタ」を返す )
0335デフォルトの名無しさん
NGNGよくわかんないんだけど、このスレって流れいくつあるの？
ポインタを推進してた>>1は逃げたし、
実装すると名乗り出ている>>39はポインタなしでGC搭載でしょ
>*とconstを全て左からかかるようにすれば
Cと微妙に違うくせに似てるのがｲﾔﾝな感じ
0336デフォルトの名無しさん
NGNG0337デフォルトの名無しさん
NGNG0338デフォルトの名無しさん
NGNGJavaやC#のように宣言と定義を同時に行う形式じゃダメなのかな？
ObjectPascalの様に分ける必要ある？
0339デフォルトの名無しさん
NGNGprocious.1
this.(:)3|project(i) 4(i)=5(i)
～ この生続き ～
0341デフォルトの名無しさん
NGNG0342デフォルトの名無しさん
NGNG0343デフォルトの名無しさん
NGNG各々自分の理想を語って終わりになるような。
0344デフォルトの名無しさん
NGNG0345デフォルトの名無しさん
NGNGつくってくれるひとはいそうだけど、どんなんつくるか、まだあまりきまってない
0347デフォルトの名無しさん
NGNGでも今のままでは、言語仕様が統一される気配もない。
作れる奴がまず言語仕様と実装を提案する形で公開すれば、もっと具体的な
議論ができる。
今までの経験からいって、「みんなで作ろう」型プロジェクトがうまくいった
試しがない。
「こんなん出来たけどどうよ？」型プロジェクトだけが現物を手にできる。
0348デフォルトの名無しさん
NGNG034939 ◆6K2ziZrM
NGNGただ、あんまりいろんな言語に明るくないので、
そんなに発言が出来ないだけナリ
035039 ◆6K2ziZrM
NGNGとりあえず、いろんな言語で「～がある・ないからダサイ」っていう発言結構あるじゃない
皆さん、言語仕様とかにこだわりがある人も多いようなんで。
だったら悩みを（ある程度解消できる）素晴らしい言語仕様を考え出せるんじゃないかな、と。
日本初の言語はおもちゃがほとんどなんで、せめてメジャー所と張り合える位には素晴らしい物を。
ちなみに、私はC++/C#/Scheme/Perl位しかマトモに扱えないんで、
どうしても考えがC#よりに偏りがちです
0351デフォルトの名無しさん
NGNGこんなの提案
switch
{
when exp0:
when exp1:
else:
}
switch文内にwhenが1つか無い状況の省略記法として
if (exp) // elseは使えなーい
も残してもいいかと
0352_
NGNGターゲット
ポインタ有りvsＧＣ有り
静的型付けvs動的
文法Ｃ風味vsオリジナル
定義宣言同時vsヘッダーとソース分離
決めない方がアイデアはいっぱいでてくるけど・・・
0353デフォルトの名無しさん
NGNG漏れはポインタは無くていいと思う。
C++で十分満足してる。
035439 ◆6K2ziZrM
NGNGGC：単に実装してみたいから
静的：好み
が理由です。
035539 ◆6K2ziZrM
NGNGそのswitch構文だと、後に続く{}はブロックじゃないんですよね？
ラベルとしてもブロック内側へのジャンプはなしの方向なので、
実現できないし。
switch構文だけ特殊化するの？
035839 ◆6K2ziZrM
NGNGやっぱりあきらめて特殊構文として扱う必要があるのかな
0359デフォルトの名無しさん
NGNG#define when break;case
でいいんじゃない？
0360デフォルトの名無しさん
NGNGなんだそれは
0361デフォルトの名無しさん
NGNGAda風ってこと
0362デフォルトの名無しさん
NGNG0363デフォルトの名無しさん
NGNGCで言うなら
0364デフォルトの名無しさん
NGNGって言うか俺はネイティブコンパイラ作る知識も経験も無いから、
おおむねで39の要望どおりで
0365デフォルトの名無しさん
NGNG上で色々言われているように各種メリットはPascal/Ada風が上。しかしC風に慣れている人は多いかな？
僕はPascal/Ada風を推します。
ちなみに352のアンケートには「GC/静的/外見C実質Ada/同時」を希望。
0366デフォルトの名無しさん
NGNGPascal/Ada風だと、UMLマッチ度も高いね
でもstaticとかreadonlyみたいな修飾子はどんな形でつくの？
あと、別スレで見たんだけど、同じ順番のVB（Var as Type）は変数を複数同時に宣言したときの初期化が面倒らしいんだけど、解決の方法はあるかな。
0367デフォルトの名無しさん
NGNG宣言と初期化を同時に行うのは
a = SomeClass.new : SomeClass;
となるのかな？
0368365
NGNG修飾子は…constはAdaなら A, B: constant := 10; (Integerであることは推論される) でした。
constant Integerって明記してもいいですけど。
readonlyみたいなのは…前か後しか無いでしょうね。
readonly A: Integer := 10;
A: Integer := 10 readonly;
Pascal/Ada風には宣言が常に名前で始まり名前の桁が揃うというメリットもあるので、それを活かすなら後ろかな。
0369デフォルトの名無しさん
NGNG0370デフォルトの名無しさん
NGNGA, B : Integer := 0;
この形式はどうだろうねぇ。
クラスだったらA,Bは同じ一つのインスタンスを刺す参照？
0371デフォルトの名無しさん
NGNGprotected:
Name: String;
Info: SomeClass;
public:
Execute: (Data: Pointer) Integer; //よくわからんが関数はこんな感じ？
protected Name: String;
protected Info: SomeClass;
public Execute: (Data: Pointer) Integer;
どちらがいいか明らか。
0372デフォルトの名無しさん
NGNG0373デフォルトの名無しさん
NGNG宣言・初期化は
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;
みたいに出来たら幸せかと思うんだけどどうでしょ？
0374デフォルトの名無しさん
NGNGメソッドは、どちらがいいかな？
Method: (Arg: int) int; //引数は型情報の一部
Method(Arg: int): int; //Pascalのfunctionに近い
( ) の後に記号無しで戻り値の型が来るのが変ならここにasを用いてこんなのもありかもしれません。
Method: (Arg: int) as int;
…intじゃなくてIntegerと書きたいな…整数型が予約語である必要は無いわけですし。まあこれは別の話ですね。
instance/sharedは、インスタンスorクラスに付くかということですか？それは幸せっぽい。
でも、何も書かないのがインスタンスで、クラスはclass public: がいいです。
0375デフォルトの名無しさん
NGNGとか
0376デフォルトの名無しさん
NGNG>でも、何も書かないのがインスタンスで、クラスはclass public: がいいです。
意味が分からない（汗
0377デフォルトの名無しさん
NGNGif (arg != 0)
result = arg * 10;
}
こうすれば、resultを暗黙の変数としなくてもいいし、
戻り値が何であるかも分かってイイかも
0378デフォルトの名無しさん
NGNG＞->result
冗長すぎない？
0379デフォルトの名無しさん
NGNG0380デフォルトの名無しさん
NGNGpublic: // ただのpublic/private/他はインスタンスメンバ
class public: // class がついたらクラスメンバ
ということだと予想
でも、この場合インナークラス（実装するとして）の可能性もあってコンパイラが混乱するから
classキーワードを使うことは出来ないと思われ
0381デフォルトの名無しさん
NGNGかなーり記号的な言語になりそうな予感
0382デフォルトの名無しさん
NGNGreturnを消して暗黙の変数resultに代入すると言う案があったから。
->index: Integerとか戻り値に名前を付けられる
0383デフォルトの名無しさん
NGNGああ、それなら納得。
0384age
NGNG0385デフォルトの名無しさん
NGNGクラス宣言(型宣言)も、名前を先にすればおっけー。(isはAdaより)
SomeClass is class: SuperClass
{
class public:
ClassAttr: Integer;
ClassMethod: (Arg: String) -> Result: Integer; //←この形に一票
InnerClass is class
{
...
};
};
0386385
NGNGよって Method: (Arg: String) -> Integer; に一票。
ついでに派生を class: SuperClass と書いたけど、ここの : も型情報の中の括弧で囲っていない : と考えると気になってきたので
ObjectPascalみたく class(SuperClass) を
…気にしすぎかな
0387デフォルトの名無しさん
NGNG0388デフォルトの名無しさん
NGNGクラスメンバ扱いの InnerClass って、どうやって外側のクラスのメンバにアクセスするの？
インスタンスメンバにはアクセスできないって事？
0389デフォルトの名無しさん
NGNGこれでいいとおもうけどなぁ
method: (arg: string) -> (result: int, status: int) { }
やろうと思えば複数戻せる
0390デフォルトの名無しさん
NGNGSomeClass is class(SuperClass)
{
class public:
ClassAttr: Integer;
ClassMethod: (Arg: String) -> Integer; //->はasでも他の記号でも何も書かなくても
public:
InnerClass is class
{
...
};
};
0391デフォルトの名無しさん
NGNGよく (int,int,int)->int 型の関数とか表記するでしょ？
0392デフォルトの名無しさん
NGNG0393デフォルトの名無しさん
NGNGint len;
length < "string" > len;
find: (base: string, part: string) -> (index: int, len, int)
int index, len;
find < ("this is a pen.", "is") > (index, len);
0394デフォルトの名無しさん
NGNG呼びだし側はどうやって複数の返値を受けとるの？
a, b := method(""); とかは想像付くけど、式の途中で呼ばれたら？
0395デフォルトの名無しさん
NGNGそう言う使い方想定してないでしょう。
使用者も制作者も。
0396デフォルトの名無しさん
NGNGC#のoutパラメータの方が使い勝手いいような。
if(Method(A, B, out C) == true)
{
...Cを使う...
}
式の途中で呼べないのなら、こういう使い方もできないことになりませんか？
0397デフォルトの名無しさん
NGNG0398デフォルトの名無しさん
NGNG返値 ＝ func（引数）
の関係を保ちたかった。
0399デフォルトの名無しさん
NGNG引数と返値をごちゃ混ぜにするから
0400デフォルトの名無しさん
NGNG0401デフォルトの名無しさん
NGNG0402_
NGNG0403_
NGNGreturn width, height;
end
width, height = box.size;
みたいに使うみたい。
0404デフォルトの名無しさん
NGNGより
ClassMethod(Arg: String) -> Result: Integer;
のほうが良くない？
呼び出し元と近い記述が出来て見目麗しいと思う。
でも出来れば -> Result はキーワードresultみたいなのを使用するように変更したほうがいいと思う
メソッドの1行目って、対人宣言としての意味もあるわけで、
ドキュメント化されたり、他の理由でメソッドの使用者が見ることもあるだろうけど、
そこにメソッドの内部で使用されるだけの変数名が出てくるのはやめたほうがいいと思う。
GetIndexOf( substr: String ) -> index : Integer;
とかいくつか考えてみたけど、その変数名が見えてもあんまりメリット無いし。
あと、暗黙のresultなどの変数に代入したものが戻り値になるのは、
{
int result = 0;
// 処理いろいろ
if (hoge) result = 1;
return result;
}
などのような方法に比べてどのようなメリットがあるのでしょうか？
0405デフォルトの名無しさん
NGNG引数も型と見なせるから
ClassMethod: (Arg: String)->Integer
でいいとおもう。
シンボルClassMethodは(string)->int型の関数を意味する
って感じかな
0406デフォルトの名無しさん
NGNG>メソッドの1行目って、対人宣言としての意味もあるわけで、
一人で使う分には名前を付けられた方がメソッド内部の実装に便利だけど、
多人数だったりするとそうでもないか。
しかし、多人数で使える物にするのかぁ？
0407デフォルトの名無しさん
NGNGなんて読むの？
0408デフォルトの名無しさん
NGNGClassMethod: (Arg: String)->Integer
意味を考えると、後者の書式で->をasと置き換えるのはよくないと思う。
(Arg: String)はIntegerではないのだから、toとかの方が適切か
0409デフォルトの名無しさん
NGNG0410デフォルトの名無しさん
NGNGありがとう。
0411デフォルトの名無しさん
NGNG…と思うので、僕は Method: (...) -> ... 派。(記号 "->" については考えてもいいと思いますが)
使用箇所と宣言を同じに見せるという考えで作られたCのポインタの宣言が結局変なのは周知の事実な訳で
使用と宣言は違うと割り切った方がいいかも。
>メソッドの内部で使用されるだけの変数名
仮引数名だってそうですけど…引数は複数渡せますからね。
結局、複数の返り値か、outパラメータか…で、複数の返り値の場合は、返り値に名前を付ける意味が出てくるのだと思います。
result変数のメリットは>>253。
戻り値が構造体の時、r = m(); を内部で m(&r); として取り扱って、
渡されたアドレスをそのままresultに見せる最適化は実際にDelphiで行われています。
0412デフォルトの名無しさん
NGNG慣れなのか？慣れれば気にならなくなるのか？
0413デフォルトの名無しさん
NGNGとりあえずPascal(ObjectPascalでも可)とAdaとEiffelと、変種なところでHaskellやJScript.NETなどのソースを沢山読んでみるとか(w
0414デフォルトの名無しさん
NGNGClassMethod;
in
Arg as String;
out
Result as Intger;
defend
0415デフォルトの名無しさん
NGNG>>411
> 仮引数名だってそうですけど…引数は複数渡せますからね。
それと、引数の名前が持ってる情報量は戻り値の名前が持ってる情報量より多いように感じた。
普通メソッドの戻り値って、何らかの値の取得か、実行結果みたいなのが多いと思うけど、
前者（たとえばGetFileName:()->fileName）は、もともと戻り地が何を表しているかを分かってて使うものだし、
後者（たとえばExecute:()->errorCode）は、結局ドキュメントを見ないと何のことやら分からない。
でもパラメータはそれを読む人に、ヒントを与えられる。
で、戻り値の名前は不要かな、と思ったしだいです。
resultについて、参考になりました。
最適化に使えるんですね。
0416デフォルトの名無しさん
NGNG全般
>>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
0417デフォルトの名無しさん
NGNG命名規則
>>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
0418デフォルトの名無しさん
NGNG条件分岐
>>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
0419デフォルトの名無しさん
NGNGポインタ演算子
>>4
オーバーロード
>>204>>205>>214>>218
ライブラリ
Windows
>>226>>227
その他参考になりそうな発言(独断と偏見)
>>10>>11>>12>>13>>83>>136>>402>>403
0420デフォルトの名無しさん
NGNGおつかれ！
0421デフォルトの名無しさん
NGNGしかし、どれもこれもアイデアの列挙で全然まとめに入ってないよな
0422デフォルトの名無しさん
NGNG0423デフォルトの名無しさん
NGNG0424デフォルトの名無しさん
NGNG機能的に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 { 無限ループ }; を兼用させても自然だなあ、とか。
0425デフォルトの名無しさん
NGNG単純な列挙には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;
}
}
0426デフォルトの名無しさん
NGNG0429デフォルトの名無しさん
NGNGウザイ。
0431デフォルトの名無しさん
NGNGこれまでの話で出てきた構文に当てはめるなら 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で統一できそうな感じですね。
0433デフォルトの名無しさん
NGNG俺は何かと<=より<のほうがいいなぁ。
で、こうすると<=のほうがｲｲ！いや<のほうがｲｲ！って争いになって、
結局中とって自分で選べるC風がｲｲって話になるんよ。
そもそも>>424はカウンタにBYTE使うのがおかしいと思う。
0434デフォルトの名無しさん
NGNG列挙型を使うことを考えてみてください。
enum T { A, B, C };
for(T i = A; i < C; ++i) { ... // 最後の値(C)を使えない
for(T i = A; i <= C; ++i) { ... // i が範囲外の値を指さないと終わらない
0435434
NGNGCの列挙型は整数定数と大差ありませんけど、まともな列挙型を持つ言語としては欠陥と思います。
で、これを避けるために、Pascal風とか、Rangeオブジェクトとか、そういう話をしたいわけで…。
PascalやAdaは、列挙型を配列のインデックスにできるため、ループ変数に列挙型を使う機会が多いように思います。
この言語では配列はどうか知りませんが、flag型が提案されているので、やはり必要に感じます。
0436デフォルトの名無しさん
NGNG>>431の場合最後のループ中にbreakしたのか、それとも最後まで実行されたのか判断できないよね。
0437デフォルトの名無しさん
NGNG0438デフォルトの名無しさん
NGNGラベル付きbreakが使えそうなのでこんなのもありかも。
L: {
for(まあ記法は置いておいて){
...
break L;
...
}
最後まで実行された時だけ実行される
}
或いはPythonみたいにforにelse節を書けるようにするとか
0439デフォルトの名無しさん
NGNG0440デフォルトの名無しさん
NGNG0441デフォルトの名無しさん
NGNGそれよか言語仕様としての例外処理を充実させた方がいい。
0442デフォルトの名無しさん
NGNG0443デフォルトの名無しさん
NGNGgotoは廃止。
0444デフォルトの名無しさん
NGNG0445デフォルトの名無しさん
NGNGというか話題はラベル付きbreakがメインじゃなく、forを最後まで実行したか、途中で抜けたかの判断方法なのですから
>>438がトリッキーと思うならPythonのfor-elseとか、他の方法とかを考えればいいと思います。
( >>438を例外処理で書き換えたら、そっちの方がトリッキーと思うのですけど )
>>439
**はAdaやHaskellでn乗演算子。例: 2 ** 3 = 8
これに関してはBASICの ^ の方が好きですね。
0446デフォルトの名無しさん
NGNGどうしてもループの底から脱出したくなったらthrowしてループの外側でcatch。
0447デフォルトの名無しさん
NGNG0448デフォルトの名無しさん
NGNGfor(int i = 0; i < a.length; ++i) //forの書式は例によってひとまず置いておく
{
if(a[i] == 探しているもの)
{
r = a[i];
break;
}
}
で、探しているものが見つからなかった時に実行したいことがある。
i == a.length で判断する方法も考えられるが、列挙型などでは i が有効範囲を超えることができないので却下。
使えそうな方法は
・フラグ変数を用いる(流れ制御のために変数を増やすのは嫌だ)
・ラベル付きbreak(トリッキー？)
・Pythonのようにforにelseを設ける(一番正当な解法と思われるが言語仕様が増える)
・見つかった時例外をthrow
「見つからなかった時」こそ例外を投げたいと思われるのに…
それでも見つかった時(むしろこっちが正常な流れと思われる)に例外を投げろと？
0449デフォルトの名無しさん
NGNG使うべき。で、インデックスが範囲を超えたときに例外を投げるなりナンナリ
した方が良いと思われ。
0450デフォルトの名無しさん
NGNG0451デフォルトの名無しさん
NGNG( i が常に 0 以上 a.length 未満であるよう気をつけるとして) こんな感じですか？
if( a.length > 0)
{
i = 0;
while(a[i] == 探しているもの)
{
if(i = a.length - 1)
{
見つからなかった時の処理;
throw 見つからなかった例外;
}
++i;
}
}
配列ならこれでいいけど foreach を使いたい時はどうすれば…
0452451
NGNGif( a.length == 0)
throw 見つからなかった例外;
else
{
i = 0;
while(a[i] == 探しているもの)
{
if(i = a.length - 1)
throw 見つからなかった例外;
++i;
}
}
……………………Pythonの解法に一票
0453デフォルトの名無しさん
NGNGPythonかー。
0454デフォルトの名無しさん
NGNG0455デフォルトの名無しさん
NGNGfor i in range(count(a)):
if a[i] == 探しているもの:
r = a[i]
break
else:
raise 見つからなかった例外
要するにbreakされなかった時に実行される節で、これなら foreach でも while でも同じように付けられます。
( …ってラベル付きbreakが使えればそれでいい気もするんですけどねー)
0456デフォルトの名無しさん
NGNG時に実行するようにも見えるから、名前を変えたほうがいいと思う。
0457デフォルトの名無しさん
NGNG同意、漏れはrangeが空だった時に実行されるように見える
finallyはどうかな？
0458デフォルトの名無しさん
NGNG0459デフォルトの名無しさん
NGNG0460デフォルトの名無しさん
NGNGというか皆さん本当にこれらが無くなっていいの？
0461デフォルトの名無しさん
NGNGgotoの様に無節操な使い方は出来ないし、
問題ないと思います
0462デフォルトの名無しさん
NGNG今のところ解決法は次のふたつ。
・Pascal/Ada風の書式にする
・Rangeオブジェクトとforeachにする
個人的には、部分範囲型を導入したいところです。
C#のようにバイト数で型を分けるのでは無く、使える範囲を明確に指定して型を作れるようにする。
で、それをRangeオブジェクトのように扱えるようにして…駄目？
0464デフォルトの名無しさん
NGNGfor ( 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
0465デフォルトの名無しさん
NGNG実行順序が重要なら別のloop構文を用意して、
iterationにはforeachを使う。
foreachならコンパイラが勝手にマルチスレッドに展開しやすいかも
0466デフォルトの名無しさん
NGNGPascalのfor文で、ひとつのforに制御変数が複数置けるようになって、なおかつwhileも併用可能な感じですか。豪華ですね。
to、downtoよりもabove、belowのほうがわかりいいかも。
C式のforは要りませんよね。
無限ループはwhileで作れますし、foreachとPascal(Ada/Dylan?) 式のforがあれば。
foreachに逆順で回る構文を追加すれば、Rangeオブジェクト or 部分範囲型 と併用することでPascalのforをカバーでき、
ループはwhileとforeachだけにできそう。
0467デフォルトの名無しさん
NGNG0468デフォルトの名無しさん
NGNG・常にforeachは順方向を用い、逆順を使いたい時は逆方向イテレータを間に挟む
・foreachに順方向か逆方向を選ぶ構文を追加する
んー、どっちでもいいとは思いますけど、強いていうなら、順方向と逆方向に優劣は無いと思うので、構文、かな？
0469デフォルトの名無しさん
NGNG自分をみうしわない、いきることを見失わない ……生きた電脳、 ﾌﾟﾘｰｽﾞ。
それを追求するなら何ｽﾚ、何年かかってもよい ……助けて 誰か 助けて…
0470デフォルトの名無しさん
NGNGコンピュータの真理
0471デフォルトの名無しさん
NGNG(classじゃなくstructになるとしても) i++ より i = i.next のほうがいい気がする
0472デフォルトの名無しさん
NGNGC++/Adaのようにインスタンスを動的と静的の両方に配置できるなら必須ですけど、
C#のようにclassは動的、structは静的と決まっているなら、「 型名( ) 」だけで意味が通じる気が。
0473デフォルトの名無しさん
NGNG違いは値型か参照型か
0474デフォルトの名無しさん
NGNG一瞬納得しかけたけれど、C#では値型もコンストラクタを呼ぶ時にnewは絶対必要みたいです。
int a = int(); はエラーになり int a = new int(); は通りました。
structが参照型になる時はBoxingのみだから、やっぱ要らない気がしますけど、なんか間違ってます？
0475デフォルトの名無しさん
NGNG実行順序重視でforでもforeachでもないループ文…どんなの？
0476デフォルトの名無しさん
NGNG0479デフォルトの名無しさん
NGNG現在でてる中からよさげな仕様をピックアップして、まとめちゃわないか？
0480デフォルトの名無しさん
NGNG0481デフォルトの名無しさん
NGNGAdaで 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
0482デフォルトの名無しさん
NGNGすぐに思いつくあたりだと
・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はここでだけ有効…
}
}
0483デフォルトの名無しさん
NGNG0485デフォルトの名無しさん
NGNG型
イテレータ
>>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
…前のを作ってからあまり経過していないと思ったらけっこうありますね。
0486デフォルトの名無しさん
NGNG0487デフォルトの名無しさん
NGNG>>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は配列の一種とみなしてツリーを作ってみましたが、別にした方がいいかもしれません。
0488デフォルトの名無しさん
NGNGgenerics導入の意義が薄れないか？
既存のJava/C#なんかとほとんど変わらないだろう
0489デフォルトの名無しさん
NGNGまだ戻り値が複数かどうか、ref、outパラメータを認めるかどうかに決着がついてなかったような。
構文も戻り値のところが曖昧なまま…
NAME: (ARG: TYPE) -> RTYPE; //"Result"は暗黙の変数
NAME: (ARG: TYPE) -> RESULT: RTYPE; //戻り値を返すための変数に名前を付けられる
NAME: (ARG: TYPE) -> (RESULT1: RTYPE2, RESULT2: RESULTTYPE2); //複数の戻り値を認める場合
0490デフォルトの名無しさん
NGNG>>163で言われているようにタイプセーフだけでもgenericsの意義はあると思いますけど…
というか代案があるならそれをまとめてみてくれませんか？
0491デフォルトの名無しさん
NGNGv: double align(16);
struct x align(16), padding(4)
{
x: int;
y: int
}
0492デフォルトの名無しさん
NGNGタイプセーフは確かにメリットだけど、
objectが頂点のツリーを形成すると、それをコンパイル時に解決できないでしょ？
いや、解決できるかもしれないけど、collectionがobjectを継承するメリットが無くなる
0493デフォルトの名無しさん
NGNGv: Real #align(16);
x is struct #align(16) #padding(4)
{
x: int;
y: int;
};
0494デフォルトの名無しさん
NGNG> objectを頂点に持ってくると、
> generics導入の意義が薄れないか？
そうなの？
クラス定義時に必ずobjectを継承しる！というのはウザイけど、
クラスライブラリの構成としてオブジェクトの標準的な振る舞いを
ルートクラスに置いておくのは普通かな、と。
そういうのもgenericsで記述すべき？
>>489
戻り値が複数っていうの本当に便利？
リストやベクターをファーストクラスオブジェクトにして、
それらのオブジェクトを一個返せば十分じゃない？
0495489
NGNG0497デフォルトの名無しさん
NGNG0498デフォルトの名無しさん
NGNG後半は結局何の変哲もないありふれた言語になりつつあるな。
0499デフォルトの名無しさん
NGNGどのへんをもって「静的」とおっしゃってますか？
ちょっと聞いてみたかったり。
0500デフォルトの名無しさん
NGNG静的で総称が使える言語はAda, Eiffel, C++, Java(予定), C#(予定) ってとこですか。
JavaとC#は知りませんけど、C++が比較的自由に使えるのに対し、Adaなんかは総称に条件が付きまくってた気が…。
genericsの仕様を先に決めるべき？
0501デフォルトの名無しさん
NGNGそうかも。
良さげなのを提案してみてください。
0502500
NGNGというわけで詳しそうな488=492?さん、お願いします。
0503デフォルトの名無しさん
NGNG例外が飛んでくるらしい
0504デフォルトの名無しさん
NGNGJVMの互換性を保つためとはいえ、型情報が失われるのは嫌ですね…。
実行時例外が起きるなら、結局ダウンキャストの手間を省いているだけのような…。
しかし、コードサイズが型毎に増えずにすむのも事実。
内部ではObjectクラスにBoxingしてコードは共有、型識別子みたいなものは別々に作るみたいに
…駄目だ、それでもパラメータとして与えられた型を実体化できない…。
やっぱコードサイズは犠牲にするしか無いのでしょうか。
0506デフォルトの名無しさん
NGNGAdaは、型の種類や持っているメソッドを事細かく指定しないといけません。型ではなく関数orパッケージが単位でちょっと他と違う感じです。
Eiffelは、普通に使えるみたいですが、(Javaの総称みたいに)パラメータ型が継承すべきクラスを指定できるようです。
>>505 もっと詳しく説明していただけますか？
0507デフォルトの名無しさん
NGNG0508500
NGNGEiffel 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;
};
…自分でも突っ込みどころ満載なのは認識してますが、議論再開のきっかけになれば幸いです。
0509デフォルトの名無しさん
NGNG0510_
NGNG厨的質問スマソ。（CでOOっぽくプログラミングしてるのでgenericsは分からない)
Eiffelで派生元を制限できるのって聞いた時かなり感動したんだけど・・・
0511デフォルトの名無しさん
NGNGもし継承が前提なら、両方ともX::Func(Object Arg)、Y::Func(Object Arg)にしなければいけないので、
型チェックのありがたみが薄れる…のだと思います。(自分も詳しく無いです)
0512500
NGNGVectorElement 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>>が通るように、">>"演算子か、型パラメータを囲む"<" ">"をどちらか変えませんか？
0513デフォルトの名無しさん
NGNGなんで<～>なんて構文にするのか疑問。
C++のテンプレート構文は後付けだから*しかたなく*そうした面があるけど。
0514500
NGNG0515デフォルトの名無しさん
NGNGimplements 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に習って[]とか。
0516_
NGNGなるほど。厨的には、親クラスを指定して制限かけるほうがいいかな。
でも実装方法は自動的にキャストしてくれるだけ？の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
0517デフォルトの名無しさん
NGNG面白いですね、それ。(ところでprotectedにしたいコンストラクタはどう書くのですか？)
type IntVector is Vector[Integer]; //generics実体化
type IntArray is [ ] Integer; //参照型
type TheArray is IntArray[1..10]; //値型(いきなり [1..10] Integerでも可)
なんて書ければ配列とgenericsが似せられていいかな…
0518デフォルトの名無しさん
NGNGBooleanは間違いでIterator[T]だね。
型が一致する場合のみ関数実体を参照・転送出来るのをイメージ
複数のインターフェースで同一メソッドがあるとき便利だから。
それと、>>515の書き方だとどのメソッドを実装しているのか一目で分かる
Arrayで総称を使うならCollectionを継承する意味が全くなかったり。
しかし、ArrayをFCOとするならCollectionを継承してたほうが何かと都合が良いんで
Java的な動的解決のGenericsしか選択肢無いような気がする。
0519デフォルトの名無しさん
NGNG>ところでprotectedにしたいコンストラクタはどう書くのですか？
分かりません（汗
メソッド定義がこの形になったんで、
アクセス識別とかpropertyとかどうやって宣言するのかサッパリ想像つかないです
0521デフォルトの名無しさん
NGNG>しかし、ArrayをFCOとするならCollectionを継承してたほうが何かと都合が良いんで
C++の配列は何も継承していなくてもSTLで使えますけど、Collectionって必要ですか？
むしろそういうのを不要にできるのがgenericsと思ってたのですが…。
0522デフォルトの名無しさん
NGNGんー、言われてみればそうだね。
FCOはすべて１つ(Object)から継承しないと行けないわけじゃないよね
やっぱり継承されてると美しいとは思うけど。
バランスなんだよな。この辺優れた感覚を持った人の意見が聞きたいところ。
0523デフォルトの名無しさん
NGNGアクセス識別というのはpublicとかprotectedとかのことですか？
なら>>371>>373>>380>>385の辺りに議論が。C++風で落ち着いたのかな…？
プロパティは>>240ぐらいしか出て無いのでこれを名前が先に書き変えるとすれば
i: property int { public get { ... } protected set { ... } }; ？？
0525デフォルトの名無しさん
NGNG0526デフォルトの名無しさん
NGNG同意です。
・全てのスーパークラスとなるObjectクラスが必要 or 不要
・genericsはC++のように無制限 or Eiffelのように派生元などを制限可能
・genericsはC++のように静的 or Javaのように動的
・ICollectionやIComparableを用いる or STLみたくgenericsを用いる
・配列はFirst Class Object or ライブラリ
ちなみに自分は、(必要/制限可能/静的/generics/First Class Object)
0527デフォルトの名無しさん
NGNGそれはDに任せて
0528デフォルトの名無しさん
NGNG0529デフォルトの名無しさん
NGNGToString()は何かと役に立つ、とか反論してみる。
0530デフォルトの名無しさん
NGNG// 前方向反復子の要件
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 ); // 初期値を指定して作成可能
}
0531デフォルトの名無しさん
NGNG可能かどうか、という所も話題にした方がいいんじゃない？
個人的にはGenericsとオブジェクト指向のポリモルフィズムは同じ所を
目指した別々の場所からのアプローチだという気がしている。
ポリモルフィズムは柔軟性をとった結果、動的な実装になり、
Genericsは効率性を目指した結果、静的な解決を目指す、みたいな。
0532デフォルトの名無しさん
NGNGそうか、interfaceをgenerics化した記法が要件リストに使えるのか…目から鱗。
>>531さんは>>526(って僕が書いたのですが)はどれがいいと思います？
僕の意見はこんなとこです。
・Objectクラスは機能的に不要でも意味的には欲しい
・genericsは静的に解決する
・実行時にチェックが必要になりそうなICollectionやIComparableは不要、全てgenericsで行う
・配列は性能重視でFirst Class Object、それとは別に伸縮可能なVector[T]を設ける
0533デフォルトの名無しさん
NGNGhttp://www.etl.go.jp/~epp/jp/mj/
0534デフォルトの名無しさん
NGNGpackageや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 なんてのは不要になって…どうです？
0535デフォルトの名無しさん
NGNG0536デフォルトの名無しさん
NGNG0537デフォルトの名無しさん
NGNGあんな腐った言語のコンパイラ作る気にならんだろ
0538デフォルトの名無しさん
NGNG>・手早くGUIを使ったアプリが書ける
>・ネットワーク使用も簡単に
>・初心者でも難しくない仕様
>・ｺﾝﾊﾟｲﾙして他の言語から使われることができる(?)
>・ポインタを入れたい
この仕様を満たす最も現実的な案だと思う。
HSPが糞な理由の実行速度も解決できるだろ。
0539デフォルトの名無しさん
NGNGHSPが糞なのは速度以上に言語仕様だろ
0540デフォルトの名無しさん
NGNG現在の心の内を書いてくれたらなあと思ったりして。
そうしたら、それを前提にまだ決まっていない部分の話に移れるのではないかと思います。
0541デフォルトの名無しさん
NGNG初心者にわかり易い言語仕様だろ
0542デフォルトの名無しさん
NGNG0543デフォルトの名無しさん
NGNG具体的なソースきぼんぬ。
0544デフォルトの名無しさん
NGNGC++で書くなら
class Mod {
public:
foo();
};
template<class T>
class Class {
public:
};
0545デフォルトの名無しさん
NGNGpublic:
foo();
};
template<class T>
class Class__ {
public:
T mod1;
};
typedef Class<Mod> FooClass;
FooClass a;
a.mod1.foo();
0546デフォルトの名無しさん
NGNGコンポジションにしたクラスを自動生成するだけのコードに見えますが‥‥？
このやり方で任意の数のModを付加したい場合もダイジョブ？
C++をあまり知らないので‥‥。
0547デフォルトの名無しさん
NGNGこの状況でって？
Rubyだってmixinはクラス定義の中に書かなきゃダメでしょ？
class Mod1{};
class Mod2{};
template<class M1, class M2>
class Class_ {
public:
M1 mod1;
M2 mod2;
};
typedef Class<M1, M2> FooClass2;
0548デフォルトの名無しさん
NGNGclassは参照型だから問題ないけど、int等は値型だから、
コレクションクラスに入れたときイテレータでいじくり回すためには
参照を返せないとダメでしょ
0549デフォルトの名無しさん
NGNGFooClass2 a;
a.mod1.foo();
a.mod2.bar();
という感じでアクセスすることになるんだよね？
a.foo();
a.bar();
でアクセスしたかったり‥‥。ダメですか？
0550デフォルトの名無しさん
NGNG「継承はクラスに取り込まれる時だけ」「メソッドもフィールドも持てる」、だったかと。
>>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#の例でメンバーのメソッドを呼ぶだけのメソッドの羅列を見た時は、面倒な上メンテナンス性悪そうだと思ったし。
0551デフォルトの名無しさん
NGNG～ is class 系の宣言で継承を : だったり、微妙に記号的な言語の要素と
そうでない物が入り交じってたりあんまり美しくないよね。
統一しちゃおう。
個人的には[～ is][～ implements]の様な記述は視覚的にメリハリがないのでイヤ。
かといってperlまで行っちゃうと行き過ぎだから、ML位な感覚が丁度良いと思う
0552デフォルトの名無しさん
NGNGAda95 | 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 { ～
":" が継承、"|" が委譲…ダメ？誰かもっといい形考えて
0553デフォルトの名無しさん
NGNGmix-inモジュールで全てのメソッドをpure virtualにしたらそれがinterfaceでは？
mix-inモジュールも単一継承だけは認めて、でinterfaceは廃止、菱形継承はコンパイルエラー…何も問題ない気が
0554デフォルトの名無しさん
NGNG>>530を見れ。
0555デフォルトの名無しさん
NGNGをみてて思ったんだけど、
テンプレート引数への条件ってテンプレート引数内に書くの？
つまり
> // テンプレート引数の 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 を後にすることのコンパイラに対するわずかな負担増こそあれメリットが感じられないからです。
055639 ◆6K2ziZrM
NGNG>>530は総称（テンプレート）構文なので、
クラスの継承の構文とどういう関係があるのか分かりません。
>関数の書き方とも親和性がよく（？）ついでに
構文解析にはyaccを使うので、ある程度の無理は利きますし、
そもそも関数宣言と構文を統一するメリットは全くありません。
Lisp系のように極端なまでに統一するなら構文解析が要らなくなっていいんですが、
そういう処理系にしても意味がないと思います。
視覚的に綺麗、もしくは意味のある構文にする方が良いと思います。
0557デフォルトの名無しさん
NGNG0558デフォルトの名無しさん
NGNG// 変数
名前 : variable 型 = デフォルト値;
// メソッド
名前 : method [ テンプレート引数リスト ] ( 引数リスト )->型 { 実装 };
// クラス
名前 : class [ テンプレート引数リスト ] ( 継承リスト ) { メンバリスト }
variable,methodについてはあいまいさがないので省略可能、ということで。
一貫性があっていい感じだと思いますが。
0561デフォルトの名無しさん
NGNGいえ、継承です。
>>530はテンプレート引数への制限として、何かを継承していなければいけない、という制限をしていますよね。
その際の記述とクラスを定義したときの継承の記述は同じようになるべきだと思います。
代替案があるならそれでいいとは思いますが。
0562552
NGNGis を使ったのですが、558さんのはイイと思います。
ただ、isの場合型の別名定義(必要ですよね？)が NEWNAME is EXISTINGNAME; で可能なのに対し、
>>558の場合は、NEWNAME: alias EXISTINGNAME; みたいに
変数宣言と区別するため別途キーワードを必要とするのではないか？と疑問が。
( 別名定義は特殊構文無しに行いたい…と思っていたので )
しかし、考えてみれば、aliasみたいなキーワードは、むしろ存在した方が、
変数や関数にも別名を定義できていいのではないか？…とも思いました。
という理由で558さんに賛成。
( ついでに、常に省略可能なら、"variable"、"method"は不要と思います )
0563デフォルトの名無しさん
NGNGJavaのIntegerみたいなクラスが必要かな？
0564デフォルトの名無しさん
NGNGC#のようなBoxingを希望♪
0565デフォルトの名無しさん
NGNGプロパティつかえば
aIterator.Current = 100;
でたぶん桶かと
0566デフォルトの名無しさん
NGNGメンバの名前が衝突したときは名前を変更する方が
個人的にはいいな～。
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
0567デフォルトの名無しさん
NGNG関数の中身の記述が離れたところに書けないようにしてくれ
0568566
NGNGどういう意味？
0569デフォルトの名無しさん
NGNG名前の変更は賛成。
でも列挙型は欲しいよ…。菱形継承も嫌なのでmix-inやインターフェースも必要だし…。
…となってくると、型の種類のほうは増え続けるのです(w
0570566
NGNGわかった！
Eiffelはクラスのメンバ関数の定義と
関数の中身の記述が離れたところに書けないよ。
面倒なので省略した。スマン。
0571デフォルトの名無しさん
NGNG変数 : 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#寄りですけど叩き台にはなるでしょ)
0572571
NGNG0574デフォルトの名無しさん
NGNGそこまで統一しちゃうなら省略可能なmethodキーワードも入れちゃった方がよさげ。
継承した型間で名前が被った時は
継承した型のどれか.メソッド : [総称] ( 引数リスト ) -> 型 override {};
のような形もご一考を。
名前のバッティングの解決のために別の名前をつけるってのはあんまり好きくないので。
delegateは、作るとしたらシングルキャストで、
マルチキャストはeventとか別キーワードを作るか専用のコンテナを。
あと、メソッドやクラスもすべて;で終わってるのは意図したものだよね。
特にプロパティは;がないとどこまでかわからないし。
0575デフォルトの名無しさん
NGNG057639 ◆6K2ziZrM
NGNG特殊構文を入れたり、ユーザー（継承クラス制作者）が勝手にリネームするのは、
あんまりフールプルーフであるとは言えないと思います。
0577デフォルトの名無しさん
NGNGmethod: (x : Integer, y : Integer, color : COLOR) -> Boolean {}
なのか、
method: (x, y: Integer; color : COLOR) -> Boolean {}
なのか。
(x, y : Integer, color : COLOR)はちょっとイヤ
0578デフォルトの名無しさん
NGNG結局、定義からずっと同じ名前で使いつづけることができないのが嫌(C++, C#)、か、
常に オブジェクト.メソッド の形式で使えないのが嫌(Eiffel, ObjectPascal)、かの
選択になるのではないでしょうか？
0579デフォルトの名無しさん
NGNG>method: (x : Integer, y : Integer, color : COLOR) -> Boolean {}
前に、a, b: Integer = 0; みたいな初期化を認めるか？という話があって、
「複数同時の変数宣言は無くてもいい」ような意見を見た記憶が。
普段も複数同時宣言を認めるなら前者、認めないなら後者、でいいかと。
複数同時宣言は引数やローカル変数とかで確かに便利ですけど
型が同じだけで用途の全く異なる変数の宣言をまとめてしまうとか多々あるので
禁止することにも意味があるような、って感じで、僕はどっちでもいいです。
0580566
NGNG名前の変更は菱形継承にも使えるよ。
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
0581デフォルトの名無しさん
NGNG>メンバの名前が衝突したときは名前を変更する方が
そんじゃEiffel使えば良いんじゃないかと言う気もするが。
名前変更の是非はともかく、型がクラスしかないと言うのは
明らかにやりすぎだし、実用的とは言い難いと思うが。
ストイックなまでにポリシーを貫く（ex Eiffel SmallTalk Lisp 初期のML等)
のも、言語としては悪くないけど、アプリケーションプログラム言語としてはどうかと。
0582デフォルトの名無しさん
NGNGまた案出しばかりになっているな。
とりあえず、案を出すのはやめて>>1-580に出た案の中から
採用、不採用を決めていかないか。
矛盾や足りないところも出てくるだろうから、
それについては問題が浮き彫りになったところで考えるか後回しに。
0583デフォルトの名無しさん
NGNG出来れば、標準ライブラリの基礎となるところも決めておいた方が良いと思う。
.NET/Javaの様なツリーを形成するのか
C++の様な離散的な物にするのか
前者だと言語仕様から強くライブラリのサポートが必要になるから、
基礎部分だけでも決定しなければならない。
後者だと、言語にあわせてライブラリを作っていく形になるから、
よほど仕様を練らないと汚い実装やつじつま合わせが必要になってくる
0584デフォルトの名無しさん
NGNG0585デフォルトの名無しさん
NGNG0586飲食会のショーンコネリー
NGNGコピーされるとメモリに情報が格納されます。
そのコピーされたメモリの情報の中の文字コードを
見るにはどうすればいいですか？
ちなみに言語はVCです。
やりたい事はVCの
ｍａｉｌｅｒでの文章をコピーし
ＶＣで作成されたウィンドウ上で貼り付けを行ったとき
その文字コードをみるソースをつくりたいんです。
ご存知の方アドバイスお願いします。
0587デフォルトの名無しさん
NGNG0588デフォルトの名無しさん
NGNGC風構文で実現できればいいって感じ？
0589デフォルトの名無しさん
NGNGusing syntax-namespace 'C-like'
とかで、複数の構文を使い分けできたらいいと思う。
デフォルトは個人の自由にして。
拡張構文を許すなら、switchとかはifの構文唐でいい気がする。
多分switchはジャンプテーブル最適化を掛けたいんだろうけど、
この手の最適化はifに展開しても間に合う気がするし。
0590デフォルトの名無しさん
NGNGうわ、しばらく見てなかったら、今作ってる自作言語の構文規則がもろに出てしまっている。
ひとりで厨房ライクにほくそえんでたのにー!!
やっぱ、似たような事は誰でも考え付くな...欝だ。
0591デフォルトの名無しさん
NGNGこんな奇妙な構文普通はあんまり考えやすいとは思えないから、
たぶんにこのスレの影響を受けて多と思われ
059239 ◆6K2ziZrM
NGNGそういうの勘弁してください、yaccが使えなくなりそう。
タダでさえ、Genericsでの継承元の制限とかややこしくなりそうなので頭を悩ましてたり。
switchはifのシンタックスシュガーで良いと思います
case節に定数しか設定できないのは不便なので、どうせ逐次判定する実装になると思います。
0593590
NGNGでも、もう書き込まれちゃった以上、特許と同じだーね。
どーせ、おいらは敗北者さ。まじ欝。
とりあえず、実装をここより早く作る事を考えよう...
0594デフォルトの名無しさん
NGNG関数の引数も返値もセットで型情報とか、
その辺ほんとに一人で仕様作ってたならすごいと思うからがんばって作ってくれ。
俺はその案が出たとき なるほど、良いかも なんて思ってたヘタレだが。
別に勝利敗北なんて関係ないんで、気にするな。
しかしココは言語開発スレだから、自作言語の宣伝をするなら
良いと思う仕様やアイデアを説明してくれた方が趣旨に添っている。
一緒に参加してくれるなら大歓迎！
自慢したいだけならｶｴﾚ!
と言ったところだ。
0595デフォルトの名無しさん
NGNG型情報が失われてしまうのは痛い
↓こういうのがいいなぁ
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は作りにくくなるかもし得れません）
0596デフォルトの名無しさん
NGNG代入はともかく、クライアント側での変数定義が関数側に影響が出るのはどうかと。
確かに、ref/outの様なキーワードは必要なくなるけど、
値型を受け取る関数は常に２つのインスタンスを生成することになるんじゃないかな
0597デフォルトの名無しさん
NGNGintと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 の値が変更されます
0599デフォルトの名無しさん
NGNGそうでない言語もあるし、型付き言語なら別に効率も悪くならないと
思うんですが。
0600デフォルトの名無しさん
NGNGGC搭載したりするのが面倒だから。
スタック中のオブジェクトをスキャンしたり、
例外処理発生時のアンワインドを導入したり、ね。
0601デフォルトの名無しさん
NGNG0602デフォルトの名無しさん
NGNGint*はJavaのIntegerクラスを自動生成するようなものですね。
0603_
NGNG0604デフォルトの名無しさん
NGNGどの辺が？
0605デフォルトの名無しさん
NGNG型付きBoxingはいいかも。Objectクラスと両方用意しても何も不都合ありませんし。
( でも、C/C++式のポインタ演算子の順序は問題ありなので
定義は A: Integer*; では無く、A: *Integer; がいいし、
Unboxingは、*A では無く、A* がいいです。理由は何度も既出 )
Boxing/Unboxingは暗黙でいいと思いますけどね。
…しかし、これを許すとclass/structを分ける必要は無くなり、全部structでいいのではないかという考えが。
ルートになるObjectをまさか値型にするわけにもいかないので、逆はどうですか？
つまり、全ての型は基本的に参照型であり、列挙型や実数型、固定長配列、Object以外何も継承していないclassなど
一部の型を、値型として宣言できる、という寸法です。(structは廃止)
A: Integer; //参照型
B: ! Integer; //値型("!"はてきとー)
比較演算子は常に値の比較(演算子オーバーロードのメソッドが呼ばれる)として、
それとは別にアドレス比較演算子(オーバーロード不可、参照型のみ)を設けたらどうでしょ。
0606デフォルトの名無しさん
NGNG方がいいと思ってはいますが、流れ的に オブジェクト.親の型.メソッド になりそうなので
防衛ラインみたいなものをはっておきます(w
この言語の場合、主流(Objectからclassとして継承してくる流れ)と伏流(mix-inやインターフェース)
が明らかなので、衝突した時も、型を明示しないといけないのは伏流から継承したやつだけにしてください。
要するに、WindowクラスにFocusメソッドがあったとして、同じくFocusメソッドを持つHighlightインターフェース
と多重継承してHighlightListBoxみたいなのを作った時、単にFocusと書いたら
C++のようにエラーを出すのでは無く、Window.Focusを意味するものであって欲しいということです。
あくまで防衛ラインで、本命は名前変更(やはり伏流の方を変える形で)希望ですけど。
0607デフォルトの名無しさん
NGNGアイデアの取りまとめ人が必要では？
定期的に決定事項と未決事項をまとめてくれる人が。
今のところ39さんしかいないが、39さんが誰かに委任してもいいと思う。
( 自分の好みを捨てられる人で無いと務まらないと思うので、私は資格無いですけど )
0608603
NGNGboxingとか、intとかも継承できるところ
structでユーザー定義の値型を作れるところとか。
まあチラッと仕様書みてサンプルコンパイルするくらいしか触ってないけど。
実用性第一に考えると値型は拘ったほうがいいと思う。いかにも静的言語って感じになるし。
0609603
NGNGintとかも実はSystem.Int16の別名で値型はstructで統一されているところ。
値型にもメッセージを送れるところ。(123.ToString()とか)
値型の配列を用意してきたところ。
0610603
NGNG0611デフォルトの名無しさん
NGNGアドレス比較 A == B
代入 A := B
を提案。やっぱ = は値比較以外に考えられません。
0612デフォルトの名無しさん
NGNG実は同じ事考えました。
ですが、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; // 変数のさしているオブジェクト同士の値比較
（あくまで =~ は説明のために適当に考えたもの）
0613デフォルトの名無しさん
NGNG> 衝突した時も、型を明示しないといけないのは伏流から継承したやつだけにしてください。
もちろんそうなるとべきだと思います。
名前変更は、39さんがあまり乗り気ではないようなのでどうなるか分かりませんが、
名前: alias 旧名
という構文もつくる方向らしいので、
それを使用して同じことが出来るのではないでしょうか。
061439 ◆6K2ziZrM
NGNG安全じゃないんじゃないかな、と考えているだけです。
基本ライブラリの class.method1 を、
利用者または中間ライブラリの作者が class.method2 に名前を変更した場合、
そのクラスを利用する人が名前を変更されていることを知らなければ、
わざわざクラス定義を見に行かなければならなくなりますよね。
class.InterfaceName.method()だと、クラス名が衝突しない限り
完全に一意の名前になりますしね。
これが大して問題にならないなら良いと思います。
エイリアスはあると便利だと思うので、>>606のように実装継承
してきた側のメソッドが自動的に使用されるようにしたいとは思いますけど。
061539 ◆6K2ziZrM
NGNGC風の構文で値型からBoxingへの代入に暗黙にコピーが生成されたり、するのは
ちょっと直感的じゃないです。
それから、>>605の案は無理だと思います。
継承して無くてもクラスオブジェクトをメンバに持つクラスの場合
スタック中のオブジェクトの中をスキャンしないと参照のリンクを完全に把握出来ません。
それから万が一C++と同じデストラクタを導入した場合、
キッチリスコープエンドで破棄される必要が出てくるので、
巻き戻し中のデストラクタ呼び出しチェーンを作らないといけないので、
例外処理もやたらと遅い物になると思います。
061639 ◆6K2ziZrM
NGNG基本は参照アドレス、ハッシュ値の比較で同一オブジェクトの比較のみ自動定義で、
値の比較はクラスごとに意味合いが違ってくる可能性もあるので、
同値比較は.equals等のメソッドで行うようにガイドラインを作るだけで良いと思います。
stringクラスあたりで比較がちょっと面倒になっちゃうのが問題だと思いますが・・・
同値比較はクラスごとに定義しないといけない場合がほとんどなので、
=~は人間が定義することになるし、オペレータオーバーロードを導入することになる。
また、オペレータオーバーロードを導入するとしたら、
==の意味づけはダレでも勝手に再定義出来ちゃうので、無意味かと。
バイナリスキャンして勝手に比較した方が良いのかな。
0617デフォルトの名無しさん
NGNG演算子オーバーロード欲しい派の私としては
+, -, *, /, %, &, |, ^, ~, <<, >>, <, <=, =~
のみをオーバーロード可能にして、
（>は<の左右入れ替え、等残りは自動的に生成できるはず）
==はオーバーロード不可能にしてはどうでしょう。
参照型のとき、==は同じオブジェクトをさしているかどうかを調べて、
値型のときは、内部的に=~を呼び出す。（=~が定義されていないときはエラー）
もちろん=~ではなくequalsでもいいのですが（記述が違うだけでやることは同じですから）、
Javaなんかでstringにequals使うの忘れて誤作動なんて経験があるので、
専用の演算子があったほうが私はいいかなと思います。
0618デフォルトの名無しさん
NGNG+ - * / の２項演算子バージョンだけに限定していい気がする
0619デフォルトの名無しさん
NGNG0620デフォルトの名無しさん
NGNG比較演算子は、
operater = :(A, B: SAMETYPE) -> Integer
か
operater = :(A, B: SAMETYPE) -> Boolean
のどちらかの形で定義し、
上のときは = > < >= <= /= が使えるようになり、
下のときは = /= だけが使えるようになる。ダメですか？
代入は、<- または := がいいと思います。
0621605
NGNGstructはメンバーに参照を持てないということですね。了解しました。
ということは、値型の配列も同様か…。
(少し考える)…長さ固定の配列は、データテーブルとか
APIに渡すバッファーぐらいにしか使って無い気がするし、
そもそも値型の配列は参照型の配列で完全に代用できる…
うん。値型の配列の要素に参照が使えなくても問題無さそうですね。
0622デフォルトの名無しさん
NGNGと言うことで、デストラクタって必要だと思う？>all
0623デフォルトの名無しさん
NGNG代入式、単項インクリメント、デクリメントの戻り値はnil/voidが良いと思います。
それから、式中の関数、メソッド呼び出しも何らかの形で制限した方が。
シーケンスポイントの問題が出てきそうです
0624デフォルトの名無しさん
NGNGObjectクラスにprotectedでvirtualなDestructorメソッドを用意しておいて、
参照型はGCで回収される時、
値型はスコープエンドで、それが呼ばれる、とか。
値型にもデストラクタがあるならstructも参照型のメンバーを持てますし。
…ただ、効率とのトレードオフになるので、
割り切って値型は参照を持てずデストラクタも無しというのも有りと思います。
ところで、メソッド定義がこの形になった今、voidって必要ですか？
Method: (Arg: String) -> void { ... } ;
Method: (Arg: String) { ... } ;
後者でいいと思うのですが。というよりもそこまでCを引きずる必然性が疑問。
( 最後のセミコロンの理由は >>574 )
0625620
NGNG言っていることには賛成します。
でも620では = は値の比較演算子のつもりなのですけど、誤解してません？
Javaのように算術演算子の呼び出しでは文を終われない、とかしてもいいかも。
可
A <- B; //代入
++ A;
-- A;
不可
A + B;
A = B; //比較
A == B; //参照比較
- A;
うーむ、折角genericsがあるのですから、++と--は要らない気が…。
Next: [T: 列挙型] (Var: ref T) { Var <- Var + 1 } ;
Next(A);
0626デフォルトの名無しさん
NGNGつーか意味無い？
0627624
NGNGいや、それ以前に自分が>>622を誤読していた気が…。
ということで624の前半は無視して下さい。
0628622
NGNG値型がデストラクタを持つなら、スコープエンドで呼び出されるのが自然なので、
関数呼び出しの深い位置で例外が起こると当然キャッチされるまで
スタック中オブジェクトの回収で、>>615で言ってるように
呼び出しリストを照会しながらデストラクタコールが必要になるから、
例外処理も大変になるような。
スタックのオブジェクトもスコープエンドじゃなくてGCで回収されるなら
この問題はなさそう。
0629デフォルトの名無しさん
NGNG== は値型でエラーといわずに C++ の == と同じ意味であって欲しいです。
参照(C++のポインタ）なら p1 == p2; // p1 と p2 が同じオブジェクトをさしているかどうか
値なら v1 == v2; // v1 と v2 の値が同じかどうか
ところで、演算子はいいかげん決めるべきと思いますが、
代入は = であって欲しいです。
代入はプログラム中でも登場回数が最も多い演算子の1つかと思いますが
:=, <- など2文字打つのはちょっと面倒です。
063039 ◆6K2ziZrM
NGNG・ボクシングの構文
・メソッド名衝突時の解決方法
・名前の変更
・エイリアスで代用、主流（実装継承）以外の名前は、
明示的にエイリアスを書かない限り隠れる
元モジュール名.メソッド名() として呼び出す
・スタックオブジェクト回収のタイミング
宣言形式については概ね出てきている形式で決定の方向で
>Class: class[generics](super, interfaces, modules) {}
063139 ◆6K2ziZrM
NGNGCの代入、Adaの比較のように複数の意味で使われているので、
どっちにしろ混乱はあると思うので。
代入は
a := b
a <- b
比較はC++の
a == b
これなら他の意味にはとらえづらいと思いますが。
0633デフォルトの名無しさん
NGNG名前の変更で行った場合どのような記述になるのか、教えてもらえますか？
0634デフォルトの名無しさん
NGNG0635185
NGNGメソッド名が同じだからといってモジュール名が同じとは限らない。
だからモジュール名を明示的に書かなければならないやり方だと、
多態したいときにやっかいなことになると思われ。
そして毎回エイリアスを書かなければならないとなると、
mix-inを継承するだけでインターフェースと実装を再利用できるという
良さが失われてしまう。
衝突しないときはやはりObject.method()式に呼び出したいです。
個人的にはメソッド名の衝突の解決には、CLOS風のモジュール間に優先順位を
持たせるやり方が好きです。
メソッド名が衝突した場合、優先順位の高い方のモジュールのメソッド名として
解決。優先順位の低い方のメソッドを呼び出したいときだけ、モジュール名を
明示したらいいと思うのですが。
0636デフォルトの名無しさん
NGNG0637デフォルトの名無しさん
NGNG1.自クラス内で定義したmethodと明示的にaliasしたもの
2.親クラス
3.module/interface
3のmodule/interface間は優先順位を定義せずに、あいまいなときはエラーを出すべきだと思います。
（そういう時は明示的にaliasするべき）
0638デフォルトの名無しさん
NGNGObject.module.method();
それとも、見えなくする？
0640デフォルトの名無しさん
NGNGC++のように継承にprivateやpublicつけます？
経験的にpublicがほとんどなので、つけるとしたらデフォルトでpublicがいいでしょうけど。
0641デフォルトの名無しさん
NGNGObject.method();
0642デフォルトの名無しさん
NGNG638はモジュール間で名前がぶつかった場合の話じゃなかろうか
0643620
NGNG値比較と参照比較を混同できるような仕様は、バグの元と思うのですけど…。
それに、自分は = は値が等しいという意味(イコール記号の本来の意味)であって欲しいと強く思います。
で、そうするとC++の == が宙に浮くので、それは参照比較、と。
代入の <- は、関数定義が -> なので、意味的にちょうどいいかなぁと思って。
0644デフォルトの名無しさん
NGNGそれともいきなりアセンブラやオブジェクトコード吐いたりする？
できればCに落としてほしいです。
gcが入ると厄介かもしれませんが。
0645デフォルトの名無しさん
NGNGObject.module.method();
0646デフォルトの名無しさん
NGNGそれは…それなら、aliasしないと衝突エラーを出すか、
Object.Module.Methodのどちらかでいいと思いますけど。
0647デフォルトの名無しさん
NGNG値型の値比較と参照型の参照比較は混同するものではなく、そもそも同一のものなんです。
参照型の変数の値を比較するということは、すなわち同じオブジェクトを指しているかということです。
0648デフォルトの名無しさん
NGNGそれは理解しています。
しかし、オブジェクトの比較は個々でオーバーロードするべきであり、
参照変数の比較は常にアドレスを比較しなければいけない(オーバーロードを許してはならない)という特徴があります。
さらに、ふたつの参照が指している中身を値比較したいばあい、値比較と参照比較が同じ記号だと、
明示的にUnboxingを行わないとオーバーロードした値比較演算子が呼べないのではないか？という疑問もあります。
他のメソッドも演算子も値と参照で同じように呼べるのに、比較演算子だけ気を遣わないといけないのは、
むしろそちらの方がデメリットではないかと。
0649647==629
NGNG値比較 <-> 参照比較
という区別ではなく、
変数比較 <-> オブジェクトの中身比較
という区別にしてはどうか、ということです。
たとえば>>643の意向を汲んで変数比較を==、オブジェクト比較を=とすると、
==は参照型に対しては、同じオブジェクトを指しているかどうか、
値型に対しては独自にオーバーロードした=が成立するかどうか、
ということになりオーバーロード不可能。
=は、参照型だろうと値型だろうとオブジェクトの中身が同じかどうか、
ということでオーバーロードしなければいけません。
基本的な主張は>>648と同じで、
ただ値型に対しても==が使えるようにするべき、というだけです。
0650620==648
NGNG参照でも値でも同じように a + b や a.Method が使えるのに、
比較だけC++のように、a == b と *a == *b を使い分けないと駄目なのか？と思ったので。
operator = を意図した時は常に = を用い、変数そのものを比較したい時は常に == を用いる、と。
それなら、Unboxingを仮に*aとすると、
「a = b」 と 「*a == *b」 が同じ意味となり、何となくC++の==の意味も生きているっぽいかな…
0651デフォルトの名無しさん
NGNG変数比較==（仮）はC++の==と同じ意味で変数同士を比較し、
オブジェクト比較=（仮）はJavaのequalsと同じ意味でオブジェクト同士を値比較します。
（あくまで提案ですが）
0652566
NGNG> そんじゃ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]
みたいに、参照型と値型のパラメータを一緒に制限することができます。
0653566
NGNGクラス定義されています。
a: INTEGER -- 値型の INTEGER
b: REAL -- 値型の REAL
0654デフォルトの名無しさん
NGNGEiffelは参照型のものを値型に変換できるのですね。
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、なんていう制限方法も出来るかと。
0655566
NGNG名前の変更を誤解しているみたいなので。
俺の勘違いだったらスマン。
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 -- コンパイル・エラー
0656デフォルトの名無しさん
NGNGa [@:d] a -> d
d + a [@:a] d + a -> a
a(-)d
a<->d a = b
a(=)d
a<=>d a == b
<a d>
@ がいいよ
^^ 押しやすいし‥‥
0657デフォルトの名無しさん
NGNG名前の変更と、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 は実装したことになるのか？
}
065839 ◆6K2ziZrM
NGNG解説どうも。
しかし、たとえばclass Bでfを定義すると、
A.fとは全く別の物になりますよね？
クライアントがclass Aのfを期待して呼び出したつもりが、
全く別のfが呼ばれていると言うことになりますよね？
分割コンパイルについて、テキストではなく
中間コード形式のバイナリで保存するのを考えていますので、
場合によってはクライアントが実装の宣言を見ることが出来なくなります。
こうなってくると、ドキュメントを完全に信じないといけないことになりますので。
065939 ◆6K2ziZrM
NGNG0660デフォルトの名無しさん
NGNGname <- 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;
}
0661デフォルトの名無しさん
NGNG数学でも左向きの表記はしないだろう
0662デフォルトの名無しさん
NGNG0663デフォルトの名無しさん
NGNG0664デフォルトの名無しさん
NGNG0665デフォルトの名無しさん
NGNG<-じゃなくて := で良いと思うんだけどなぁ
0666デフォルトの名無しさん
NGNGmodula方式ですな。
0667デフォルトの名無しさん
NGNG<->
->
<- というか
辞書みたいなんはないんですか？
0668デフォルトの名無しさん
NGNG+=や-=はどうすんだよ
+<-
-<-
ですか？
代入は:=にして
:=
+=
-=
0669デフォルトの名無しさん
NGNGvarでいいだろvarで。
propertyはpropだろ。
代入は=。 :=は打ちにくいから却下。
比較は==。eqでもいいけどな。
あと、個人的には大文字小文字入り乱れてるソースは読みにくいから、
ライブラリとかは全部小文字にして_(アンスコ)で区切ってくれ。
0670デフォルトの名無しさん
NGNGヤダ♪
0671デフォルトの名無しさん
NGNG0672デフォルトの名無しさん
NGNG言うこときけ
0673デフォルトの名無しさん
NGNG>>660みたいなのは読みにくいよ
0674デフォルトの名無しさん
NGNGvariableは省略可能だろ。
大文字小文字入り乱れてるソースが読みづらいのは個人的に同意。
しかし、世間の流れがそういう方向じゃないので却下だろう。
0675デフォルトの名無しさん
NGNG小文字化については、はげしく同意。
例えばgetHogeだと、小文字から始まってるのにいきなりHで大文字になるから
一瞬Hなのかl-lなのかわかんなくなる。
get_hogeが妥当でしょ。
0676デフォルトの名無しさん
NGNG0677デフォルトの名無しさん
NGNG↑これって、昔のSmalltalk？
それともHaskellのﾓﾅﾄﾞかな？
0678デフォルトの名無しさん
NGNG0679デフォルトの名無しさん
NGNGって言おうとｵﾓﾀが、くだらないレスつけすぎて駄スレ化思想だから思いとどまった。
0680デフォルトの名無しさん
NGNGGetHomeとgetHomeとgethomeを同時に使うような馬鹿が
出現しないように、名前の大文字小文字は区別しない
ことは必須だと思う。
0681デフォルトの名無しさん
NGNGだからget_hogeにすれ。
gethogeだと一見、なんだかわからん。
0682デフォルトの名無しさん
NGNG0683デフォルトの名無しさん
NGNGcase-sensitiveには対応すべき。
対応してないとpascalやschemeみたく教育用に成り下がる恐れがある。
DelphiではDLLのAPI呼んだりするときに結構問題だったでしょ。
モードで切り分けできればいいけど。
0684デフォルトの名無しさん
NGNGHTMLは区別しなかったのに。
0685デフォルトの名無しさん
NGNG処理系側は区別しない方が良いと思う。
処理系が区別すると言うことは、
GetHomeとgetHomeとgethomeを同時に別の名前に使える(そういう
使い方を支援する)ってことだ。
それは害があって利益がないと思う。
0686デフォルトの名無しさん
NGNGディレクトリ風って感じで、
< > でかこったのが変数、
そのあとの / はディレクトリの記号。
その右側のが、計算して、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 の答えが入ったりするって感じ。
変数をかっこでかこってもいいし、式をかっこでかこってもいいし、
/ が割り算とややこしかったら別の記号にしてもいいし。
まあいろいろやりやすいように、やってみてくださいﾁｭﾝ♪ (●＞
0687デフォルトの名無しさん
NGNG誤爆？
0689デフォルトの名無しさん
NGNGじゃあVMの設計もやるんですか？
069039 ◆6K2ziZrM
NGNG>処理系が区別すると言うことは、
>それは害があって利益がないと思う。
case-insensitiveであるべきという考えですか？
>>688
今考えているのは、x86/win32ネイティブのみですよ。
VMはデバッグ用やその他アプリ組込用なんかのために後から作ります。
069139 ◆6K2ziZrM
NGNG設計というか、ほぼまるまる手本になるVM(JVM)があるんで、
それを参考に車輪の再発名でもやりますよ。
.NETのようにVMレベルでセキュリティチェックしたりするほど
大がかりな物じゃないんで、ここで設計するまでもないです。
簡単なスタックマシンで実装するって事で。
0692デフォルトの名無しさん
NGNGそう。case-insensitiveにしておけばそういう無意味な
ことはできなくなるでしょ？
標準ライブラリなどの大文字小文字表記の慣習はまた
議論で決めれば良いが、どうしても納得が行かない人は
従わないこともできる(case-insensitiveにしておけば)。
0694デフォルトの名無しさん
NGNGcase-insensitiveでも前２つしか対応できない。
前２つのスタイルの違いはあまり問題にならないが、
重要なのは前２つと３つ目の違いだと思われ。
0695デフォルトの名無しさん
NGNGはコンパイラオプションによって警告を出す程度にしておけば問題ないのかな。
0696デフォルトの名無しさん
NGNG良く主張がわからない。
getHome等とget_homeも同時に使えないような言語仕様にしろと言うこと？
それとも、GetHome, getHome, gethome, gEThOme等を防ぐだけだと
「満点じゃないから０点」ということ？
case-sensitiveにするメリットは別にないんだから、満点じゃなくても
case-insensitiveにして損はないと思う。
(ところで些細な話だけど、GetHomeとgetHomeとget_homeだけじゃなくて
localtimeとかgethostbynameとかの流儀もあるんだよ。)
0697デフォルトの名無しさん
NGNG0698デフォルトの名無しさん
NGNGそうすればgethomeとget_homeを同時に定義する馬鹿もなくせる。
0699デフォルトの名無しさん
NGNGメリットがないと言い切る根拠は？
現在メジャーである言語のほとんどがcase-sensitiveを採用していることから
何らかのメリットはあるんじゃないの？
原初のBASICはcase-insensitiveだったんだし、それを引き継がないでいるんだから。
漏れには全く具体例が上げられないけど
0700デフォルトの名無しさん
NGNGそんな奇妙な加工をしたら _ に意味を持たせることが出来なくなるじゃないか。
0701デフォルトの名無しさん
NGNG誰もメリットが挙げられないならメリットはないんじゃないの？
それに「ほとんどのメジャーな言語」って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をばらばらに書いたプログラムを見たことがある。
0702デフォルトの名無しさん
NGNGcase-sensitiveは、無用な_を防ぐという目的から広まっていると思う。
プライベートなフィールドにtext、パブリックなプロパティにTextなんて使い方が行われるからね。
あとcase-insensitiveは、
system.io.path.getfullpath
みたいに、全部小文字で書いちゃったりしてOOPLとの親和性が低いんじゃなかろうか。
0703_
NGNGそういうの自由だから最近だと逆にcase-insensitiveの方がいいかもしんない。
0704デフォルトの名無しさん
NGNG> あとcase-insensitiveは、
>
> system.io.path.getfullpath
>
> みたいに、全部小文字で書いちゃったりしてOOPLとの親和性が低いんじゃなかろうか。
え、逆だろ？ case-sensitiveだと、決めたcaseで書くことを
「強制される」。case-insensitiveなら
system.io.path.getFullPathのように書く自由が与えられる。
0706デフォルトの名無しさん
NGNGその自由が、自分で書くときはメリットになるが、他人が書いたのを読むときにはデメリットになる。
OOPLを全部小文字で書かれたら激しく読みにくいと思われ。
0707デフォルトの名無しさん
NGNGそういう「ありもしない可能性」で言うなら
gEThOmEとかgeTHoMeとか書かれる方が読みにくいと思うが？
0708デフォルトの名無しさん
NGNG全部小文字はぜんぜん「ありもしない可能性」じゃないだろ。
0709デフォルトの名無しさん
NGNGAdaだってModula2だってそうしてる。
厨房は「case-insensitiveだから全部小文字で書ける」なんて
いうことに気が付かないだろう。
わざわざ逆らうやつは、それだけの理由(主張)があるやつだろ
う。「逆らう自由」を奪って「getHomeとGetHomeを同時に使う」
ことを奨励するなんておかしいよ。
0710デフォルトの名無しさん
NGNGgetHomeとGetHomeを混ぜるのだってありもしない可能性じゃないぞ．
実際にその手のCソースは何度も見た。
(openFileとopenfileとOpenFileが同じファイルにあった。)
0711デフォルトの名無しさん
NGNGこんなの結論出ないんだから。
実装について考えれば些細な問題だろーが。
>>701
>(Modula-2, Oberon, Ada, Common Lisp, Schemeなどは全部ci。)
言語仕様はおいといて、製品として出てる様な処理系は外部との
インターフェースのためにcase-sensitiveに対応してるよ。
例えばACLとかはモード切り替えでね。
DelphiはDLLに対してのラッパーを作るとか。
0712_
NGNG071339 ◆6K2ziZrM
NGNG標準は折を見て決めると言うことでci/csの議論は終わりませんか
何か不毛だし。
0714デフォルトの名無しさん
NGNGwith Ada.IO_Exceptions;
with Ada.Streams;
with System;
with System.File_Control_Block;
with Ada.Text_IO
なんてのを全部小文字で書いてるやつは
見たことがない。
0715デフォルトの名無しさん
NGNGgetHogeだろうがGetHogeだろうがget_hogeだろうがかまわないけど、
case-insensitiveで書く人によって記述が変わるのはちょと勘弁願いたい。
0716デフォルトの名無しさん
NGNG>言語仕様はおいといて、製品として出てる様な処理系は外部との
今決めてるのは言語仕様じゃないの？
>インターフェースのためにcase-sensitiveに対応してるよ。
Cとのインターフェース用だろ。やっぱcsを広めたCがアホだな。
>>715
記述が変わるとなぜ思う？
実例からするとそんなことは起きてないが。
0717デフォルトの名無しさん
NGNG記述が変わらないならなぜcase-insensitive？
getHogeが嫌だから自分で勝手にGetHogeにしたいってのが
case-insensitive派の主張じゃないの？
といっても、漏れもこの問題は不毛と思うので後回しで。
0718デフォルトの名無しさん
NGNG0719デフォルトの名無しさん
NGNGciな言語とのインターフェースだけ
ciな仕様にすれば問題ないよね。
0720デフォルトの名無しさん
NGNG今までのどの仕様検討よりも明らかに流れが速いし、レス消費も異常。
どこで議論しても平行線だし、勿論多少は意味があるだろうけど、
ほとんど各人が好みをいつまでも言い続けておわっちゃうからさ。
0721デフォルトの名無しさん
NGNG>>685
0722デフォルトの名無しさん
NGNG（続けたい人はスレ立ててね）
0723デフォルトの名無しさん
NGNG「local変数は外側の変数を隠す」っていうのは良くないと思う。
CLUやJavaのように、名前がぶつかったらエラーにするべきだ。
0724_
NGNG0725デフォルトの名無しさん
NGNGもっと厳しい提案も聞いたことがあるな。
「global変数はimportしないとメソッドの中で使えない」
0726デフォルトの名無しさん
NGNGなにいってんの？
それはコーティングスタイルが悪いってことなんじゃない？
0727デフォルトの名無しさん
NGNG0728デフォルトの名無しさん
NGNG良くないからエラーにすべきってことでわ
0729デフォルトの名無しさん
NGNG0730ジャジメン
NGNG「case-sensitive vs. case-insensitive論争」
http://pc.2ch.net/test/read.cgi/tech/1022352006/
0731723
NGNGうん。確かに、
{ int x;
...
{ float x; ...
みたいなコーディングスタイルは良くないよね。
だから「内側の変数が暗黙の内に外側を隠す」というルールは
入れなくて良いだろう、と言うこと。
「ひとつの場所で、すでに宣言済みの名前は宣言できない」
だけで、「内側優先」という例外を入れないほうがシンプルだし、
上のようなコーディングを防げる。これは取り入れても良いと
思う。
0732デフォルトの名無しさん
NGNGCとおんなじかと思ってたYO
0733_
NGNG0734デフォルトの名無しさん
NGNGC#もそうだった、気づかず書きまくったせいで、
コンパイルエラーでてから1つも逃さず置換するのは大変ﾀﾞﾀｰﾖ。
（置換し忘れてもコンパイル通っちゃうんで）
0735デフォルトの名無しさん
NGNG>>713
ということで。
0736デフォルトの名無しさん
NGNGまだ実装段階が目に見えていないのに、そう急ぐこともないだろう。
今決めることでもないし、もしかすると分岐したスレで良い意見が聞けるかもしれないから、
他のところを考えましょう。
実装・仕様ともに大きく響いてきそうなデストラクタやインスタンス回収のタイミングとか、
0737デフォルトの名無しさん
NGNG＞実装・仕様ともに大きく響いてきそうなデストラクタやインスタンス回収のタイミングとか、
タイミングはガベコレのときじゃないの？
ファイルとかのリソースのクローズは明示的に呼ぶしかないでしょう。
0738デフォルトの名無しさん
NGNG考えてください。
漏れはくちばしを突っ込めそうにないので暖かくROMらせてもらいます。
0739デフォルトの名無しさん
NGNGスタックに生成したインスタンスね。
上の方でスコープエンドでデストラクタを呼び出してくれって話が少し出た。
0740デフォルトの名無しさん
NGNGじゃないとGCの意味がなくなりそう。
C#みたいに、参照型のインスタンスはすべてヒープに
置かれる(Boxingするとnewされる)で良いよね？
0741デフォルトの名無しさん
NGNGもち
0742 名無しさん
NGNGなにができる言語にしますか？
0743デフォルトの名無しさん
NGNG0744_
NGNGそうでないタイプどっちにしますか？
0745デフォルトの名無しさん
NGNG0746デフォルトの名無しさん
NGNG500までに決まらなかったのでwikiを設置しようよ。
オレはやりかたわからんのでパスするけど。
このスレでその辺は作ってしまったほうが良いよ。
0747620
NGNG+<- -<- …この手の演算子を考えてませんでした。すみません。
"<-" 自体は関数定義の "->" を流用した提案で深く考えて無かったので取り下げてもいいです。
( でも個人的には、 := を使うとしても、 A := A + 1; または Inc(ref A); などと書く方が好みだったり )
>>660
名前をclassやvariableなどの先に書くようになった理由を把握してますか？
定義でも "<-"を用いるにしても name: method result: type <- (arg: type) { ... }; かと…
…やっぱ嫌です(w
遅レスごめんなさい
074839 ◆6K2ziZrM
NGNG昼休みか帰宅後にでも設置してみます。
今回はそれだけです。
074939 ◆6K2ziZrM
NGNGそちらで議論が進むかどうかだけどね。
ここより遙かにスローペースになると思う。
wikiより2ch形式のスクリプトも設置したほうが良いのかな。
0750デフォルトの名無しさん
NGNG立ててくれたら俺は移住するよ。
条件分岐スレッドとかBoxingスレッドとか分けれたら便利じゃない？
0751デフォルトの名無しさん
NGNG勿論OSのHeapAlloc等で取得したメモリや、LoadResourceで取ってきたリソースも
キッチリ解放してくれるんでしょ？
0752デフォルトの名無しさん
NGNGそういうライブラリを作れば可能かと。
ただし現時点ではガベコレでなにがされるかなどの仕様は決まってないはず。
LoadLibrary/FreeLibraryとC関数呼び出しあたりは組み込みにしないと
微妙な気がする。あと_cdecl/_stdcallを切り分けできる様に。
DLLは簡単に呼び出せる様になってほしいね。
とりあえず窓作ってHelloWorldぐらいはできないと。
0753デフォルトの名無しさん
NGNG取りこまないといけない事とか。
膨大な量だから、変換ツールを用意できるならした方がいいし。
あとライブラリとして取りこんだとしても、名前が変わってしまう様だと
既存のヘルプが引けなくなるという問題も。
075439 ◆6K2ziZrM
NGNGフリースペース申し込んできたけど、すぐにアカウントが発行されないようです。
iswebとツキニイチドノハツジョウキ（ttp://haruno.fam.cx/~sawatari/index.html）
に申し込み申請。
後者が通ったら、後者に設置させてもらおうと思います。
0755566
NGNG> [ M: delegate( p1: int ) ] として、M はint型の引数を1つ取るdelegate、なんていう制限方法も出来るかと。
Eiffelだと [T ->ROUTINE[ANY, TUPLE[INTEGER]]]
>>658
よく考えてみると Eiffelふうの名前変更は
class, interface, module の３つの組み合わせと
相性が悪いような気がします。
module のみ名前変更できるようにするといいのかも。
A: class { f: (){ ... }; }
X: module { f: (){ ... }; }
Y: module { f: (){ ... }; }
B: class (A,X,Y)
{
f1: X.f; // X.f を f1 に名前変更
f2: Y.f;
}
B: class (A,X,Y) // エラー
{
f1: A.f;
f2: Y.f;
}
class.InterfaceName.method() のほうがいいような…
0756デフォルトの名無しさん
NGNG0757デフォルトの名無しさん
NGNG名前変更した場合、旧名の扱いはどうなるでしょうか
・旧名も継続して使用可能
＝すでに出ているalias機能に相当
・旧名は使用不可能
＝専用の機能が必要
＋object.module.method()のような呼び出し方は出来なくなる？
私はalias使うのがいいんじゃないかと思いますが
0758デフォルトの名無しさん
NGNG全てvirtualで実装を持たないmodule ≒ interface のようなもの(微妙に違いますが)なので
名前変更はどちらでも使えるか、完全に使えないか、がいいとおもいます。
僕もaliasでいいかと。別名も旧名も両方同じものとして使えるならば
ドキュメントが胡散臭い時は object.module.method 使えばいいし。
( 同時に旧名と別名の両方で override しようとすると当然エラーですよね？)
ところで
>>658
>中間コード形式のバイナリで保存するのを考えていますので、
>場合によってはクライアントが実装の宣言を見ることが出来なくなります。
中間ファイルから宣言部分を復元するツールがあればいいのではないかと。
( Javaの.classでは確かできましたよね？Delphiの.dcuとかもIDEのブラウザで見えますし )
0759デフォルトの名無しさん
NGNG>同時に旧名と別名の両方で override しようとすると当然エラーですよね？
同名で同じ型情報を持つメソッドは当然そうだろうけど、
同名で違う型情報を持つならエラーにはならないんじゃないの？
オーバーロードって奴で。
>ところで～
宣言のみ再生するツールがあったとして、それを使うというのも面倒な話かもしれない。
0760デフォルトの名無しさん
NGNGまだ学生でＪａｖａ， C++をやったものなんですが、
ウィンドウズプログラミングのhelloworldを
import windows;
void main(){
}
0761デフォルトの名無しさん
NGNGオーバーロードでは無く名前変更の話ですけど…
>>760
そう言えばエントリポイントの形式って決まってました？
・Eiffelのように特定クラスのコンストラクタから始まる
・Java/C#のように特定クラスの決められた名前のクラスメソッドから始まる
・Adaのようにメソッドだけで1ファイル作ってそこから始まる
・Pascalのように専用の構文がある
・Cのようにグローバルな決められた名前のメソッドから始まる
…などと色々方法はあると思いますが。
( Eiffel方式は起動中ずっとコンストラクタの中になるのでやめて欲しいところ。好みで言うならAda方式がいいな )
0762投稿失敗
NGNGimport windows;
void main(){
Window w;
w.createWindow(0,0,100,100);
w.drawText("hellow world"", 10,10);
}
みたいにできませんか？
一回Windowクラスのオブジェクト作ったら、全部ドットナンチャラで
出来るようにしてくれると初心者がGUIを簡単に作れるのではないかと
こうプルダウンメニューつくるのもこんな感じ
Window w;
MenuBar mb;
w.createWindow(0,0,100,100);
mb.addMenuItem("開く", openFileProc()); //選ばれたらopenFileProc()を実行
mb.addMenuItem(”印刷”, printJobProc());//選ばれたらopenFileProc()を実行
mb.addMenuItem("閉じる", closeWindow(w)); // window w を閉じる
w.addMenuBar("ファイル", mb); //ファイルを引っ張ると上でmbにADDした奴が出てくる
0763デフォルトの名無しさん
NGNG>・Eiffelのように特定クラスのコンストラクタから始まる
>・Java/C#のように特定クラスの決められた名前のクラスメソッドから始まる
これが良いかなぁ。
上+Manifestやコンパイル時のコマンドラインオプションなどで、
どのクラスから始めるか、もしくはどのクラスのどのメソッドから～
各クラスがエントリーを持てるのはテストに便利かと。
Ada式だとテストケースを作成するごとにファイルがどんどん膨れていかない？
0764デフォルトの名無しさん
NGNG全部ドット(.)でアクセスできるようにはなるだろうが、
それはライブラリの分野だろう。
0765デフォルトの名無しさん
NGNGところで
>>762
お手軽言語は当然そのお手軽さの代償を払わなきゃいけないんだよね。
1つ目の例は描画メソッドをウィンドウクラスのメンバにしてしまっていたり、ダブルバッファリング前提だったりとその代償があんまり安くない。
2つ目の例はまぁ、人それぞれだろうけど、メニューが起こすイベントは、選択完了だけじゃなくて、表示開始とか、ハイライトとか、マウスボタンダウンとか、いろいろあるわけで、選択完了だけを特別扱いしていしてるのは嫌って人もいるだろうね。
0766デフォルトの名無しさん
NGNG生成してそのメソッドを実行、ってのがいいかなぁ。
標準ライブラリに必要なのは標準入出力、ファイルI/O、基本的なGUI、ソケット、
高レベルネットワークI/O(http/ftp...)
あとはコレクションとかアルゴリズム系の抽象ライブラリ？
0767デフォルトの名無しさん
NGNGそれをさらに拡張してコンストラクタに適用して
Window w = new Window()
w.Create(0,0,100,100);
MenuBar mb = new MenuBar();
w.SetMenuBar(mb);
mb.AddItem(
new SubMenu( "ファイル" )
{
AddItem( new MenuText( "開く" ){ OnSelected = this.openFileProc; } );
AddItem( new MenuText( "印刷" ){ OnSelected = this.printJobProc; } );
AddItem( new MenuText( "閉じる" ){ OnSelected = this.closeProc; } );
} );
かなーり強引な例ですけど、>>762と同じことをやるプログラムです
今までいろいろやってきて、メソッドに渡すだけなのに、渡す前にプロパティを設定したいときはいちいち一時変数を作らなきゃいけないのが面倒でした。
上の例ですと、各MenuTextの新しいインスタンスをメソッドに渡す際に、
この構文がないときはいちいち名前を考えて変数を作らなきゃいけません。
この構文を使用すると無駄な一時変数を減らすことが出来ると思います。
0768761
NGNG常に作成中で作成が完了したらプログラムも終了するオブジェクトというのが…。
テストコードをクラスと一緒に書くのは、画面と無関係なクラスでも、コンソール(or Window)を扱うパッケージを
(importかusingかusesかwithかはさておき) 使ってしまうということになりませんか？
例えファイル数が増えても、切り離しておきたいです。
ところで
>>762
まだ言語機能の途中ですので、ライブラリの話はまだ先と思われますが、
少し読んでもらえればわかるように、総称とかmix-inとか凝りまくってます。
恐らくライブラリも、言語機能フル活用の凝りに凝りに凝りまくったものになるのは想像に難く無いので
「短く書ける」ようにはなるかもしれませんが、「初心者向き」にはならない気が…(w
( >>767さんの例も、スマートではありますがもはや「初心者が簡単」とは言えないような )
0769767
NGNG一時変数を減らせるあの構文を激しく一押しです！
どうかお奉行様（３９？）ご採用くださいまし！
0770デフォルトの名無しさん
NGNG0771767
NGNGJavaの無名クラスだってそんなだし
0772デフォルトの名無しさん
NGNGhello, worldの表示くらい何も考えずに作っても数十KBで出来るようにしてﾎｽｨ…
小規模なプログラムだったら100KB以下で収まると理想的。
0773デフォルトの名無しさん
NGNGダレにも扱いきれないｵﾅｰﾆ言語になるかもしれない
そもそも772が使うかどうかすら分からない
こんな状況で実行ファイルのサイズを気にしてどうする
0774デフォルトの名無しさん
NGNGw: Window = new Window;
w.Create(0, 0, 100, 100);
mb: MenuBar = new MenuBar;
w.MenuBar := mb;
FileMenu: () -> SubMenu
{
NewItem: (T: String, E: delegate ( )) -> MenuItem { Result := new MenuText(T); Result.OnSelected := E; };
OpenItem: () -> MenuItem { Result := NewItem("開く", Self.OpenFileProc); };
PrintItem: () -> MenuItem { Result := NewItem("印刷", Self.PrintJobProc); };
CloseItem: () -> MenuItem { Result := NewItem("閉じる", Self.CloseProc); };
Result := new SubMenu("ファイル");
Result.AddItem(OpenItem());
Result.AddItem(PrintItem());
Result.AddItem(CloseItem());
};
mb.AddItem(FileMenu());
0775デフォルトの名無しさん
NGNGそこまでやるんじゃλの方がスマートだが、
人間様が読むプログラムじゃぁなくなるよな
0776デフォルトの名無しさん
NGNG関数内関数の是非はともかくとしてそういう使い方は反対
0777デフォルトの名無しさん
NGNGバナーが出るのでProxomitron推奨。
http://isweb43.infoseek.co.jp/computer/am_dev/
ツキニイチドノハツジョウキさんの方にも申請しているので、
そちらが通ったら移転させようと考えてます。
どなたか、MegaBBSのスクリプトお持ちでしたらUPしてください
http://www.megabbs.com/megabbs/index.html
こちらから落とせませんでした。
0778デフォルトの名無しさん
NGNGhttp://lemmingdead.mine.nu/download/MegaBBS1_69_b1.zip
0779デフォルトの名無しさん
NGNGお疲れさまです。
0780566
NGNG>>758
では alias にしましょう。
>>761
> そう言えばエントリポイントの形式って決まってました？
エントリポイントの形式は特定クラスのクラスメソッドから始まる
(Smalltalkふう？)がいいと思います。
> Eiffelのように特定クラスのコンストラクタから始まる
> Eiffel方式は起動中ずっとコンストラクタの中になるのでやめて欲しい
Eiffelは特定クラスのインスタンスメソッドから始まります。
0781デフォルトの名無しさん
NGNG0782566
NGNGcreate foo.make -- create foo; foo.make
0783デフォルトの名無しさん
NGNGなるほど、勉強になりますた。
C++勉強した時に思ったのはpublic, privateで十分で、friendなんて何で
作るんだろう、と。
0784デフォルトの名無しさん
NGNG0785デフォルトの名無しさん
NGNGいちいちC++のように友達を書き並べるのも細かすぎる気が。
C#のようにinternal修飾子を追加します？
既にclass/shared(←結局どっち？)が出ているので、同じ感じで。
或いは、public(FriendClass): と相手を指名してアクセス制御を行うとか…。
ObjectPascal方式(同一ソース内は全て見える)が単純でいいとは思いますけど。
0786デフォルトの名無しさん
NGNG邪魔してクラス内に実装できない。
そして、そのoperatorをfriendにするのはクラスの隠蔽の仕組みを壊さずに
publicなメンバ以外にもアクセスさせたいから。
0787デフォルトの名無しさん
NGNGソース単位ではなく、プロジェクトっていう単位が
コンパイル時にも影響してくることになる。
0788デフォルトの名無しさん
NGNG0789デフォルトの名無しさん
NGNGFriendの時点でカプセル化がなかったことになると思うんだが・・・
0790デフォルトの名無しさん
NGNG{
obj.protectedMethod();
// カプセル化破壊覚悟でprotectedなメソッドにアクセス！
}
・・・ダメっすか？
0791デフォルトの名無しさん
NGNGFriendは言語仕様にはあるけど、解説にはなしってことで(w
にしても、その構文いいね。
0792デフォルトの名無しさん
NGNGName: (params) -> Type;
より
Name: Type ( params ) のほうが良くない？
というのも、プロパティって変数と関数の中間くらいなものだと思うけど、
現状案だと関数だけ（？）が->Typeで、変数とプロパティはTypeが左なんだよね
↓のように書けると何かと美しいと思うんだけど。
Name: Type = 100; // 変数
Name: Type (params){ result = hoge; }; // 関数
Name: Type get{ hoge = value; } set{ result = hoge; }; // プロパティ
0793デフォルトの名無しさん
NGNGCの構文のような順に読みたいと言う欲求がふつふつと・・・
とまあ、関係ないんで下sageます
0794デフォルトの名無しさん
NGNGでもメソッドの-> Resultはいただけないので792に１票
0795デフォルトの名無しさん
NGNGname: type
のように左に 名前、対象 右に型と言う統一性を考えた場合、
type (arg: type)
この構文はあんまり美しくないと思うんだけど。
1 Name: Type = 100; // 変数
2 Name: Type (params){ result = hoge; }; // 関数
3 Name: Type get{ hoge = value; } set{ result = hoge; }; // プロパティ
1と3の実体は Type だけど、2の実体はTypeとは言えない。
見た目の位置あわせのためだけに珍妙にするのはどうかと
0796デフォルトの名無しさん
NGNGその順ですと、delegate型を戻り値にしたい場合、こんな風になってしまうような…
Name: method delegate Integer ( ) (Arg: String) { ... }; //methodが無いと意味不明
現状ですと、
Name: (Arg: String) -> delegate ( ) -> Integer { ... };
methodキーワードの省略は、"(" が常に先頭に来るからこそできると思うのですけど。
…でも、"property"も省略できるのではないか？とは思いました。
getとsetのどちらかがあれば意味は通じます。(flag型のsetは先頭に来るので区別は付きます)
Name: variable TYPE = HOGE;
Name: method (PARAMS) -> TYPE { Result := HOGE };
Name: property TYPE get { Result := HOGE; } set { HOGE := Value };
型以外は(constantを除いて)全てキーワードが省略可能。こっちの方が便利では？
Name: TYPE = HOGE;
Name: (PARAMS) -> TYPE { Result := HOGE };
Name: TYPE get { Result := HOGE; } set { HOGE := Value };
0797デフォルトの名無しさん
NGNG関数だけ->Result形式にしても結局delegate型のfieldやpropertyでは意味がなくなるのでは・・・
Name: variable delegate ()->Integer := this.hoge; // delegate型のfield
Name: property delegate ()->Integer get {}; // delegate型のproperty
こういうときは素直に
MyDelegate: alias delegate Integer ();
しておいて
Name: MyDelegate (PARAMS){};
のほうがいいなぁ。
0798796
NGNGところで戻り値無しの時はどうするつもりですか？(void書くのは嫌ですよ)
( ) -> Type { ... }; を、戻り値が無いので省略して ( ) { ... }; というのは素直ですが
Type ( ) { ... }; を、戻り値が無いので省略して ( ) { ... }; というのは素直じゃ無い気がなんとなく。
794さんの言うように"->"の記号が珍妙なのは半分同意。"to"や、いっそ何も書かなくても…とも思います。
>>795 さんの反論が本命とは思いますけど
0799デフォルトの名無しさん
NGNGその形だと素直に左から右に流し読み出来ないじゃん
0800デフォルトの名無しさん
NGNGいや、voidは必要かと
総称使ったときに、voidとそうでないのを同じ記述で使えないと何かと不便かも
DelegateToUneryFunctorAdapter: class[ RetType: typename, ArgType: typename ]
{
MyDelegate: delegate RetType ( ArgType );
_func: MyDelegate;
new: ( func: MyDelegate ){ _func := func; }
call: RetType ( arg: ArgType ){ Result := _func( arg ); }
または
MyDelegate: delegate ( ArgType ) -> RetType;
_func: MyDelegate;
new: ( func: MyDelegate ){ _func := func; }
call: ( arg: ArgType ) -> RetType { Result := _func( arg ); }
}
どちらの記述にしても戻り値のvoidは欲しい、
void型の変数（何も格納しない＝プログラム上の作用は一切ない）も欲しい
0801デフォルトの名無しさん
NGNG実装のない関数宣言は delegate でいいんじゃないの？
[delegate]
Name: () -> Integer := this.hoge; 'delegate
Name: property () -> Integer := this.hoge get {} set {}; 'delegate property
Name: () -> Integer := this.hoge get{} set{}; 'delegate property
[function/procedure]
Name: () -> Integer { Result := 0; };
>>800
戻り値 void は省略時に void と言う扱いで良いんじゃない？
Zero: () -> 0 { };
Nil: () -> Nil { };
常に 0 を返す関数、常に Nil を返す関数等 戻り値に constant を記述できると面白いかも
0802デフォルトの名無しさん
NGNG( void型変数は、サイズ 0 でvoid型間でしか代入できないダミーってことでいいのですよね？)
しかし、そうなると尚更 Name: void ( ) { ... }; は、まるでNameがvoidみたいで嫌…。
(C系言語を読む時、voidで常に違和感を感じてます…)
読む時「これはメソッドだ！」という情報がvoidよりも先に来て欲しいので、引数の括弧が戻り値より先に来ることを主張します。
メソッドの戻り値型のvoidは省略可能というルールを作るにしても
Name: ( ) -> void { ... }; を省略して Name: ( ) { ... }; の方が素直な…(ってさっき書いたか…)
0803デフォルトの名無しさん
NGNG呼び出し元で
a = obj.method( 10 );
のように呼ぶので、戻り値が左にあったほうが自然と感じるのです漏れの頭は。
0804デフォルトの名無しさん
NGNG移転先では、採用されたものだけでなく、是非却下された意見も載せていただきたく思います。
なぜ現在の形になったのかがわかれば議論の繰り返しを避けることができますし、
思わぬ形で再利用できるアイデアもあるかも知れません。
ここでなされた会話は埋もれさせるには勿体ないと思います。
もし抜けがありましたらごめんなさい。
全般
>>152>>155>>156>>157>>158>>352>>364>>658>>659>>688
>>690>>691
型
種類
>>195>>199>>201>>487
mix-in
>>187>>188>>189>>190>>192>>194>>534>>535>>542>>544
>>545>>546>>547>>549>>550
interface
>>550>>553>>554
Boxing
>>488>>494>>528>>529>>584>>585>>595>>596>>597>>605
>>612>>615>>654
template
>>160>>163>>166>>508>>510>>511>>512>>513>>514>>515
>>516>>517>>518>>521>>522>>530>>532>>654>>755
0805デフォルトの名無しさん
NGNG>>241>>242>>246>>250
配列
>>481
文字列
>>172>>173
イテレータ
>>425>>471
宣言
名前
>>324>>325>>326>>327>>328>>669>>675>>676>>680>>683
>>685>>692>>694>>695>>696>>698>>699>>700>>701>>702
>>703>>704>>705>>706>>707>>708>>709>>710>>711>>713
>>714>>715>>716>>717>>719>>723>>724>>725>>727>>730
>>731
型
>>197>>199>>385>>388>>390>>552>>555>>556>>558>>559
>>561>>562>>571>>631
0806デフォルトの名無しさん
NGNG>>144>>228>>229>>230>>371>>373>>374>>380>>385>>785
>>787>>790>>791
変数
>>365>>366>>367>>368>>369>>370>>373>>482>>558>>571
ポインタ
>>60>>61>>81>>88>>89>>91>>92>>94>>95
delegate
>>571>>572>>574>>801
constant
>>63>>98>>139>>141>>370
プロパティ
>>240>>523>>571>>574
0807デフォルトの名無しさん
NGNG>>334>>374>>375>>377>>386>>389>>392>>393>>394>>395
>>396>>397>>398>>399>>404>>405>>406>>408>>415>>489
>>495>>496>>558>>571>>574>>577>>579>>624>>792>>793
>>794>>795>>796>>797>>798>>799>>800>>802>>803
alias
>>192>>571>>576>>578>>606>>613>>614>>635>>636>>637
>>638>>640>>646>>657>>658>>755>>757>>758>>780
宣言と定義が同時か分割か
>>338>>364
特殊指令
>>491>>493
0808デフォルトの名無しさん
NGNG条件分岐
>>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
列挙(for, foreach)
>>424>>425>>431>>433>>434>>435>>462>>464>>465>>466
>>467>>468
後判定反復
>>70
0809デフォルトの名無しさん
NGNG>>71>>73>>255>>257>>260>>263>>264>>265>>266>>267
>>268>>273>>274>>276>>278>>279>>280>>281>>283>>285
>>287>>288>>289>>291>>436>>438>>441>>442>>443>>444
>>445>>446>>447>>448>>449>>450>>451>>452>>453>>454
>>455>>456>>457>>458>>459
with
>>767>>769>>770>>771>>774>>775>>776
assert/表明
>>247>>249>>251>>269>>270>>275
Result
>>253>>256>>258>>404>>411
0810デフォルトの名無しさん
NGNGポインタ演算子
>>4
n乗
>>439>>445
new
>>472>>473>>474
比較演算子
>>612>>616>>620>>629>>631>>632>>643>>647>>648>>649
>>650>>651
代入演算子
>>660>>664>>665>>668>>747
オーバーロード
>>204>>205>>214>>218>>617>>618>>619
戻り値
>>623>>625
0811デフォルトの名無しさん
NGNG>>599>>600>>615>>621>>622>>623>>627>>628>>737>>739
>>740>>751>>752
ソース
構文拡張
>>589>>592
ソース配置/エントリポイント
>>744>>761>>763>>765>>766>>768>>780
ライブラリ
>>226>>227>>753>>762>>764>>765>>766
その他参考になりそうな発言(独断と偏見)
>>10>>11>>12>>13>>83>>136>>402>>403>>504>>506
>>533>>566>>580>>652>>653>>655>>782
0812デフォルトの名無しさん
NGNG3 > b +
3 を b に足す
3 > b -
3 を b から引く
3 > b !
b の内容を書き換える。
(1) 3 > b :
b + 3 ; 対象となる変数がひとつだけなら、この式だけでも、b に代入される。
(2) 3 < b :
b - 3
(*)
b + 1
(1) 3 > b だったら
b + 3
(2) 3 < b やったら
b - 3
その他なら
b + 1
* > 3
a + c + 1 -> c
*
* から * までを 3回 くり返す
*
a + c + 1 -> c + ; -> のほうが分かりやすいか……
(1) c = 0 :
*
(2) c > 1 :
-
*
くり返し(ループ)
a + c + 1 -> c +
a + c + 1 を c に足す
(1) c = 0 だったら、
* をくり返す
(2) c > 1 やったら、
くり返し終わり
簡潔に表す。
0813デフォルトの名無しさん
NGNG乙ｶﾚｰ
0814デフォルトの名無しさん
NGNGわざわざそんな難解な構文にする必要ってある？
0816デフォルトの名無しさん
NGNG-> で代入する方向が明確だし、b = b + 3 などより、表現が
紛らわしくない。読む方向が一定。(まあこれは思考にもよるが。)
ループや条件分岐などの基本的な構文は、記号にしたほうが視認性があがる。
また、同じ記号を入れかえることによって、文字を節約でき、
他の機能に割り当てる余地ができる。
全体的に打ちやすく、覚えやすくなるだろう、と思った。
0817デフォルトの名無しさん
NGNGいや、ダメだ。気色悪い。
FORTHにさらに輪を掛けて気味悪くした構文にしか見えない
0818デフォルトの名無しさん
NGNGFORTHの構文とそんなに違わないし、FORTHに比べてどこが
すぐれているのかわからない。
今時FORTH以外の言語でRPNをやって何が嬉しいのかわからない。
0819818
NGNGでもキモイ。
0820デフォルトの名無しさん
NGNGどういう風にページを分けるか、とか、どういうフォーマットで書くか、とか…。
もっとも、全ては39さん次第なのですけれども。
( >>777を見るに、MegaBBS互換の掲示板で現在のように相談して、
結果をWikiでまとめる形にしようとしているのかなぁと勝手に想像 )
このスレッドから必要な発言を書き写すのに協力しろとか
命じて貰えれば、協力させていただきたく思います。
0821デフォルトの名無しさん
NGNG0822デフォルトの名無しさん
NGNGあっ、でもFORTHはいい言語だよ。 C++とかよりも、和むものがあるよ。
082339 ◆6K2ziZrM
NGNGで、wikiだけでも良いのですがやっぱり参加しづらい人もいるので、
互換スクリプトを設置しておいた方が移行もしやすいだろうと思うので。
wikiだけで良いならwikiだけにしますけど。
物事をまとめるのが苦手なので誰かが進行をやってくれるのが
たぶん大多数にとって有益だと思います。
やってくれる人が居ないのなら私がやるしかないんですけど。
082439 ◆6K2ziZrM
NGNGたぶん39を名乗って意見をすると意図せずとも発言の影響が強くなるので
言語仕様に関することは名無しで参加しますし
雑用なども出来ることはやらせてもらうので
希望を言ってもらえればそれに添うようにします
相手を思いやる気持ちはすばらしいです。
いいたいことは気がねなく話し合えて、
お互いの気持ちが通じ合えたら、もっと
生き生きすると思いますよ。(^^) きっと
そのほうがあなたにとってもいいことだと
思うし、心に新鮮な空気が送りこまれてくると
思います。 ――生きるということ。
ひとそれぞれに生きる幅があるけど、
どんなときも、無理しないでくださいね。
自分を見つめることは、とても大事だと
思います。
こうやって、言語を作ってるうちにも、
何かしら見えてくるものがあるかも知れませんね。
まあ、お互いそんなに緊張せんと、協力して、
おだやかにつくっていこうではありませんか。
0827デフォルトの名無しさん
NGNG>>826
0828デフォルトの名無しさん
NGNGwikiスレを読みましたが、wikiは話し合いには向いていないと思えたので
相談は掲示板で行い、ある提案が通った場合提案者がwikiを書き換える、というのはいかがでしょうか？
( wikiを見れば現段階の仕様がわかる、みたいな )
雑用は、(cgi管理などは別にして)、誰がやってもいいようなものは
「誰かやって」と言って貰えれば(僕を含め)何人かやってくれる人がいるような。
0830デフォルトの名無しさん
NGNG0831デフォルトの名無しさん
NGNGよう分からんです・・
0832デフォルトの名無しさん
NGNG>>831 右上に編集ボタンないの？ かんはれ
0833デフォルトの名無しさん
NGNG>>831
編集できるようですけど？
0834831
NGNG*従来のif/else文とswitch/case文は同じような記述にまとめる・・・・らしい
を追加したいんだけど
保存ボタンを押すとエラーが出てダメっぽい・・・
ndbm store returned -1, errno 28, key "条件分岐" at /home/freeweb/computer/am_dev/cgi-bin/wiki/wiki.cgi line 249.
0835833
NGNGでも、「比較演算子」ページに加筆したら成功しました。謎です。
ところで、ページ削除の手段が無い？とか、荒らしに書き換えられたら？とか、疑問が続々と…(w
0836デフォルトの名無しさん
NGNGなにしてはんの
0837デフォルトの名無しさん
NGNG比較演算子
/= は商を代入する複合代入演算子とダブるような・・・
もっとも、個人的には商を代入する演算子なんて必要ないですけど。
= の否定は同じ１文字の ! がよくないですか？
今度は論理否定の演算子とダブりますがあちらは単項演算子なので影響はないと思う。
0838デフォルトの名無しさん
NGNG0839デフォルトの名無しさん
NGNG比較に = を使うということは必然的に代入に = 以外( := ?)を使うという事なので
/= も /:= みたいになって大丈夫な気が。
# wikiに書こうとすると保存でエラーが出るのですが、時々は通ったりもします…微妙だ
0840デフォルトの名無しさん
NGNGとりあえず期待age
0841デフォルトの名無しさん
NGNG一度全文をコピーした後にいったんページを削除（空白にして保存）
その後コピーした文を貼り付ければいける
0842デフォルトの名無しさん
NGNG/= *= += -= &= ... や ++ --などはもう必要ないでしょう。
0843＊
NGNG「簡単に～」
みたいのがすでに無いような気がするんだが。。。
文法など奇をてらいすぎで初心者にはますます意味不明な言語になりつつあると思う。
レス数忘れたが、
Window a;でウインドウが開ける。
みたいなのでいいんじゃね-の？（言語仕様と言うより、ライブラリの話かこりゃ）
今目指しているところがよく分からん。。
（わからんなら口出すな、ね。ﾊｲﾊｲ）
0844デフォルトの名無しさん
NGNGWindow a;
これ、正確にはWindowを開いて処理シーケンス自体はブロックかな。
こういう例にすると
{
Window a;
Window b;
}
a窓が開いてユーザーが窓を閉じると、次にb窓が開かれる、と。
0845デフォルトの名無しさん
NGNGその方法で >>834 に書かれているように 「*従来のif/else文とswitch/case文は同じような記述にまとめる・・・・らしい」
を追加しようと試みたのですが、ダメでした。
試行錯誤の末復元を試みたのですが、どうしても「C言語に書き直すと以下の様になります」を入れられませんでした…
834さんには申し訳ありません…
0846デフォルトの名無しさん
NGNG4
0847逝って良しの１
NGNGプログラミング＝テキストエディタでシコシコ書くもの、と決め付けてるわけだわ。
レゴみたいなのを組み立てて記述するとかいう発想がなぜ出来ない？
0848デフォルトの名無しさん
NGNGこれは大切なことですね:-)
0849デフォルトの名無しさん
NGNG++ と -- はイテレータでも用いると思うのですが。
それとも、I := I.Next(); みたいにします？
自分は += 系は要らないと思っていますが、
++ と -- はイテレータの仕様にかかってくるので微妙です。
>>843
現在は>>152ということでエレガントなOOPLが目標では？
スレッドの目標が言語の開発なので、>>847は残念ながらスレ違いです。
意見としては面白いと思いますけどね。
0850デフォルトの名無しさん
NGNG(何気に同意。)
0851デフォルトの名無しさん
NGNGCADですら言語での記述に移行する時代になったのに。
プログラムが回路図みたいになったら修正大変だよ。
0852デフォルトの名無しさん
NGNG人間が記述しないで、機械が記述する言語て意味じゃないの？
VBみたいのに特化すれば、見やすいし、簡単
0853デフォルトの名無しさん
NGNGそれは昔マックであったけど、
一部でしか流行らなかった。
0854デフォルトの名無しさん
NGNG＞レゴみたいなのを組み立てて記述するとかいう発想
記述という言葉を使っている時点で結局言語に発想を縛られてますね？:)
0855デフォルトの名無しさん
NGNGRealBasic?
>>854
マシン語も記述と言わないか？
0857デフォルトの名無しさん
NGNG単語打つ代わりに図形アイコンずらーっと並べて
実行する言語。簡単そうな代わりに欲しいソフト
が作れそうにもない。
0858デフォルトの名無しさん
NGNG0859デフォルトの名無しさん
NGNG表現力が確実に落ちるからね。
それを補おうとすると、制御構文までアイコン化されてフローチャートの悪夢再び。
0860デフォルトの名無しさん
NGNGわけわからん
0861デフォルトの名無しさん
NGNG書いてみれば図形言語になるのでは？
0862デフォルトの名無しさん
NGNGそらを見上げてみよ！
0863デフォルトの名無しさん
NGNGいや、857 がこういう開発環境を指していると思ったので。
http://www.cyberlab.co.jp/cf_info.html
ちょっと昔だとインテリジェントパットか。
0864863
NGNG適当なページが見つからんかったんで。
0865デフォルトの名無しさん
NGNGMACに実際にあった開発環境のこと言ってたんじゃないの？
0866デフォルトの名無しさん
NGNG<>でもいいのですがちょとタイプしにくいです。
んで、+=や>>=などの複合代入は残すことを希望します。
a += 10
は
a := a + 10
と記述することも出来るでしょうが、エレガントではないと思います。
a+=10と書くときにプログラマがやりたいことは「aに10を足す」ことであって、
けして「aと10を足したものをaに代入する」ことではないはずです。
逆にイテレータに++を使用するのはあまり賛成できません。
++itrと書くときにプログラマがやりたいことは「イテレータの値を増加させる」ことではなくて、
「イテレータに次の要素を指させる」ことだと思います。
itr.next();
のほうがプログラマの思考に近いはずです。
0867デフォルトの名無しさん
NGNG変数の更新を兼ねてしまっているので、単独で「次」を得る演算子を新設するのはどうでしょう？
仮に、「次」をafter, 「前」をbefore とすると、
2 = after 1
'B' = after 'A'
E.Sec = after E.Fir (E: enum {Fir, Sec}; として)
2番目の要素を指すイテレータ = after 最初の要素を指すイテレータ
で、イテレータは I := after I; のように進める…と。
++、--は「X := after X」「X := before X」を意味するとして残すのも有りかと。
こうすれば、operator +を定義すれば+=も使えるようになる、というのと同じ感覚で
operator afterを定義すれば++も使えるようになる、という風にでき、
値を返す演算子(+ - * / after before)と変数を更新する演算子(+= -= *= /= ++ --)と整合が取れると思います。
あと、/= というのは「≠」記号を模していて(実際にAdaでは≠の意味ですよね？)個人的に好きなのですけど…
複合代入は +:= とか /:= という方向はダメですか？
0868デフォルトの名無しさん
NGNGex. Button.pushed -> Label.changeText("Hello, world!")
とか。prologみたく、ぼんやり書いてて何とかなっちゃうのキボン。
0869デフォルトの名無しさん
NGNG0870デフォルトの名無しさん
NGNG前置/後置の++/--はシーケンスポイントの問題で、
# o = o -- - -- o;
導入する事によるメリットが無いと思うんですが。
戻値を nil や void にして式の中に書けないと言うのなら問題ないけど、
前置、後置２つ設置するメリットが無くなって、結局
a.inc()とかinc(a)とかの形式が良さそうです。
それから、複合代入にわざわざ +:= なんてするなら、やっぱり必要ないと思う。
a := a + 10; a.add(10); どっちでも良いじゃない。
>>868
あんまりメリットがあるとは思えないんだけど、elseは？
0871デフォルトの名無しさん
NGNG文法がおかしいのが関係しているのかも。
整形済み（プログラムなど）テキストは、先頭に１つ半角スペースを入れれば
出来たりしませんか？
0873867
NGNGそっちに反応されるとは…余計なことを書きすぎたかも。
統一性のため気を回しましたが、複合代入や ++ は、無いなら無いで別に構いません。
after/before演算子が本題のつもりでした。
・参照型のイテレータは複数から参照できるようimmutable希望
(つまり a.inc(); では無く a := a.next(); がいいと思っています)
・次を取得するための演算子が++しか無く、変数を書き換えず結果を返すものが無い
という理由で、after/before演算子を提案したいと思います。
( 別に英単語の演算子が不自然とは思わないのですが(notとかmodとか普通にあるし)、
気になるなら記号は考えて下さい )
0874デフォルトの名無しさん
NGNG0876566
NGNGとりあえずwikiに全部コピペしたほうがいいのでは。
0877デフォルトの名無しさん
NGNGｽﾏｿ
0878デフォルトの名無しさん
NGNG賛成。
続きをpart2で行うのか、39さんが他の場所に掲示板を設置するのかは別にして、
折角の成果を埋もれさせないようにしておかないと、同じ議論を繰り返すことになってしまう。
とりあえず少しづつでもコピペ作業を開始することにします。(構いませんよね？)
0879デフォルトの名無しさん
NGNG0880878 ◆cqNzZ922
NGNG幾つかページを追加してみましたが、
エラー(>>834に挙げられているものです)が多発するのは相変わらずで、多少嫌気が(w
また、wikiの場合、変更点や発言のかたまりが不明確で、相談事に向いていないと思います。
勝手を言って申し訳ありませんが、
39さん、もしおられましたら、その辺の意向をお聞かせいただけませんか？
( 何人か気にかけておられるように、dat落ち対策や、part2はどうするかなど… )
僕も、雑用なども言いつけて下さればできる範囲でやらせていただきたいと思います。
技術的な協力は恐らく無理なので、できる事をしたいです…。
0881デフォルトの名無しさん
NGNG0882デフォルトの名無しさん
NGNGこの言語は誰をターゲットにしているの？
言語オタク？マニア？シロウト？一般人？
088339 ◆6K2ziZrM
NGNGDBの設定を変えるため、すべての記事をいったん削除します。
しばらく登録は行わないようにお願いします。
088439 ◆6K2ziZrM
NGNGpart2は立てたいとは思っているのですが、
今の状況で立ててもスレの無駄遣いになってしまうと思うので、
議論の方はiswebの方に移行してもらった方がうれしいです。
形が出来たら改めてpart2を立てると言うことで。
088539 ◆6K2ziZrM
NGNG審査落ちしたので、当分はiswebで運用して行こうと思います。
>>880
たぶん、設定を修正して今まで出ていたエラーは出なくなったと思いますが、
新たな問題が発生する可能性もありますので、少し様子を見てください。
dat落ち対策は、このスレが1000に到達したら、一応iswebにアップロードするつもりです。
>>881
私のISPはdtiなので、cgi利用できないから不可能です。
自鯖はフレッツISDNなので、固定IPじゃないから不便です。
広告の事でしたら、Proxomitronを利用してもらえば除去出来ると思います。
0886逝って良しの１
NGNGあれはツールが安いから金のない企業がやってるだけ。
日経も煽ってたからインチキ度大盛り。
ＧＵＩからテキストってのは明らかな後退。
それに回路図エディタの裏で一度テキストに変換されるんだからやっぱ後退
0887デフォルトの名無しさん
NGNGスレも終わりに近づいて、移行するにしても整理しなきゃならない段階なんだから、
無駄にレス数消費させないでくれ。
0888デフォルトの名無しさん
NGNG心狭いなぁ（ｗ
0889デフォルトの名無しさん
NGNG基本的な方針だけでもさっさと固めてった方が良いとおもう。
前衛的な構文を提示するやつはEBNFで出させる様にすれば39氏の負担も軽いな。
それとクラス関係は、あれもこれもじゃきりが無いから、
いっそのことメタクラスみたいなのを導入したほうがいい。
アクセス制限なんかは決めておく必要があるだろうけど。
ところでいままでで確定的な決定事項って何？
値オブジェクト、静的genericって意見は良く見るけど。
0890デフォルトの名無しさん
NGNG>>889
同意。
この言語の得意分野、不得意分野は？
「こういうことをやるならこの言語を使うと、このようなめりっとがあるよ。」
みたいなお題目がwikiにない。
あるいは
「なんにもメリットは無いけど、一度言語を作ってみたかった。
自己完結はしているぞ」
とか。(笑)
0891566
NGNG構文は適当。
class A
{
make(){}
}
A a = new A.make() //A a = new A; a.make()
new A.make() 全体をコンストラクタと考えることもできるので
> Eiffelのように特定クラスのコンストラクタから始まる
でもいいのかも…
make()はサブクラスに継承されます。
0892デフォルトの名無しさん
NGNGEiffelの仕様みたいなの日本語で見れるサイト無い？
0893デフォルトの名無しさん
NGNG検索すればいくらでも
0894デフォルトの名無しさん
NGNG0895デフォルトの名無しさん
NGNGじゃあこれ、というのを探して来い。
0896デフォルトの名無しさん
NGNGhttp://www.geocities.co.jp/SiliconValley/8632/syntax.html
0897デフォルトの名無しさん
NGNGどうも知識をひけらかしたいﾔｼらがひけらかすだけで終わってしまう予感。。
0898デフォルトの名無しさん
NGNG0899デフォルトの名無しさん
NGNG勝手言ってしまって申し訳ありませんでした。対応ありがとうございます。
議論はiswebの掲示板で続けるとのことですが、
まだスレッドがひとつも無いので、どんな風に立ててやろうか画策中です(w
取りあえずライブラリは除外して考えるとして
・雑談
・型の種類と機能
・GC
・宣言文
・制御文
・演算子
こんなとこですか？どう？→all
0901デフォルトの名無しさん
NGNG・目的／用途 (これを使うと結局なにができるんだ？なにがしたいんだ？)
・要求されるスキルレベル (VBしか使ったことないやつは却下だ！とか。)
・サポート動作環境 (Windows95以降ならok、等)
も追加してくり。
こういう項目列挙は他の言語の仕様書とかを参考にするのが
手っ取り早いと思ったりする。
0902 ◆cqNzZ922
NGNGhttp://isweb43.infoseek.co.jp/computer/am_dev/cgi-bin/bbs/dev/index.html
(直行のURL書いていいのかな？)
0903デフォルトの名無しさん
NGNGTierraみたいなのつくる方向で。 じゃ。 ﾆﾔﾘ (ー_ー)†
0905891の訂正
NGNG構文は適当。
class A
{
make(){ ... }
}
A a = new A.make() // A a = new A; a.make()
new A.make() 全体をコンストラクタと考えることもできるので
「Eiffelは特定クラスのコンストラクタから始まる」
でもいいのかも…
make()はサブクラスに継承されます。
0906デフォルトの名無しさん
NGNG0907デフォルトの名無しさん
NGNG0908デフォルトの名無しさん
NGNG今まで誰もが意図的に避けてきたと思われる質問をさせていただきます。
名前が主に全角スペースだけ、メール欄はよくsageの後に全角スペースふたつ or 何かの文字列を付けている氏に質問です。
主に>>639>>825>>826>>846>>838のような哲学的な発言を繰り返しているようですが、技術系の板で何が目的ですか？
時々前衛的な構文を提案したりもしているようですが、それも説明不足と思われます。
宜しければあなたがこのスレ(と移転先)でやりたいことを教えていただけないでしょうか？
(それとも複数人いるのかな？)
0909デフォルトの名無しさん
NGNGそれを藪を突付いて蛇を出すという
0910☆
NGNG水は方円の器に随う
類は友を呼ぶ
氷山の一角
明鏡も裏を照らさず
盲蛇に怖じず
瑠璃も玻璃も照らせば光る
虚心坦懐
0911デフォルトの名無しさん
NGNG0912デフォルトの名無しさん
NGNGhttp://isweb43.infoseek.co.jp/computer/am_dev/cgi-bin/bbs/dev/index2.html
091339 ◆6K2ziZrM
NGNG0914デフォルトの名無しさん
NGNG0915デフォルトの名無しさん
NGNGこのスレの移転先は
http://isweb43.infoseek.co.jp/computer/am_dev/cgi-bin/bbs/dev/index2.html
開発するプログラミング言語の仕様を議論しているので見に来てください。
0916デフォルトの名無しさん
NGNG0918デフォルトの名無しさん
NGNG0920デフォルトの名無しさん
NGNG0922デフォルトの名無しさん
NGNG0923デフォルトの名無しさん
NGNG0924デフォルトの名無しさん
NGNGhttp://isweb43.infoseek.co.jp/computer/am_dev/archives/draft.txt
0925デフォルトの名無しさん
NGNG>>375-380
>>382-383
>>385
>>387
>>391
>>393
>>398
>>401
>>404
>>409
>>412
>>414
>>418
>>421
>>425
>>428
>>430
>>433
0926デフォルトの名無しさん
NGNG話題が出なくなって言語がまとまってきたようなので、
いちど39さん、試作していただけないでしょうか。
そのためにも言語仕様をいまいちどしっかりと
まとめたらいいと思います。
0927デフォルトの名無しさん
NGNG動かそうと思えばIntegerなど組み込みクラスの仕様も必要でしょうけれど
基本的な宣言文などは、パーサぐらいなら書ける程度にまとまってきたのではないでしょうか。
( 今後大幅な変更が無いとも限りませんが… )
0928デフォルトの名無しさん
NGNG0929デフォルトの名無しさん
NGNG314159265358979323846264338327950288419716939937510582
097494459230781640628620899862803482534211706798214808
651328 ･･･
0932デフォルトの名無しさん
NGNG0933デフォルトの名無しさん
NGNG0934デフォルトの名無しさん
NGNG0935デフォルトの名無しさん
NGNGあと、引数とかに使う、列の概念もあるといいなぁ。
0936デフォルトの名無しさん
NGNG0937デフォルトの名無しさん
NGNG0938デフォルトの名無しさん
NGNG39さんの開発状況はわからない…
別コンセプトの言語仕様でも話ながら、
ﾏﾀｰﾘしてませんか
0939デフォルトの名無しさん
NGNG>>938 言語というより、んー、たとえば、Age of Empires 風にできない？
人が変数で、ぷろぐらむを楽しむという供用でいいだろうか・・・・。
0941デフォルトの名無しさん
NGNGそれはもはや「プログラミング言語 開発スレ」の内容じゃない…
むー、実際問題コンパイラを作れる人がいないとどうしようも無いですからねぇ。
( スクリプトを作るというならともかく、ネイティブexeなんて僕はフォーマットすら知りませんし )
0942938
NGNGそこまで違うコンセプトの話が出てくるとは思いませんでした。
このスレ、実現化が目標のようなので、
概念的な話から始めるとしんどいかも。まだ漠然としているようですし。
>>941
オレはコンパイラ書くのはよく挑戦するけど、まだ完成させたことないからなぁ。
今までは、言語設計の話がメインだったけど、コンパイラやランタイムら辺の話もする？
0943941
NGNG>コンパイラやランタイムら辺の話
それいいかも。少なくとも*.objさえ吐けるようになれば後はどうにでもなるでしょうし。
まず、パーサー等は放置して、「何もしない*.exeの元になる*.objを吐くだけ」のプログラムを目指すとか…。
0944デフォルトの名無しさん
NGNGそろそろ次スレを用意してください。
良スレsage
0945デフォルトの名無しさん
NGNGその辺はnasmを使うでいいと思う。
objファイルやLinuxのELF形式のファイルも吐けるらしいし。
0946デフォルトの名無しさん
NGNG凄く興味あるっす。nasmコード吐く物は少し作ったことがありますけど。
次スレキボンヌ
0947デフォルトの名無しさん
NGNG0948デフォルトの名無しさん
NGNGプログラミング言語 開発スレ( ´ⅴ｀) 2
http://pc3.2ch.net/test/read.cgi/tech/1030737381/
レス数が900を超えています。1000を超えると表示できなくなるよ。