🚀 go-pugleaf

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