PLEX86  x86- Virtual Machine (VM) Program
 CVS  |  Mailing List  |  Download  |  Newsgroups

Where should the type information be 152


Your Ad Here

Your Ad Here

Where should the type information be 156
Considering that PL-I was designed by a committee with a short time limit 40 years ago...

No, it isn't - it is a huge language, as may be seen by comparing the size of Fortran 77, Fortran 90 and C compilers.

K&R C was a simple COMPILER, and the more subtle aspects of the language were more-or-less defined as "whatever the compiler does". As it was being used as a high-level, semi-portable buttembler, that did not impact most programmers. But it did lead to the separately developed compilers supporting quite seriously different languages.

ISO C was (and is) a simple DESCRIPTION, and the more subtle aspects of the language have to be deduced by reading between the lines (e.g. discounting possible interpretations because they conflict with the intention in apparently unrelated sections). Let's ignore the large number of ambiguities and inconsistencies this causes, and concentrate on the size of the language (essentially its complexity).

Algol 68 had an even simpler description but, because it was almost mathematically precise and multi-level, the language was larger than it appeared from that. Fortran 90 has an "expanded" description but, because it has, is not as large as it appears to be.

Where should the type information be 155
John, An even cleaner solution would be to simply declare the syntaxes that are now guaranteed to make C compilers produce garbage code to at least produce a stern "warning" diagnostic indicating that the...

My estimates, from the sizes of the compilers, what I need to know to have to resolve user problems, and other "wet finger" measurements, is that Algol 68, Fortran 90 and C90 are all comparably "large".

Exactly the same mistake is being made in the design of I-O interfaces. FAR too many of them produce a very simple hardware design that needs a mbutt of firmware to avoid the "gotchas". Similarly, far too many produce a very simple programming interface that needs a mbutt of code to make them work reliably and portably. It is a SERIOUS engineering mistake to look at the complexity of a unit as separate from the complexity of its use.

Where should the type information be 153
Unlike LALR parsing, operator precedence parsing can be implemented by hand, and is more efficient than LL parsing in handling expressions. There are a few languages that can be implemented exclusively...

The same remark can be made about (RISC) floating-point, a great deal of memory management and so on. Many architectures leave essential features undefined, and specify them (if at all) in the release notes or equivalent. This does not exactly help with operating system reliability :-(

Regards, Nick Maclaren.



Your Ad Here

List | Previous | Next

Where should the type information be 153

Alt Folklore Computers from Newsgroups

The #1 Usenet Provider on the Internet

Where should the type information be 151