[squeak-dev] CompiledCode(SequenceableCollection)>>#flatten

Eliot Miranda eliot.miranda at gmail.com
Thu Dec 30 18:34:58 UTC 2021


Hi Christoph,

> On Dec 30, 2021, at 4:23 AM, Christoph.Thiede at student.hpi.uni-potsdam.de wrote:
> Hi all,
> 
> this fails:
> 
>     {Object >> #halt} flatten.
> 
>     CompiledMethod(Object)>>error:
>         Receiver: (Object>>#halt "a CompiledMethod(343681)")
>         Arguments and temporary variables: 
>             aString:     'subscript is out of bounds: 1'
>         Receiver's instance variables: 
>     (Object>>#halt "a CompiledMethod(343681)")
> 
>     CompiledMethod(Object)>>errorSubscriptBounds:
>         Receiver: (Object>>#halt "a CompiledMethod(343681)")
>         Arguments and temporary variables: 
>             index:     1
>         Receiver's instance variables: 
>     (Object>>#halt "a CompiledMethod(343681)")
> 
>     CompiledMethod(Object)>>at:
>         Receiver: (Object>>#halt "a CompiledMethod(343681)")
>         Arguments and temporary variables: 
>             index:     1
>         Receiver's instance variables: 
>     (Object>>#halt "a CompiledMethod(343681)")
> 
>     CompiledMethod(SequenceableCollection)>>do:
>         Receiver: (Object>>#halt "a CompiledMethod(343681)")
>         Arguments and temporary variables: 
>             aBlock:     [closure] in [] in CompiledMethod(SequenceableCollection)>>flatten
>             index:     1
>             indexLimiT:     48
>         Receiver's instance variables: 
>     (Object>>#halt "a CompiledMethod(343681)")
> 
>     [] in CompiledMethod(SequenceableCollection)>>flatten
>         Receiver: (Object>>#halt "a CompiledMethod(343681)")
>         Arguments and temporary variables: 
>             stream:     a WriteStream
>         Receiver's instance variables: 
>     (Object>>#halt "a CompiledMethod(343681)")
> 
> You get the problem, we don't want to split up compiled codes. How should we fix it?

I can think of one of two rational ways. The key issue is that a CompiledCode is two sequenceable collections (& a header and trailer), inheriting from ByteArray simply for implementation convenience, and hence do: is not well defined.

So one approach would be to implement CompiledCode>>#do: as self shouldNotImplement with an explanatory comment, stating that at: accesses bytecodes, and literalsDo: should be used to enumerate literals.  I’d also implement bytecodesDo: to complement literalsDo:.

The second approach would be to define CompiledCode>>#do: to enumerate over bytecodes.

> Replace each isString with something like each canBeFlattened? Or just override #flatten on String and CompiledCode instead?

This is a poor approach because it introduces special cases rather than dealing with the underlying issue.

> 
> By the way, I am also not sure whether this is what we expect:
> 
>     {'foo'. 'bar' asText. UUID new} flatten. "#('foo' $b $a $r 188 125 70 227 253 103 13 67 180 100 32 52 18 134 92 153)"
> 
> Maybe also override #flatten on Text and UUID? Any other collections that we do not want to flatten? It is hard to make this decision without knowledge about the domain-specific context ... :-)

KISS.  Strings and UUIDs ate collections so flatten: does the non-magic but predictable thing and indeed answers

 {'foo'. 'bar' asText. UUID new} flatten."#('foo' $b $a $r 188 125 70 227 253 103 13 67 180 100 32 52 18 134 92 153)"

If you want something clever introduce (in your own experimental package first) some variant, fooFlatten: that does what you want.  eg
      flattenWhen: aBlock
      flattenUnless: aBlock

so eg
    {'foo'. 'bar' asText. UUID new}
        flattenUnless: [:e| e isString]

> 
> Best,
> Christoph
> 
> ---
> Sent from Squeak Inbox Talk

Eliot
_,,,^..^,,,_ (phone)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211230/2f58251a/attachment.html>


More information about the Squeak-dev mailing list