S04 now reads:
==========
However, a hash composer may never occur at the end of a line. If the
parser sees anything that looks like a hash composer at the end of
the line, it fails with "closing hash curly may not terminate line"
or some such.
my $hash = {
1 => { 2 => 3, 4 => 5 }, # OK
2 => { 6 => 7, 8 => 9 } # ERROR
};
==========
I think this is a bit of a problem, since it leads to a number of "looks
fine to the uninitiated" errors, and is likely output from code
generators. In general, there's just no particularly good answer to "why
can't I do that?"
So, why not provide an unambiguous form for all of the sigiled types,
leaving {...} as the ambiguous, half-cousin? (note: I don't think I'm
the first to suggest this)
Proposal: A sigil followed by [...] is always a composer for that type.
%[...] - Hash. Unicode: ⦃...⦄
@[...] - Array. Unicode: [...]
? - Seq. Unicode: ⎣...⎤
&[...] - Code. Unicode: ⦕...⦖
|[...] - Capture. Identical to \(...). Unicode: ⦇...⦈
$[...] - Scalar. Identical to item(value). Unicode: ⦋...⦌
#[...] - A comment. Just seeing if you're paying attention ;)
So, construction of an anonymous data structure might now look like:
my $hash = %[
1 => %[ 2 => 3, 4 => 5 ],
2 => @[ 6 => 7, 8 => 9 ],
3 => &[ %[ 10 => 11, 12 => 13 ] ]
];
Which is also:
my $hash = ⦃
1 => ⦃ 2 => 3, 4 => 5 ⦄,
2 => ⟦ 6 => 7, 8 => 9 ⟧,
3 => ⦕ ⦃ a => 1, b => 2 ⦄ ⦖
⦄;
And there is exactly no ambiguity. You can always use the old {...} if
you like:
my $hash = {
1 => { 2 => 3, 4 => 5 },
2 => [ 6 => 7, 8 => 9 ],
4 => { { a => 1, b => 2 }; }
};
And you get whatever confusion you deserve (I don't even know if that
would do what I think it should, to be honest).
As always, I tend to prefer any solution that involves placing the
disambiguating bits in the FRONT, rather than at the end. I would expect
that compiler-writers feel similarly.
