Thanks for the pointer, Bob. I read through it and it might be
tangentially related to this. That problem is about scopes being
modeled by subs in parrot. IMHO there is not a great problem there,
since a sub is really an abstraction for entering and leaving a scope
and so a good abstraction for what is being done. Gotos can and are a
problem then, but I'm not sure what the semantics are for jumping into
a scope via a goto in any language is.
My problem is that once you get into the new scope the vars of the
outer scope don't seem to be accessible if the new scope has a var
that shadows (creates a new var with the same name).
What I'm trying to get is the scheme let semantics, and what I'm
getting right now out of the box is the letrec semantics. Take a look
at the R6RS (http://www.r6rs.org/final/r6rs.pdf) page 35 for a good
description of the different types of bindings.
Thinking about it right now it could be done by passing the required
vars into the inner scope's sub as parameters. I'd have to think
about that some more to make sure it would cover all of the required
cases, but my hunch right now is that it won't (or will take a lot of
hoop jumping).
Andrew Parker
On Feb 12, 2008, at 5:13 AM, Bob Rogers wrote:
From: Andrew Parker <[EMAIL PROTECTED]>
Date: Mon, 11 Feb 2008 22:27:27 +0100
Hi all,
I was checking a couple of things in the compiler that I wrote and
put
together a simple program:
let x = 1 in let x = x + 1 in x
which ends up being pretty much equivalent to the perl5:
my $x = 1; { my $x = $x + 1; print "$x\n"; }
The generated code doesn't work however. The problem seems to come
down to the problem that in PIR you cannot distinquish between
lexical
variables of an outer scope and an inner scope that have the same
name
(try running the following PIR) . . .
One might think that because the .lex in "inner" comes after the
find_lex it would find the outer "x" var, but it doesn't seem to.
The
only reason I can think of is that it is because the LexInfo is
defined at compile time based on the .lexs in a scope.
Yes; .lex is more of a declaration, and is scoped to the whole sub.
I'm not sure what is wrong. The solutions that I can think of for
this are:
* mangle variable names in PAST so that we can distinquish the
scopes
from the var names
This is what I do (for now anyway).
* change how PIR and LexInfos work to pay attention to the order in
which lexical vars are declared and used in scopes
That would certainly require some work to implement in Parrot, but it
would have the strong advantage of giving Parrot more detailed
variable
metadata, the sort that debuggers need to report variable values in
HLL
terms, and evaluate expressions in context.
Any ideas?
Andrew Parker
A third solution, which is certainly more complicated for the compiler
writer, is to split out each lexical scope into its own sub, though
this
may not be feasible for your language if it allows "goto" into scopes.
This is the only solution for taking distinct closures within loops;
see
the "Lexical scopes are too coarse-grained for loops" discussion
(RT#44395) of 3-Aug-07.
HTH,
-- Bob Rogers
http://rgrjr.dyndns.org/
