【Python】オフサイドルール 2桁【Haskell】

1 ：11/07/14 〜 最終レス ：11/11/27

オフサイドルール（字下げによってブロックを示す規則）について議論するスレです。
もちろんタイトルにないプログラミング言語のオフサイドルールの話も歓迎します。
http://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%95%E3%82%B5%E3%82%A4%E3%83%89%E3%83%AB%E3%83%BC%E3%83%AB
前スレ
Pythonに見られるインデントによる制御構造の是非
http://hibari.2ch.net/test/read.cgi/tech/1169473442/

2 ：

経験15年のOCaml ユーザーが Haskell を仕事で半年使ってみた
http://d.hatena.ne.jp/camlspotter/20101212/1292165692
>Offside rule は何もいいこと無い
>　百害あって、一利あるか、どうか。
>　インデントでプログラムの意味が変わる offside rule はいらないですよ。

3 ：

>　インデントでプログラムの意味が変わる offside rule はいらないですよ。
実際使ってみると気にならないレベルだとわかる
いらんと言う香具師は素人

4 ：

うざい中括弧が基本的にいらない言語だよね。<Python,Haskell
いいと思うよ。中括弧見てるとCやJavaの腐ったもんって感じがするもん。
後、オフサイドルール故に、可読性が〜とよくいわれるけど
そのとおりだと思うよ。一部アルゴリズムの本にPythonを採用してる動き
があるのはよく分かる。

5 ：

単に、気になる・ならないという個人の気分的なレベルの話だったの?
前スレではメリットとデメリットが具体的な形で挙ってたと思うけど

6 ：

最終的にはその具体的な(デ)メリットをどう判断するかということだから、じゃないの？

7 ：

スレタイから「制御構造の是非」取れちゃったからなぁ

8 ：

制御構造ってのは抽象のことであって、
オフサイドルールは具象だから、「是非」はともかく「制御構造の」は当たっていない。

9 ：

オフサイドルールが貧弱だと、横に長い文ができやすいのが気に入らない。
見辛いコードがすなわち悪い構造のコードだって言い切れるのなら、オフサイドルールにメリットがあると言えるんだけど、
(if文がネストしまくるのは悪いこと、とか)そうでもない場合もあって困る。
pythonのルールはまだいいかもしれんが、haskellのコードはそうでもない、ってのが印象。

10 ：

>>8
ブロックは逐次実行という制御構造です。

11 ：

インデントの深さ方向もだけど
一つのブロックが何行にも渉って延々と続くのも考え物
途中でインデントの深さが判らなくなってしまう
(特に印刷物でソースが複数ページにまたがる場合)

12 ：

>>10 ブロック（複文）は、文を順番に並べてまとめたものという抽象構文のレベルのものです。
それを、逐次実行する、というのは意味のレベルです。
それを、字下げで表現する、というのは具象構文のレベルです。
これらをごっちゃにするのは、HTTPとIPをごっちゃにするようなものです。

13 ：

逐次実行というsemanticsを表現するためのsyntaxがブロックなのです。
「syntaxとsemantics」という初歩も理解してないのですね。

14 ：

もともと行儀の悪い書き方をしてきた人や
スペースをタブにしてしまうエディタを使ってる人は
オフサイドルールがうっとおしいと思う
オフサイドルールがあるときれいに書こうという気になる

15 ：

ブロック構文だからといって逐次実行とはかぎらんわな。
並列実行の構文がブロック型をしてる言語だってある。
初歩を理解してないのはどちらですかな？

16 ：

>>6
・個人の感想
・事実の積み重ね
意味合いが全然違いますから

17 ：

>>14
残念ながら、全てを奇麗に書き下せる究極の言語はまだこの世に生まれてないんだ
汚れ仕事にも文句を言わずに付き合ってくれる言語じゃないと信頼関係は生まれないね

18 ：

GNUスタイルのインデントは嫌い

19 ：

制御構造の { と } が2桁ずれるんよな
while(expr)
  {
    statements;
  }
