[squeak-dev] Character space in literal arrays

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Mon Apr 3 20:45:04 UTC 2017


I mean, the decompiler knows that it's a literal...

2017-04-03 22:41 GMT+02:00 Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com>:

> Something strikes me: if it's a literal, then we should print it as
> literal rather than asking whether we should or could...
>
>
> 2017-04-03 22:34 GMT+02:00 Eliot Miranda <eliot.miranda at gmail.com>:
>
>> Hi All,
>>
>>     I'm cleaning up the decompiler and the changes back in 2015 for
>> deciding which characters are literal or not affects e.g. Date>>printOn: ::
>>
>> printOn: aStream
>>
>> self printOn: aStream format: #(1 2 3 $  3 1 )
>>
>>
>> This currently decompiles as
>>
>> printOn: aStream
>> self printOn: aStream format: ((Array new: 6) at: 1 put: 1; at: 2 put: 2;
>> at: 3 put: 3; at: 4 put: Character space; at: 5 put: 3; at: 6 put: 1;
>> yourself)
>>
>> I see four approaches
>>
>> 1. live with it
>>
>> 2. add an exception to LiteralNode>>printOn:indent: that invokes a
>> special case Array print routine that forces printing as a Literal (this
>> also requires special case printing in Character; I suggest we refactor all
>> literal printing as printAsLiteralOn: if we take this approach)
>>
>> 3. relent and allow space (but no other whitespace character) to be
>> considered as a literal
>>
>> 4. make an exception for Character space only when being printed in an
>> Array:
>>
>> shouldBePrintedAsLiteralVisiting: aSet
>>
>> ^self shouldBePrintedAsLiteral or: [self == Character space]
>>
>> 2. is I think the nicer.  It would allow LiteralNode to insist that a
>> literal print itself as literal and hence would correctly decompile e.g.
>> the legal (but rightly disapproved of)
>> shouldBePrintedAsLiteralVisiting: aSet
>>
>> ^self shouldBePrintedAsLiteral or: [self == $ ]
>>
>> Thoughts, opinions?
>> _,,,^..^,,,_
>> best, Eliot
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170403/1a0857a9/attachment.html>


More information about the Squeak-dev mailing list