Re: PL/1, Origin of struct
toda@lbm.go.jp wrote:
> In article <bjn3l3$jhr$1@bluegill.lbm.go.jp> I write:
>
>>>> そもそも言語メカニズムというならCの祖先BCPLや親戚BLISSを調べる
>>>>必要はあるんじゃないでしょうか。
>>>
>>>ですよね。あと、algol 68も見ておきたいんだけど、
>>>教科書探しから始めねばならない状況です。
>>
>> M.Richards and C.Whitby-Strevens(和田英一訳)
>> BCPL言語とそのコンパイラ(共立出版1985)ISBN4-320-02245-9
>>が滋賀県立図書館にあったので、借りてきました。
>
> B言語についてはオンラインで見つけました(英語ですが)。
> Ken Thompson, Users' Reference to B,
> http://www.cs.bell-labs.com/who/dmr/kbman.html
> http://cm.bell-labs.com/cm/cs/who/dmr/kbman.html
> (同じ内容のようです)
>
> データ型が無いことを除けば、C言語にソックリですね。
> algol系の「“=”は比較、代入は“:=”」という
> 伝統(BCPLも継承している)に逆らって、
> 「“=”は代入、比較は“==”」としているのも同じです。
> 代入演算子が逆順(“+=”ではなく“=+”)とか、
> ビットごと論理と2値論理の区別が無いとかいったあたりは、
> 教科書類に「初期のC言語はこうだった」と書いてあるそのまんま。
>
> 注釈を「/* */」で表記することや、
> “;”を分離記号ではなく終端記号として用いることも、
> B言語経由でPL/IからC言語に継承されたようです。
>
> In article <qkpoexs3t6g.fsf@dash.tokyo.pfu.co.jp> kate@pfu.fujitsu.com writes:
>
>>>>(7)配列(ベクタ)を宣言すると、同名の単純変数も同時に確保され、
>>>>当該配列へのポインタで初期化される
>>>>わけのわからん無駄な仕様ですね。
>>>>当該配列へのポインタを値とする定数名とするのが素直なんですけど。
>>>
>>>定数オペランドアドレスにアクセスするアドレッシングモードがない
>>>計算機を想定していたのでは?
>
> だからって、「変数」としてアクセス可能にする必要は無いでしょう。
> 変数と同じメモリ領域に値を保持するとしても、「無名の変数」にして
> プログラムからはアクセスできなくする方が素直だと思います。
> 即値定数や文字列定数の値を、CPUの都合で、
> 変数と同じメモリ領域に保持するのと同じことです。
>
>
>>これは、
>>
>>>>データは言語レベルでは内部表現としてのみ意味があり、
>>>>その内部表現にどういう意味を持たせるかはプログラマ次第
>>>>という意味で「機械寄り」の「区別の無さ」です。
>>>
>>>要は word ですよね。
>>
>>こっちと関係があるのではないかと思います。
>>配列宣言でその配列へのポインタも用意しておくことで、配列というデー
>>タ型をコンパイラが覚えておく必要が無くなります。
>
> よく解りません……
>
> 配列は「データ型」ではありませんよね。
> コンパイラにとっては、
> 「宣言されただけの記憶域をシステムが確保する」というのが
> 配列というオブジェクトの本質であり
> (この「確保」がシステムにとって一番の負担ですよね)、
> それは、対応するポインタ変数を確保するかどうかに関係ありません。
>
> そして、いずれにしても配列名は
> 「確保された記憶域のアドレスという意味を有するword型のデータ」であり、
> 今問題になっているのは、
> それが「定数」なのか「変数」なのかという違いに過ぎません。
>
> ちなみに、B言語には、この妙な仕様は継承されていないようです。
> (B言語の処理系は、ネイティブコードを吐くコンパイラが記述できないような
> 貧弱な環境のために開発されている)
> やはり、必然性の無い仕様なのではないでしょうか?
>
> 戸田 孝@滋賀県立琵琶湖博物館
> toda@lbm.go.jp
Fnews-brouse 1.9(20180406) -- by Mizuno, MWE <mwe@ccsf.jp>
GnuPG Key ID = ECC8A735
GnuPG Key fingerprint = 9BE6 B9E9 55A5 A499 CD51 946E 9BDC 7870 ECC8 A735