On Wed, Apr 20, 2005 at 08:51:24AM -0700, Larry Wall wrote:
> That may look like an arbitrary amount of lookahead, but I tried to
> define the hash/closure rule in terms of a semantic analysis rule
> rather than a syntax rule, such that it's always parsed as a closure,
> but at some point in semantic analysis you can look at the AST and see
> that the top-level operator is =>, and throw an implicit "new Hash:
> do" on the front of the closure, or whatever operator it is that
> evaluates a closure for its pairs and builds a hash from it.

Currently in Pugs, the analysis is done when the parser is done parsing a
block, i.e. when there is a Exp already formed:

    -- Try to analyze Exp if the block is bare and without formal
    -- arguments; extractHash merely looks at the toplevel OP, to
    -- see if it matches (pair | =>) or ("," [(pair | =>), ...])
    retBlock SubBlock Nothing exp
        | Just hashExp <- extractHash exp = return \\{}" [hashExp]

>     %ret = map { ($_ => uc $_) }, split "", $text;
>     %ret = map { $_ => uc $_; }, split "", $text;

Sadly, both the grouping parens and the trailing semicolon are currently
ignored as semantically insignificant.

I think the latter suggestions works better, as we already make the
distinction between semicolon-separated Stmts (which contains multiple
Exps), and a simple Exp.

Adding a special form Parens that takes one Exp and simply returns
it is possible, but unless it serves to disambiguate other cases,
that approach seems more heavy-handed to me.


Attachment: pgpSrBabV4fWE.pgp
Description: PGP signature

Reply via email to