SequenceableCollection>>#allButFirst: inconsistence across subclasses

On 30 August 2019 at 12.28.14, Cyril Ferlicot ([hidden email]) wrote:

On Fri 30 Aug 2019 at 09:34, Julien <[hidden email]> wrote:

Hello,

I opened that issue: https://github.com/pharo-project/pharo/issues/4442

And I think to fix it we need to actually discuss about what we want.

#allButFirst: behaves differently depending on the actual type of sequenceable collection when argument is greater than collection size.

For instance:

#(1 2) allButFirst: 3.  "PrimitiveFailed signaled"

(LinkedList with: 1 with: 2) allButFirst: 3. "PrimitiveFailed signaled"

(OrderedCollection with: 1 with: 2) allButFirst: 3.  "an OrderedCollection() »

The question is then, who is right?

Should #allButFirst: with an argument greater than the collection size raise an error

Or

Should #allButFirst: with an argument greater than the collection size returns an empty collection ? 

I asked a few people about it @ ESUG and it appears that the expected behaviour from #allButFirst: is not the same to all people.

We need to decide so we improve consistence of collections.

And then, we need to document that with a test :-).

Hi, 

I was one of the person who discussed this with Julien at ESUG and IMO it should launch an error. 

While working on complexe models, errors in such cases are really really really helpful to find bugs. Errors such as SubscriptOutOfBound or NotFound help me a lot to find bugs and sometimes without this kind of methods it could have take me days to find the problem (and it’s only in the case I know there is a bug).

Cheers.

Julien

---

Julien Delplanque
Doctorant à l’Université de Lille

http://juliendelplanque.be/phd.html
Equipe Rmod, Inria

Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq

Numéro de téléphone: +333 59 35 86 40

--

Cyril Ferlicot
https://ferlicot.fr

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 <[hidden email]> 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