1. specialise () to parse as (,)
2. scalars are singleton lists, so () naturally
3. make (1) die horribly.
We all seem to agree that #3 is least useful and probably wrong. But
there's a divide between whether #1 or #2 is the "right" behavior.
#2 implies that (1) == 1
#1 means that (1) == 1 and (1) is an error
FWIW, I'm in favor of #1
What does p6l think? (What does @Larry think?)
Jonathan Scott Duff
#1 also means that ($aref) is $aref, rather than $aref.
I pick #2, also because I think being able to pass scalars where arrays
are expected simplifies other parts of the language as well.
I favor #3 as syntax error.
But note $TSa == all( none(@Larry), one($p6l) ) or so :)
TSa (Thomas Sandlaß)
It may or may not help, but I direct your attention to:
Aaron Sherman <a...@ajs.com>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
(*) Of course, that's assuming that there's at least one value in the
list as a whole -- PDL does, and perl 6 should, support zero-element
lists; any looping or threading construct on a zero-element list is a no-op.
#2 is also more intuitive and comfortable. () in P5 constructs a list,
which is why (split ' ', $foo) works so nicely.
Hm? Under #2, no matter whether @foo is (1) or (1,2), the construct
(@foo) would always means @foo.. Not sure how the length of @foo
I think it has to be #1. We can't have (@foo) working at two different
indirection levels depending on whether @foo == 1.
Tell you what, let's require P5's (...) to be translated to [...],
so (...) should assume scalar context that will return some kind of
array reference. (What Luke said about (1,(2,3),4) still holds, though.
Commas create lists, and lists by default impose list context, and
parens are only for grouping in lists, not scalarifiying.)
Sure (and done). Now that #1 is eliminated, the question is now
whether a simple scalar can be treated as a small (one-element) array
reference, much like a simple pair can be treated as a small
(one-element) hash reference.
1.; # evaluates to 1?
If yes, then (1) means the same as 1. and 1.. If no,
(1) is a runtime error just like 1. -- i.e. unable to find the
matching . multisub under Int or its superclasses.
Maybe we should just let someone poke a Subscriptable role into some
class or other to determine the behavior if they care.
(1) means 1, which is probably undefined, so it dies. That could
be detected at compile time. (my $foo = 1) means $foo, which would
die at runtime, unless there's type inference going on. In any case, I
don't see a List in () without a list-creating expression in the ().
-=- James Mastros
Different abstraction level. Maybe defining the postcircumfix is
exactly what the role does.