5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

1 :*.ini:2001/08/21(火) 01:27
C/C++, Baic, Perl, Object Pascal, Java のいいとこ取り。どうぞ。

2 :デフォルトの名無しさん:2001/08/21(火) 01:28
目的は?

3 :デフォルトの名無しさん:2001/08/21(火) 01:28
rubyはないのね。

4 :デフォルトの名無しさん:2001/08/21(火) 01:29
Baicがわからんことにはどうにも。

5 :デフォルトの名無しさん:2001/08/21(火) 01:32
Del厨がいなければ良スレに育つ予感

6 :デフォルトの名無しさん:2001/08/21(火) 01:34
Baic ってなに?

7 :デフォルトの名無しさん:2001/08/21(火) 01:35
C/C++, Object Pascal, Java までだと C# という気がするが。

8 :デフォルトの名無しさん:2001/08/21(火) 01:35
1に出てくるのはBaic(謎とC以外全部オブジェクト指向言語だが
これでいいのか?

9 :デフォルトの名無しさん:2001/08/21(火) 01:35
JavaScriptは?
Objective-Cは?

10 :デフォルトの名無しさん:2001/08/21(火) 01:38
HaskellとPrologも入れとけ

11 :デフォルトの名無しさん:2001/08/21(火) 01:39
糞スレの予感(;´Д`)

12 :デフォルトの名無しさん:2001/08/21(火) 01:40
Parlってオブジェクト指向言語なの?

13 :デフォルトの名無しさん:2001/08/21(火) 01:41
>>12
それってBaicと同じ・・・

14 :デフォルトの名無しさん:2001/08/21(火) 01:42
>>12 Perl5からね。一応。

15 :デフォルトの名無しさん:2001/08/21(火) 01:46
型の概念をなくそう。
新人に型の説明するのもいいかげん飽きてきた。
数学でも、変数の型は重要ではない。
重要なのは、その変数がどういう意味を持つのか である。

16 :デフォルトの名無しさん:2001/08/21(火) 01:47
>>15
コンパイラ作る人の身にもなると(以下略

17 :デフォルトの名無しさん:2001/08/21(火) 01:49
>>15
どうやって?
文字列とかは?

18 :デフォルトの名無しさん:2001/08/21(火) 01:50
>>1
貴様!!
M$の手先だな!!

19 :デフォルトの名無しさん:2001/08/21(火) 02:01
perl 見たいに。
for 文でも省略を可能にしよう。

for 0 to 10
print;

このように。

20 :デフォルトの名無しさん:2001/08/21(火) 02:03
Delphi∋C∪C++∪Baisc∪Perl∪Java

21 :デフォルトの名無しさん:2001/08/21(火) 02:09
なぜBasicをちゃんと書ける奴がいないかな

22 :デフォルトの名無しさん:2001/08/21(火) 02:10
Cの文法を持ったschemeが良いな。

23 :デフォルトの名無しさん:2001/08/21(火) 02:12
構文1
for 0..10 do
 print $_;

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

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

24 :デフォルトの名無しさん:2001/08/21(火) 02:14
標準でCOMPLEX型をサポート。
整数〜複素数の混在演算を許す。

25 :デフォルトの名無しさん:2001/08/21(火) 02:19
引数が大量にある関数を呼び出す場面で、
後から見るとどの引数がどんな意味をもっているのか
その関数を知っていないと分からない。
そこで以下のような書き方を希望

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

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

26 :デフォルトの名無しさん:2001/08/21(火) 02:20
smalltalkくせー>>25

27 :デフォルトの名無しさん:2001/08/21(火) 02:20
Lispが一番

28 :デフォルトの名無しさん:2001/08/21(火) 02:20
文字列の扱いはBASICだね。
サイズを明示的に指定したり
サイズが固定されたりするのはやだね。

29 :デフォルトの名無しさん:2001/08/21(火) 02:25
複素数、文字列型、ベクトル、行列型の標準サポートを希望。
それから、Σ関数のサポートも。

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

30 :デフォルトの名無しさん:2001/08/21(火) 02:28
加算はすべて
object s = Add(12,24,5,25)
のようにAdd(数値)にする。+(プラス)は禁止

31 :デフォルトの名無しさん:2001/08/21(火) 02:29
>>30
メリットは?
カンマで区切るか、プラスで区切るかの違いにしか…
優先順位の問題か?

32 :デフォルトの名無しさん:2001/08/21(火) 02:30
>>28>>29>>30
なにそれ・・・

33 :デフォルトの名無しさん:2001/08/21(火) 02:30
減算は、-(マイナス)を使用。
ただし右辺から左辺を引くこと。

34 :デフォルトの名無しさん:2001/08/21(火) 02:31
+ - 32 45 58

35 :デフォルトの名無しさん:2001/08/21(火) 02:31
dim object s = sum 12,24,5,25;

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

36 :デフォルトの名無しさん:2001/08/21(火) 02:33
大きな配列でも自由に切れる。
メモリの割当をOSに依頼する部分は言語側で吸収する。

37 :デフォルトの名無しさん:2001/08/21(火) 02:34
左辺 . 右辺を、左辺を整数部、右辺を小数部として解釈する。

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

38 :デフォルトの名無しさん:2001/08/21(火) 02:35
糞言語間違いなしだね

39 :デフォルトの名無しさん:2001/08/21(火) 02:38
>>35
変数の宣言に"dim"を使うの反対!
あれを見ると頭が痛くなってくる。
そもそもあれは配列宣言用の命令(?)で、"dimension"から来てるんだから。

40 :デフォルトの名無しさん:2001/08/21(火) 02:40
じゃあ dim じゃなくて def ならどうよ。

41 :デフォルトの名無しさん:2001/08/21(火) 02:41
var
obj
object
Dim
local
new

どれがいい?

42 :デフォルトの名無しさん:2001/08/21(火) 02:41
変数は0次元の配列だからDIMでも問題なし。

43 :デフォルトの名無しさん:2001/08/21(火) 02:42
>>42
(;´Д`)

44 :デフォルトの名無しさん:2001/08/21(火) 02:42
1次元だろ

45 :デフォルトの名無しさん:2001/08/21(火) 02:43
変数にロック機能をつける。

dim a = 4;

a.lock;

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

a には代入可能

46 :デフォルトの名無しさん:2001/08/21(火) 02:44
じゃあ def じゃなくて grep ならどうよ

47 :デフォルトの名無しさん:2001/08/21(火) 02:44
>>45
変数やないやん・・・

48 :デフォルトの名無しさん:2001/08/21(火) 02:44
0次元=点 = dim a
1次元=直線= dim a[10]
2次元=平面= dim a[10,10]
問題ないじゃん。整合性はある。

49 :デフォルトの名無しさん:2001/08/21(火) 02:44
grep s/[0-9]+//

50 :デフォルトの名無しさん:2001/08/21(火) 02:45
dimは厨房用語

51 :デフォルトの名無しさん:2001/08/21(火) 02:46
>>48
心で。

52 :デフォルトの名無しさん:2001/08/21(火) 02:46
breakしないとそのまま下に制御が移ってしまうCのswitch文はダメ。
Pascalのcaseを採用。

53 :デフォルトの名無しさん:2001/08/21(火) 02:53
>>52
そうか?
あれはあれでいいんじゃないのか?

54 :デフォルトの名無しさん:2001/08/21(火) 02:53
>>45
Adaのランデブを勉強して来い。

55 :デフォルトの名無しさん:2001/08/21(火) 02:53
>>52
ついでに列挙型も採用ってか。いらねー。

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

56 :デフォルトの名無しさん:2001/08/21(火) 02:56
if xxxx
elsif xxxx
elsif xxxx
.....................


糞コードだ(藁

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

58 :デフォルトの名無しさん:2001/08/21(火) 03:00
>>57
16読め。

59 :55:2001/08/21(火) 03:02
>>56
んなこたねーっての。

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

60 :デフォルトの名無しさん:2001/08/21(火) 03:03
>>59
ライブラリは糞になりそう・・・

61 :デフォルトの名無しさん:2001/08/21(火) 03:02
基本的な三角関数やLog,Exp等の関数は
Includeなどの宣言をしないでいきなり使える。

62 :デフォルトの名無しさん:2001/08/21(火) 03:04
MLも入れてくれ。
メタランゲージ最高!

63 :デフォルトの名無しさん:2001/08/21(火) 03:04
Java並にライブラリ揃っててスクリプト言語みたいに書いて即実行出来るのがええな

64 :55:2001/08/21(火) 03:05
>>60
Javaのライブラリの中にswitch文あるか数えてみ。
やったことないけどさ^^

65 :デフォルトの名無しさん:2001/08/21(火) 03:06
JavaScript
名前は同じだが、中身Java(藁

66 :デフォルトの名無しさん:2001/08/21(火) 03:10
ループ制御はBASICみたく

  FOR - NEXT
  WHILE - WEND
  REPEAT - UNTIL

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

Cの

  }
 }
}

