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.
Thanks,
/Autrijus/
pgpSrBabV4fWE.pgp
Description: PGP signature
