43443


haskellの練習で数列の問題を解こうとして、(!!)を使いたいことがありました。そのとき、ふと、疑問に思ったのですが、なぜhaskellではリストのインデックスが0から始まる、と考えるのでしょうか？  
takeやdropなどを合わせて考えると、1から数えるとした方が、なんとなく、ですが良いような気がするのです。  
おそらく、意味があってのことなのだろうと思いますが、なぜなのでしょうか？


CC BY-SA 3.0
2018-04-15T07:35:36.103
43256
2018-04-20T16:29:18.483
7460
question
haskell
Haskellにおいて、リストのインデックスが0から始まる理由


Haskell にかかわらず多くのプログラミング言語ではリストや配列のインデックスは 0
から始める習慣があります。これには歴史的背景や、メモリアクセスに関する最適化のしやすさなどが理由として挙げられることが多いです。

また、私の知る限り、「Haskell では〇〇だから 0 から始めなければいけない」といった、Haskell
個別の理由はありません。単にデザインの問題だと思います。


CC BY-SA 3.0
2018-04-15T08:04:46.627
43259
2018-04-15T08:04:46.627
19110
43256
answer


配列のインデックスが１から始まる言語は、COBOL, PL/I, RPG, FORTRAN, BASIC くらいですかね。  
他はみんな０から始まる。


CC BY-SA 3.0
2018-04-15T08:39:40.963
43261
2018-04-15T09:02:43.730
2018-04-15T09:02:43.730
43256
answer


自然数を0はじまりで考える。つまり最初は0ということではないかと思います。  
加法演算の単位元0を含めておいたほうがいろいろ便利だろうという立場かな？

インデックスは最初の要素からのオフセットだと考えると0から始まるのは悪くない選択でしょう。


CC BY-SA 3.0
2018-04-20T00:39:08.660
43418
2018-04-20T00:39:08.660
24701
43256
answer


例えばCにおいてarrを配列だとすると、arr[5]といった配列へのインデックスアクセスは、ポインタ加算及びメモリアクセス*(arr+5)と等価だとみなされるため高速です。arrは配列のベースポインタ(つまり配列の始まりのアドレス)のことであり、+5というのはここではarrの要素の型のサイズ(例えばlongなら8bit)×5をarrに加算するといった意味論になります。0スタートだとここらへんの最適化処理が簡単になりますというのが極めて一般的な回答だと思われます。

しかしおそらくそれだけが理由でhaskellの言語設計者が0スタートをよしとしたのではないと思います。コンパイラ設計者が頑張れば実はインデクスが1スタートでも問題がないです。だってarr[5]を*(arr+4)と解釈させればいいのですし、例えばfortranも1でスタートしてますよね。  
(純粋関数型言語haskellの)設計者たちは必ず次のようなことを考えたはずです。  
「宣言的記述arr[5]が命令的にどう実行されるかは重要ではない。6番目の要素を指すべきか、5番目の要素を指すべきなのかが宣言的記述として重要だ。」  
そうした判断を踏まえたうえでゼロスタートのほうが好ましいと判断したのではないかとまず考えます。  
僕はゼロスタートが採用されているのはメモリアドレスなどのハードウェアが理由ではなくコンピュータサイエンスと親和性の高い数学の集合論に基づいた結果だと考えます。集合論において自然数はゼロから始まります。ラムダ計算におけるチャーチ数や集合論における自然数の定義を見て頂ければわかりますが、ゼロから始めないとマッピングが汚くなります。そのことを踏まえて上記のCの例をもう一度見てもらいたいのですが、宣言的記述arr[5]が命令的記述*(arr+4)にマッピングされるというのは集合のマッピングとしてやはり汚いと思います。宣言的か命令的か、そして綺麗汚いというのは所詮相対的なものですが、上記のような「勝手に引数がデクリメントされる」ようなマッピングを正とすると非常に実装がナーバスになると思いませんか？  
個人的所感では納得頂けないとは思うので、ダイクストラ先生の意見も引用いたします。  
<http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html>


CC BY-SA 3.0
2018-04-20T16:29:18.483
43443
2018-04-20T16:29:18.483
25980
43256
answer