Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!math.fu-berlin.de!fauern!ira.uka.de!ifistg!bs3!schoebel From: schoebel@bs3.informatik.uni-stuttgart.de (Thomas Schoebel) Newsgroups: comp.lang.modula2 Subject: Re: BIX - BYTE - JPI - Chaos Message-ID: <10236@ifi.informatik.uni-stuttgart.de> Date: 26 Apr 91 14:08:48 GMT References: <10113@ifi.informatik.uni-stuttgart.de> <1991Apr23.170148.23254@iitmax.iit.edu> Sender: news@ifistg.uucp Organization: Informatik, Uni Stuttgart, W. Germany Lines: 152 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