とかPascalの

  end
 end
end

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

67 :デフォルトの名無しさん:2001/08/21(火) 03:12
>>66
それは慣れじゃないかと・・・

68 :デフォルトの名無しさん:2001/08/21(火) 03:14
OpelaterOver"Ride"
演算子をオーバーライド

本気にするなよ(藁

69 :デフォルトの名無しさん:2001/08/21(火) 03:15
>>67
いや、全然楽だって。閉じてる命令が違うと。

70 :デフォルトの名無しさん:2001/08/21(火) 03:16
if~fi、case~esacみたいなのはいやだぞ

71 :67:2001/08/21(火) 03:17
おれは、Cで慣れちゃったから・・・

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

72 :デフォルトの名無しさん:2001/08/21(火) 03:17
>>70
激同意。

73 :デフォルトの名無しさん:2001/08/21(火) 03:19
function
  switch
    case x
    〜
  end switch
end function

のほうが楽。

74 :デフォルトの名無しさん:2001/08/21(火) 03:22
並列処理も楽に書ける(or 並列処理にしてくれる)ようにしてくれ。
KL1参考にして。

75 :デフォルトの名無しさん:2001/08/21(火) 03:29
>>74
言語自体見直す必要が・・・

76 :デフォルトの名無しさん:2001/08/21(火) 03:36
配列は実行時にサイズを確定する。
(DIM文に制御が来た時にサイズを確定してメモリを確保)
ソースの段階で確定しなくてよい。
(BASICと同じ)

77 :デフォルトの名無しさん:2001/08/21(火) 03:42
言うは易し、行うは難し

78 :デフォルトの名無しさん:2001/08/21(火) 04:02
VB厨が多数いる予感。

79 :デフォルトの名無しさん:2001/08/21(火) 04:17
オブジェクト指向なScheme
ついでに、Delphiのような開発環境も欲しい

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

80 :デフォルトの名無しさん:2001/08/21(火) 04:56
>>58
switch case を文字列に対応させるなんて めっちゃ簡単だよ。
プリプロセッサ使って、
case V of
A: begin 処理A end;
B: begin 処理B end;
C: begin 処理C end;
end

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

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

81 :shige:2001/08/21(火) 05:10
.

82 :◆3DelPhIM:2001/08/21(火) 08:20
やっぱり大事なのは機能よりバランスだと思う

83 :デフォルトの名無しさん:2001/08/21(火) 08:33
文法がRubyでIDEがDelphiな奴で良いや。

84 :デフォルトの名無しさん:2001/08/21(火) 09:15
>>25
そんなの開発環境の入力支援でやれば良い。

85 : :2001/08/21(火) 09:39
ObjectPascalのpropertyと
C++のtemplate
は便利。

86 :デフォルトの名無しさん:2001/08/21(火) 09:45
>>16
コンパイラなんか作らなきゃいいんだよ。smalltalkやrubyみたいにする、と。
型の概念は変数じゃなくObjectの中に(暗黙のうちに)存在する。
気にせんで済まそうと思えば済ませられる。

>>22

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

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

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

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

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

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

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

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

87 :デフォルトの名無しさん:2001/08/21(火) 10:18
>25
TOWNSで動いてたHI-Cでは(書き方は違うけど)実現してた。

88 :無名λ式:2001/08/21(火) 11:09
>>79
> オブジェクト指向なScheme
goops
http://www.gnu.org/software/guile/gnu-guile-projects.html#Core

89 :デフォルトの名無しさん:2001/08/21(火) 11:20
型無しの方がいいな

90 :デフォルトの名無しさん:2001/08/21(火) 11:38
制御構造を表すのにインデントを文法に取り入れてる言語あったよね?

91 :デフォルトの名無しさん:2001/08/21(火) 11:43
>>90 パイソン

92 :無名λ式:2001/08/21(火) 12:12
>>90 Haskellのオフサイドルール

93 :デフォルトの名無しさん:2001/08/21(火) 12:58
仮に>>1のいうように、いいとこ取りの言語ができても
Scheme なんかのほうがよさげ。

94 :デフォルトの名無しさん:2001/08/21(火) 13:11
いっそのこと、最悪な言語仕様を考えるのはどうだろう

95 :デフォルトの名無しさん:2001/08/21(火) 13:14
>>94
HSPにオブジェクト指向
作者が作れば間違いなしさ(藁

96 :デフォルトの名無しさん:2001/08/21(火) 15:17
省略形の一切できない言語が業務的にうれし。
関数や命令の範囲がどこまであんねんってのがわからなきついんでカッコ分化マンセー
あと、変数の頭に必ず指定の接頭詞つけなきゃコンパイルエラーとか。
厨の多くはこれで抑制できる
 ↓と
(°д°)ウマー

97 :perl perler perlest:2001/08/21(火) 15:35
>>96
> 省略形の一切できない言語が業務的にうれし。

ガ━━(゜д゜;)━━ン!

98 :デフォルトの名無しさん:2001/08/21(火) 15:42
>>96 パスカルってもともとは設計思想がそんなカンジだったような。
RUBYのスコープ=接頭辞ってのはわりと良いアイデアだと思う

99 :デフォルトの名無しさん:2001/08/21(火) 20:28
Eiffelの契約による設計希望。

100 :デフォルトの名無しさん:2001/08/21(火) 20:48
ここって考えるだけ?

101 :デフォルトの名無しさん:2001/08/21(火) 22:20
みな赤面して何も言えないようだw

102 :デフォルトの名無しさん:2001/08/21(火) 23:13
無名関数があると何かと便利な気がする予感…

103 :デフォルトの名無しさん:2001/08/21(火) 23:23
無名関数が無いとハッキリ言って糞な予感…

104 :デフォルトの名無しさん:2001/08/22(水) 01:01
>>100
今 漏れは言語を作っているのだが、不幸なことにそれは「いいとこどり」なものではない。
漏れのかわりに誰かいいとこどりなのを作ってageてくれぃ。



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

105 :1:2001/08/22(水) 14:13
ありがとう。とりあえず、俺の知らない他の言語の特徴を見ることが出来た。
俺のためにみんな、ありがとう。後は勝手にやってくれ。

106 :デフォルトの名無しさん:2001/08/22(水) 14:33
>>105
別にアンタのタメにやってたわけじゃないだろう。

107 :デフォルトの名無しさん:2001/08/22(水) 15:24
まず行番号を実装する必要があるな。

108 :デフォルトの名無しさん:2001/08/22(水) 16:31
>>107
スパゲッティプログラムの読み方
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=997717227
の人ですか?

109 :デフォルトの名無しさん:2001/08/22(水) 21:16
すでにある言語を元にしないで、どの言語の書き方とも違う言語じゃないと
皆がいいと思うものはできないと思う。
というわけで、斬新なアイディアで新しい言語を考えよう。

110 :デフォルトの名無しさん:2001/08/22(水) 21:27
じゃ、縦書きで。

111 :デフォルトの名無しさん:2001/08/22(水) 21:30
とりあえず、コードを書いたら、自動的におまけで仕様書が勝手にできあがるような仕組みにしよう。

112 :デフォルトの名無しさん:2001/08/22(水) 21:38
いや、仕様書から自動的にコードが生成されるような仕組みに…

113 :デフォルトの名無しさん:2001/08/22(水) 21:47
会話にも使えるプログラム言語

114 :デフォルトの名無しさん:2001/08/22(水) 21:51
用途を定めず字面の話ばっかしててもねぇ

115 :デフォルトの名無しさん:2001/08/22(水) 21:56
2ちゃんねらー専用プログラム言語「2ch言語」をみんなで
作ろう。

116 :デフォルトの名無しさん:2001/08/22(水) 21:57
>>115
本気ならお前がアイデア出せ。

117 :デフォルトの名無しさん:2001/08/22(水) 22:22
英語に非常に近い形で例えばHelloWorldも
I write "HelloWorld".
とかいう風にするとか。
変数の定義は
I make 型 変数名.
て感じで・・・・・・
こんなアイディアでどうでしょう。
非常に書きやすく、読みやすくなると思うのですか。

118 :デフォルトの名無しさん:2001/08/22(水) 22:23
>>117
COBOLつかえ。

119 :デフォルトの名無しさん:2001/08/22(水) 22:26
HSPを超える言語は無いだろ

120 :デフォルトの名無しさん:2001/08/22(水) 22:26
>>114
科学技術計算用。(OSとかドライバとかは書けなくていい)

121 :デフォルトの名無しさん:2001/08/22(水) 22:28
>>120
APLつかえ。

122 :デフォルトの名無しさん:2001/08/22(水) 22:40
>>117
プリプロセッサ使えばできると思うんだが・・・
つか、あまり書きやすくも読みやすくもないと思うぞ・・・

123 :デフォルトの名無しさん:2001/08/22(水) 22:45
>>121
APL ってこれか
http://member.nifty.ne.jp/ysaigusa/jp/apl/guide/intro/index.html

124 :デフォルトの名無しさん:2001/08/22(水) 22:47
>>121

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

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

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

125 :デフォルトの名無しさん:2001/08/22(水) 22:53
結局、ほかにアイデアはなしですか?

126 :デフォルトの名無しさん:2001/08/22(水) 22:54
あるけど言いたくない。

127 :デフォルトの名無しさん:2001/08/22(水) 22:55
>>126
何故

128 :デフォルトの名無しさん:2001/08/22(水) 22:57
作成中だから

129 :デフォルトの名無しさん:2001/08/22(水) 22:58
>>123-124
んじゃこりゃーーーーー

130 :128:2001/08/22(水) 22:58
修正。
言語を作成中だから

131 :デフォルトの名無しさん:2001/08/22(水) 23:03
>>130
作成中なら、この場でみんなで語りあってよりいっそういいもの
にしませんか。

132 :128:2001/08/22(水) 23:06
>>131
正気?

133 :デフォルトの名無しさん:2001/08/23(木) 05:19
>とりあえず、コードを書いたら、自動的におまけで仕様書が勝手にできあがるような仕組みにしよう。

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

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

134 :デフォルトの名無しさん:2001/08/23(木) 09:49
>>133
自分で客先に行って必要事項をまとめてくれる自律型仕様書きぼーん

135 :デフォルトの名無しさん:2001/08/23(木) 10:26
>>134
それが更に進歩すると自律型お客様+自動作成ソフトになって、
プログラマやSEがシツギョーン。

136 :デフォルトの名無しさん:2001/08/23(木) 16:59
マジな提案です。

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

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

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

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

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

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

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

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

137 :デフォルトの名無しさん:2001/08/23(木) 17:38
>>136
新しい関数を自動生成する方式でよかったら、
Schemeあたりすぐに実装できそうな気が。

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

...みたいな。

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

138 :デフォルトの名無しさん:2001/08/23(木) 17:42
>>136 Lisp/Scheme風にいうと
(define hoge (lambda (n) (...)))
(map hoge listm)
もしくは
(map (lambda (n) (...)) listm)

139 :138:2001/08/23(木) 17:46
137とかぶった上に
137が自分より建設的で高級な提案をしてるよ
Hazukasi〜Yo〜

140 :デフォルトの名無しさん:2001/08/23(木) 17:51
>>138
map系の関数は知ってまふが、暗黙にできるとこがミソなのですが。
ダメかな・・・。

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

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

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

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

141 :140:2001/08/23(木) 17:52
あ 137=140 です。

142 :140:2001/08/23(木) 17:54
>>141
> あ 137=140 です
間違い。 136 = 140。

143 :デフォルトの名無しさん:2001/08/23(木) 18:04
明示的に map で十分。

144 :140:2001/08/23(木) 18:13
>>143
うぐぅ(;_;)

145 :デフォルトの名無しさん:2001/08/23(木) 18:41
>>136
>これが可能であるためには、Java のような型の強い言語でなきゃダメだし、
>また配列だけでなくコレクションクラスを統一的に扱える必要があるかも。

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

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

146 :136:2001/08/23(木) 19:33
>>145
> ソースだけじゃなくバイナリレベルで)統一的に扱うためには、
> 型が強かったら却って不都合じゃないの?

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

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

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

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

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

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

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

147 :デフォルトの名無しさん:2001/08/23(木) 20:16
>>136
Adaなら引数の型が違えば別の関数として認識してくれるから
同じ名前で引数の異なる関数が複数作れるけど。

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

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

これじゃダメ?

148 :136:2001/08/23(木) 22:06
>>147
はい、強い型の言語はこういうことができますね。C++ でも可能です。
ただ今回の話は明示的にではなく暗黙にやってほしいということです。

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

list<int> ls;
hoge(ls);

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

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

hogehoge(Collection<Object> co)

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

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

だったから

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

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

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

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

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

149 :デフォルトの名無しさん:2001/08/24(金) 08:25
D言語はどうでしょうか?
http://slashdot.org/developers/01/08/15/234223.shtml

150 :デフォルトの名無しさん:01/09/02 05:54 ID:3bXnTTWA
VISIOでフローチャート書く

そのままコンパイル

(゚д゚)ウマー

151 :デフォルトの名無しさん:01/09/02 19:06 ID:o3BNP3Lw
>>150
> VISIOでフローチャート書く

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

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

153 :デフォルトの名無しさん:01/09/04 00:38 ID:FYWyf6W.
いささか些事ではあるけど
>>152
> 型有り、型無しのそれぞれの特徴を生かすため、宣言があれば型有り変数、無ければ
> 型無し変数ということにする。

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

154 :デフォルトの名無しさん:01/09/04 00:53 ID:taq6YMMs
>>153
スペルミスは、なにもコンパイル時にチェックする必要は無いじゃん。
スペルミスチェッカーでも別に付けとけば?

155 :デフォルトの名無しさん:01/09/04 01:00 ID:7wOQam5w
PL/I の理想と挫折、再び。

156 :デフォルトの名無しさん:01/09/04 01:04 ID:taq6YMMs
つーかschemeでいいじゃん

157 :デフォルトの名無しさん:01/09/04 01:45 ID:RaNfIHXg
>>153
そうだね。そうだとすると、型無しだと宣言する方がいいね。

158 :デフォルトの名無しさん:01/09/04 02:23 ID:ih5eONCo
やっぱり2ch言語は
goto文が「逝ってよし」だったり、
default文が「名無しさん」だったり、
return文が「あぽ〜ん」だったりするのだろうか。

159 :デフォルトの名無しさん:01/09/04 02:35 ID:JE/PAhhI
10: I ← 2
14: 数値←キー入力
15: もしも(数値 が1)ならば80へ逝ってよし
20: もしも(数値 MOD Iがゼロ)ならば
30:   数値=数値÷I
40:   表示(数値+スペース)
50: そうでなければ
60:   I=I+1
70: 15へ逝ってよし
80: 糸冬了

160 :153:01/09/04 03:56 ID:z5/49YHM
>>154
> スペルミスチェッカーでも別に付けとけば?

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

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

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

161 :デフォルトの名無しさん:01/09/04 04:39 ID:F8eDitgE
>>153
宣言と初期化を同時にするのはどうでしょう?

162 :153:01/09/04 05:45 ID:z5/49YHM
>>161
> 宣言と初期化を同時にするのはどうでしょう?

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

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

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

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

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

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

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

163 :153:01/09/04 05:46 ID:z5/49YHM
×意義なし
○異議なし

164 :153:01/09/04 05:49 ID:z5/49YHM
よく考えると、いきなり EOF の場合もあるから、lastChar = 0 は
ムダじゃないなぁ。例が悪かったゴメソ。

165 :デフォルトの名無しさん:01/09/04 22:48 ID:ddDwxAtA
これからはコーディングレス言語の時代だよ。
画面上で電子ブロックみたいな部品を配置するやつってあったよね?

166 :デフォルトの名無しさん:01/09/04 23:23 ID:OYi1KVOE
>>152

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

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

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

167 :デフォルトの名無しさん:01/09/05 00:32 ID:wY.x.P2I
>>165
> 画面上で電子ブロックみたいな部品を配置するやつってあったよね?

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

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

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

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

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

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

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

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

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

168 :デフォルトの名無しさん:01/09/05 00:46 ID:/gpTLwPE
>>166
Schemeも副作用ありの遅延評価だけど・・・

169 :デフォルトの名無しさん:01/09/05 02:57 ID:jFtajofc
>166
>それから、SQLもCORBAもライブラリじゃなくて言語レベルで組みこんじまえば完璧だね。
なおさらScheme(というかlisp)の思想の様な気がするけど?

170 :sage:01/09/05 14:12 ID:6PT9EWiQ
>>169
Common Lispの思想かなあ?

171 :デフォルトの名無しさん:01/09/05 19:59 ID:zoyp8Lbo
ていうか Lisp って特殊だよね。もともと S式以外に構文らしいものを
持ってないわけだから、機能を追加してもパーサに手を入れる必要が
ほとんどない。

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

172 :デフォルトの名無しさん:01/09/05 23:21 ID:.VljIIMQ
でもCommonLispにコンパイル時型チェックや継続や遅延評価などを仕様をいじらず
追加しようとしたって無理だよね。
後者二つはSchemeにあるけど、仕様としてはじめから組み込まれてるものだし。

173 :171:01/09/05 23:56 ID:zoyp8Lbo
いや、そりゃ処理系を全く書き換える必要もないって意味じゃなくて
syntax レベルでは Lisp には S式しかないってことなんで

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

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

42 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)