🚀 go-pugleaf

In article <1991Mar14.235248.24540@jato.jpl.nasa.gov> vsnyder@jato.Jpl.Nasa.Gov (Van Snyder) writes:
>In article <1991Mar14.191513.20184@iitmax.iit.edu> gkt@iitmax.iit.edu (George Thiruvathukal) writes:
>>
>>It is somewhat regrettable that Niklaus Wirth left the issue of libraries so
>>open-ended that programmers cannot rely upon a minimal set of libraries from
>>implementation to implementation.  Even in the C language, one can count on
>

Actually, an alternate interpretation of the PIM book is that he not only
made recommendations, he gave examples.  Additionally, the Source Code was
available.  I tend to believe that some vendors wanted to produce a mature
product, and based their products on those libraries.  I can clearly port
code between very different machines, including IBM-PC, the Mac, and VAXes
using these products.

Other vendors suffer from sole source trapping in their marketing plans.
in those systems, I cannot move code between vendors on the same CPU
platform.  (Of course, some folks have had trouble between versions
1.04, 1.12, and 2.0 by the same vendor)

But I can buy the source to the libraries, and if they are well written,
port them into the alternate compiler's environment.  Sometimes there are
booby traps there as well.  I don't want to pick on a certain vendor without
having code in front of me, but I have seen very non-standard CODE procedures
in several library modules, and sometimes I felt that was gratuitous to 
prevent complete freedom of usage of the source.

If there was a standard, and "Primo Donya Software" released a non-compliant
version on "Spiffo Cpu" before anyone else, then we'd be right where we are
now without a standard.  What then?  Well, same as now. Don't buy a product
that prohibits second sourcing, portability, or which encourages use of
non-standard extensions.  And you can write clean Modula2 no matter what
the vendor offers as bells and whistles.

If this is a REAL nuisance in your mind, then invert that to a potential income
advantage:  Write a correct and portable library, and methodically place it on
each available platform/vendor position.  Either you should get rich, or 
you shouldn't be bitchin.

I'm certain I can produce .OBJ files in the MS-DOS world that will link with
FST, JPI, and Logitech 3.<any> all at the same time.  I've been deep into the
details, and I seriously doubt that I'm the only one who has.  I'm certain
I can produce code that is clean Modula2 or Clean Modula-2 .DEF and .ASM/.OBJ
pairs to do this, so that it ports between vendors.  With minimal thought,
this would port to radically different platforms.  The C community writes
code that fixes problems, then releases it.  If there is a need for a
'Terminal' or 'FileNameandOptions' module on a SPARC, then it could be written
and distributed, just as mail, rn, uudecode, and most other utilities are.
None of this is language or library deficiency.   

I bought a source license to one of the early ETH compilers, and partially 
ported
it as a cross compiler on an IBM-PC using Logitech.  This involves enough
machine differences to make me believe that Modula-2, when well written, is
inherently portable.


-- 
Aubrey McIntosh  /  Chemistry  /  University of Texas  /  Austin, TX 78712
..another Gaelic learner...