You're completely right. Function equivalence is a beast and in the context of a computer program undecidable for nontrivial cases. And that's a valid reason to ban this entirely. Personally, I can also see some value in recognizing equality in trivial cases, e.g.,

1) constant blocks: [ <same code> ] = [ <same code> ]

2) pure functions: [:a1 ... | <same code> ] = [:a1 ... | <same code> ]

3) enclosed constants: same as 1) and 2) but with references to variables that do not change after block creation.

If I am not mistaken VW 1) and 2) are considered clean blocks and 3) a copying block. For both equality is recognized if the bytecode is identical even if they are created in different contexts. Why do think VW regards them not equal? Do you mean another case or did I miss something? I did a short positive test in my VW 8.3 image.

Of course, one can have different opinions on the matter depending on the applications. I just wonder whether it was a conscious decision not to implement this in Pharo or just one of the thing that could be but haven't been done yet. And no, I do not rely on this functionality. I am just curious. ;-)

Kind regards,

Steffen

Richard O'Keefe schrieb am Donnerstag, 13. April 2023 12:17:05 (+02:00):

There is no agreement between Smalltalk systems about how to

compare block contexts for equality.  In Smalltalk-80 (and I

have two versions of Smalltalk-80 to compare), block equality

is identity.  The same in VisualAge Smalltalk 8.6.3.  The

same in GNU Smalltalk.  The same in Smalltalk/X-JV.

Squeak has a similar definition to  VW.

My reading of the ANSI standard is that it is carefully vague about this.

Equality of functions has been troublesome for decades.

Haskell: bans it.

Standard ML: bans it.

Some other ML-family languages: it's a run-time error.

Lisp family: varies.  Interlisp says nothing.  Scheme gives lower and upper bounds.

Imagine a Smalltalk that recognises [<literal>] blocks and

allocates one static closure per <literal>.  Then

[true] == [true] hence [true] = [true] even when the two

<block constructor>s were in different methods.  The Squeak

and VW definitions would regard them as unequal.  (This is

on my TODO list, principally for [] [true] [false] and [0].)

For the special case of [], you don't *have* to imagine it.

If I'm reading VAST correctly, it treats "empty blocks"

specially.

If you *rely* on the definition of #= for block contexts/closures

you are almost certainly doing something dangerous.  You are

certainly doing something that is not portable.

On Thu, 13 Apr 2023 at 18:55, Steffen M��rcker <merkste@web.de> wrote:

Hi!

In VisualWorks, blocks can be compared with each other. In Pharo the
comparison just checks for Identity. Is this on purpose? For reference,
that's how BlockClosure>>= is implemented in VW:


= aBlockClosure
        ^aBlockClosure class = self class and:
         [method = aBlockClosure method and:
          [outerContext = aBlockClosure outerContext and:
           [copiedValues = aBlockClosure copiedValues]]]

Kind regards,
Steffen

-- 
Gesendet mit Vivaldi Mail. Laden Sie Vivaldi kostenlos von vivaldi.com herunter.