2009/10/31 Bert Freudenberg <bert at freudenbergs.de>:
>
> On 30.10.2009, at 19:13, Nicolas Cellier wrote:
>
>> 2009/10/30 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
>>>
>>> 2009/10/30 Eliot Miranda <eliot.miranda at gmail.com>:
>>> currently it is a 3 stages rocket:
>>>
>>> Array with: 1. -> #(1)
>>> Array with: 1 at 2. -> {1 at 2}
>>> Array with: OrderedCollection new. -> an Array(an OrderedCollection())
>>>
>>>> prints as { OrderedCollection () } than #(OrderedCollection ()).  The
>>>> first
>>>> is a syntax error but the second is completely ambiguous (i.e. evaluates
>>>> to
>>>>  #(#OrderedCollection #())).
>>>> So I don't see the need to provide isSelfEvaluating.  isLiteral gives
>>>> you
>>>> all that you need to avoid printing an Array as a literal when it isn't.
>>>>  And if you've drunk the braces kool aid (which I have, while studying
>>>> my
>>>> agrippa) you're happy with Arrays printing themselves as brace
>>>> constructs
>>>> naively even when the naive print produces non-code.
>>>
>>> That's a fair and simple approach.
>>>
>>
>> I gave it a try, now every Array print as #( ... ) if literal, { ... }
>> otherwise
>> Please vote
>
> I like the self-evaluating print string. It's useful for interactive use and
> debugging. Plus shorter, usually.
>
> - Bert -
>

Hi Bert,

You don't loose it.
Array that previously printed as literal #( .. ) still do
Array that previously printed with braces { .. } (isSelfEvaluating) still do.
Array that did print anArray( ... ) now print using { ... }
So, you only loose quick identification of Array that can't be
re-evaluated to itself

Note that isSelfEvaluating is plenty implementors for 1 sender, and
was not correct anyway, and would be overkill to correct
A killing example:
    (Array with: (0 at 0 extent: 1 at 1) -> 0)
So that was the rationale to trade off quick identification

Is this acceptable ?