Ad 1.
To cut a long story short,
the ANSI Smalltalk standard is the nearest thing we have to a clear
specification
of the nearest thing we have to a consensus.
One of the reasons that Smalltalk gets less use than many of us would
like
is that it can be extremely unpleasant trying to port from one dialect of
Smalltalk to another, so you have to commit to a dialect.
And dialects of Smalltalk have an unpleasant habit of disappearing.
I really liked Ambrai. What was I to do with my Ambrai code when
Ambrai disappeared?
I have never met a better-looking Smalltalk than Dolphin.
ObjectArts stopped selling Dolphin a year or two ago, and open sourced
it.
Today the ObjectArts website has an expired certificate,
pages have the date 2016 on them,
and the GitHub link points to a GitHub site containing an Amber fork
but no Dolphin.
Imagine my relief at discovering that Dolphin *is* still being
maintained,
it's just not where ObjectArts said it was. But I am worried about
whether I should bother with it any more.
Then there's ST/X.
...
Code written for C99 is still useful.
I have four different C compilers and I don't have to care which one I
use.
Code written for Fortran95 is still useful (and yes I know about Fortran
2018).
I have two different Fortran compilers; the one that does the best job
handles
Fortran 2003 but not 2008 or 2018, and as long as I stick to 2003 I
don't have
to care which I use.
The Common Lisp standard came out in 1994 and the HyperSpec is still
useful
to me for writing Lisp today.
My copy of Common Lisp the Language, 2nd edition, is still useful to me.
Ad 2.
In the Pharo 7.0 sources there are on the order of 600 senders of
#signal[:]
-- exceptions and semaphores both use #signal so this is approximate --
and on the order of 1000 senders of #error:, which really should be
exceptions. (It is surprisingly hard to make this change.) The newer
components use exceptions a lot more than the old ones.
Of course some exceptions (like subscript out of bounds) are raised
inside primitives, which Ctrl-N doesn't show you.
One quite strange thing about the ANSI Smalltalk standard is that it
introduced an elaborate exception-handling system into the language
-- much more complicated than C++ or Java or Ada -- but introduced
almost no standard exceptions that a portable program could catch.
Let's take one consequence of this.
What does
(OrderedCollection withAll: #[3 1 4 1 5 9]) copyFrom: 2.5 to: 4.2
do?
My Smalltalk: currently reports 'bad start' coming from the call to
#copyFrom:to: with culprit 2.5.
This is going to be an IndexError some day; cleaning
up the code to use well-chosen exceptions is a mammoth task.
Squeak: 'Array called #basicNew: with invalid argument 2.7'
Of course there is no 2.7 in our code...
Pharo: 'PrimitiveFailed: primitive #basicNew: in Array class failed'
VW: 'Unhandled exception: This message needs a positive integer argument'
appearing to come from OrderedCollection>>new:
VisualAge Smalltalk: drops you into a debugger with no actual
explanation;
the only number in sight is 2.7, which is not one of the numbers we
provided.
GNU Smalltalk: 'Object: 1 error: The program attempted to divide a
number by zero'.
I kid you not.
Exceptions could be useful IF you knew what to catch.
Just for grins, sending #copyFrom:to: to an OrderedCollection with a
start
or stop value out of range raises an ExCLDTIndexOutOfRange exception but
sending it to an Array with the same contents does not.
Ad 3.
allButFirst: n ^self copyFrom: n+1 to: self size
and then ask what #copyFrom:to: should do.
This is actually one tiny symptom of a pervasive issue in Smalltalk.
When commercial Smalltalks are riddled with not-quite-working and/or
not-self-consistent stuff in basic classes, what can we expect from
an open source project, unless someone is prepared to donate serious
money for a cleanup?
On Tue, 3 Sep 2019 at 04:01, Kasper Østerbye <kasper.oster...@gmail.com>
wrote:
> This is actually an intersting discussion. There are several levels to it.
>
> 1. Should Pharo be compatible with a standard from 1998?
> 2. What is the general view on using exceptions in Pharo?
> 3. What should allButFirst: do?
>
> Ad 1) I am relatively new to Pharo, If backwards compatibility is
> important, it should adhere to the standard and the spirit of the standard.
> If we want a different semantics in some areas, it seems like new methods
> are needed, with names which is not confused with existing standard.
>
> Ad 2) I am so new to Pharo I do not even know how efficient (or expensive)
> exceptions are in Pharo. In most programming languages they are expensive,
> and should not be used as an alternative to an if statement. My views on
> exceptions are very influenced by Bertrand Meyer, which lead me to the view
> that a) Asking for the all but the first three elements of a two element
> array is most likely a broken pre-condition. Hence an error. b) As it is
> the clients responsibility to ensure precondition, we might as well help
> the client of the collection by offering an other method with a different
> pre-condition.
>
> Ad 3. Should follow from the first two :-)
>
> Best,
>
> Kasper
>
