If you could compile it as a literal, you should be able to decompile it 
as a literal too.
If I'm not mistaken, only option 2. would do this.

Also, there are cases when the method was manipulated after compilation. 
In those cases perhaps the decompiler should raise a warning and create a 
brace array instead of the expression it creates now.

Levente

On Mon, 3 Apr 2017, Eliot Miranda wrote:

> 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
> 
>