Juerd wrote:
If you STILL don't understand that it has nothing to do with
inconsistency or asymmetry, then please allow me to at this point give
up and stop trying to explain.

I would bewail that, because your explainations are very clear.
And it might appear different but I'm just trying to understand
things. Obviously I'm quite bad at it. So keep on helping a pity
old man.

() and [] are as alike as [] and {} or <> and (), or ** and ++.

Ohh, that is interessting. I look at them beeing all basically
the same thing: syntax draped around operations that are lexically dispatched according to the types of the values involved. In other
words my primary interest is in the type system of Perl6 in particular
and all languages running on Parrot in general.

Your expectation, not the language, is wrong.

I have no expectations, and I'm not judging right or wrong.
But passive observation isn't enough either. So I'm asking
questions as well. I hope this is usefull to this list or
at least not considered as pestering.

%a = ( a => 1, b => 2, c => 3 )  # @a = (1,2,3)


I look at it as &infix:{'='}:( Hash, List of Pair : --> Ref of Hash )
and then try to understand how it behaves. BTW, I'm neither sure
of the type of the second invocant parameter nor of the return type.
Even the position of the : is contestable.

%b = { a => 1, b => 2, c => 3 }  # @b = [1,2,3]


&infix:{'='}:( Hash, Scalar : --> Ref of Hash )

That probably does roughly the same as:

%b{ { a => 1, b => 2, c => 3 } } = undef;

Here I ask myself: is &infix:{'='} dispatching to &postfix:<{ }>?
What then ultimately defines hashiness: the type, the indexing
operator or the sigil? The other two are then derived concepts.

And +[1,2,3] seems to mean &prefix:<+>:(Ref of Array: --> Num)
while +(1,2,3) is &prefix:<+>:(List: --> Num). More interesting
are the &infix:<,> inside. Is that &infix:<,>:(:*Num --> Eager of Num)?

BTW, another mystery to me is which operators are pure code types,
which ones are macro assisted---and to what extent---and which are
pure macros aka syntactic sugar/necessity without a specific
implementation backend.

So, to summarize we could interpret our points of view as
"syntax-down" and "type-up" if the upward direction is from
implementation to type to syntax.
TSa (Thomas Sandla▀)

Reply via email to