$B9=B$BN$N%a%s%P$N5-210h$N=g(B

[to...@lbm.go.jp]

とりあえず、Newsgroups:に
fj.comp.lang.cobol
fj.comp.lang.fortran
fj.comp.lang.pascal
fj.comp.oldies
を加えますが、Followup-To:からはfortranとpascalを外しておきます。

In article <bic3a2$nsg$2...@newsserv.ics.es.osaka-u.ac.jp> sai...@ist.osaka-u.ac.jp writes:
>> そもそも、構造体の歴史的起源ってCOBOLのものだと思うんですが、
>> （それ以前が存在することを御存知の方は御教示ください）
>Cのstructは、PDP-11のアセンブラの　FRAME疑似命令が
>起源だと思いますが。
直接の起源をターゲット機のアセンブラに求めますか……
いくらＣ言語が「高級アセンブラ」だからって、
それだけが起源だと断定するのはどうでしょうね。
また、アセンブラにそういう疑似命令を準備したというのが、
過去の高級言語からの発想という可能性もありそうですし……

私の断片的な知識を、ざっとまとめてみました。

(1)algolには構造体に相当する概念は無い。
FORTRANのCOMMONブロックは、
バイナリレベルでは外部構造体（Ｃ言語のextern struct）と
同等に扱われることが多いと思われるが、発想は違いそう。
即ち、1950年代に開発された高級言語の「御三家」で、
構造体に相当する概念があるのはCOBOLだけである。

(2)しかし、COBOLでは「構造体（structure）」という用語は用いていない。
この用語が規格レベルで出てきたのは、PL/I（1964年）ではないかと
思われるが、確かな証拠は今のところ得られていない。

(3)Pascal（1968年）では構造体に相当するものを「record型」と呼んでいる。
この呼称は、COBOLの構造体がファイル入出力における「record」の概念と
密接に結びついているところから来ているのではないかとの推測が成り立つが、
あくまで推測に過ぎない。

ちなみに、Ｃ言語は1972年に開発されたことになっており、
前身を遡るとＢ言語（1970年）←BCPL（1967年）←CPL（1963年）となるようです。
（CPLの前身はalgolまで行き着いてしまう）

COBOLにおける構造体の概念がファイル入出力と密接に結びついている
ということは、前電でも
In article <bi73b2$u5m$1...@bluegill.lbm.go.jp> I write:
>COBOLの構造体は「ファイル入出力の単位」という性格を
>明確に主張する仕様になっています。
>そもそも、COBOLは「磁気テープ上のデータを読み込んで、加工して、
>別の磁気テープに書き出す」処理を行うという発想で設計されていて、
>変数は入出力デバイスにリンクしているのが「フツー」であり、
>そうではない「作業用一時変数」は継子扱いです。
と説明した通りですが、もう少し詳しく説明してみます。

COBOL以外のほとんどの高級言語のファイル入出力では、
例えば出力の場合には、プログラム中で記述された変数領域のデータを、
プログラムでは直接見えない「入出力バッファ」領域に複写して
（書式つき出力の場合には、書式に従った変換結果をバッファ領域に書込んで）、
その（直接見えない）データをデバイスに引き渡すという手順だと思います。

ところが、COBOLでは「入出力バッファ」の中に、
当該入出力デバイス専用の（プログラムから見える）変数を確保する
という発想になっています。
（実際には、デバイスとの間にワンクッション置く実装が多いと思われるが、
言語の習得に際しては、そのことを意識しない方が解りやすい）
書式つき出力にしても「出力バッファ内の変数」への
代入に際して書式に従った変換が行われるという発想です。
（つまりバッファ内の各変数の属性の１つとして“書式”がある）

そうすると、入出力単位である「レコード」は、
「内容は多種多様だが、組（前田さんのいう“tuple”）として
まとまっているデータ群」になりますから、
その中身は自ずから構造体の性格を有することになります。

そのため、COBOLでは他の構造体の要素ではない「一番上のレベルの」構造体と、
入出力単位である「レコード」が同義語になるんですね。
なお、「一番上のレベル」に限らない、中間レベルも含めた構造体のことは、
COBOLでは集団項目（group item）と呼んでいます。

FORTRANだと、バイナリ入出力にも「入出力並び」があって、
レコードは個々の入出力文の並びで「１回ごとに定義される」
「偶々その場に居合せたというだけの集団」という感覚ですが、
COBOLではそれが「恒常的な社会集団(??)」であることを要求しているわけです。

この点、PL/Iでは書式なしのREAD/WRITE（RECORD入出力）では
「並び」ではなく「１個の変数（＝構造体を想定）」を引数とするのに対して、
書式つきのGET/PUT（STREAM入出力）では引数は「並び」と使い分けられています。
Ｃ言語でもfread/fwriteで入出力されるデータは「１個の引数」なのに対して、
fscanf/fprintfでは「不定数の引数」になるというのは似たような発想ですね。
ただ、PL/IにしてもＣ言語にしても、
変数が言語仕様上は「当該デバイス専用」ではないというところが、
COBOLと異なります。

戸田 孝＠滋賀県立琵琶湖博物館
to...@lbm.go.jp

[Yasushi Shinjo]

新城＠筑波大学情報です。こんにちは。

Ｃ言語の「構造体」の考え方の元は、PL/1 だと思います。正確に
は、PL/Iという、PL/1 のサブセットで、Multics の記述に使われ
たもの。

Ｃ言語の /**/ のコメントも、PL/1 と同じです。

In article <bieihv$p5r$1...@bluegill.lbm.go.jp>

to...@lbm.go.jp writes:
> (2)しかし、COBOLでは「構造体（structure）」という用語は用いていない。
> この用語が規格レベルで出てきたのは、PL/I（1964年）ではないかと
> 思われるが、確かな証拠は今のところ得られていない。

PL/1 は、Fortran と Cobol を会わせて１つで記述しようというこ
とで作られた言語なので、C の構造体の元が Cobol というのは、
ある意味では正解なんでしょう。

Ｃを先に勉強してから PL/1 を見た時には、PL/1 は、かっこ悪い
感じがしました。構造体の定義で、ネストのレベルを現すのに数字
を書かないといけなかったと思います。

＼＼　新城　靖　（しんじょう　やすし）　＼＼
＼＼　筑波大学　電子・情報　　　　　　　＼＼

[to...@lbm.go.jp]

In article <YAS.03Au...@kirk.is.tsukuba.ac.jp> y...@is.tsukuba.ac.jp writes:
>Ｃ言語の「構造体」の考え方の元は、PL/1 だと思います。正確に
>は、PL/Iという、PL/1 のサブセットで、Multics の記述に使われ
>たもの。
>Ｃ言語の /**/ のコメントも、PL/1 と同じです。

>PL/1 は、Fortran と Cobol を会わせて１つで記述しようというこ
>とで作られた言語なので、C の構造体の元が Cobol というのは、
>ある意味では正解なんでしょう。

情報ありがとうございます。
ところで、Subject:には「PL/M」とあるのですが、
本文の方が書き誤りと考えて良いでしょうか？
（PL/IのサブセットのPL/Mというのは聞き覚えがあるので……）

>Ｃを先に勉強してから PL/1 を見た時には、PL/1 は、かっこ悪い
>感じがしました。構造体の定義で、ネストのレベルを現すのに数字
>を書かないといけなかったと思います。

この仕様は、COBOLそのまんまです。

戸田 孝＠滋賀県立琵琶湖博物館
to...@lbm.go.jp

[SAITOH akinori]

to...@lbm.go.jp wrote:
>>Cのstructは、PDP-11のアセンブラの　FRAME疑似命令が
>>起源だと思いますが。

> 直接の起源をターゲット機のアセンブラに求めますか……
> いくらＣ言語が「高級アセンブラ」だからって、
> それだけが起源だと断定するのはどうでしょうね。
> また、アセンブラにそういう疑似命令を準備したというのが、
> 過去の高級言語からの発想という可能性もありそうですし……

構造体(の概念)の起源がFRAMEだとはいってません。あくまでもCの
structの話です。
他の言語に構造体があったからCにもstruct機能をつけようと
発想したのではなく、アセンブラでFRAME機能を使っていたのを
容易に移行できるようにstructを導入したのではないでしょう
かね。

齊藤明紀　sai...@ist.osaka-u.ac.jp

[koun...@mbh.nifty.com]

鴻池です。

<to...@lbm.go.jp> wrote in message news:bif0l6$u7v$1...@bluegill.lbm.go.jp...

> In article <YAS.03Au...@kirk.is.tsukuba.ac.jp> y...@is.tsukuba.ac.jp
writes:
> >Ｃ言語の「構造体」の考え方の元は、PL/1 だと思います。正確に
> >は、PL/Iという、PL/1 のサブセットで、Multics の記述に使われ
> >たもの。
>

> ところで、Subject:には「PL/M」とあるのですが、
> 本文の方が書き誤りと考えて良いでしょうか？
> （PL/IのサブセットのPL/Mというのは聞き覚えがあるので……）

PL/1とPL/Iは同じではないのでしょうか。ちょっと探してみましたが，PL/Iの上位の
言語を見つけれませんでした。PL/IのサブセットでEPLというのは，見つかりました
が。

ところで，「構造体」の考え方の元がPL/Iというのは，その通りかも知れませんが。
ところで

The Development of the C Language　

Dennis M. Ritchie
Bell Labs/Lucent Technologies
Murray Hill, NJ 07974 USA
(http://www.cs.bell-labs.com/who/dmr/chist.html)

に以下のような記述がありました。
中略
Embryonic C
中略

These semantics represented an easy transition from B, and I experimented
with them for some months. Problems became evident when　I tried to extend
the type notation, especially to add structured (record) types. Structures,
it seemed, should map in an intuitive way onto memory in the machine, but in
a structure containing an array, there was no good place to stash the
pointer containing the base of the array, nor any　convenient way to arrange
that it be initialized.

リッチーは，構造体の実装にかなり苦労したようですが，その並びについては直感的
にメモリに割り付けるべきと考えていたようです。（直感的とは，並び順に素直に割
り付けるという意味でしょうか。）

中略

また，Ｃにおける型のデザイン（構造体を含め）については，

The scheme of type composition adopted by C owes considerable debt to Algol
68, although it did not, perhaps, emerge in a form that Algol's adherents
would approve of. The central notion I captured from Algol was a type
structure based on atomic types (including structures), composed into
arrays, pointers (references), and functions (procedures). Algol 68's
concept of unions and casts also had an influence that appeared later.

Algol 68に負うところが多いと言っているようです。

--
******************************
keizi kounoike
******************************

[Akihito Nakamura]

Chunです。

> PL/1とPL/Iは同じではないのでしょうか。ちょっと探してみましたが，PL/Iの上位の
> 言語を見つけれませんでした。PL/IのサブセットでEPLというのは，見つかりました
> が。

http://www.net.intap.or.jp/oiia/cont1/p0302.html{0recid=10112.html
によると

　　PL/I(初期にはPL/1と表記されていたが、現在はPL/Iが正しい)

そうです。

--
--
Akihito Nakamura( Chun )

[Yasushi Shinjo]

新城＠筑波大学情報です。こんにちは。

In article <bif0l6$u7v$1...@bluegill.lbm.go.jp>

to...@lbm.go.jp writes:
> ところで、Subject:には「PL/M」とあるのですが、
> 本文の方が書き誤りと考えて良いでしょうか？

すみません。間違えました。Multics だから M かなあと、
Subject: を書く時に思っていたのですが、本文書く時には、PL/1
でいいかと思って。

http://www.multicians.org/pl1-raf.html
------------------------------------------------------------
The language

The Multics PL/1 language is the language defined by the IBM
"PL/1 Language Specifications" dated March 1968. At the time
this paper was written most language features were
implemented by the compiler but the run time library did not
include support for input and output, as well as several
lesser features. Since the multi-tasking primitives provided
by the Multics operating system were not well suited to PL/1
tasking, PL/1 tasking was not implemented. Inter-process
communication (Multics tasking) may be performed through
calls to operating system facilities.
------------------------------------------------------------

> >Ｃを先に勉強してから PL/1 を見た時には、PL/1 は、かっこ悪い
> >感じがしました。構造体の定義で、ネストのレベルを現すのに数字
> >を書かないといけなかったと思います。
> この仕様は、COBOLそのまんまです。

そうでしたか。Cobol は、書いたことがないので。

http://www.users.bigpond.com/robin_v/c2pli.htm より構造体の
宣言の仕方の対比があったので抜き出しておきます。

C言語:
struct S {
int p;
float q;
};

PL/1:
DECLARE 1 S,
3 p FIXED BINARY,
3 q FLOAT DECIMAL;

C言語(ビットフィールド)
struct T {
unsigned int u : 1;
unsigned int v : 2;
unsigned int w : 0;
};
Note that a zero field is filled out to a byte boundary as shown.

PL/1:
DECLARE 1 T,
3 u BIT (1) UNALIGNED,
3 v BIT (2) UNALIGNED,
3 w BIT (5) UNALIGNED;

過去の話もいいんですが、未来の話ももっとしたいですね。
現在のＣの規格が、未来永劫変るわけでもないし。

[MAEDA Atusi]

<koun...@mbh.nifty.com> writes:

> リッチーは，構造体の実装にかなり苦労したようですが，その並びについては直感的
> にメモリに割り付けるべきと考えていたようです。（直感的とは，並び順に素直に割
> り付けるという意味でしょうか。）

このすぐ下のディレクトリエントリをファイルから読む例で，
I wanted the structure not merely to characterize an abstract object
but also to describe a collection of bits that might be read from a directory.
というところが興味深いですね．やっぱり，単なる抽象的なタプルの表現でな
く，メモリ上，ファイル上のビットパターンをそのまま記述できるものにした
かったんですね．

前田敦司

[to...@lbm.go.jp]

In article <YAS.03Au...@kirk.is.tsukuba.ac.jp> y...@is.tsukuba.ac.jp writes:
>> ところで、Subject:には「PL/M」とあるのですが、
>> 本文の方が書き誤りと考えて良いでしょうか？
>すみません。間違えました。Multics だから M かなあと、
>Subject: を書く時に思っていたのですが、本文書く時には、PL/1
>でいいかと思って。

とりあえず、ざっと調べてみたら、
PL/MというのはCP/Mの記述言語で、Multicsとは関係無いようです。
http://contest.thinkquest.gr.jp/tqj1999/20204/bbs/f/freetalk/10/

In article <bihokq$o3q$1...@nn-tk102.ocn.ad.jp> ch...@bekkoame.ne.jp writes:
>> PL/1とPL/Iは同じではないのでしょうか。ちょっと探してみましたが，PL/Iの上位の
>> 言語を見つけれませんでした。PL/IのサブセットでEPLというのは，見つかりました
>> が。
>http://www.net.intap.or.jp/oiia/cont1/p0302.html{0recid=10112.html
>によると
>　　PL/I(初期にはPL/1と表記されていたが、現在はPL/Iが正しい)
>そうです。

でも「I」を「one」と読むんですよね。
「IBMのI」だという話もあるんですが、
読み方からすると「ローマ数字の壱」なのかなあ？
「IBM as No.1」ってこと？

In article <bihqr1$1ga$1...@dnknews.denken.or.jp> take...@criepi.denken.or.jp writes:
> >PL/1 は、Fortran と Cobol を会わせて１つで記述しようというこ
> >とで作られた言語なので、C の構造体の元が Cobol というのは、
> >ある意味では正解なんでしょう。

>PL/IはFORTRANとCOBOLとALGOLを一つにしたとどこかで聞いたような。
>出所はよく憶えていない。
文を行単位ではなく「;」で区切るという発想は、間違い無くalgol起源ですね。
ただ、algolの「;」が分離記号（delimiter）なのを、
PL/Iでは終端記号（terminator）に変えちゃった。
ついでに、algolでは「文という単位から超越した記号」だった
「begin」や「end」などを、FORTRAN的な発想の「制御文」に変えちゃいました。
「BEGIN;」「END;」と、「;」を付けて、それで１つの「文」なんですね。
これは、行という単位に文法上の意味があるFORTRANやCOBOLとの
親和性を求めた結果なんだと思います。

＃PL/Iの「BEGIN;」はインラインの「手続き」とも言えるような強い区切りなので、
＃algolの「begin」は「DO;」に相当すると考える方が正確かもしれません。

「;」が終端記号であるという特徴はＣ言語にも受け継がれていますね。
実際、Pascalを勉強しているときにイライラしたことなんですが、
「プログラムの入れ子構造を段下げで表現」したりするなど、
２次元的な広がりの中でプログラムを理解して読み書きしようとすると、
「;」がalgol式に分離記号であるという定義とは相容れないのです。
分離記号の「;」は、あくまでプログラムを１次元的に理解することを
前提にした流儀だと言え、２次元的にプログラムを書く現実には
そぐわないものだと思っています。
この点、Ｃ言語はPL/Iの特徴を良い具合に受け継いだと言えると思います。

戸田 孝＠滋賀県立琵琶湖博物館
to...@lbm.go.jp

[Shinji KONO]

河野真治 @ 琉球大学情報工学です。

In article <bii43j$2m4$1...@bluegill.lbm.go.jp>, to...@lbm.go.jp writes
> PL/MというのはCP/Mの記述言語で、Multicsとは関係無いようです。
> http://contest.thinkquest.gr.jp/tqj1999/20204/bbs/f/freetalk/10/

PL/M はインテルのマイクロプロセッサ用の言語です。

CP/M 80がPL/Mでかかれていたってのは僕は信じられないです。
CP/M は、たぶん、アセンブラで書かれていたんだろうと思う。
CP/M 86 とか 68k は違うかも知れませんが。

一回だけ使ったことあるんだけど、むごい言語だと思った。
再帰がだめとかつまんない制約があったような気がするし。

> 読み方からすると「ローマ数字の壱」なのかなあ？
> 「IBM as No.1」ってこと？

Programming Language 1 ですよね。1 つですませたいっていう
意味だったかも。PL だけでは少ないと思ったんだろうな。

> ただ、algolの「;」が分離記号（delimiter）なのを、
> PL/Iでは終端記号（terminator）に変えちゃった。

declare を de とか書くのが普通になった時点で終ったんじゃない
かと思います。

> 「;」が終端記号であるという特徴はＣ言語にも受け継がれていますね。
> 実際、Pascalを勉強しているときにイライラしたことなんですが、
> 「プログラムの入れ子構造を段下げで表現」したりするなど、
> ２次元的な広がりの中でプログラムを理解して読み書きしようとすると、
> 「;」がalgol式に分離記号であるという定義とは相容れないのです。

C の実用的ですよね。

---
Shinji KONO @ Information Engineering, University of the Ryukyus,
PRESTO, Japan Science and Technology Corporation
河野真治 @ 琉球大学工学部情報工学科,
科学技術振興事業団さきがけ研究21(機能と構成)

[OOTANI TAKASHI]

大谷と申します。

ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> In article <bii43j$2m4$1...@bluegill.lbm.go.jp>, to...@lbm.go.jp writes
>> PL/MというのはCP/Mの記述言語で、Multicsとは関係無いようです。
>> http://contest.thinkquest.gr.jp/tqj1999/20204/bbs/f/freetalk/10/
>
> PL/M はインテルのマイクロプロセッサ用の言語です。
>
> CP/M 80がPL/Mでかかれていたってのは僕は信じられないです。
> CP/M は、たぶん、アセンブラで書かれていたんだろうと思う。

CP/Mの本体であるBDOSは読んだ限り明らかにアセンブラで書かれたコードです。
コマンドプロセッサのCCPもアセンブラ。
BIOSのサンプルもアセンブラ提供。

トランジェントコマンド(外部コマンド)のいくつかがPL/Mで書かれていたようです。
SUBMITともうひとつ何か(STATだったか)を読みましたが、レジスタが特徴的な
使われ方をしており、何らかのコンパイラ言語(おそらくPL/M)で書かれていることが
読み取れます。
XSUBは外部コマンドですが、常駐するためかアセンブラで書かれてました。

PL/Mとは別に、CP/M用のPL/Iコンパイラはありましたよ。レベルFだかGだかの
サブセットということでしたが。

--
oo

[to...@lbm.go.jp]

細かい話ですが……

In article <bii43j$2m4$1...@bluegill.lbm.go.jp> I write:
>>PL/IはFORTRANとCOBOLとALGOLを一つにしたとどこかで聞いたような。
>>出所はよく憶えていない。
>文を行単位ではなく「;」で区切るという発想は、間違い無くalgol起源ですね。
>ただ、algolの「;」が分離記号（delimiter）なのを、
>PL/Iでは終端記号（terminator）に変えちゃった。

>「;」が終端記号であるという特徴はＣ言語にも受け継がれていますね。

「分離記号」を「delimiter」と訳しましたが、
「separator」の方が良さそうですね。
Pascalの開発者であるWirthがJensenと1974年に共著で出した教科書
（原田賢一訳：培風館1981）では、
「;」は「statement separator」であるとして、
「PL/Iのようなstatement terminatorではない」とまで念押ししてあります。

戸田 孝＠滋賀県立琵琶湖博物館
to...@lbm.go.jp

[to...@lbm.go.jp]

とりあえず、
http://www.lbm.go.jp/toda/comp/struct.html
のような形にまとめてみました。
御批評いただければ幸いです。

戸田 孝＠滋賀県立琵琶湖博物館
to...@lbm.go.jp

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

to...@lbm.go.jpさんは書きました。
> とりあえず、
> http://www.lbm.go.jp/toda/comp/struct.html
> のような形にまとめてみました。

面白いですがFRAME疑似命令が起源というのはちょっと抵抗あるなあ。
ちなみに他のアセンブラでもメモリは割り当てずにオフセット振るだけ
の疑似命令はありましたよ。360系とかにも。どっちかというと、当時
アセンブリ言語コードで普通に使われていた「インデクス+オフセット」
みたいなアドレシングにそのまま対応づけられるような言語メカニズム
としてとか…

そもそも言語メカニズムというならCの祖先BCPLや親戚BLISSを調べる
必要はあるんじゃないでしょうか。

といいつつ調べていない私。 久野

[to...@lbm.go.jp]

戸田＠終夜観測の立会いで泊り込み　です。

In article <binp21$1...@utogw.gssm.otsuka.tsukuba.ac.jp> ku...@gssm.otsuka.tsukuba.ac.jp writes:
>> とりあえず、
>> http://www.lbm.go.jp/toda/comp/struct.html
>> のような形にまとめてみました。
> 面白いですがFRAME疑似命令が起源というのはちょっと抵抗あるなあ。
>ちなみに他のアセンブラでもメモリは割り当てずにオフセット振るだけ
>の疑似命令はありましたよ。360系とかにも。

なるほど。
とりあえず、断定を避ける表現に改めてみました。
他にも、自分で読み直してみて気になった部分をざっといじってあります。

> そもそも言語メカニズムというならCの祖先BCPLや親戚BLISSを調べる
>必要はあるんじゃないでしょうか。
ですよね。あと、algol 68も見ておきたいんだけど、
教科書探しから始めねばならない状況です。

ま、そのうち何とかして、きちんと勉強する機会を作って、
それに基づいて自分の責任で改訂することを目指しますが、
既に御存知の方から御指摘をいただければ、
とりあえず当面の改訂はできるので、よろしくお願いします。

＃印刷物と違って、際限無く改訂できるし^_^;

戸田 孝＠滋賀県立琵琶湖博物館
to...@lbm.go.jp

[to...@lbm.go.jp]

In article <binuft$49p$1...@bluegill.lbm.go.jp> to...@lbm.go.jp writes:
>> そもそも言語メカニズムというならCの祖先BCPLや親戚BLISSを調べる
>>必要はあるんじゃないでしょうか。
>ですよね。あと、algol 68も見ておきたいんだけど、
>教科書探しから始めねばならない状況です。

ということで、とりあえずWebで少しは判らないかと
いろいろ探してたら、
http://www.page.sannet.ne.jp/mnagai/msj/pgm_lang.htm
なんていうページが出てきました。
まあ、わりとよくできてるかな。

Pascalのところに、「Algol 60はその妹」とあるんですが、
「Algol 68は」の間違いじゃなかろうか。

戸田 孝＠滋賀県立琵琶湖博物館
to...@lbm.go.jp

[Akihito Nakamura]

<to...@lbm.go.jp> wrote in message news:bin6uf$s2l$1...@bluegill.lbm.go.jp...
> とりあえず、
> http://www.lbm.go.jp/toda/comp/struct.html
> のような形にまとめてみました。

「全く字下げが無くてもプログラムとしては等価です」とあるのですが、COBOLもそうでしたっけ？
確か、字下げが正しくないとコンパイル時にエラーが返ってきたような覚えが…。

[Tomomi Kashiwagi]

"Akihito Nakamura" <ch...@bekkoame.ne.jp> wrote in message
news:bj0r9t$664$1...@nn-tk106.ocn.ad.jp...

>
> <to...@lbm.go.jp> wrote in message news:bin6uf$s2l$1...@bluegill.lbm.go.jp...
> > とりあえず、
> > http://www.lbm.go.jp/toda/comp/struct.html
> > のような形にまとめてみました。
>
> 「全く字下げが無くてもプログラムとしては等価です」とあるのですが、COBOLも
そうでしたっけ？
> 確か、字下げが正しくないとコンパイル時にエラーが返ってきたような覚えが…。

A領域とB領域に制限がありますが、
一般的な字下げはチェック対象ではありません。

--
かしわぎともみ kash...@cup.com

[OOTANI TAKASHI]

"Akihito Nakamura" <ch...@bekkoame.ne.jp> writes:
> <to...@lbm.go.jp> wrote in message news:bin6uf$s2l$1...@bluegill.lbm.go.jp...
>> とりあえず、
>> http://www.lbm.go.jp/toda/comp/struct.html
>> のような形にまとめてみました。
>
> 「全く字下げが無くてもプログラムとしては等価です」とあるのですが、COBOLもそうでしたっけ？
> 確か、字下げが正しくないとコンパイル時にエラーが返ってきたような覚えが…。

そういった意味では、IBMメインフレームのPL/I(現用のPL/Iってメインフレーム
だけでしょうね)では、プログラムは2カラム目から72カラム目の間に書きます。
1カラム目は無視されます。(コンパイルオプションで変更できますが)

何故標準で1カラム目を無視するのか理由はわかりませんが、コメントの開始記号と
JCLのオンヒアドキュメントの終端記号がどちらも /* なのが関係しているのかも。

unix風に書くとこんな感じです：

pli <<'/*'
sample:proc options(main);
/* nanchara kanchara */
end sample;
/*

--
oo

[OOTANI TAKASHI]

大谷と申します。

to...@lbm.go.jp writes:
> In article <binuft$49p$1...@bluegill.lbm.go.jp> to...@lbm.go.jp writes:
>>> そもそも言語メカニズムというならCの祖先BCPLや親戚BLISSを調べる
>>>必要はあるんじゃないでしょうか。
>>ですよね。あと、algol 68も見ておきたいんだけど、
>>教科書探しから始めねばならない状況です。
> ということで、とりあえずWebで少しは判らないかと
> いろいろ探してたら、

algol68 struct union esac でググって、
http://www.cs.virginia.edu/~evans/cs655-S00/Spring-1999/Slides/05a68_pasc.pdf
や http://page.inf.fu-berlin.de/~wolff/Algol68-OCCL.html
というのを見つけました。
20年ほど前に解説書を1冊読んだのですが、これを見て少し思い出してきました。

戸田さんのサンプルをalgol68で書くと、

STRUCT (
INT maindata,
STRUCT (
INT subdata,
[0:3] CHAR subtext
) subsets,
[0:79] CHAR maintext
) datasets;

でしょうか。一番 C と似てますね。(algol68 のプログラムの記述には2種類の文字が
必要なのでとりあえずキーワードや型名を大文字にしました)

union もありますが、これは C とずいぶん違う。C ではどの型のデータが入っている
かはプログラマが管理しますが、algol68 では処理系が管理します。

宣言：
UNION (INT,REAL) foo;

代入：
foo := 1.5;
foo := 123;

参照：
CASE foo IN
(INT i): print(("integer=",i)),
(REAL f): print(("real=",f))
ESAC

代入した型と違う型で参照しようにも方法が無い。i の有効範囲は , までなので
(REAL f)の後の式では使えません。f も逆に同じ。
print手続きの引数も任意の型のunionです。上記例では、STRUCT(STRING,INT)型や
STRUCT(STRING,REAL)型の表記です。

ちなみに ; は区切りでも終端でもなく演算子です。C の , 演算子と同意。
処理系をさわったことが無いだけに憧れの言語ですね。
ふた昔前の記憶で書いているので間違ってたらごめんなさい。
--
oo

[MAEDA Atusi]

to...@lbm.go.jp writes:

> ということで、とりあえずWebで少しは判らないかと
> いろいろ探してたら、
> http://www.page.sannet.ne.jp/mnagai/msj/pgm_lang.htm
> なんていうページが出てきました。
> まあ、わりとよくできてるかな。

politically incorrectではありますが．
# 実際，読んであまり気分が良くないです．

> Pascalのところに、「Algol 60はその妹」とあるんですが、
> 「Algol 68は」の間違いじゃなかろうか。

姉も妹もsisterだけど，年齢から言えばAlgol 60が姉でしょうね．

OOTANI TAKASHI <tks...@anet.ne.jp> writes:

> algol68 struct union esac でググって、
> http://www.cs.virginia.edu/~evans/cs655-S00/Spring-1999/Slides/05a68_pasc.pdf
> や http://page.inf.fu-berlin.de/~wolff/Algol68-OCCL.html
> というのを見つけました。

http://dmoz.org/Computers/Programming/Languages/Algol_68/
というページがありました． Revised Reportもここからたどって読めます．
(恐ろしく読みにくいが…)

> union もありますが、これは C とずいぶん違う。C ではどの型のデータが入っている
> かはプログラマが管理しますが、algol68 では処理系が管理します。

Pascalの場合は「可変レコード」ですね(たぶん，unionという予約語を1つ
ケチった?)． Algol68との大きな違いは，

・どの型のデータが入っているかを表す「タグ」を陽に書く．
type
nodetype = (interim, leaf);
node = record
case tag: nodetype of
interim: (left, right: ^node);
leaf: (value: integer);
end

・ところが，タグを省略することも出来るのだそうです(型システムの抜け穴)．
type
node = record
case boolean of
false: (left, right: ^node);
true: (value: integer);
end

こっち(タグなしの可変レコード)は，Cのunionと機能的に同等です．

> 処理系をさわったことが無いだけに憧れの言語ですね。

上のページには，処理系もいくつか載っています．

前田敦司

[to...@lbm.go.jp]

In article <m3znhmwq...@maedapc.cc.tsukuba.ac.jp> ma...@cc.tsukuba.ac.jp writes:
>> http://www.page.sannet.ne.jp/mnagai/msj/pgm_lang.htm
>> なんていうページが出てきました。

>politically incorrectではありますが．
># 実際，読んであまり気分が良くないです．

まあ、そのことはさておくとして^_^;

>> Pascalのところに、「Algol 60はその妹」とあるんですが、
>> 「Algol 68は」の間違いじゃなかろうか。
>姉も妹もsisterだけど，年齢から言えばAlgol 60が姉でしょうね．

というか、
系譜的に言えば、PascalとAlgol 68が姉妹で、
共にAlgol 60の娘とするのが妥当なんじゃないか、
ということなんですけど。

＃この発想で行くと、Algol 60は凄い「子沢山」になってしまう……

戸田 孝＠滋賀県立琵琶湖博物館
to...@lbm.go.jp

[to...@lbm.go.jp]

In article <u7k4rg...@anet.ne.jp> tks...@anet.ne.jp writes:
>>>> そもそも言語メカニズムというならCの祖先BCPLや親戚BLISSを調べる
>>>>必要はあるんじゃないでしょうか。
>>>ですよね。あと、algol 68も見ておきたいんだけど、
>>>教科書探しから始めねばならない状況です。

>algol68 struct union esac でググって、
>http://www.cs.virginia.edu/~evans/cs655-S00/Spring-1999/Slides/05a68_pasc.pdf
>や http://page.inf.fu-berlin.de/~wolff/Algol68-OCCL.html
>というのを見つけました。
>20年ほど前に解説書を1冊読んだのですが、これを見て少し思い出してきました。

情報ありがとうございます。

プログラムが書けるには程遠い状況ですが、
何となくalgol 68の雰囲気が解ってきたので、
http://www.lbm.go.jp/toda/comp/struct.html
を改訂してみました。
「COBOLからPL/Iへ」の部分は、状況証拠がかなり明確なんですが、
「Ｃ言語への影響」になってくると、「どっちの影響が強い」のか
明確で無くなってきますね。ちょっと歯切れの悪い書き方になってしまいました。

>ちなみに ; は区切りでも終端でもなく演算子です。C の , 演算子と同意。

algol系の「式と文を区別しない」発想の延長ですね。
Pascalはこの発想を捨てているので、
FORTRAN→Basic→PL/I→COBOL→Pascal→algol→Cという順で
学習してきた身としては、
algolのところでカルチャーショックを受けました^_^;

戸田 孝＠滋賀県立琵琶湖博物館
to...@lbm.go.jp

[OOTANI TAKASHI]

大谷です。

to...@lbm.go.jp writes:
> In article <u7k4rg...@anet.ne.jp> tks...@anet.ne.jp writes:
> 「Ｃ言語への影響」になってくると、「どっちの影響が強い」のか
> 明確で無くなってきますね。ちょっと歯切れの悪い書き方になってしまいました。

ちょっとそれますが、
Cと深い関係を持っているunixのもうひとつの主要言語である Bourne shell には
alogl68の影響が大きく見られます。if/then/elif/else/fi、case/in/esac は同一。
for/while/do/od はodがdoneにかわっただけ。(odコマンドが先にあったからか？)
キーワード名の一致だけでなく、Bourne shell で、
while read a,b
test a -gt 0
do foo bar $a $b
done < file
のように条件部分に複数の文/式をかけることも同じですし、
すべてのコマンド実行が別の面から見ると条件式であるのも式言語を思わせます。
program |
case "$opt" in
-format) pr ;;
*) cat ;;
esac | lpr
のように構造文がパイプの中で使えるのもこれらがalgol68では値を持つことと
似ているような気がします。

> http://www.lbm.go.jp/toda/comp/struct.html
> を改訂してみました。

そこから引用：
>COBOLの名前空間は全体で１つであり、メンバー変数の名前を個々の構造体ごとに
>変えねばならない。そして、構造体変数の代入は常に並び順照合である。

これは間違ってます。

>PL/Iでは、異なる構造体に同一名のメンバーが属することを許容し
>（むしろ同一構造の構造体には同一メンバ名を用いることを推奨し）、
>代入に際して名前で照合する「BY NAME」指定を導入した。

と書いてあるPL/Iと同じです。同じ名前の要素の参照は、「要素名 OF 親の名」
で参照します。要素名がプログラム中でユニークなら「OF 親の名」は省略可。
名前で照合して代入や計算するのは CORRESPONDING 。

>ちなみに、COBOLで構造の異なる構造体変数へ代入する場合は、一旦バイト列に
>分解して頭から変数に切り直すという恐ろしい仕様（ファイル入出力のバッファ
>という発想からすれば自然か？）になっている。

これはちょっと意味がわかりません。構造の異なる構造体変数への代入は
ごく普通に親の名前を使って MOVE すればできるのでは？

COBOL,PL/Iのリファレンスは、http://www.jbooksrv.yamato.jp.ibm.com/ がいいです。

--
oo

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

tks...@anet.ne.jpさん:

> Cと深い関係を持っているunixのもうひとつの主要言語である Bourne shell には
> alogl68の影響が大きく見られます。if/then/elif/else/fi、case/in/esac は同一。
> for/while/do/od はodがdoneにかわっただけ。(odコマンドが先にあったからか？)

なるほどね。ただBourne shellはUnix V7からだからCよりはかな～り後
の言語という印象です。V6までのshellは全然言語っぽくない。

BCPLはもうおぼえている人がいないのかな… 久野

[to...@lbm.go.jp]

fj.comp.lang.cobolへ振ります。

In article <uu17rw...@anet.ne.jp> tks...@anet.ne.jp writes:
>> http://www.lbm.go.jp/toda/comp/struct.html
>> を改訂してみました。
>そこから引用：
>>COBOLの名前空間は全体で１つであり、メンバー変数の名前を個々の構造体ごとに
>>変えねばならない。そして、構造体変数の代入は常に並び順照合である。
>これは間違ってます。

情報ありがとうございます。

ただ、私の知り得る情報を総合した限りでは、
「間違っている」のではなく「情報が古い」のではないかと思うのですが、
如何でしょうか？

実は私のCOBOLに関する知識は、（恐ろしいことに）1982年で停まっておりまして、
従って、「第３次規格」（ANSI 1985, ISO 1985, JIS 1988）以前なのです。
使っていた教科書にも、
「構造化プログラミングを導入する改訂の規格化が進められている」と
コラムの中で触れられていて、
手続き部の書き方に関する簡単な例が挙げられているだけで、
詳細な内容はありません。

>>PL/Iでは、異なる構造体に同一名のメンバーが属することを許容し
>>（むしろ同一構造の構造体には同一メンバ名を用いることを推奨し）、
>>代入に際して名前で照合する「BY NAME」指定を導入した。
>と書いてあるPL/Iと同じです。同じ名前の要素の参照は、「要素名 OF 親の名」
>で参照します。要素名がプログラム中でユニークなら「OF 親の名」は省略可。
>名前で照合して代入や計算するのは CORRESPONDING 。

というのも、発想的にはalgol系の世界から持ってきた
（直接にはPL/Iから逆輸入した？）と考えられる内容なので、
第３次規格の際に導入されたのではないかとニラんでいるのですが、
裏付ける情報が全く得られていません。

どこかに、第３次規格の際の改定内容の詳細を
簡潔にまとめたテキストって無いでしょうか？

>>ちなみに、COBOLで構造の異なる構造体変数へ代入する場合は、一旦バイト列に
>>分解して頭から変数に切り直すという恐ろしい仕様（ファイル入出力のバッファ
>>という発想からすれば自然か？）になっている。
>これはちょっと意味がわかりません。構造の異なる構造体変数への代入は
>ごく普通に親の名前を使って MOVE すればできるのでは？

「分解」というより「展開」と表現した方が良かったかな？
例えば、
01 ORGNSTRC.
10 ORGNTEXT1 PIC X(4).
10 ORGNTEXT2 PIC X(6).
と
01 DESTSTRC.
10 DESTTEXT1 PIC X(6).
10 DESTTEXT2 PIC X(4).
があって、
ORGNTEXT1の内容が「1234」、ORGNTEXT2の内容が「ABCDEF」だったときに
MOVE ORGNSTRC TO DESTSTRC.
とすると、
DESTTEXT1の内容は「1234AB」、DESTTEXT2の内容は「CDEF」になる
（つまり、メンバ変数間の区切りが無視される）ということです。

戸田 孝＠滋賀県立琵琶湖博物館
to...@lbm.go.jp

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

to...@lbm.go.jpさん:
> 実は私のCOBOLに関する知識は、（恐ろしいことに）1982年で停まっ
> ておりまして、従って、「第３次規格」（ANSI 1985, ISO 1985, JIS
> 1988）以前なのです。

うーん、move corresponding(構造体コピーで同名のものを対応づけ
る)って1982にはなかったでしたっけ?

今手元に参考書がない… 久野

[OOTANI TAKASHI]

to...@lbm.go.jp writes:
>>>COBOLの名前空間は全体で１つであり、メンバー変数の名前を個々の構造体ごとに
>>>変えねばならない。そして、構造体変数の代入は常に並び順照合である。
>>これは間違ってます。
> 情報ありがとうございます。
>
> ただ、私の知り得る情報を総合した限りでは、
> 「間違っている」のではなく「情報が古い」のではないかと思うのですが、
> 如何でしょうか？

そうかもしれません。学生時代COBOLの入門書を読んだことはありますが、
面白くない言語だったので詳細までは覚えてなかったはず。
(他にもっと面白い言語があったので)
メインフレームCOBOLのマニュアルを読んだのは1985年以降です。
逆輸入か、きっとそうですね。今はOO-COBOLとかもあるし。
失礼しました。

>>>ちなみに、COBOLで構造の異なる構造体変数へ代入する場合は、一旦バイト列に
>>>分解して頭から変数に切り直すという恐ろしい仕様（ファイル入出力のバッファ
>>>という発想からすれば自然か？）になっている。
>>これはちょっと意味がわかりません。構造の異なる構造体変数への代入は
>>ごく普通に親の名前を使って MOVE すればできるのでは？
> 「分解」というより「展開」と表現した方が良かったかな？

意図は了解しましたが、それを「分解」とは？むしろ「結合」ではないでしょうか？
PL/IだとUNSPEC関数、UNSPEC擬関数をつかって構造体をひとまとめにするイメージ。

＜ちなみに、COBOLで構造の異なる構造体変数へ代入する場合は、一旦全体を1つの
＜バイト列と見なして、それを頭から変数に切り直すという恐ろしい仕様

でどうでしょうか。

と、ここまで書いて、「分解」と書かれた意味がわかりました。
「バイト列」という言葉のイメージの食い違いですね。
--
oo

[to...@lbm.go.jp]

In article <bji7mm$2v...@utogw.gssm.otsuka.tsukuba.ac.jp> ku...@gssm.otsuka.tsukuba.ac.jp writes:
>> 実は私のCOBOLに関する知識は、（恐ろしいことに）1982年で停まっ
>> ておりまして、従って、「第３次規格」（ANSI 1985, ISO 1985, JIS
>> 1988）以前なのです。
> うーん、move corresponding(構造体コピーで同名のものを対応づけ
>る)って1982にはなかったでしたっけ?

手元の教科書を見てみたら、
巻末付録の予約語一覧表に「CORRESPONDING」が載ってるんですが、
その使い方の説明は一切ありません。
（巻末付録の「一般形式」にさえ載っていない）
「入門」段階では、名前照合の考え方は不要という
教科書著者の判断だったのでしょうか？

戸田 孝＠滋賀県立琵琶湖博物館
to...@lbm.go.jp

[to...@lbm.go.jp]

えー、結局「間違い」というのが正しかった、という結論です。^_^;

In article <bjhms9$lvj$1...@bluegill.lbm.go.jp> to...@lbm.go.jp writes:
>>そこから引用：
>>>COBOLの名前空間は全体で１つであり、メンバー変数の名前を個々の構造体ごとに
>>>変えねばならない。そして、構造体変数の代入は常に並び順照合である。
>>これは間違ってます。

>ただ、私の知り得る情報を総合した限りでは、
>「間違っている」のではなく「情報が古い」のではないかと思うのですが、
>如何でしょうか？
>実は私のCOBOLに関する知識は、（恐ろしいことに）1982年で停まっておりまして、
>従って、「第３次規格」（ANSI 1985, ISO 1985, JIS 1988）以前なのです。

ふと思いついて、私が使っていた教科書の索引で
「identifer（一意名）」を索いてみました。
そしたら、

>>>PL/Iでは、異なる構造体に同一名のメンバーが属することを許容し
>>>（むしろ同一構造の構造体には同一メンバ名を用いることを推奨し）、
>>>代入に際して名前で照合する「BY NAME」指定を導入した。
>>と書いてあるPL/Iと同じです。同じ名前の要素の参照は、「要素名 OF 親の名」
>>で参照します。要素名がプログラム中でユニークなら「OF 親の名」は省略可。

が、しっかり出てきました^_^;
＃「要素名 IN 親の名」でも良いようです。

ただ、この教科書の著者の立場としては、
この機能は「極力使うべきではない」と考えているようです。
名前空間云々とか、同一構造は同一名で識別するべきとかいう考えは頭に無く、
単に命名を「手抜き」するための機能とでも認識していたのではないかと思います。
そのため、極力この機能を隠すように記述していました。

すっかり騙されてしまった^_^;

戸田 孝＠滋賀県立琵琶湖博物館
to...@lbm.go.jp

[to...@lbm.go.jp]

In article <binuft$49p$1...@bluegill.lbm.go.jp> I write:
>> そもそも言語メカニズムというならCの祖先BCPLや親戚BLISSを調べる
>>必要はあるんじゃないでしょうか。
>ですよね。あと、algol 68も見ておきたいんだけど、
>教科書探しから始めねばならない状況です。

M.Richards and C.Whitby-Strevens（和田英一訳）
BCPL言語とそのコンパイラ（共立出版1985）ISBN4-320-02245-9
が滋賀県立図書館にあったので、借りてきました。

とりあえず、元の話題に関連するところでは、

(1)「構造体」という概念はBCPLには無い

データ型が無い（後述）ので、
種類の異なるデータを１つの配列（ベクタ）に混在させることはできますが、
要素を「指標数値」ではなく「名前」で識別するというものはありません。
オフセット値を定数名（マニフェスト定数）として定義することによって、
実質的に「名前による要素の識別」を行うことはできますが、
構造体のようにコンパイラが自動的にオフセット値を計算するのではなく、
プログラマがオフセット値を計算してプログラムに記述せねばなりません。

(2)Ｃ言語がPL/Iから直接受け継いだと思われる特徴はBCPL起源ではない

注釈に“/* */”を使う流儀ではありません。
“//”から行末までが注釈です……って、
最近のC++とかに追加された注釈の書法と同じだ^_^;

また、“;”は分離記号です。但し、行末も分離記号です。これはビックリ。
正確には、行の最後のトークンが文末に位置し得るものであれば分離記号で、
文末に位置し得ないトークンで終わっていたら次行に継続します。
何ちゅう投げ槍な仕様だ……

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
元の話題と直接関係ない点で興味を引いたところとしては、

(3)データ型の区別が無い

CPLからBCPLへの最大の変更点は、この点なんだそうです。
区別が無いと言っても、AWKやPerlのように、
"123"という文字列が数式に現れたら「123」という数値になる
というような「人間寄り」の「区別の無さ」ではありません。
データは言語レベルでは内部表現としてのみ意味があり、
その内部表現にどういう意味を持たせるかはプログラマ次第
という意味で「機械寄り」の「区別の無さ」です。
まあ、アセンブリプログラマにとっては素直な発想ですし、
おそらくこの考え方がＢ言語に引き継がれ、
いくら何でもそれじゃ不便だというので
Ｃ言語で揺り戻されたということなんでしょうね。
（Ｂ言語の詳細を知らないので、その部分は推測です）
とはいえ、システム記述の上で重要な
「文字型データは、その内部表現を値とする整数型データでもある」
「アドレスデータ（ポインタ）は、
その内部表現を値とする整数型データと相互に変換できる」というような
「データの二面性」はＣ言語にまで引き継がれたわけです。

ちょっと気になったのが、
Ｃ言語の「charとshort intとlong int」に相当する区別が無いこと、
つまり如何なるデータも同一量の記憶域を占有するということです。
この仕様ってCPUを選んでしまうんじゃないでしょうか？

なお、文字列に関しては、１配列要素に何文字かを詰込んで取扱う
ライブラリが標準で準備されています。
Ｃ言語やPascalと違って、詰込まれた文字列に対する操作を
配列操作と同じ書式で行うことはできず、専用のライブラリを要します。

(4)IF構造に相当するものがELSEの有無で区別されている

IFにはTHEN節のみでELSE節がありません。
THEN節とELSE節が共存する場合はIFに代えてTESTを使います。
こういう言語って初めて見ました。

ちなみに、UNLESS～DOというのがあって、
ELSE節だけあってTHEN節が無い状況に相当します。

(5)FORループの制御変数のスコープは、そのループ内
（FORTRANやPL/IのDOループに相当）

「ループを飛出した時の値を参照する」技法が使えないということです。
そのくせ、制御変数の値を途中で変えてしまって、
繰り返し回数に影響を与えることは認められています。変なの。
制御変数はFORループの形式に記述することによって宣言され、
改めて変数を宣言する必要は無い
……というより、改めて宣言してはならないことになっています。

(6)“A < B < C”という条件式が自然言語の数式と同じ意味を有する

つまり、「A < B」AND「B < C」という意味になります。
これも初めて見た……

(7)配列（ベクタ）を宣言すると、同名の単純変数も同時に確保され、
当該配列へのポインタで初期化される

わけのわからん無駄な仕様ですね。
当該配列へのポインタを値とする定数名とするのが素直なんですけど。
（Ｃ言語は、まさにそう）

(8)インラインの手続きが、親手続きの局所変数にアクセスできない

アクセスが必要な場合はグローバル変数を使うことになりますが、
親手続きの中で定義すれば、親手続きの外では見えないので、
スコープ的には素直に親子での変数共有になります。
しかし、変数のメモリ管理（寿命など）は、あくまでグローバルです。

戸田 孝＠滋賀県立琵琶湖博物館
to...@lbm.go.jp

[SAITOH akinori]

大阪大学の齊藤です

to...@lbm.go.jp wrote:
> M.Richards and C.Whitby-Strevens（和田英一訳）
> BCPL言語とそのコンパイラ（共立出版1985）ISBN4-320-02245-9

> (3)データ型の区別が無い
「BCPLは型無し言語である」というのは有名ですよね。

> データは言語レベルでは内部表現としてのみ意味があり、
> その内部表現にどういう意味を持たせるかはプログラマ次第
> という意味で「機械寄り」の「区別の無さ」です。

要は　word　ですよね。

> ちょっと気になったのが、
> Ｃ言語の「charとshort intとlong int」に相当する区別が無いこと、
> つまり如何なるデータも同一量の記憶域を占有するということです。
> この仕様ってCPUを選んでしまうんじゃないでしょうか？

PDP-11などでは困りますが。
多くのメインフレームのようなワードマシンでは困らなかったの
だとおもいます。

> (7)配列（ベクタ）を宣言すると、同名の単純変数も同時に確保され、
> 当該配列へのポインタで初期化される
>
> わけのわからん無駄な仕様ですね。
> 当該配列へのポインタを値とする定数名とするのが素直なんですけど。
> （Ｃ言語は、まさにそう）

定数オペランドアドレスにアクセスするアドレッシングモードがない
計算機を想定していたのでは？（正確には、アドレス空間全体は
アクセスできない）。最近ではCASLくらいですがそんなのは。
そういうCPUでのアセンブラのお作法に引きずられた。
(すみません。思いつきです)

齊藤明紀 sai...@ist.osaka-u.ac.jp

[KATAYAMA Yoshio]

片山＠ＰＦＵです。

SAITOH akinori <sai...@ist.osaka-u.ac.jp> writes:

> to...@lbm.go.jp wrote:

> > (7)配列（ベクタ）を宣言すると、同名の単純変数も同時に確保され、
> > 当該配列へのポインタで初期化される
> >
> > わけのわからん無駄な仕様ですね。
> > 当該配列へのポインタを値とする定数名とするのが素直なんですけど。
> > （Ｃ言語は、まさにそう）
>
> 定数オペランドアドレスにアクセスするアドレッシングモードがない
> 計算機を想定していたのでは？（正確には、アドレス空間全体は
> アクセスできない）。最近ではCASLくらいですがそんなのは。
> そういうCPUでのアセンブラのお作法に引きずられた。
> (すみません。思いつきです)

これは、

> > データは言語レベルでは内部表現としてのみ意味があり、
> > その内部表現にどういう意味を持たせるかはプログラマ次第
> > という意味で「機械寄り」の「区別の無さ」です。
>
> 要は　word　ですよね。

こっちと関係があるのではないかと思います。

配列宣言でその配列へのポインタも用意しておくことで、配列というデー
タ型をコンパイラが覚えておく必要が無くなります。

数 KB 程度のメモリで動作するコンパイラの場合、データ型が“word”
だけで済む（＝データ型を区別する必要が無い）のとそうでないのとで
は、コンパイラのサイズが相当変わってきます。

うろ覚えですが、μPLAN も同様な仕様だったと思います。
--
片山＠ＰＦＵ

[to...@lbm.go.jp]

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

>が滋賀県立図書館にあったので、借りてきました。
Ｂ言語についてはオンラインで見つけました（英語ですが）。
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
（同じ内容のようです）

データ型が無いことを除けば、Ｃ言語にソックリですね。
algol系の「“=”は比較、代入は“:=”」という
伝統（BCPLも継承している）に逆らって、
「“=”は代入、比較は“==”」としているのも同じです。
代入演算子が逆順（“+=”ではなく“=+”）とか、
ビットごと論理と２値論理の区別が無いとかいったあたりは、
教科書類に「初期のＣ言語はこうだった」と書いてあるそのまんま。

注釈を「/* */」で表記することや、
“;”を分離記号ではなく終端記号として用いることも、
Ｂ言語経由でPL/IからＣ言語に継承されたようです。

In article <qkpoexs...@dash.tokyo.pfu.co.jp> ka...@pfu.fujitsu.com writes:
>> > (7)配列（ベクタ）を宣言すると、同名の単純変数も同時に確保され、
>> > 当該配列へのポインタで初期化される
>> > わけのわからん無駄な仕様ですね。
>> > 当該配列へのポインタを値とする定数名とするのが素直なんですけど。

>> 定数オペランドアドレスにアクセスするアドレッシングモードがない
>> 計算機を想定していたのでは？
だからって、「変数」としてアクセス可能にする必要は無いでしょう。
変数と同じメモリ領域に値を保持するとしても、「無名の変数」にして
プログラムからはアクセスできなくする方が素直だと思います。
即値定数や文字列定数の値を、CPUの都合で、
変数と同じメモリ領域に保持するのと同じことです。

>これは、
>> > データは言語レベルでは内部表現としてのみ意味があり、
>> > その内部表現にどういう意味を持たせるかはプログラマ次第
>> > という意味で「機械寄り」の「区別の無さ」です。
>> 要は　word　ですよね。
>こっちと関係があるのではないかと思います。
>配列宣言でその配列へのポインタも用意しておくことで、配列というデー
>タ型をコンパイラが覚えておく必要が無くなります。

よく解りません……

配列は「データ型」ではありませんよね。
コンパイラにとっては、
「宣言されただけの記憶域をシステムが確保する」というのが
配列というオブジェクトの本質であり
（この「確保」がシステムにとって一番の負担ですよね）、
それは、対応するポインタ変数を確保するかどうかに関係ありません。

そして、いずれにしても配列名は
「確保された記憶域のアドレスという意味を有するword型のデータ」であり、
今問題になっているのは、
それが「定数」なのか「変数」なのかという違いに過ぎません。

ちなみに、Ｂ言語には、この妙な仕様は継承されていないようです。
（Ｂ言語の処理系は、ネイティブコードを吐くコンパイラが記述できないような
貧弱な環境のために開発されている）
やはり、必然性の無い仕様なのではないでしょうか？

戸田 孝＠滋賀県立琵琶湖博物館
to...@lbm.go.jp

[Takao Ono]

小野@名古屋大学 です.

<bjpl36$gfg$1...@bluegill.lbm.go.jp>の記事において
to...@lbm.go.jpさんは書きました。
toda> In article <qkpoexs...@dash.tokyo.pfu.co.jp> ka...@pfu.fujitsu.com writes:
toda> >> > (7)配列（ベクタ）を宣言すると、同名の単純変数も同時に確保され、
toda> >> > 当該配列へのポインタで初期化される
toda> >> > わけのわからん無駄な仕様ですね。
toda> >> > 当該配列へのポインタを値とする定数名とするのが素直なんですけど。
toda> >> 定数オペランドアドレスにアクセスするアドレッシングモードがない
toda> >> 計算機を想定していたのでは？
toda> だからって、「変数」としてアクセス可能にする必要は無いでしょう。
toda> 変数と同じメモリ領域に値を保持するとしても、「無名の変数」にして
toda> プログラムからはアクセスできなくする方が素直だと思います。
BCPL の都合上 a!i と書いたら a にアクセスしてしまうので,
# BCPL のバージョンにより配列の要素参照はいろいろな構文があるので
# すが, ここでは a!i を使います.
「無名の変数」の意味はないでしょう (配列名をその変数の名前にして
しまえばいいわけで). まぁ, 「変数」である必要はよくわかりませんが
(「定数」でもいいので).

toda> >これは、
toda> >> > データは言語レベルでは内部表現としてのみ意味があり、
toda> >> > その内部表現にどういう意味を持たせるかはプログラマ次第
toda> >> > という意味で「機械寄り」の「区別の無さ」です。
toda> >> 要は　word　ですよね。
toda> >こっちと関係があるのではないかと思います。
toda> >配列宣言でその配列へのポインタも用意しておくことで、配列というデー
toda> >タ型をコンパイラが覚えておく必要が無くなります。
toda> よく解りません……
toda> 配列は「データ型」ではありませんよね。
toda> コンパイラにとっては、
toda> 「宣言されただけの記憶域をシステムが確保する」というのが
toda> 配列というオブジェクトの本質であり
toda> （この「確保」がシステムにとって一番の負担ですよね）、
toda> それは、対応するポインタ変数を確保するかどうかに関係ありません。
ただ, 対応するポインタ変数を確保することによって「コンパイラが配
列の大きさを意識しなくていい」ということは言えると思います.

これは 2次元以上の配列になると影響してくるんですが, C で a[M][N]
という配列 (M, N は定数) を確保したときに a[i][j] をアクセスしよ
うとすると, 実質的に *(a[0] + i*N + j) という計算をすることになり,
このため N を記憶しておく必要があります (場合によっては i*N とい
う乗算も必要). ところが, BCPL では同じ配列に対して a の分に加えて
a!0～a!(M-1) の分も確保します (a の内容は a!0 のアドレス, a!i の
内容は a!i!0 のアドレス). こうすると a!i!j のアクセスに必要な処理
は C で書くと *(*(a + i) + j) となり, N の値を記憶する必要はなく
なります (しかも乗算も不要).

toda> そして、いずれにしても配列名は
toda> 「確保された記憶域のアドレスという意味を有するword型のデータ」であり、
toda> 今問題になっているのは、
toda> それが「定数」なのか「変数」なのかという違いに過ぎません。
BCPL にとっては「変数」か「定数」かはどうでもよくって, 単に「メモ
リ上に存在すればいい」ということです.

toda> やはり、必然性の無い仕様なのではないでしょうか？
「変数」である必然性はないですね.

でも, 「メモリ上にポインタとして存在する」というのは便利だと思い
ますよ. 実際, C だってまともに 2次元配列を扱う (ex. 行列演算) ラ
イブラリを作ろうと思ったら同様の方法を採るしかないわけですし.
--
名古屋大学大学院 情報科学研究科 計算機数理科学専攻
小野 孝男

[to...@lbm.go.jp]

In article <0309112153...@flame.hirata.nuee.nagoya-u.ac.jp> ta...@hirata.nuee.nagoya-u.ac.jp writes:
>ただ, 対応するポインタ変数を確保することによって「コンパイラが配
>列の大きさを意識しなくていい」ということは言えると思います.
>
>これは 2次元以上の配列になると影響してくるんですが, C で a[M][N]
>という配列 (M, N は定数) を確保したときに a[i][j] をアクセスしよ
>うとすると, 実質的に *(a[0] + i*N + j) という計算をすることになり,
>このため N を記憶しておく必要があります (場合によっては i*N とい
>う乗算も必要). ところが, BCPL では同じ配列に対して a の分に加えて
>a!0～a!(M-1) の分も確保します (a の内容は a!0 のアドレス, a!i の
>内容は a!i!0 のアドレス). こうすると a!i!j のアクセスに必要な処理
>は C で書くと *(*(a + i) + j) となり, N の値を記憶する必要はなく
>なります (しかも乗算も不要).

このこと自体は解るんですが、
だからって、配列を切る際に、
コンパイラが有無を言わせずポインタ変数を確保する理由には
ならないような気がするんですけどねえ……

そういうアクセス法が必要だとプログラマが判断した場合に、
明示的にプログラミングによって確保するとする方が、
BCPLの哲学にも合っているような気がします。

戸田 孝＠滋賀県立琵琶湖博物館
to...@lbm.go.jp

[to...@lbm.go.jp]

In article <bjncgh$tf8$1...@newsserv.ics.es.osaka-u.ac.jp> sai...@ist.osaka-u.ac.jp writes:
>> ちょっと気になったのが、
>> Ｃ言語の「charとshort intとlong int」に相当する区別が無いこと、
>> つまり如何なるデータも同一量の記憶域を占有するということです。
>> この仕様ってCPUを選んでしまうんじゃないでしょうか？
>PDP-11などでは困りますが。
>多くのメインフレームのようなワードマシンでは困らなかったの
>だとおもいます。

Dennis M. Ritchie, The Development of the C Language,
http://www.cs.bell-labs.com/who/dmr/chist.html
では、
Ｃ言語で型の概念を再導入した３つの動機のうち２つが、
この問題に関連するものだと述べていますね。
（残りの１つは浮動小数点関連）
バイト境界で文字が並んだ文字列を取扱う際、
機械語のバイトアドレッシングを直接使えば素直に取扱えるのに、
わざわざワード境界にunpackして取扱うという
馬鹿げた作業が必要になるというのが１つ、
プログラム上ではアドレスをワード単位で取扱い、
それをポインタとして用いる段階で
逐一バイト単位に換算せねばならないというのが１つです。

戸田 孝＠滋賀県立琵琶湖博物館
to...@lbm.go.jp

[ka...@sra-tohoku.co.jp]

to...@lbm.go.jp sed in <bjn3l3$jhr$1...@bluegill.lbm.go.jp>:

>> (2)Ｃ言語がPL/Iから直接受け継いだと思われる特徴はBCPL起源ではない
>>
>> 注釈に“/* */”を使う流儀ではありません。
>> “//”から行末までが注釈です……って、

手元の資料では

BCPL /*...*/
BCPL |*...*|
BCPL \*...*\
BCPL //...
BCPL ||...
BCPL \\...

なんですが、これガセネタだったんでしょうか？
＃BCPLにもバージョンがあったんかもしれませんが
--
kabe

[R4000 2.2]

こんばんは、立花＠鎌ヶ谷市です。

<ka...@sra-tohoku.co.jp>さんの<750211200...@sra-tohoku.co.jp.msgid>から

http://web.cs.mun.ca/~ulf/pld/surface.html
には、かべさんの書いたものが載ってますね。

--
R4000 2.2 mailto:ta...@kc5.so-net.ne.jp

[to...@lbm.go.jp]

In article <750211200...@sra-tohoku.co.jp.msgid> ka...@sra-tohoku.co.jp writes:
>>> 注釈に“/* */”を使う流儀ではありません。
>>> “//”から行末までが注釈です……って、
>手元の資料では
>BCPL /*...*/
>BCPL |*...*|
>BCPL \*...*\
>BCPL //...
>BCPL ||...
>BCPL \\...
>なんですが、これガセネタだったんでしょうか？

少なくとも私が参照したBCPLの教科書では“//”のみですし、
Ritchieが書いたＣの歴史の文章でもそうなっています。

>＃BCPLにもバージョンがあったんかもしれませんが
方言（独自拡張）が多数あったようですよ。
私が参照したBCPLの教科書にも、浮動小数点対応とか
ライブラリ参照に絡んだ拡張に触れた部分がありましたし。

戸田 孝＠滋賀県立琵琶湖博物館
to...@lbm.go.jp

[SAITOH akinori]

[SAITOH akinori]

大阪大学の齊藤です

間違って編集前に出してしまいました。

SAITOH akinori wrote:

>
> to...@lbm.go.jp wrote:
>>>>定数オペランドアドレスにアクセスするアドレッシングモードがない
>>>>計算機を想定していたのでは？

>>だからって、「変数」としてアクセス可能にする必要は無いでしょう。
>>変数と同じメモリ領域に値を保持するとしても、「無名の変数」にして
>>プログラムからはアクセスできなくする方が素直だと思います。
>>即値定数や文字列定数の値を、CPUの都合で、
>>変数と同じメモリ領域に保持するのと同じことです。

必要はないですが、コンパイラが楽になりますね。
identifierが配列名だった場合の処理が省略できる。

BCPLの作者のメンタリティが戸田さんと異なっていて、異なる
デシジョンをしたというだけだとおもいますが。

齊藤明紀　sai...@ist.osaka-u.ac.jp