Hash composers and code blocks
Aaron Sherman
==========
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.
Aaron Sherman
> Proposal: A sigil followed by [...] is always a composer for that type.
>
> %[...] - Hash. Unicode: ⦃...⦄
> @[...] - Array. Unicode: [...]
...
I left out ::, which is probably a mistake. Part of the elegance of
this, IMHO, is that it behaves the same for all sigils. The body of ::
should probably be a capture whose invocant (required) is a type name:
::[Foo: 1,2,:x<3>,:y<4>]
Which is identical to:
Foo.new(1,2,:x<3>,:y<4>)
Unicode for that seems like overkill, but if we needed it, ⦗...⦘ would
suffice. Thus:
⦗Foo: 1,2,:x<3>,:y<4>⦘
That gives me the visual sense that something big and heavy is being
created ;-)
Mark J. Reed
> 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 ;)
Are those supposed to be question marks up there (meaning "up for
discussion"), or did something go awry in the email encoding (possibly
on my end)?
--
Mark J. Reed <mark...@mail.com>
Aaron Sherman
There is one occurance of ? in there (Seq has no sigil, and thus no
<sigil>[...] form).
The rest are Unicode characters, and my headers did include:
Content-Type: text/plain; charset=UTF-8; format=flowed
so, I don't think there's a problem there... still, what Unicode
characters are chosen (if any) is rather moot. The real issue is: do we
want to have a disambiguated composer form, and if so is <sigil>[...]
the right choice?
Aaron Sherman
(updated based on followup conversations)
> Proposal: A sigil followed by [...] is always a composer for that type.
>
> %[...] - Hash.
> @[...] - Array.
> &[...] - Code.
> |[...] - Capture. Identical to \(...).
> $[...] - Scalar. Like item(...), but forces copying even in argument lists
Added after:
::[Type:...]
fglock pointed out that @(...), %(...) actually already do this.
I was going to modify this proposal around that, but then I looked at
the variations. I now contend that <sigil>(...) has more of a "cast"
semantic than a "compose" semantic. If we wish to combine the two, then
we could, but that would require that &(...) take a block body, not an
expression (again, not what &(...) does now, at all).
In the end, I still think the bracket forms are a wonderfully simple
solution to the ambiguity problem, and I'm more convinced every time I
look at this that the ambiguity needs a fix. What's more, having one
syntax for composition of container and non-container types in free-form
data structures is tremendously appealing. We've thrown out ${...}, so
we could use that instead of brackets, but that's just one more
shift-key, and it doesn't seem to buy much. Am I wrong?
fglock also suggested that this might not be seen by the community as
"looking like perl." I'm not so sure that's the case, since we already
have @(...) and @{...}, but even if some do feel that way, I AM NOT
proposing that we eliminate any currently correct behavior. I am only
suggesting that we add "one more way to do it" for those of us who want
to dodge the ambiguity. Surely, that's not a big request?
To sum up:
<sigil>(...) - cast expression ... to type implied by sigil
<sigil>[...] - composition of type implied by sigil
Nice and uniform, no?
Dr.Ruud
> Aaron Sherman:
>> 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
;)
>
> Are those supposed to be question marks up there (meaning "up for
> discussion"), or did something go awry in the email encoding (possibly
> on my end)?
It took me a while to find a font that displays them: Code2000.
http://en.wikipedia.org/wiki/Code2000 (shareware)
See also:
http://en.wikipedia.org/wiki/Free_software_Unicode_fonts
http://en.wikipedia.org/wiki/Unicode_typefaces
http://www.alanwood.net/unicode/fonts_windows.html
--
Affijn, Ruud
"Gewoon is een tijger."