statements;

20 ：

>>16 それで何がしたいの？
客観的事実をもって徹底的にdisりたいの？
>>18-19
コーディングスタイルのスレは別になかったっけ？

21 ：

>>20
技術者なら常に事実を把握しておきたいだろ
disるとかdisられたとか、個人の感想なんかはどうでもいい話
そんな事に拘って事実が見えなくなったら、俺は引退するわ

22 ：

事実はそれぞれの文法にある通りでしょ
あとはエディタのサポートとかそういう細々した話
事実について議論することなど何もないと思うが

23 ：

その文法を種々のプログラムに適用した場合の効果については自明じゃないと思うけど、
議論する事が何も無いと思うなら議論しなくていいんだよ

24 ：

IDEに自動フォーマットさせたら、こんなルールいらない。

25 ：

原因と結果を取り違えるタイプの人はプログラム書くのには向いていない

26 ：

iDE前提では、魅力ない。

27 ：

>>9
むしろpythonのループには何かしらbegin-end的な物が欲しいとか思うんだよな。。。何か極端過ぎと言うか
(ループされる処理の塊がまとまってると言うより、ぶら下がって見えるのが)
haskellはループ無いからインデントに違和感無かった
有った方が良いとか、無かった方が良いかはどうでも良いけど

28 ：

いみふ

29 ：

やっぱいらんかったんやこのスレ...

30 ：

あげ

31 ：

スレタイがキャッチャーじゃないから食いつきが悪いね。
前のスレタイなら初心者でも理解できたし。

32 ：

プログラムVIP板

33 ：

キャッチャー？

34 ：

キャッチョー？

35 ：

ピッチャーだろ

36 ：

>>29
今は Henry Kroll III 氏の Anchor のようなものがあり、
どっちのスタイルにも変換できるからイラネだな。
しかしこういった議論が起きるということからブロック構造を構文の
一種として意識して記述させるというのは今となっては不自然なのかもしれないな。

37 ：

プログラミング言語の構造を、構文でなく記述するってどういうこと？
遅延評価や高階関数や継続を駆使して、制御構造をライブラリで表現できるように
（ifとかwhileとかを、文ではなくて全部関数に）するのが自然ってこと？

38 ：

桁を意識するのはFORTRANからの伝統。
パンチカードの正当な継承者。

39 ：

7カラム目に特別な記号を置いたりするのはむしろCOBOLだろ

40 ：

スレ違い
http://hibari.2ch.net/test/read.cgi/tech/1248937976/
巣に戻れ

41 ：

>>37
そこまでってないが言えば頭大丈夫？ってくらい単純な方法。
今は大人の地蔵でいえないが生きていればどこか日の目を見るかもね。

42 ：

できるだけ早く病院行け

43 ：

Python？Haskell？　どっちももガキの好きそうな優しい言語だな。
ナゼこのスレで Occam が話題にならんの？(悪いが過去スレは知らん)
An Introduction to the occam Language
・http://frmb.org/occtutor.html

44 ：

まあ、元々Pythonのオフサイドルールの是非を問うスレだったからな
今後色んな言語を追加していけばいいと思うぜ

45 ：

オフサイドルールについて何を話せばいいんだよｗ

46 ：

文句言ってる香具師は大抵Python使ってない
食わず嫌い
実際使ってみれば全然問題にならないレベル
かえってソースが綺麗になって嬉しいくらい

47 ：

IDE使えばどの言語も同じ。

48 ：

中括弧派だがオフサイドルールのいい点を取り込む仕様を考えた
A()
{
doSomething();
return A;
return B;
}
A(){
doSomething();
return A;
return B; }
下のように記法してなおかつ return; と } の間に目に見えない改行を挟む
これでvimのddで　return B; だけ消せる

49 ：

その代わりvimの%によるカッコの対応付けはくずれるけどねw

50 ：

え、なんで？

51 ：11/11/27

>>50
あ、俺の勘違いだ、ゴメソ