From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!mx05.eternal-september.org!feeder.eternal-september.org!feeder.erje.net!eu.feeder.erje.net!nntp.club.cc.cmu.edu!micro-heart-of-gold.mit.edu!newsswitch.lcs.mit.edu!nntp.TheWorld.com!.POSTED!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Seeking for papers about tagged types vs access to subprograms Date: Tue, 14 May 2013 15:56:14 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <12gn9wvv1gwfk.10ikfju4rzmnj.dlg@40tude.net> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: pcls6.std.com 1368561375 20678 192.74.137.71 (14 May 2013 19:56:15 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Tue, 14 May 2013 19:56:15 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:3eA+DWXM6lyg6PidRoj/cWPBBVM= Xref: news.eternal-september.org comp.lang.ada:15563 Date: 2013-05-14T15:56:14-04:00 List-Id: "J-P. Rosen" writes: > Le 13/05/2013 21:13, Robert A Duff a écrit : >> I haven't used VMS in years, but I recall Record Management Services >> being a nightmare! Far more complexity than could possibly be worth >> the functionality provided. >> > Maybe you used it from C... No, I don't recall writing any C on VMS. On Unix, Windows, misc embedded systems, yes, but not on VMS. On VMS I mainly used Pascal, with a little bit of assembly. Pascal I/O is also poorly designed, by the way, which is probably why I was horsing around with RMS. Text I/O in Java or Lisp, for example, is superior to either C or Ada, IMHO. >... I remember VMS had to invent new access > methods specifically for C, because the VMS view of a file was too high > level for C. Interesting. I don't see why -- VMS files can represent a "sequence of bytes", among other things. >> Text_IO ought to provide simple streams-of-characters abstractions, >> and what it looks like on the disk, or what it looks like to the >> OS should be hidden at that level. > Sorry, but I see a stream of characters as a lower level abstraction > than an organised sequence of pages, lines, and individual characters > (not that I am especially fan of pages) OK, let's agree that pages are junk. That leaves "sequence of lines, each of which is a sequence of characters". Some programs do indeed want to view text that way. But Text_IO doesn't support that very conveniently. There isn't even a Line type in Ada. And the Get_Line procedure requires a fixed-length string, and the length of that string is guaranteed to be both too short and too long. (I'm talking about flaws in the original design, here, so Ada 83 -- I realize a Get_Line function was later added.) So the design encourages the sort of broken program that doesn't work right when there are long lines. There are lots of C programs with the same kind of bug, for similar reasons. And there's no data type in Ada that can portably represent a multi-line piece of text. Of course, you can build your own, but something so basic ought to be predefined. Furthermore, lots of programs do NOT want that two-level structure. They just want a sequence of characters, with one (not two!) particular character that means "line break". They want to have code like: ... loop case Current_Char is ... where a line break is treated similarly (or identically) to ' '. The GNAT front end is like that (the lexical analysis, I mean), and it doesn't use Text_IO to read the source text. - Bob