GRANGERG@VTVM1.BITNET (Greg Granger) (04/02/91)
Speaking of BIX (which I'd like to try, 'cept I'm poor) ... did anyone notice the "Onion with Garlic clove" that JPI recieved in the Chaos Manor column for ... merging M2 and C :-) (wish I could remember the exact quote, cause it's the kind of off-handed bite that keeps me reading Mr. P's column). Now I'm not trying to start a flame war I use to read JPAM and I know that JPI has this hard-line stand that the only problem with JPI M2 V2 is the manuals (which 'they be fixing'). The way they justified all the C kludges forced into the _M2 _language, was almost (but not quite) enough to make me switch to another compiler but alas, I am poor, and the V1 of their compiler was slick. I hope they do a 'proper' job with V3 (and I hope they get it out the door before their free coupon expires), but judging from their "we make no secert that we are a multi-compiler company, always have been, always will be" (which appears to mean their goals are to change any language so that it will compile with there ONE compiler) attitude I expect V3 will require keywords in lower case and 'printf' and 'scanf' for I/O. <big sigh> Such is life, I'm really an optimist (really!), for example I'm still hoping someone will build a 'popular' and cheap box using the NS32000 series processor. I'm having a bad morning, does it show? Greg
brandis%INF.ETHZ.CH@UCF1VM.CC.UCF.EDU (Marc Brandis) (04/03/91)
I agree with you on your opinion of JPI Modula-2 V2. I think that V1 was much better. I really hated the long compilation time V2 exhibits, even if you turn all optimizations off. It is my impression that if you turn them off, the code is already optimized, if you turn them on, the compiler burns millions of additional CPU cycles to get the last few percent of run-time improvement. But maybe this is what most people are looking for. They are used to slow compilations anyway (and do not understand where the productivity benefit of fast compilations lays) and they heard so much about optimizations from Microsoft that they will not buy a product unless it is optimizing. -:) However, I do not understand why you would like to get a cheap system based on the NS32000. The NS32000 is quite a clean architecture, but it is slow and it will remain so. It is just too CISCy, especially in terms of unnecessarily complicated interpretation of data structures at run-time (I am thinking at the module and link tables). NS is not going to develop this family further (the new architecture is the "Swordfish", a rather conventional RISC chip), so you will be stuck with the current highest performing members of the family: the 532 and the GX32. In fact, everybody at our lab has his workstation based on the NS32000 family (the "Ceres" workstation) and we are quite content with it and the "module" features in the chip are used in our Oberon system (the newest development of Wirth). However, even we considered changing it not to use the "module" features because it would be only slightly more complicated and a lot faster. Nobody changed it at the moment (since people have other stuff to do), but eventually somebody may do it. On the long run we may turn our heads completely away from the NS32000. If we want workstations with more than 5 MIPS there is no other way than to change to a different architecture. I do not know what this architecture will be, but I am quite sure that the change will occur in the next two years. In other words: on the long run, the NS32000 is a dead end. Cheers, Marc-Michael Brandis Computer Systems Laboratory, ETH-Zentrum (Swiss Federal Institute of Technology) CH-8092 Zurich, Switzerland email: brandis@inf.ethz.ch
Rw.Hutchinson@f503.n151.z1.fidonet.org (Rw Hutchinson) (04/05/91)
In a message to All <02 Apr 91 22:33> Greg Granger wrote: GG> From: GRANGERG@VTVM1.BITNET (Greg Granger) GG> Date: 2 Apr 91 14:09:41 GMT GG> Organization: The Internet GG> Message-ID: <INFO-M2%91040209465626@UCF1VM.BITNET> GG> Newsgroups: comp.lang.modula2 GG> I use to read JPAM and I know that JPI has this hard-line stand that GG> the only problem with JPI M2 V2 is the manuals (which 'they be fixing'). GG> The way they justified all the C kludges forced into the _M2 _language, GG> was almost (but not quite) enough to make me switch to another compiler GG> but alas, I am poor, and the V1 of their compiler was slick. I was under the (woefully mistaken?) impression that most of the changes to be found between 1.0 and 2.0 of the Jensen compiler, were also features that might be found, earlier, in Oberon, and hence had been implicitly sanctioned by Wirth. What is being talked about here? I assume we are talking about something more or less in the spirit of object orientation. Was there much in version 2.0 that did not have a close parallel in Wirth's Oberon compiler? I know that there was a great deal in Oberon not to be found in anything calling itself a Modula-2 compiler, such as the abolition of variant records and the addition of built-in garbage collection. But between Modula-2 and Oberon, was it not possible to find a precedent for "almost" anything in JPI M2 2.0? Assuming that there are features in JPI M2 2.0, that have never before been seen in association with either M2 or Oberon, what is there about them that makes them so pernicious? Are they pernicious per se, or chiefly so only because it makes source code written for JPI compilation un-portable? -- uucp: uunet!m2xenix!puddle!151!503!Rw.Hutchinson Internet: Rw.Hutchinson@f503.n151.z1.fidonet.org
GRANGERG@VTVM1.BITNET (Greg Granger) (04/07/91)
On Fri, 5 Apr 91 01:34:00 GMT <editor%ucf1vm.BITNET@LILAC.BERKELEY.EDU> said: >... >I was under the (woefully mistaken?) impression that most of the changes to be > found between 1.0 and 2.0 of the Jensen compiler, were also features > that might be found, earlier, in Oberon, and hence had been implicitly > sanctioned by Wirth. What is being talked about here? I assume we are > talking about something more or less in the spirit of object > orientation. Hmmm, well I guess it is somewhat a matter of taste, but M2 isn't Oberon nor would I what it to be, newer is not always better. Further, 'implicitly sanctioned by Wirth' is a bit of a broad statement, imagine if you saw that on a bright red peel sticker (the kind marketing people are so fond of) on your lastest compiler product box ;-) Well in terms of object orientation, JPI did add some OOP features, these were in the spirit of Borland Turbo Pascal. In TP these features greatly increased one's ability to encapsulate, but M2 was already strong in this area. I believe it would have been better to have added operator overloading, and a few parameter passing enhancements, IF OOP was the intent. I believe JPI fell to the market pressure of "gee we have to say it's object oriented or no one will buy it". It was clearly hung on the compiler with little thought about it's value or of the long term concepts that make up OOPS, IMHO strictly marketing hype 'enhancement'. I also read on JPAM (quite a while back) the JPI refused to consider operator overloading because it would "make your code unreadable". >Was there much in version 2.0 that did not have a close parallel in Wirth's > Oberon compiler? I know that there was a great deal in Oberon not to be > found in anything calling itself a Modula-2 compiler, such as the > abolition of variant records and the addition of built-in garbage > collection. But between Modula-2 and Oberon, was it not possible to > find a precedent for "almost" anything in JPI M2 2.0? Again this is a question of whether you want a M2 compiler or a Oberon compiler. Note, that the first copy of Version 2 JPI sent me did have a primitive form of garbage collection (which BTW I think is rarely useful, considering it's overhead, unless you are heavily OO). JPI's version of garbage collection involved the program crashing which did effectively clear the heap :-) This was corrected in later versions. Tracing this problem make me aware of just how C oriented TopSpeed Version 2.0 is. You can trace a lot of calls to the 'CLB' module (this according to JPI stands for 'Common Library') the 'Common Library' is just chocked full of _(proc name) type defs. I traced the heap problem to a _fmalloc (malloc a good sound M2 name :-) call. I get the feeling that TopSpeed C users get a lot of their calls mapped directly to assembly language procedures while TopSpeed M2 users (the companies first customers) get call overhead out the ying-yang, M2 call->M2 call->M2 call->assembly call. >Assuming that there are features in JPI M2 2.0, that have never before been > seen in association with either M2 or Oberon, what is there about them > that makes them so pernicious? Are they pernicious per se, or chiefly > so only because it makes source code written for JPI compilation > un-portable? Un-portablity isn't an issue, a least not until someone comes up with a set of standard libraries. I really comes down to the reason I posted the first message, which was what Jerry Pournelle said in byte (which I have handy today) "A fair-size onion to Jensen & Partners International who thought it might be interesting to turn Modula-2 into C. The old JPI compiler was pretty good; the new one borders on the absurd." The differences between the new compiler and the old: the new requires a least 5 times more disk space, requires more memory, compiles half as fast, was/is buggy and has even poorer manuals. Further, the libraries in the old compiler were simple useful and written in M2, if you wanted to (for example) change the heap manager, it was a fairly straight forward task. The new libraries are ... COMPLEX (in fact I think some of the code was written in an imaginary plane). In short version 1 inbodied certain philosophical concepts about programming and M2 that are utterly and completely missing in version 2. Sigh. Greg Hoping that JPI TopSpeed Modula 2 Version 3 won't be JPI TopSpeed Modula 2 - Oberon - C - ++ Version 3. :-)
jordan@aero.org (Larry M. Jordan) (04/09/91)
I must disagree with Mr. Pournelle's condemnation of JPI M2 V2 whose failings--I admit there are failings--are being blown out of proportion. I refuse to believe that I am the only developer who has not stumbled onto any major failings. (As I have indicated earlier on this forum, I have used the V2 product without major incident on on two significant projects, using a lowly 8086!) I was not disturbed by increased disk space requirements--big deal! Or compilation rate-- We're still talking thousands of lines of code per minute! See Peter Coffee's review of Modula-2 compilers in a past issue of PC-Week). I'd gladly chose a 2000 LPM compiler/system that is part of a multi-language platform. I don't do everything in Modula-2. Even if I don't create multi-lang. apps., why should I have to learn a new editor, a new debugger and M.O.? That time is more important than 4000 vs. 2000 (arb. example) LPM compilation rates. True (and unfortunately so) the system is poorly documented when compared with Borland and Microsoft documentation standards. (Even the V1 docs. were pretty Spartan). I don't want an ARM (shouldn't have to suffer one for Modula-2), but would like more details on the object system--specifically about object creation/initialization; more details and many more examples on the use of the pragma system. Let's hope V3 docs show the lesson learned. I would not go back to V1. The OOP extension IMPO appears well integrated (I've implemented an OOP extension to M2 myself and was pleased with what JPI had done). This is still Modula-2. As to the C'ness complaints I've seen leveled at the product--hogwash. I'm not particularly enamored with C, but have not been tainted by using JPI M2! Regarding libraries...If the intent is to build a multi-lang. platform, then one will probably want to capitalize on REUSE. The same debugger, the same code generator, the same or a shared subset of core libraries. At the lowest levels who cares if the same resources are shared by C and Modula-2?! --Larry
gkt@iitmax.iit.edu (George Thiruvathukal) (04/09/91)
In article <INFO-M2%91040711362771@UCF1VM.BITNET>, GRANGERG@VTVM1.BITNET (Greg Granger) writes: > Well in terms of object orientation, JPI did add some OOP features, > these were in the spirit of Borland Turbo Pascal. In TP these features > greatly increased one's ability to encapsulate, but M2 was already > strong in this area. I believe it would have been better to have added > operator overloading, and a few parameter passing enhancements, IF > OOP was the intent. I believe JPI fell to the market pressure of > "gee we have to say it's object oriented or no one will buy it". I am not so sure Modula-2 needed any object-oriented extensions at all. A Modula-2 implementation with an adequate set of modules might be appropriate. Good library support is to be preferred to syntactic extensions in my opinion. I would probably not be alone on the idea that any implementation of an object- oriented language ought to provide a robust set of classes (like the Smalltalk classes) to encourage the use of the object-oriented paradigm. It is somewhat of a shame that language definition after language definition continues to ignore the issue of standard libraries, as a side note. Sigh. Look at the intricate tangle associated with the C++ programming language. > It was clearly hung on the compiler with little thought about it's > value or of the long term concepts that make up OOPS, IMHO strictly > marketing hype 'enhancement'. I also read on JPAM (quite a while back) > the JPI refused to consider operator overloading because it would > "make your code unreadable". Maybe so, but they have been working on a C++ compiler for some time now and are planning on releasing it with version 3.0, so why the heck would anybody say something so stupid. Seemingly, it would argue against development of languages which implement the feature. > "A fair-size onion to Jensen & Partners International > who thought it might be interesting to turn Modula-2 into C. The old > JPI compiler was pretty good; the new one borders on the absurd." Well, it is no surprise to hear someone from Byte uttering such rubbish. The compiler technology JPI is developing is good, even if the emphasis is not necessarily directed properly wrt the multiple-language environment. JPI is doing compilation techniques that have almost never been implemented on micro- computers. The ideas of machine independent representation, common code generation, and code optimization have come to fruition in early releases of the JPI compilers prior to all of the other vendors. It took Microsoft six major releases to get their C compiler to perform optimizations correctly. Once all was said and done, their compiler still cannot produce the same quality code as JPI's C compiler. Their Modula-2 compiler has always supported the Modula-2 language defined in Programming in Modula-2 and even contains an implementation of the Wirth Modula-2 libraries. So what is the guy from Byte trying to say? > Greg > Hoping that JPI TopSpeed Modula 2 Version 3 won't be > JPI TopSpeed Modula 2 - Oberon - C - ++ Version 3. :-) Well, don't get your hopes up too high! You know how the multiple-language model is inherent to their products. -- George Thiruvathukal Laboratory for Parallel Computing and Languages Illinois Institute of Technology Chicago
gkt@iitmax.iit.edu (George Thiruvathukal) (04/10/91)
In article <1991Apr8.205015.12217@aero.org>, jordan@aero.org (Larry M. Jordan) writes: > I would not go back to V1. For one who does development in one language, Modula-2, version 1 is adequate. Version 2, while it employs the expected extensions for OOP support, really gives Modula-2 programmers nothing new in terms of library support (and in particular class libraries). I believe object-oriented languages are almost totally uninteresting without some decent class libraries (or modules). In a previous message I advised OOP enthusiasts to examine the current debacle associated with the C++ standardization efforts. > As to the C'ness complaints I've seen leveled at the product--hogwash. > I'm not particularly enamored with C, but have not been tainted by > using JPI M2! Regarding libraries...If the intent is to build a > multi-lang. platform, then one will probably want to capitalize on > REUSE. The same debugger, the same code generator, the same or a > shared subset of core libraries. At the lowest levels > who cares if the same resources are shared by C and Modula-2?! Actually, I don't think anybody really cares, save a few purists who really could care less about "silly implementation details." Usually, these same people never get anything done. I would argue, based on language features, that it would not be sensible for all library functions to be sharable, which I must confess is purist in nature. It does not make any sense for a Modula-2 programmer to call the C printf function, because Modula-2 does not support variable arguments and weak-typing. I think JPI marred the languages by bludgeoning them into submission to such foolishness. This is perhaps the only point I would make against JPI's work, as they have been very innovative wrt their project system, common code generation, and the "plug-n-go" idea. -- George Thiruvathukal Laboratory for Parallel Computing and Languages Illinois Institute of Technology Chicago
GRANGERG@VTVM1.BITNET (Greg Granger) (04/16/91)
Sorry I'm so late responding, lots going on ... On Mon, 8 Apr 91 20:50:15 GMT Larry M. Jordan said: >I must disagree with Mr. Pournelle's condemnation of JPI M2 V2 whose >... >4000 vs. 2000 (arb. example) LPM compilation rates. I never said (nor did Dr. Pournelle) that is didn't work (well I they did have a heap problem, but they fixed it). What was said is that the implementation was not true to the design philosophy of M2 or even in line with there version 1 compiler. I have no problem with a multi-lang platform, I like the idea, but it should be implemented is such a way that does _force _the _user _to _deal _with _the _details _of _the _other _languages, _like _the '_' _that _are _generated _by _C _compilers (see JPI's graphics lib). > >True (and unfortunately so) the system is poorly documented when >... >Let's hope V3 docs show the lesson learned. I think they have learned there lesson on docs. Better docs would have saved JPI and it's customers lots of trouble. > >I would not go back to V1. Hmmm, well I'm using V2, but am often temped to nuke it and put V1 back on the system. > >The OOP extension IMPO appears well integrated (I've implemented an OOP >extension to M2 myself and was pleased with what JPI had done). This >is still Modula-2. Well integrated, perhaps, but not well considered. Further, when using those extension, you leave M2, but I don't see any problem with that if portablity is not an issue. I still say is was a no-thought, "let's copy MS and Borland" move. > >As to the C'ness complaints I've seen leveled at the product--hogwash. >I'm not particularly enamored with C, but have not been tainted by >using JPI M2! Regarding libraries...If the intent is to build a >multi-lang. platform, then one will probably want to capitalize on >REUSE. The same debugger, the same code generator, the same or a >shared subset of core libraries. At the lowest levels >who cares if the same resources are shared by C and Modula-2?! Reuse is good, IF the libraries have been designed from the start to support multi-languages and not just stolen from the most recent language offering. Same debugger and code generator are fine (and generally they did a fair job on both), but the libraries are C the main ones they took the time to wrap (increasing call overhead if you don't use C), other they just tell you to use '_' when calling. Generally, V2.0 gives me the feeling of a product rushed out the door (at $100.00 US a pop) about 2 months too early. Which is another gripe, at a time they decreased the quality they increased (tripled) the price. I understand (hope) they have reconsidered that. Greg
gkt@iitmax.iit.edu (George Thiruvathukal) (04/16/91)
In article <INFO-M2%91041514385809@UCF1VM.BITNET>, GRANGERG@VTVM1.BITNET (Greg Granger) writes: > Sorry I'm so late responding, lots going on ... > > On Mon, 8 Apr 91 20:50:15 GMT Larry M. Jordan said: > >I must disagree with Mr. Pournelle's condemnation of JPI M2 V2 whose > >... > >4000 vs. 2000 (arb. example) LPM compilation rates. > I never said (nor did Dr. Pournelle) that is didn't work (well I they > did have a heap problem, but they fixed it). What was said is that > the implementation was not true to the design philosophy of M2 or even > in line with there version 1 compiler. I have no problem with a > multi-lang platform, I like the idea, but it should be implemented > is such a way that does _force _the _user _to _deal _with _the > _details _of _the _other _languages, _like _the '_' _that _are > _generated _by _C _compilers (see JPI's graphics lib). Well, as I mentioned in a previous message, Pournelle is full of it. There is absolutely no good reason for anybody to argue about language "purity" and "philosophy" when discussing a multiple-language development environment. It is never going to be possible to interface Modula-2 and C without some details entering the picture. I might also mention that it is pretty common practice in the art of compilation to generate linkage names which begin with an underscore symbol. > > > >The OOP extension IMPO appears well integrated (I've implemented an OOP > >extension to M2 myself and was pleased with what JPI had done). This > >is still Modula-2. > Well integrated, perhaps, but not well considered. Further, when using > those extension, you leave M2, but I don't see any problem with that > if portablity is not an issue. I still say is was a no-thought, "let's > copy MS and Borland" move. In fact, you and I are in complete agreement here. The only company which has done anything intelligent with object-oriented languages in the PC world is Borland. Their Borland C++ product is equipped with a robust class library and interfaces to the state-of-the-art object-oriented technology (like Actor). Quite frankly, the whole idea of adding objects/classes to a language is useless, if the object paradigm is not supported and encouraged. The only way to support (encourage) the use of the paradigm is to include class libraries and examples of non-trivial nature. I, for the sake of myself and the rest of the world, hope these vendors will eventually get the idea that object- oriented is more than just another buzzword which makes everybody's hair stand straight and eyes pop out. > [inessential stuff deleted] > main ones they took the time to wrap (increasing call overhead if you > don't use C), other they just tell you to use '_' when calling. If you use Modula-2 as Modula-2, there is no additional overhead for procedure calls. In fact, in JPI Modula-2, there is less overhead for a procedure call than there is in Turbo Pascal, because the parameters can be passed in registers most of the time. Your allusion to underscores, I might add, is not relevant at all to call overhead. > Which is another gripe, at a time they decreased the quality they > increased (tripled) the price. I understand (hope) they have > reconsidered that. It is my impression that the product doubled in price for the Standard Ed. -- George Thiruvathukal Laboratory for Parallel Computing and Languages Illinois Institute of Technology Chicago
mdlcpgs@lhn.dsir.govt.nz (04/17/91)
George writes: > people never get anything done. I would argue, based on language features, > that it would not be sensible for all library functions to be sharable, which > I must confess is purist in nature. It does not make any sense for a Modula-2 > programmer to call the C printf function, because Modula-2 does not support > variable arguments and weak-typing. I think JPI marred the languages by > bludgeoning them into submission to such foolishness. This is perhaps the > only point I would make against JPI's work, as they have been very innovative > wrt their project system, common code generation, and the "plug-n-go" idea. Important point missed here. If you are doing a mixed language programming (say you dont have time to re-write someones excellent C-based library of routines that sing and dance), then the advantage of a common library base is smallness of resultant code. If the library stuff isnt in common, then you link in both languages support stuff. This I am sure was JPI intent ( I was one of those who suggested it to JPI on BIX...). Then of course printf isnt lovely but then neither is M2's individual calls for each IO item... :-) Personally, I support the idea of operator overloading and variable no. of parameters in procedure calls. It seems to me to be lack of imagination to suggest that compilers cant do this safely. (and yes, I have suggestions which involve minimal new syntactic elements). Add those features and you get real power in the libraries. Phil
GRANGERG@VTVM1.BITNET (Greg Granger) (04/19/91)
On Tue, 16 Apr 91 04:02:46 GMT George Thiruvathukal said: >In article <INFO-M2%91041514385809@UCF1VM.BITNET>, GRANGERG@VTVM1.BITNET (Greg >>... >Well, as I mentioned in a previous message, Pournelle is full of it. There >is absolutely no good reason for anybody to argue about language "purity" and >"philosophy" when discussing a multiple-language development environment. It >is never going to be possible to interface Modula-2 and C without some details >entering the picture. I might also mention that it is pretty common practice >in the art of compilation to generate linkage names which begin with an >underscore symbol. Yes often he is, but I do like his BYTE articles. I would disagree about the language purity and philosophy issue. I see no reason why, even in a multiple-language development environment, that implementation details can't be hidden. Likely, you are more familiar with 'the art of compilation' than I, the only place I've seen underscores appended to everything is in C. >>... >In fact, you and I are in complete agreement here. The only company which has >done anything intelligent with object-oriented languages in the PC world is >Borland. Their Borland C++ product is equipped with a robust class library >... >oriented is more than just another buzzword which makes everybody's hair stand >straight and eyes pop out. <nod> <smile> marketing .. ain't it grand :-) > >>... > >If you use Modula-2 as Modula-2, there is no additional overhead for procedure >calls. In fact, in JPI Modula-2, there is less overhead for a procedure call >than there is in Turbo Pascal, because the parameters can be passed in >registers >most of the time. Your allusion to underscores, I might add, is not relevant >at all to call overhead. Not directly, but I get the impression that if I were using TopSpeed C I might have to 'go through' 1 to 2 function calls to get to a base level (in the multi-lang system) routine, while under TopSpeed M2 I have to got through 4 to 5 to get to the SAME routine. In short the routines seem to have been written for use with TopSpeed C then kludged up to work with M2, instead of designed from the ground up to work with a multi-lang environment >>... >It is my impression that the product doubled in price for the Standard Ed. Doubled, tripled ... not really important as long as they have adopted a 'reasonable' pricing structure for the future. Don't get me wrong over all I like JPI, and think the are TRYING to do a good job. Unfortunately, trying isn't doing. Hopefully, version 3.0 will be a better effort and a return to M2 (as god intended it :-) Greg
USDGOG@VTVM1.BITNET (Greg Granger) (04/19/91)
On Wed, 17 Apr 91 08:49:18 GMT <editor%ucf1vm.BITNET@LILAC.BERKELEY.EDU> said: >... >for each IO item... :-) Personally, I support the idea of operator >overloading and variable no. of parameters in procedure calls. It seems to >me to be lack of imagination to suggest that compilers cant do this safely. >(and yes, I have suggestions which involve minimal new syntactic elements). >Add those features and you get real power in the libraries. Absolutely!!!!!!!! Why isn't (hasn't) someone done in something other than C++ or smalltalk? Greg
gkt@iitmax.iit.edu (George Thiruvathukal) (04/20/91)
In article <8015.280c0c0e@lhn.dsir.govt.nz>, mdlcpgs@lhn.dsir.govt.nz writes: > > Important point missed here. If you are doing a mixed language programming > (say you dont have time to re-write someones excellent C-based library of > routines that sing and dance), then the advantage of a common library base is > smallness of resultant code. If the library stuff isnt in common, then you link > in both languages support stuff. This I am sure was JPI intent ( I was one of > those who suggested it to JPI on BIX...). > > Then of course printf isnt lovely but then neither is M2's individual calls > for each IO item... :-) Personally, I support the idea of operator > overloading and variable no. of parameters in procedure calls. It seems to > me to be lack of imagination to suggest that compilers cant do this safely. > ^^^^^^^^^^^^^^^^^^^ If you read my discussion, there is no insinuation on my part that compilers cannot do overator overloading, variable parameters, or any C-like syntactic extension correctly. Such an insinuation would be completely absurd, because we (compiler writers) already know how to implement such features. Further, it is the case that compiler writers are implementing such features (as is the case in JPI Modula-2). I will suggest, however, that language extensions probably ought to be done in a fashion consistent with the original philosophy of the language. Modula-2 was designed to support the notion of very strong typing. An extension to the language which allows variable argument lists effectively relaxes the type checking system. > Add those features and you get real power in the libraries. Here is a nifty idea. Extend every language to have all of the features of C. Add a type cast operator. Allow any operator to be overloaded, including the dot and comma. Why not throw in those variable arguments. Maybe even change the type system so it is unreadable by humans (like it is in C). Well, if you add all of those features, you will be able to exploit the "real power" of practically any C library. After all, the semantics of the languages will practically be the same! -- George Thiruvathukal Laboratory for Parallel Computing and Languages Illinois Institute of Technology Chicago
schoebel@bs3.informatik.uni-stuttgart.de (Thomas Schoebel) (04/23/91)
In article <1991Apr19.173651.9572@iitmax.iit.edu> gkt@iitmax.iit.edu (George Thiruvathukal) writes: >I will suggest, however, that language extensions probably ought to be done in >a fashion consistent with the original philosophy of the language. Modula-2 >was designed to support the notion of very strong typing. An extension to the >language which allows variable argument lists effectively relaxes the type >checking system. > >> Add those features and you get real power in the libraries. > >Here is a nifty idea. Extend every language to have all of the features of C. >Add a type cast operator. Allow any operator to be overloaded, including the >dot and comma. Why not throw in those variable arguments. Maybe even change >the type system so it is unreadable by humans (like it is in C). Well, if you >add all of those features, you will be able to exploit the "real power" of >practically any C library. After all, the semantics of the languages will >practically be the same! > >-- >George Thiruvathukal I don't agree. The problem is not to *allow* language extensions, rather than *how* this is done. If your extensions lead to a *chance* to get more (undiscovered) errors, you are right. But who says all this "dirty" features lead to unreadability? An example: I want to implement exact arithmetic, numbers which may be as large as there is memory. Normal Operators like + - * / are not usable in standard MODULA-2, but if I have the chance to make a "dirty" implementation of this, my code will be more readable! Same will be true for other OOP features. So I *want* the ability to express the same semantics as in C, but in a safe way! You may not believe it, but I am a language purist, too! Nothing looks more atrocious than FORTRAN or BASIC style written in MODULA-2. The best language, the best tools will not give you any gain if you don't know how to take advantage from it. So I think the best is to give experts the ability to implement langage extensions, if they know what they are doing. Of course, this is unsafe and may lead to bugs, but you can shield the details from the user. If the interfaces are well designed, the user's system will be more safe. This is the main idea of modularity, which is *totally* missing in C! In Modula, linking may be done type-safe. Extending the language will not generally circumvent all checks! I doubt you really know the original philosophy of MODULA-2. To me the main goals seem not only to be clarity, modularity, safety and so on, but also the possibilities of a SYSTEM IMPLEMENTATION LANGUAGE which has to allow unsafe operations by its nature. But when I am a pig doing dirty things, I have to write this *expicitly* down. For example, If I use a typecast, this may be read as "Now I do dirty things, because I need it and I know what I'm doing". This is the essential difference to C, where I am always a pig even if I don't want to be one! Thomas
gkt@iitmax.iit.edu (George Thiruvathukal) (04/24/91)
In article <10113@ifi.informatik.uni-stuttgart.de>, schoebel@bs3.informatik.uni-stuttgart.de (Thomas Schoebel) writes: > In article <1991Apr19.173651.9572@iitmax.iit.edu> gkt@iitmax.iit.edu (George Thiruvathukal) writes: > >I will suggest, however, that language extensions probably ought to be done in > >a fashion consistent with the original philosophy of the language. Modula-2 > >was designed to support the notion of very strong typing. An extension to the > >language which allows variable argument lists effectively relaxes the type > >checking system. > > > >> Add those features and you get real power in the libraries. > > > >Here is a nifty idea. Extend every language to have all of the features of C. > >Add a type cast operator. Allow any operator to be overloaded, including the > >dot and comma. Why not throw in those variable arguments. Maybe even change > >the type system so it is unreadable by humans (like it is in C). Well, if you > >add all of those features, you will be able to exploit the "real power" of > >practically any C library. After all, the semantics of the languages will > >practically be the same! > > > >-- > >George Thiruvathukal > > I don't agree. The problem is not to *allow* language extensions, > rather than *how* this is done. If your extensions lead to a *chance* to > get more (undiscovered) errors, you are right. But who says all this > "dirty" features lead to unreadability? Maybe you should reread the sentence above more carefully. The "type system" alluded to is the mechanism for one to declare a type expression. "It" refers to the "type system" and does not imply anything about the readability of the overall code in a given application. I was facetiously proposing that we go so far as to change the syntax of type declarations, so Modula-2 looks like C. > An example: I want to implement exact arithmetic, numbers which may be > as large as there is memory. Normal Operators like + - * / are not > usable in standard MODULA-2, but if I have the chance to make a "dirty" > implementation of this, my code will be more readable! Same will be > true for other OOP features. So I *want* the ability to express the > same semantics as in C, but in a safe way! Your argument is fine, except for one fine point. What we are talking about is Modula-2. Operator overloading, definition, and OOP features are more than language extensions. The semantics of the Modula-2 language must be changed in a significant way to accommodate such extensions. To properly accommodate the notion of operator overloading (and operator definition in the Prolog sense) would require significant language extensions (which would invariably be derived from C++ -- the most unfortunate of programming languages). > So I think the best is to give experts the ability to implement langage > extensions, if they know what they are doing. Of course, this is unsafe > and may lead to bugs... No, I believe there exists a serious flaw in your argument. I think there is a big, big difference between those who implement and those who design programming languages. The people at JPI and Borland are language implementors. Their primary objective is to get the product out the door. A secondary (or perhaps insignificant) issue is to design a good language. There is no question that these people know what they are doing when it comes to implementation. You are right about the fact that it is unsafe for the (language implementation) experts to do so, because it may lead to bugs (as well as changes which are inconsistent with the original design philosophy). Many people have complained that one of the penetrating problems at JPI from version to version is the proliferation of bugs. > I doubt you really know the original philosophy of MODULA-2. ^^^^^^^^^^^^^^^^^^^^^ | | Here is how I feel right now :-( . Does that make you :-) ? I do not recall going out of my way to insult anyone, but obviously you have no problem doing so. Let me ask you a question, given your status as an "eminent" philosopher of "language design" in our time: are you Niklaus Wirth? If you are, then you know the original design philosophy of Modula-2. Your discussion unveils your lack of comprehension (or appreciation) of the philosophy of Modula-2, because you echo the chimes of others who believe we ought to add every unsafe feature to the language just so we can get the dirty work done with the minimum amount of effort. Regards, -- George Thiruvathukal Laboratory for Parallel Computing and Languages Illinois Institute of Technology Chicago
schoebel@bs3.informatik.uni-stuttgart.de (Thomas Schoebel) (04/26/91)
In article <1991Apr23.170148.23254@iitmax.iit.edu> gkt@iitmax.iit.edu (George Thiruvathukal) writes: >In article <10113@ifi.informatik.uni-stuttgart.de>, schoebel@bs3.informatik.uni-stuttgart.de (Thomas Schoebel) writes: >>[...] >> I don't agree. The problem is not to *allow* language extensions, >> rather than *how* this is done. If your extensions lead to a *chance* to >> get more (undiscovered) errors, you are right. But who says all this >> "dirty" features lead to unreadability? > >Maybe you should reread the sentence above more carefully. The "type system" >alluded to is the mechanism for one to declare a type expression. "It" refers >to the "type system" and does not imply anything about the readability of the >overall code in a given application. I was facetiously proposing that we go so >far as to change the syntax of type declarations, so Modula-2 looks like C. Do you impute I didn't know what a type system is? Catchword "carefulness": I didn't relate to the type system in neither part of my text. I intended to speak about language extensions in general, and my intension was more on operator overloading. >Your argument is fine, except for one fine point. What we are talking about is >Modula-2. Operator overloading, definition, and OOP features are more than >language extensions. The semantics of the Modula-2 language must be changed in >a significant way to accommodate such extensions. To properly accommodate the Are you sure? The semantics of MODULA-2 must be changed?? As far as I know, standard Modula will (or, at least, should) compile under JPI with standard semantics! >notion of operator overloading (and operator definition in the Prolog sense) >would require significant language extensions (which would invariably be derived >from C++ -- the most unfortunate of programming languages). Again, are you sure? What is if I don't define any (overloaded) operators? Is there a need to have other semantics for standard/predefined operators? Note: I do not claim JPI has correct semantics in spite of their additional features, nor that they have found the best solution. I'm just talking about the general principles what could be done in language design. >> So I think the best is to give experts the ability to implement langage >> extensions, if they know what they are doing. Of course, this is unsafe >> and may lead to bugs... > >No, I believe there exists a serious flaw in your argument. I think there is a >big, big difference between those who implement and those who design programming >languages. [...] Yes, but the biggest difference is between static languages and extensible languages! Who said that language extensions can be made only by designers or implementors? Perhaps my formulation lead to a misunderstanding: I didn't mean the language implementor, rather I related to language extensions made by an "expert user". Remember: You can view almost every (serious) language as an extensible language, even PASCAL. Defining a new FUNCTION may be viewed as adding new productions to the grammar. Some languages, like FORTH, use the extensionablility as a fundamental concept. Think also of good old ALGOL68. Last not least, extensionablility is one of the underlying main ideas of all OOP languages! So why not be consequent and allow language extensions in a consistent and symmetric way? >> I doubt you really know the original philosophy of MODULA-2. > ^^^^^^^^^^^^^^^^^^^^^ > | > | > >Here is how I feel right now :-( . Does that make you :-) ? > >I do not recall going out of my way to insult anyone, but obviously you have no >problem doing so. Let me ask you a question, given your status as an "eminent" >philosopher of "language design" in our time: are you Niklaus Wirth? Counterquestion: Are you Niklaus Wirth? Who has said that "language extensions probably ought to be done in a fashion consistent with the original philosophy of the language"? All you can interpret from my text is that I claim that MODULA-2 has been intended also as a SYSTEM IMPLEMENTATION LANGUAGE, which is a provable fact. (Read Wirth's Programming in Modula-2, part 5 mainly) Question: Where is the philosophy in the related part of my text? Aren't that either facts or didn't I indicate the others as personal opinion? >[...] Your discussion >unveils your lack of comprehension (or appreciation) of the philosophy of >Modula-2, because you echo the chimes of others who believe we ought to add >every unsafe feature to the language just so we can get the dirty work done >with the minimum amount of effort. Now, what *is* the philosophy of Modula-2? Did I say I'd knew it? Rather, my arguments relate to what is POSSIBLE in language design, which is general and has nothing to do with Modula or how a specific language is named. Catchword "lack of comprehension": Does adding OOP features to a language (say, Modula-2) imply it is getting unsafe thereby? You are ignoring that addition of such features can be done using new keywords, such that the original language can only be altered using these specific keywords (like CLASS, for example). Now, if the user doesn't know anything of the existence of such keywords, is there any danger? Please, don't reply the user might accidentally try such a keyword as an identifier, I think normal language users are not so silly. Another problem, where you are right, is to make the extensions safe, i. e. the extensions have to be restricted somehow. Extending the type system itself may be dangerous in some cases. Now I repeat: My intension is *NOT* to introduce unsafe features in languages like Modula-2. I am an enemy of dirty work! Better you should have cited the last paragraph of my text: >same semantics as in C, but in a safe way! >[...] But when I am a pig doing >dirty things, I have to write this *expicitly* down. For example, If I >use a typecast, this may be read as "Now I do dirty things, because I need >it and I know what I'm doing". This is the essential difference to C, >where I am always a pig even if I don't want to be one! If you don't need dirty things (I *sometimes* need them, but then the language should support it), just leave "dirty operators" etc. out, and all is right! For maximum safety, add compiler switches or special keywords to the language which entitles the user to use "dirty" tricks. Example: UNSAFE IMPLEMENTATION MODULE LowLevel; ... END LowLevel. Without keyword UNSAFE, the compiler refuses all dirty tricks. What about this suggestion? We could also introduce a hierarchy of "dirtyness", so different levels can be authorized. For OOP features, for example, you would have to use a keyword OOP to be entitled to use them. If you are consequent, you also have to introduce additional security mechanisms: variables could be declared as read-only (from outside the implementation), record fields may be even unaccessible, and so on. Here I have a "theory" why the C freaks are defending their language so dogged: It is, in practice, the only one serious(?) language where you can do specific dirty things! Now, generations of software go on, and yesterday's technology may be out of date very soon. OOP is coming! Somewhen C and OOP are marriaged, the result is C++, an unfortunate language for my opinion, too. But the freaks are defending it with arguments like "you can do everything with it". And Modula? Is it bad when a language allows to do as much things as possible, as far as this is done as safe as possible? Safety and universality are no contrary! Another point regarding OOP: Is it the best strategy for the Modula group not to introduce modern software engineering technologies, so that our language will be out of date in 20 or 30 years? Almost every language has passed a development when time went on (just think of BASIC), so why shouldn't this happen to Modula? Now I hope the discussion is more clear. Regards Thomas
news@m2xenix.psg.com (Randy Bush) (04/27/91)
Professor Wirth is said to have said something like [paraphrase]
If you choose to modify the language in any serious way, it would be nice
for you to put your own name on it and not mine.
At least the folk at DEC had the honesty to call it Modula-2* etc. Perhaps the
ISO committee should have the same honesty. Perhaps we all should.
Humph.
--
Randy Bush / news@psg.com / ..!uunet!m2xenix!news