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.: 
    # Compile-time error: $*DOM not declared 
    #!/usr/bin/pugs -BParrot 
    use JavaScript::Browser <$*DOM>; 
    # error: $*DOM does only work when running in a browser 
    #!/usr/bin/pugs -CJS 
    use JavaScript::Browser <$*DOM>; 
    # 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. 
Linux, the choice of a GNU | There are no answers, only 
generation on a dual AMD   | cross-references.   
Athlon!                    |  

Reply via email to