Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!ut-emx!ccwf.cc.utexas.edu From: aubrey@ccwf.cc.utexas.edu (Aubrey McIntosh) Newsgroups: comp.lang.modula2 Subject: Re: Oh My! Modula-2 Book Message-ID: <45670@ut-emx.uucp> Date: 16 Mar 91 00:02:17 GMT References: <2177.27DB3A01@puddle.fidonet.org> <2441@sumax.seattleu.edu> <1991Mar14.191513.20184@iitmax.iit.edu> <1991Mar14.235248.24540@jato.jpl.nasa.gov> Sender: news@ut-emx.uucp Reply-To: aubrey@ccwf.cc.utexas.edu (Aubrey McIntosh) Organization: The University of Texas at Austin Lines: 60 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. 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...