[Cuis-dev] [DEFECT] #copyFrom:count: for OrderedCollections

[Gerald Klix]

I read it, I agree partially.

40 years ago, I started to study „Informatik“ aka . Computer Science
at the Technical University of Munich.
Friedrich L. Bauer than read computer science 101.
He sat in the Algol (68) IFIP Working Group 2.1 (Wirth was also in that 
comity).
Sometimes he came back to this experience, full of rage
about the semantics of Algol 68 and this weird call by
name parameter passing conventions and the semantics,
that were specified by a Van Wijngaarden grammar.
That's a grammar that uses meta-productions, specifying
function overloading – „false ploymorphism“ comes to my mind –
that in turn generated an infinite, but countable number, of
productions, that in turn are used to parse the actual program.

Some compiler guru  – I don't have the source ready – summarized the 
situation as follows:
"If Pl/1 was a fatal diseases, than Algol 68 is capital punishment!"

Concerning semantics and scrutiny by logicians: For these
people – Wirth, Bauer, van Wijngaarden et.al. – using a language that
supported duck typing, like Smalltalk, was a damnable sin.
(Haskell wasn't invented, yet)

At TUM we were taught a programming language called CIP-L,
which rigorous algebraic semantics and a program transformation
system, that could be used transform your program to a procedural one,
where recursion was replaced by (while-)loops, or even gotos.
Needless to say, that all this transformations had strict preconditions.
It was your task to prove that these (meta)-preconditions were met.

In order to teach that syntax isn't that important,
it had two syntaxes one inspired by Pascal and another one,
inspired by Algol, where every expression had a value (it did not have
statements, like its Pascal-variant).

In order to force the student to analyze problems completely,

if condition then <some expression> fi

was equivalent to

if condition then <some expression>
else abort fi

It also had a case statement, where is
the cases' gurads were evaluated in random order,
to force the programmer to cover all cases.

If I compare all this with Cuis and its  refactorings, the later seem to 
be just
the first step.


Concerning Juan's argument of "false polymoprphism":
If there ever was a strict precondition like

For each integer n  and each collection c the following holds:
c new: n :: size = n

then Juan would have had a point. As I pointed out several times,
this never was the case!

Actually Smalltalk-80 used inheritance to conserve space
and not to specify semantics. In fact – see classes Set and Dictionary –
inheritance was and is used to inherit implementation and not semantics.
If you are daring, you could say: "They did it all wrong!".

A Smalltalk with rigorous algebraic or denotational semantics
is an interesting idea. I fear that this is an entirely different beast,
perhaps something like Scheme with Smalltalk syntax.
(In Lisp terminology Smalltalk is a Lisp2, which produces some
interesting problems; trust me, I already implemented such a thing,
I can show you the code).


HTH and Best Regards,

Gerald


Sources:
Friedrich Ludwig Bauer: https://en.wikipedia.org/wiki/Friedrich_L._Bauer
Adriaan van Wijngaarden: 
https://en.wikipedia.org/wiki/Adriaan_van_Wijngaarden
IFIP Working Group 2.1: https://en.wikipedia.org/wiki/IFIP_Working_Group_2.1
CIP-L: 
https://www.amazon.de/-/en/Friedrich-L-Bauer/dp/3540151877/ref=sr_1_1?crid=11N3GSZKBL2DM




On 2/7/24 2:40 PM, Hernán Wilkinson via Cuis-dev wrote:
> The idea is to fix important bugs in the stable release. I think this one
> is an important bug and should be fix in 6.2, in this case keeping
> compatibility (that is, with a different solution to the one used in 6.3).
>
> BTW, I was reading this excellent and timeless paper of N. Wirth from 1974,
> "On the Design of Programming Languages", especially the section "Language
> Design is Decision Making". If you have time, please read that section, I
> think that it summarizes our spirit very well :-).
> Here is the link:
> https://web.eecs.umich.edu/~bchandra/courses/papers/Wirth_Design.pdf
>
> Cheers!
> Hernan.
>
> On Wed, Feb 7, 2024 at 10:13 AM Gerald Klix via Cuis-dev <
> cuis-dev at lists.cuis.st> wrote:
>
>> On 2/6/24 9:01 PM, Juan Vuletich wrote:
>>> On 2/6/2024 2:23 PM, Gerald Klix via Cuis-dev wrote:
>>>> ...
>>>> Juan,
>>>>
>>>> consistency-wise, this all makes sense!
>>>>
>>>> In an implementation that is used for real work,
>>>> you should not changes semantics so lightheartedly.
>>>>
>>>> If you really want to do this you should proceed it like this:
>>>>
>>>> For current Cuis 6.3 you should mark these methods,
>>>> as "to be deprecated" (by some means yet to be invented).
>>>>
>>>> For Cuis 6.4 you could mark them as deprecated
>>>> and write messages to the transcript or bother the user/programmer
>>>> with a (Pre)-Debugger.
>>>>
>>>> For Cuis 6.5 or later you may enforce that semantics.
>>>>
>>>> Of course there still will be hue and cry,
>>>> but people had their time to adapt and
>>>> after a lot of complaining, event I would have found
>>>> a way to live with it :)
>>>>
>>>> Now I am in the middle of an important project (money-wise)
>>>> and I have to deal with that – ah, äm, well – shit!
>>>>
>>>>
>>>> I hope you understand,
>>>>
>>>> Gerald
>>> These changes are being done in the Rolling Release. If you expect
>>> stability, and compatibility issues only when you are ready to face
>>> them, you'd use the Stable Release.
>>>
>>> See
>>>
>> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentation/CuisReleaseProcess.md
>>> vs.
>>>
>> https://github.com/Cuis-Smalltalk/Cuis6-2/blob/main/Documentation/CuisReleaseProcess.md
>>> Thanks,
>>>
>> This document does not say anything about bug fixes.
>> I presume this #copyFrom:count bug will stay in Cuis 6.2 until hell
>> freezes over.
>> Needless to say, that I don't like this either.
>>
>>
>> Best Regards,
>>
>> Gerald
>> --
>> Cuis-dev mailing list
>> Cuis-dev at lists.cuis.st
>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>>
>
>