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=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,39579ad87542da0e X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.180.76.115 with SMTP id j19mr4599284wiw.2.1369279440684; Wed, 22 May 2013 20:24:00 -0700 (PDT) Path: fw11ni1136wic.0!nntp.google.com!feeder1.cambriumusenet.nl!82.197.223.108.MISMATCH!feeder2.cambriumusenet.nl!feed.tweaknews.nl!85.12.40.130.MISMATCH!xlned.com!feeder1.xlned.com!border2.nntp.ams.giganews.com!nntp.giganews.com!news.panservice.it!news.swapon.de!eternal-september.org!feeder.eternal-september.org!mx05.eternal-september.org!.POSTED!not-for-mail From: Jeffrey Carter Newsgroups: comp.lang.ada Subject: Re: Seeking for papers about tagged types vs access to subprograms Date: Wed, 15 May 2013 11:15:07 -0700 Organization: Also freenews.netfront.net; news.tornevall.net Message-ID: References: <12gn9wvv1gwfk.10ikfju4rzmnj.dlg@40tude.net> Mime-Version: 1.0 Injection-Date: Wed, 15 May 2013 18:11:18 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="656ea2f23126f57fb36504d2d15a002c"; logging-data="31038"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+V+I3HcjaYgSWs8wzwQnpEL/b+kLEw4CY=" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 In-Reply-To: Cancel-Lock: sha1:5ly2916uXYQrmhoNjOTiiomrJt4= Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Date: 2013-05-15T11:15:07-07:00 List-Id: On 05/15/2013 04:31 AM, Peter C. Chapin wrote: > > The genius of the Linux (and Windows) way of representing files is that the > operating system does not need to know anything about the nature of the data > being stored in the files. Thus new file types can be defined by applications > without any OS changes. This does push the burden of interpreting the file's > format into the application but the benefit is a more generic operating system. > When one considers all the different kinds of files created by applications > today, I can't imagine any other way working well. Ada 83 had a philosophy of providing building blocks and letting the user use them to create what he wants. The language provided the means to create mathematical functions and unbounded arrays and queues and sets, so the language did not provide such things. This resulted in a proliferation of external libraries and negative comparisons to languages with large standard libraries. In 1995 Ada was revised to include some of these things, and again in 2007 more of them, including hashed and ordered maps and sets, but the underlying building blocks of an O(log N) searchable structure and a hash table were not provided to the user. This represents the opposite philosophy to that of Ada 83: providing high-level abstractions but not the building blocks to build them. (Of course, Ada 83 required a compiler implementer to have a bignum package, but not to make it available to users of the compiler, so the difference is not as clear as I'm pretending.) Between these 2 extremes is a philosophy of providing building blocks and common high-level abstractions build from them. Physically, a disk is a bunch of bytes; everything else is built on top of that. The Unix file concept provides the building blocks but no higher-level abstractions. VMS (which, IIRC, did not initially have a sequence-of-bytes way to access files) represented the other extreme. Presumably there are some common higher-level file types that it would be useful to have the OS provide in addition to the sequence-of-bytes view, just as it's useful to have a language provide common higher-level constructs as well as the building blocks to build them. -- Jeff Carter "Nobody expects the Spanish Inquisition!" Monty Python's Flying Circus 22