More Pugs Bugs

[Stevan Little]

Got another one!

This one is your basic parsing error, and hopefully easily fixed.
Basically the return statement will not work without a value to return,
unless you have a () after it (which I assume is not "correct" syntax,
but also not really "wrong" syntax (but I will leave that for the
language-designers to figure out)). Here are some basic tests I put
into t/statements/return.t which illustrate the issue.

eval 'sub bar { return }';
eval_is('bar()', undef, '... bare return statement returned undef');

sub bar2 { return() }
is(bar2(), undef, '... bare return statement w/ parens returned undef');

eval 'sub foobar { return if 1; }';
eval_is('foobar()', undef, '... bare return worked with a statement
modifier');

sub foobar2 { return() if 1; }
is(foobar2(), undef, '... bare return worked with a statement
modifier');

- Stevan

[Lev Selector]

These things don't work in pugs yet, right?

=====================
arrays of arrays
hash of hashes
etc.

@ar.elems
@ar.last
=====================

Warm Regards
Lev Selector

[Autrijus Tang]

On Mon, Apr 04, 2005 at 09:01:20PM -0400, Stevan Little wrote:
> eval 'sub foobar { return if 1; }';

I've fixed everything except this. I'm not exactly sure how the postfix
form of "if" is supposed to work here, because the first thing the
parser tries is to parse it as return(if(1)), as a valid expression itself.

As Perl6 parsing is supposed to require no lookaheads, I wonder how
we are to tackle this. Ideas?

Thanks,
/Autrijus/

[Larry Wall]

On Tue, Apr 05, 2005 at 09:22:29PM +0800, Autrijus Tang wrote:

: On Mon, Apr 04, 2005 at 09:01:20PM -0400, Stevan Little wrote:
: > eval 'sub foobar { return if 1; }';
:
: I've fixed everything except this. I'm not exactly sure how the postfix
: form of "if" is supposed to work here, because the first thing the
: parser tries is to parse it as return(if(1)), as a valid expression itself.

That's why there's a statement_control:<if>, and there's a
statement_modifer:<if>, but there's no prefix:<if>. If you see
a statement modifier in the middle of an expression, it must be
interpreted as a statement modifier regardless of the context.
Statement modifiers are among the "most reserved" words in Perl.

So despite the fact that return parses like a list operator and
expects a term after it, the "if" is acting a bit like a semicolon.

If you want to embed a statement control inside an expression, you
have to use "do". We're thinking about allowing "do" without curlies
before any statement_control so that you could say

$x = do if $x { $y } else { $z }

But to make that work we'd have to give a different name to do-FILE
(which we're going to do anyway, so that's not a problem). And that
gives us a way to write the rather useful

$x = do given $x {
when 0 { 'a' }
when 1 { 'b' }
when 2 { 'c' }
default { '?' }
}

I expect general do-EXPR is disallowed. It's only bare blocks and
other statement beginnings that can follow "do". But that includes labels,
so you can say things like:

$x = do LINE: loop {
...
next LINE;
...
}

which there's no way to say in Perl 5 without do-{}.

: As Perl6 parsing is supposed to require no lookaheads, I wonder how

: we are to tackle this. Ideas?

One-token lookahead is fine. It's the arbitrarily long lookahead we're
trying to avoid. Or to put it the other way around, if you have to
backtrack, you've got an error, so use the backtracking capability
to try to give a good error message rather than trying to guess what
they mean. You can backtrack and continue parsing, but only to try
to determine what alternate choice might have made it come out better,
so you can give the befuddled user an intelligent "Did you mean..." hint.

Larry

[Autrijus Tang]

On Tue, Apr 05, 2005 at 08:24:42AM -0700, Larry Wall wrote:
> That's why there's a statement_control:<if>, and there's a
> statement_modifer:<if>, but there's no prefix:<if>. If you see
> a statement modifier in the middle of an expression, it must be
> interpreted as a statement modifier regardless of the context.
> Statement modifiers are among the "most reserved" words in Perl.

Aye. Is there an idea on how the two forms of `if` would be defined
using plain Perl 6?

> So despite the fact that return parses like a list operator and
> expects a term after it, the "if" is acting a bit like a semicolon.

Got it. What if the user had defined a prefix form of `if`, though?
Is it resolved using the precedence table?

Thanks,
/Autrijus/

[Larry Wall]

On Wed, Apr 06, 2005 at 12:32:37AM +0800, Autrijus Tang wrote:

: On Tue, Apr 05, 2005 at 08:24:42AM -0700, Larry Wall wrote:
: > That's why there's a statement_control:<if>, and there's a
: > statement_modifer:<if>, but there's no prefix:<if>. If you see
: > a statement modifier in the middle of an expression, it must be
: > interpreted as a statement modifier regardless of the context.
: > Statement modifiers are among the "most reserved" words in Perl.
:
: Aye. Is there an idea on how the two forms of `if` would be defined
: using plain Perl 6?

That's exactly what the syntactic category syntax is for, and why
parsing has to be done indirectly in terms of syntactic categories,
if you'll recall my message of some weeks ago on parser states.

: > So despite the fact that return parses like a list operator and

: > expects a term after it, the "if" is acting a bit like a semicolon.
:
: Got it. What if the user had defined a prefix form of `if`, though?
: Is it resolved using the precedence table?

Since the prefix syntactic category is only recognized where a term
is expected, I would guess that one of two things would happen.
Either you end up in a situation where a term expectation sees
prefix:<if> and operator expectation sees statement_modifier:<if>,
or both still see the statement_modifier:<if> and prefix:<if> is
effectively invisible. I can argue that one both ways, but I lean
toward the latter interpretation on the basis that someone could
really mess themselves up defining an "interface" function with a

sub if {...}

declaration. On the other hand, maybe we could allow the split
interpration if "if" is defined as a macro, which is less likely to
happen accidentally than "sub if". But that seems a bit hacky. I
think if people really want to override statement modifiers, they
should do it with an explicit grammar munge that elevates prefix:<foo>
to hide statement_modifier:<foo>. By default statement modifiers
are true reserved words, I think.

Larry

[Autrijus Tang]

On Tue, Apr 05, 2005 at 10:33:00AM -0700, Larry Wall wrote:
> : Aye. Is there an idea on how the two forms of `if` would be defined
> : using plain Perl 6?
>
> That's exactly what the syntactic category syntax is for, and why
> parsing has to be done indirectly in terms of syntactic categories,
> if you'll recall my message of some weeks ago on parser states.

Hrm, sorry if it has been covered before, but I was asking for
the code that defines statement_modifier:<if> itself, something like
this:.

sub statement_modifier:<> ($x) is parsed(rx:p/[if|unless]/) {...}
sub statement_modifier:<if> (Expression $body, Expression $cond) {
...
}

except I'm not quite sure of the syntax above, and what to fill in the
"..." part.

> declaration. On the other hand, maybe we could allow the split
> interpration if "if" is defined as a macro, which is less likely to
> happen accidentally than "sub if". But that seems a bit hacky. I
> think if people really want to override statement modifiers, they
> should do it with an explicit grammar munge that elevates prefix:<foo>
> to hide statement_modifier:<foo>. By default statement modifiers
> are true reserved words, I think.

Okay, then I'll make prefix:<if> invisible. :)

Thanks,
/Autrijus/

[Steven Schubiger]

On 5 Apr, Lev Selector wrote:

: These things don't work in pugs yet, right?

:
: =====================
: arrays of arrays
: hash of hashes
: etc.
:
: @ar.elems
: @ar.last

I'm not sure about AoA's, HoH's, etc. since I don't have a working
pugs installation (yet), due to ghc not compiling properly.
But to my knowledge, the last two should work.

Steven

[Lev Selector]

Steven,

I do have recent installation:

pugs -> /usr/local/ActivePerl-5.8/bin/pugs (Version: 6.0.13)
ghc -> ghc-6.4

But I can't make Arrays of Arrays or Hash of Hashes work.
@ar.elems & @ar.last don't work either.

Unless I am doing something wrong - then may be somebody
can show an example of usage?

Warm Regards
Lev

[Nathan Gray]

On Wed, Apr 06, 2005 at 09:52:40PM -0400, Lev Selector wrote:
> But I can't make Arrays of Arrays or Hash of Hashes work.
> @ar.elems & @ar.last don't work either.

Autrijus' journal entry (http://use.perl.org/~autrijus/journal/) from
Wednesday states one of the goals for this week is:

* Implement multidimensional data structure.

> Unless I am doing something wrong - then may be somebody
> can show an example of usage?

pugs> my @ar = <a b c>; say @ar.elems;

I'm not sure where you found @ar.last.

-kolibrie