Hi,
Yuval Kogman <nothingmuch <at> woobling.org> writes:
> On Sat, Aug 20, 2005 at 22:27:56 +0000, Ingo Blechschmidt wrote:
> > > Not &code, but the return value of &code.emit
> >
> > Hm, Str? Or possibly a subtype of Str, allowing:
>
> I would guess an AST, that is, any object, that implements
> stringification.
>
> the AST could just be the same PIL reblessed with some new
> serialization magic, but I guess for most languages you want to make
> a real AST to AST conversion, and only then serialize.
Even better :)
But we should note that some backends don't generate meaningful
ASTs, simply because they don't convert PIL -> target language
AST -> target language, but PIL -> target language directly. I.e.
my $ast = $code.emit(..., :language<Foo>);
say keys $ast; # "FooCode"
say $ast<FooCode>; # ...
my $ast = { 3 + 4 }.emit(..., :language<PIL>);
say $ast.pBody.pStmt.pExpr.pLV.pArgs[1].pLit.pVal; # 4
> > Ah. Normal globals can probably be freezed more or less exactly
> > like normal lexical variables, I don't see a big problem there.
>
> The question is - should globals be frozen? Or should they
> optimistically refer to values on the other side?
>
> I think that
>
> sub hello {
> $*DOM.document.write("<p>Hello World!</p>");
> }
>
> should capture $*DOM in the same sense that a closure matches them,
> and the global scope is implicitly the uber-parent lexical scope
> type thingy.
>
> Then, once we've unified, we can steal something from C and friends:
>
> $*DOM is external;
> sub hello {...} # $*DOM is not serialized, but will be resolved
> # by the runtime on the other side
>
> Anybody got ideas on how control is needed, and how it should be
> specified?
Hm, I think the $*DOM thing could be solved quite elegantly:
There could be a module JavaScript::Browser or so, which would
export $*DOM. I.e.:
#!/usr/bin/pugs
$*DOM.document.write(...);
# Compile-time error: $*DOM not declared
#!/usr/bin/pugs -BParrot
use JavaScript::Browser <$*DOM>;
$*DOM.document.write(...);
# error: $*DOM does only work when running in a browser
#!/usr/bin/pugs -CJS
use JavaScript::Browser <$*DOM>;
$*DOM.document.write(...);
# fine now
This exported $*DOM object could then be a (proxy) object with
appropriate magic -- i.e. die when the current runtime is not
a browser and relay all calls to the respective native JavaScript
objects otherwise.
I think something like "$*DOM is exported" is too generic,
not sure...
> > The code itself isn't much a problem, much more problematic
> > are access to outer lexical variables:
> >
> > my $a = ...;
> > my $b = { ...$a... };
> > $b();
>
> Right... It is my assumption that actually serializing this is
> trivial. The real question is whether we want to serialize, and
> what parts we would like to serialize when we do.
Hm, probably we should serialize all variables which are not
specifically marked as objects which should not be freezed (e.g.
$*DOM).
--Ingo
--
Linux, the choice of a GNU | There are no answers, only
generation on a dual AMD | cross-references.
Athlon! |
