I forgot: Is there currently a good way to test whether a block is a copying block (in the VW meaning) in Pharo (11)? This means a block that: - Copies only variables not changing after block creation - Does not need the outer context for evaluation So far did not find an obvious way. It seems that a block always has a reference to its outer context. Variables in copiedValues are not modified after block creation if I understand the class comment correctly, but variables in tempVector can, right? Best, Steffen Steffen Märcker schrieb am Donnerstag, 13. April 2023 15:14:16 (+02:00): Hi Richard! 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.