🚀 go-pugleaf

 >     Is Modula-2 as powerful as C?
 
 >     JPI is using TopSpeed Modula-2 to write their "ANSI Standard" 
 > TopSpeed C compiler.

This really avoids the question.  You could write the C compiler in COBOL and   
it's quality would depend mostly on how good a coder you are.  The choice of  a  
language depends more on what a programmer knows than what the language is   
suited for.

Instead of saying so-and-so is writing such-and-such in Modula-2, why don't   
you talk about Modula's powerful encapsulation facilities.  Why don't you   
mention that this makes Modula better for large projects than C is?  You  could  
also talk about the improved support for abstraction.

 > Portability... tough question.  Is C portable? Is Modula-2 portable.

 >     A lot of persons say C is portable, but... the standard just came out 
 > and not all vendors were close to the standard (some were around 40%, 
 > others were 90%).  So, how portable is C?

Do you honestly want an answer?  Before the ANSI (assuming that you're in the   
USA, otherwise you have to talk about ISO) committee produced their final   
standards document, there was a de-facto C standard that was the result of  C's  
birth and adolescence on Unix machines.  

Even though nobody has had a chance to implement (well, try anyway - there's   
no validation suite) the full ANSI standard, the language supported is always   
Unix System V compatable.  The same is said for the "Standard library."  The   
standard library means that a C programmer has a fighting chance at making his   
programs portable.  (He has to restrict himself, however.  It is difficult to   
write interactive programs in C that are truly portable.)

 > There currently is no standard for Modula-2, so the same point stands.
 
 >     Most compilers follow the "defacto standard" set up by Wirth; 
 > following Programming in Modula-2 III (PIM3) or IV (PIM4).  So, the 
 > language itself has some portability in it.

Aside from the fact that N. Wirth does not say whether Modula-2 is a one-pass   
or a two-pass language, this is correct.  (It is quite possible to write two   
different compilers that won't compile each other's code but which are BOTH   
compatable with PIM.)

 >     However, Wirth supplied little in his papers concerning what 
 > libraries should contain or how they should be formatted; so, there is 
 > little to go by in terms of "standard" libraries.  

Actually, Wirth wimps out and fails to specify even a minimum standard for a   
standard library.  In my copy of PIM3c he says that he presents a "typical   
hierarchy of modules used in performing conventional input and output   
operations."  Further, he says that "the hierarchy of these Modules and their   
exports do not belong to the language proper."  

That view, while it is not incorrect by any stretch of the imagination, is not   
likely to promote portability of any code which does I/O at all.  In fact, a   
minimum I/O library specification SHOULD be part of the definition of any   
higher-level programming language.  (Well, that's what I believe, anyway.  In   
fact, I think that de-facto I/O library standards will be created but they   
will be different for each computer family.)

In any case, I don't think that portability is a major issue for casual   
programmers.  It probably isn't even that big an issue for professional   
programmers.  It's importance is certainly overemphasized.

...You trust them with your fortunes, let them guard your lives

--  
uucp: uunet!m2xenix!puddle!226!70.2!Jon.Guthrie
Internet: Jon.Guthrie@p2.f70.n226.z1.fidonet.org