Re: Perl6 grammar (take V)
[no longer sent to perl6-internals because it's not relevant there]
I see a problem . . whether the problem's with me or the grammar, that's
for you people to decide.
Do I read this part of the grammar correctly?
> sv_literal: /(?:\d+(?:\.\d+)?|\.\d+)(?:[Ee]-?\d+)?/
> | '{' hv_seq '}'<
> | '[' av_seq(?) ']'
> |
>
> hv_seq: /,?/
>
> term: '<' expr(?) '>'
> | subscriptable subscript(s?)
> | /$CONTEXT/o term
> | sv_literal <
> | class
> | closure<
A "term" can be either a scalar literal ("sv_literal") (which might be a
hash reference literal), or a closure (which might be a block).
Both of those could be written "{ stuff }", for various values of stuff,
but it looks like the current disambiguation rule is "if it's nothing
but a sequence of "pair"s, then it's a hash ref, otherwise it's a
closure.
My perl5 sensibilities tell me that that's likely to cause a problem
when I want to do something like this:
$hashref = { function_returning_hash() };
because I won't get the function's return values put into a hash,
because the stuff inside the { ... } isn't a list of pairs. Instead
I'll get a (reference to) a closure, not at all the same thing.
Of course, in perl5, the requirement that "sub" prefix any
closure-as-a-term nicely disambiguates that, but I understand that this
is being phased out for perl6 (the grammar backs that up).
How does perl6 distinguish between:
$hashref = { function_returning_hash() };# call sub, get hash ref
and
$subref = { function_returning_hash() }; # make closure, don't call sub yet
?
(I hope the answer isn't "white space" . . )
[Hi, I'm new around here, so I'll give you the three-line introduction.
I teach Perl at Monash Uni, my office is in the same corridor as
Damian's, and I like cats, chocolate, and curry. (Not all at once.) ]
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
Ambivalent? Well, yes and no. - button slogan
RE: Perl6 grammar (take V)
Deborah Ariel Pickett:
# [no longer sent to perl6-internals because it's not relevant there]
#
# I see a problem . . whether the problem's with me or the
# grammar, that's for you people to decide.
#
# Do I read this part of the grammar correctly?
#
# > sv_literal: /(?:\d+(?:\.\d+)?|\.\d+)(?:[Ee]-?\d+)?/
# > | '{' hv_seq '}'<
# > | '[' av_seq(?) ']'
# > |
# >
# > hv_seq:/,?/
# >
# > term: '<' expr(?) '>'
# > | subscriptable subscript(s?)
# > | /$CONTEXT/o term
# > | sv_literal <
# > | class
# > | closure<
#
# A "term" can be either a scalar literal ("sv_literal") (which
# might be a hash reference literal), or a closure (which might
# be a block).
#
# Both of those could be written "{ stuff }", for various
# values of stuff, but it looks like the current disambiguation
# rule is "if it's nothing but a sequence of "pair"s, then it's
# a hash ref, otherwise it's a closure.
#
# My perl5 sensibilities tell me that that's likely to cause a
# problem when I want to do something like this:
#
# $hashref = { function_returning_hash() };
#
# because I won't get the function's return values put into a
# hash, because the stuff inside the { ... } isn't a list of
# pairs. Instead I'll get a (reference to) a closure, not at
# all the same thing.
#
# Of course, in perl5, the requirement that "sub" prefix any
# closure-as-a-term nicely disambiguates that, but I understand
# that this is being phased out for perl6 (the grammar backs that up).
#
# How does perl6 distinguish between:
# $hashref = { function_returning_hash() };# call sub,
# get hash ref
# and
# $subref = { function_returning_hash() }; # make
# closure, don't call sub yet
# ?
When Perl can't disambiguate, you have to do it instead:
$hashref = hash { function_returning_hash() };
$subref = sub { function_returning_hash() };
Of course, there may be other ways for Perl to disambiguate--this one
comes to mind:
my HASH $hashref;
my CODE $subref;
As for the above grammar, I suspect that the is misplaced. It
should probably be allowed to fall through to the closure.
(Alternatively, always parse it as a closure and afterwards run through
the parse tree, checking all the closures and converting those that only
contain pairs.)
# (I hope the answer isn't "white space" . . )
#
#
# [Hi, I'm new around here, so I'll give you the three-line
# introduction. I teach Perl at Monash Uni, my office is in the
# same corridor as Damian's, and I like cats, chocolate, and
# curry. (Not all at once.) ]
Well, any friend of Damian's... :^)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
RE: Perl6 grammar (take V)
On Sun, 14 Jul 2002, Brent Dax wrote:
> Deborah Ariel Pickett:
> # My perl5 sensibilities tell me that that's likely to cause a
> # problem when I want to do something like this:
> #
> # $hashref = { function_returning_hash() };
> #
> # because I won't get the function's return values put into a
> # hash, because the stuff inside the { ... } isn't a list of
> # pairs. Instead I'll get a (reference to) a closure, not at
> # all the same thing.
You've got a point. There's an easy way to say "I want a sub":
my $sub = -> { ... }
But I can't think of a similarly punctuation-intensive way to say "I want
a hash." (someone please step in and correct me).
> # that this is being phased out for perl6 (the grammar backs that up).
I wouldn't take the grammar too seriously -- it's more or less one
person's interpretation of the Apocalypses, Exegeses, and recent mailing
list traffic.
> my HASH $hashref;
> my CODE $subref;
So if I have the above two declarations, and do this later:
$hashref = { ... };
$subref = { ... };
It does "the right thing"? This could work up to a point, but Perl can do
crazy things like this:
$foo ?? $hashref :: $subref = { ... };
and propagate context differently to different branches of the ternary
(try doing $x ? @y : $z = (2,3,4) sometime -- very cool!). And while we
could interpret the block differently on each branch, that seems a bit too
scary.
> (Alternatively, always parse it as a closure and afterwards run through
> the parse tree, checking all the closures and converting those that only
> contain pairs.)
Or use context to try and figure it out. Unfortunately, from the outside
I think either would just look like "a reference". Maybe if the compiler
could figure out that your function would return pairs, it could fix
things up so that turns into a hash-ref. But then you can get into
trouble with a function that returns pairs only in non-hash-ref
contexts...
/s
Re: Perl6 grammar (take V)
On Monday 15 July 2002 06:57 am, Sean O'Rourke wrote:
> On Sun, 14 Jul 2002, Brent Dax wrote:
> > Deborah Ariel Pickett:
> > # My perl5 sensibilities tell me that that's likely to cause a
> > # problem when I want to do something like this:
> > #
> > # $hashref = { function_returning_hash() };
> > #
> > # because I won't get the function's return values put into a
> > # hash, because the stuff inside the { ... } isn't a list of
> > # pairs. Instead I'll get a (reference to) a closure, not at
> > # all the same thing.
>
> You've got a point. There's an easy way to say "I want a sub":
>
> my $sub = -> { ... }
>
> But I can't think of a similarly punctuation-intensive way to say "I want
> a hash." (someone please step in and correct me).
I nominate:
$() == scalar()
%() == hash()
@() == array()
For the above function:
$hashref = %(function_returning_list_which_needs_to_be_hashified());
That would make %() a hash constructor, just like {}.
Ashley Winters
--
When you do the community's rewrite, try to remember most of us are idiots.
