Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site pegasus.UUCP
Path: utzoo!linus!philabs!cmcl2!floyd!clyde!ihnp4!drux3!hogpc!pegasus!wilner
From: wilner@pegasus.UUCP
Newsgroups: net.lang
Subject: Re: Modula-2 faults - (nf)
Message-ID: <575@pegasus.UUCP>
Date: Wed, 28-Sep-83 17:51:07 EDT
Article-I.D.: pegasus.575
Posted: Wed Sep 28 17:51:07 1983
Date-Received: Fri, 30-Sep-83 04:47:22 EDT
References: <1246@ecsvax.UUCP>
Organization: AT&T Information Systems, Lincroft NJ
Lines: 18


   I must smile when ecsvax!dgary says "...the 8-16-32-64 family is
[well-established] (IBM and Burroughs...".  The famous B5000 was a
48-bit machine, the B3500 was decimal, and the B1700 was bit-addressed
(although it had 24-bit data paths).  It may seem that computer
architecture is stabilizing but I hope that's just a bad illusion.
   As to philosophy of languages, I like to recall the early days
of railroading, when each State of the Union had its own gauge for
track.  There was a portability problem at many state lines: if you
couldn't carry it from one train to the next, you were out of luck.
As I apply that lesson to languages, I conclude that each language
should mandate byte-size, byte-order, word-size and say what happens
to each bit in each operand for each operator.  That means we would
have Modula-8, Modula-16, Modula-32, etc., but the porting problems
would occur between Modula-8 and Modula-16 (say), not between Modula-16
on IBM and Modula-16 on Burroughs.  I think the problems "dgary" raises
result from languages being too loose in their semantic definitions,
then trying to protect programmers by being too restrictive in their use.