トップページ⇒tech
949コメント399KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさんNGNG
暇で本気な人はｶﾓｿ！
0153デフォルトの名無しさんNGNG
>>152
マジ？そのネイティブコンパイラってオプティマイザ込み？
015439NGNG
>>153
共通項の括り出しとか、末尾再帰の最適化程度なら出来るかもしれんが。
普通の商用コンパイラ並みのオプティマイズは無理だな
0155デフォルトの名無しさんNGNG
なるほど。
ネイティブバイナリの出力フォーマットはPE？ELF？
それともコンパイル済みのコードをリソースとして保持して
実行ファイルにはローダを作り込む？
015639NGNG
Win用のバイナリで、
COFFにするか、直接PEを吐くかはまだ決めていない。
COFF/OMFが吐ければ便利だけど、他言語との連携を考えないといけないからな。
0157デフォルトの名無しさんNGNG
そうか。COFFを吐けばいいわけか。
エレガントなOOPLね。オブジェクト指向周りの設計が難しいな。
実際の所、プロトタイプベースの言語以上の柔軟性って思いつかないし、
実行パフォーマンスとのバランスを考慮すればC++が最良の解に思える。
でもそういう既成言語を踏襲するだけじゃエレガントの内には入らないんだよね？(ｗ
015839NGNG
>>157
んー、漏れが考えているのはC#程度まではシンプルになった
C++がいいかな、とは考えているんだが。
ファイルベースのモジュールじゃなくて、シンボルベースにしたり、
今のC++の古いところを取り除いて。
ああ、それから、GCをネイティブで搭載したいな、とも。
0159デフォルトの名無しさんNGNG
C#かぁ。C#だと property とか delegate があるね。
delegate なんかは俺はエレガントとは思えないんだけど、便利ではある。
あと attribute もエレガントとは思えない。
でも、そういう特徴を除いちゃうとDじゃんって話になる。
もちろんそのまま取り入れるだけだったらC#じゃんって話になる。
そこはやっぱり差別化しなくちゃいけないよね。
templateの有無なんかはどう見てる？
016039NGNG
まぁ、Dでもいいんだけどね。
それを言ったら言語を作る意味がなくなっちゃうしな。

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

それから、静的型付けﾏﾝｾｰなんで、templateは導入したいけど、
C++そのままというのはちょっとイヤだから、いろんな言語を見て研究、と。
Java Genericsもイマイチピンと来ないし。
0161デフォルトの名無しさんNGNG
delegateは無くてもいいからeventはほしいなぁ。
フラグ値と列挙値は区別して。
プリミティブは従来のshort,longじゃ無くてint16,int32のように。

templateの魅力はinline展開されてこそだと思うけどその辺はどう思う？
0162デフォルトの名無しさんNGNG
eventってのはBCBの__closureみたいもののこと？
templateのinline展開は必ずしもコンパイル時にやらなくても、
JITを使うとして実行時の処理に任せるというのも手だと思うな。
016339NGNG
templateの魅力ってインラインじゃなくて、
オブジェクト参照やvoid*を使ったポリモーフィズムじゃなくて、
タイプセーフを保ったまま総称を実現出来る事じゃないかなぁ
0164デフォルトの名無しさんNGNG
インラインで処理しない場合、バイトコード周りの仕様決めが難しくならない？
0165デフォルトの名無しさんNGNG
>>163
コンテナではそれも大きいんだけど（キャストうざい＆コンパイル時チェックできない）。
アルゴリズム側から見ると、ポリモーフィズムでも別にいいじゃん、って話にならない？
0166デフォルトの名無しさんNGNG
GenericProgrammingスレで出ているような技を見ると
templateがポリモーフィズムだけでお終いってことはないと思う。
0167デフォルトの名無しさんNGNG
>>162
delegateは関数ポインタのお化け（型）でeventはフィールド・・かな？
delegate型のメンバも作れるけど代入演算子が使えるとか、問題が多いからeventでラップする。

C#ってdelegate作った後にevent作らなきゃいけなくて、なんか2度手間のように感じてしまう・・・いい方法無いかな？
016839NGNG
>>164
それはならないでしょう。
タイプごとに別に関数・クラス実体を作成するから、たいした問題では無いと思う

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

それから、万が一オプティマイザを搭載する事になったら、
そのときに自動判断で展開するようにすればいい。
templateを無条件インラインにしちゃうと、
inlineキーワード追加しないとならないし、どんどん言語仕様がシンプルじゃなくなるでしょ
016939NGNG
>templateがポリモーフィズムだけでお終いってことはないと思う。
それでも、テンプレートの本質はこれでしょ？
あのスレの話題はそれを発展させたトリックであると言うだけで。
0170デフォルトの名無しさんNGNG
ポリシーという考え方は新鮮だった、大いに取り入れさせてもらってるよ。
0171デフォルトの名無しさんNGNG
>>169
一般化された概念としてのポリモーフィズムとしてはそうだね。
C#/Java/C++などで言われるところのポリモーフィズムでは不足。
でもその辺を追究していくとHaskellになっていくような・・・。
0172デフォルトの名無しさんNGNG
文字列は言語側で用意？ライブラリ側？
Cのような単なるchar配列というのもなんだか使えないし。
C++のbasic_stringはSTLとあわせると強力だけど、パフォーマンス的にあれだし。
JavaやC#のように行くの？
017339NGNG
>>171
テンプレートについては私自身勉強不足な点は多いんで、
何かいいことがあればどんどん書いてほしいと思いますが

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

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

そもそも、こういうミクロな話じゃなくて、
もっと言語のポリシーや構文を決定するマクロな話からしたほうがいいかと。
基本的に、質問じゃなくて、アイデアを提案してください
私が仕様を決定するのではなく、私は単なる１実装者でありたいので。
0174デフォルトの名無しさんNGNG
マクロな話としては、シンプルな実用言語、を希望かな。
新しいフィーチャーはなくてもいいから実用十分な機能があって使いやすいのがいい。
結局は、C#と似たり寄ったりになるんだろうけど、もっと文法はシンプルな方がいい。
0175デフォルトの名無しさんNGNG
とりあえず、言語にあわせてクラスライブラリを作るんじゃなくて
GUIフレームワークを最初に作り、それに親和性の高い構文を持つ言語とする
と言うのが理想かな。
どうせ2chの烏合の衆じゃ一般化された素晴らしい言語仕様なんて作れないだろうから
0176デフォルトの名無しさんNGNG
>>175
はい、喧嘩売るなら自分で実装してからにしてくれ。
0177デフォルトの名無しさんNGNG
>>175
前半部は同意
窓をサクっと書きたいね
0178　　　　　　NGNG


　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　循環するもの
0179デフォルトの名無しさんNGNG
これやってよ
http://pc.2ch.net/test/read.cgi/prog/961558082/l50
018039NGNG
>>179
そういう方向に進むなら漏れの出番はないです
0181デフォルトの名無しさんNGNG
aforがあるならforeachもありだろ
0182デフォルトの名無しさんNGNG
結局誰もマトモに作ろうとはしてないってことで
★☆★☆★☆　糸冬　了　☆★☆★☆★☆
0183デフォルトの名無しさんNGNG
レスを見ながら各言語構文の要点整理をして案を練ってる私は一体…
暇人は帰れってことですか？（泣

とりあえず継承の構文はまだですよね？
018439NGNG
>>183
継承って単一継承か、Javaの用に実装一つインターフェース複数にするか、
それすらも決まってないようです。

>>10-12の型推論は面白そうだけど、実装がちょっとめんどくさそうですね。
MLの型推論に関する文章読んでます。
0185デフォルトの名無しさんNGNG
mix-inできる静的型付け言語キボンヌ
0186デフォルトの名無しさんNGNG
>>185
mix-inの概念がよくわからないので、詳細ｷﾎﾞﾝ
0187185NGNG
制限された多重継承です。
多重継承と同じでインターフェースと実装を継承できます。
mix-inされるモジュールは通常のクラス定義と同じように
インスタンス変数とメソッドを定義できますが、モジュールは
スーパークラスを持たず、また、単体ではインスタンスを生成
できないと言う制限が付きます。
クラスは一つのスーパークラスと複数のモジュールを継承できるので
クラスを横断するような実装を再利用しやすくなります。

‥‥といふのが私の認識ですが間違ってたらつっこんでやってください。
0188デフォルトの名無しさんNGNG
class AClass {
public:
　foo();
}

class IClass {
public:
　bar();
}

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

こうするとClassは
Class : IClass
+foo()
+bar()
こんな感じになるって事？
0189デフォルトの名無しさんNGNG
>>187
mix-inの実装されてる言語の構文は良くわからないけど、こんな感じ？

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

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

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

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

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

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

……個人的にはCLOS流が好きですが、静的型付けの好きなタイプの
ひとはEiffel流を好むような気がします。
0191デフォルトの名無しさんNGNG
言語仕様がちょっと無駄に複雑になる気もしますが・・・
0192デフォルトの名無しさんNGNG
名前がぶつかるところはどのクラスやインターフェイスから継承したのか明示的に指定するのはどうかな。

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

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

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

>>192
Renameをいちいち書くのは面倒だし優先順位のやり方だとアクセスできない
メソッドやインスタンス変数が出てくる場合があるのでナイスなアイデアかも。
0195189NGNG
>>181
多重継承のせいで同じ基本クラスが複数含まれてしまう問題と、
インターフェイス内でメソッドの実装が行えない問題の
両方に対してなかなかいい答えを出してくれると思う。

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

これくらいあるとうれしい。
え？多すぎる？
0196デフォルトの名無しさんNGNG
クラス定義の構文なんかもいろいろな流儀がありそうだね。
0197デフォルトの名無しさんNGNG
>>196
漏れは>>10の様にclassキーワードをつけないのが好みだったり
0198デフォルトの名無しさんNGNG
つけないとコンパイラが大変じゃない？
漏れは変数にはvar、関数にはfuncつけたほうがいいとか思ったり、でもそれは面倒だとも思ったり。
0199デフォルトの名無しさんNGNG
未定義の識別子から始まる構文をもし使うなら、頻度から考えて
メソッド定義の場合に限定するとかしないと、
class
interface
module
なんかの区別がうまくできない気がします。

ところでstructってやっぱり必要？
0200デフォルトの名無しさんNGNG
たしかに>>10だとクラスのテンプレートメソッドと混乱しそうだなぁ。
でも、コンパイラ制作者ががんばれば出来ないことも無いと思うが
0201デフォルトの名無しさんNGNG
>>199
C#みたいにintやlongをstructとするといろいろ幸せなことが多いです。
確かintを継承したり出来ますよね。
あ、そうそう、演算子のオーバーロードもほしい、オーバーライドもあるとなおうれしい。
0202デフォルトの名無しさんNGNG
moduleの有用性がわからない。
classをmix-inすればいいんでないの？
0203デフォルトの名無しさんNGNG
>>202
mix-inされるクラスは他のクラスを継承してはいけないとか制限があるから、
ただわかりやすくするため、程度に。

メソッドの宣言しか出来ないクラス（に似たもの）をinterfaceと呼ぶのと同じ気分で。
0204デフォルトの名無しさんNGNG
演算子オーバーロードはいらないと思うな。
シンプルで敷居の低い言語であってほしい
何でもかんでもごちゃごちゃ入れちゃうと、
C++っぽくつぎはぎだらけに・・・
0205デフォルトの名無しさんNGNG
複素数や巨大な数を扱うクラスにはやっぱり演算子オーバーロードがホスィ・・・。
（こいつらの使用頻度自体が低いことはおいといて・・・）
0206デフォルトの名無しさんNGNG
お前ら本気で作る気かよ。
コンパイラ作るには仕様ががちっと決まっている必要があるぞ。
何スレ目までかかることやら・・・。
0207デフォルトの名無しさんNGNG
>>205
複素数や巨大な数のクラスは言語標準でサポートすれば

>>206
500過ぎても構文が決まらなかったらwikiを設置しよう
0208デフォルトの名無しさんNGNG
そう言われると500までに仕様を固めたくなるのだよ…ふふふ
0209デフォルトの名無しさんNGNG
>>207
言語仕様は小さいほうがいいなぁ。
0210デフォルトの名無しさんNGNG
>>209
禿て同感
0211デフォルトの名無しさんNGNG
>>209
複素数を言語でサポートするのと
オペレータオーバーロードを導入するの、
セーフティプログラミングの観点から見て、どっちがいいと思う？
0212デフォルトの名無しさんNGNG
言語名は是非guajavaで。
0213デフォルトの名無しさんNGNG
もちろん 2ch.NET で。
0214デフォルトの名無しさんNGNG
>204
スマートポインタも作れないよぉ。
他にもPOINT とか SIZE とか演算子が欲しくなるようなクラスが沢山。
演算子が使えないのはやっぱり嫌だなぁ。

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


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

個人的にはテンプレートライブラリが作りやすい言語がいいな。
0215デフォルトの名無しさんNGNG
スマートポインタって・・・ポインタありなの？
0216デフォルトの名無しさんNGNG
>>214
39はGC搭載したいとか言ってなかったか？
生ポインタはそもそも入れるつもり無いと思われ

>セーフティ．．．
多人数開発での保守性といった方がいいのかな
0217214NGNG
>>215
ん？ポインタ無し？

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



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

インデクサもあればコレクションが作りやすいけど。
0219デフォルトの名無しさんNGNG
age
0220デフォルトの名無しさんNGNG
パーサ書くのと文法考えんの面倒だから前置か後置にしよう。
0221デフォルトの名無しさんNGNG
パーサは39が書くから構文をみんなで考えようって話じゃないのか？
0222デフォルトの名無しさんNGNG
後置ならDiamondスレでやってるからがんばれ
0223デフォルトの名無しさんNGNG
前置や後置は初心者にやさしくない。
それより GUI フレームワークを考えるべきだと思う。
Windows 限定なのか Swing などのようにマルチプラットフォームを目指すのか。
022439 ◆6K2ziZrM NGNG
>>223
Win限定でいいんじゃないかな、とか。
いや、わたしゃWinしか知らないもので。
0225デフォルトの名無しさんNGNG
Window a;
このくらいの打鍵数で窓を開けさせてくれ！
初心者はこれくらいが限界だよ！
0226デフォルトの名無しさんNGNG
となると Windows のコントロールを使いやすいようにラップするのが基本的な作業になるね。
個人的には VCL ライクだと使いやすくていいけど(ｗ

一番問題なのはスレッディングモデルかね。
ウェジェットにスレッド化の属性を付けてやって
クリック一つでマルチスレッド処理ができればいいが
そんなに簡単なパターンばかりじゃないしな。
022739 ◆6K2ziZrM NGNG
VB/Delっぽいかなぁ・・・
GUIビルダとそれを接続するイベントモデルを作って、
コード上から(Windowsの)コントロールを操作するコードを
完全に切り離すというのはどうだろう。
ってそれは幻想だよなぁ。

結局ソースからさわる必要も出てくるだろうし・・・
0228デフォルトの名無しさんNGNG
>>142-144

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

？？？？？？
0229デフォルトの名無しさんNGNG
class Class
{
　public // ブロックも可能
　{
　　int field;
　　void method();
　}

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

あと書き込みはprotected、読み込みはpublicな属性もほしい。
俺はreadonlyって呼んでたけど、C#で別の意味で使われちゃったね。
0230228NGNG
「宣言の文字数が全部そろってて」
「頭文字が違う」
の実演テストしてみただけです…。
でもpublicとかに慣れてるせいか自分じゃ見やすいのかよくわかんない…。
しかも等幅じゃないからインデント崩れてるし…。

別にallclsキーワードは本気ではないですよ。
ただちょっとstatic宣言の代用にclsとinsを思いついたので。
0231_　NGNG
javaファイルを吐き出す簡単なＣもどき作ってます。
*a++ = 0;
*a = 1;
と
a[0] = 0;
a[1] = 1;
の上って必要？あんまり上が必要になったことないのだけど・・・
下だけじゃだめ？

http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html
ここにJVMをターゲットにした言語山ほどありますね。。。
0232デフォルトの名無しさんNGNG
>>231
そっくりなコードをさっき別スレで見た気がする・・・
場合によって違うじゃん。
C++的にはイテレータって概念が浸透してるから上のほうが主流だろうけど、
C的にはどっちも同じくらいの頻度で使うんじゃないの？
ランダムアクセスが必要なら当然下になるし。
0233231NGNG
すみません。jvmをターゲットにしてるのにポインタ操作っておかしいですね。
（下の話につなげたかっただけ）
ほんとは8086ファミリーがターゲットです。。。
0234231NGNG
>>232
やっぱみんな下よく使うんですね。
私はランダムアクセスは別に変数用意＋キャストしてやってる気がする・・・
0235231NGNG
>>232
はう、混乱してる。上だとおもってしまた。上が必要な時は
変数用意＋キャストしてプログラミングしてる気がします。
下だけじゃ駄目っすか？
0236デフォルトの名無しさんNGNG
別に下があれば上はなくても文法上は困らないけど。
読みにくくなることはあるだろうね。
0237231NGNG
>>236
なる～ｻﾝｷｭ。じゃあ、下だけにしよっと。

今までちょっと作ってみた感じでは
Ｃへのトランスレータ＞8086インタプリタ＞＝JVMコンパイラ
＞8086コンパイラ
の順で楽だと思います。これからは.NET対応が一番幸せになれそう。
023839 ◆6K2ziZrM NGNG
>>229
propertyでset/getでgetしか定義されてないなら読みとり専用。
これじゃダメなの？
0239デフォルトの名無しさんNGNG
>>237
何が言いたいのかｻﾊﾟｰﾘわからんのだが
8086インタプリタってナニ？
エミュレータ？
しかも、楽とか・・・
何が言いたいのかわからん
024039 ◆6K2ziZrM NGNG
>>229
ああ、ごめん、読み書きで属性変えたいのね。

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

こんな感じって事？
0241229NGNG
>>238
んや、それで桶です。
おれっちの考えたのにはプロパティはなかったんで。

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

みたいなのは、どうでしょうか。
hogeをサブクラスでオーバーライドしたときは、
そのサブクラスのhogeが呼び出される前後にbefore hogeとafter hogeが呼ばれるです。
024239 ◆6K2ziZrM NGNG
>>241
それってクラス定義がかなり汚染されませんか？
inner関数やlambdaを導入するとかで解決できそう。
0243229NGNG
>>240
241の前半は勘違いなんで無視してください。
そういう記述が出来ればなおいいです。
024439 ◆6K2ziZrM NGNG
>>241
ああ、違うか、ごめん
DのDBCですか？
0245デフォルトの名無しさんNGNG
なあ、もうallinsでよくないか？
0246229NGNG
>>244
あんまり深く練ってなかったんで、
あったらdebugとか便利かなと思ったんですけど、
> hogeをサブクラスでオーバーライドしたときは、
> そのサブクラスのhogeが呼び出される前後にbefore hogeとafter hogeが呼ばれるです。
この部分は撤回です、挙動がおかしくなるです。

DBCは、機能自体は知ってるんですけど、
実際どのように実装されているんでしょう？
0247229NGNG
DBCの表現方法は言語によってまちまちですね。
debug時にだけ有効になるassertがあれば、特に他に言語サポートは必要ないんじゃないでしょうか。
024839 ◆6K2ziZrM NGNG
>>247
http://pc.2ch.net/test/read.cgi/tech/1003674814/21
記述形式がこれと似ていたのでそうかなって

0249デフォルトの名無しさんNGNG
C系の関数の書き方だとこちらのほうが受け入れやすいかも。
漏れは別にいらない気もするけど。

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

　// 本体

　return 1;
}
0250デフォルトの名無しさんNGNG
>>241
いっそのことaspectキーワードを入れてしまうとか。
025139 ◆6K2ziZrM NGNG
>>249
それだと、継承後時にfuncをオーバーライドしたら失われてしまうでしょ
0252デフォルトの名無しさんNGNG
>>247
D 言語がよりモダンな構文だと思う。

D言語ドラフト一応読んだよ
http://pc.2ch.net/test/read.cgi/tech/1003674814/
■ このスレッドは過去ログ倉庫に格納されています