Yuval Kogman <nothingmuch <at> woobling.org> writes: 
> So now that the skeptics can see why this is important, on the 
> design side I'd like to ask for ideas on how the code serialization 
> looks... 
>  sub { $?DOM.document.write("<p>hello world!</p>") }.emit( 
>   :runtime($browser_autodetect_object), 
>   # this can be guessed by asking the $runtime object: 
>   # :language<javascript>, 
>  ); 
> This is superficially nice, 
> but here's what's missing: 
>  - what exactly is a code object? 
>   - a wrapper for some PIL code 
>   - that can be executed by the runtime 
Code objects may as well be executed at compile-time 
(think macros, use and BEGIN blocks), but...: 
    sub foo { $?DOM.document.write(...) } 
    BEGIN { foo() };   # error, there's no $?DOM object 
                       # at compile-time! 
>  - what exactly is &code.emit 
>   - also an object? 
Well, you call &code.emit above, so it's probably a Code 
object, even though it calls subs and methods from the 
Perl6::Internals namespace (or somesuch). 
>  - handling of data 
>   - types of: 
>    - globals? 
I've probably misunderstood you, but can't globals, like all 
other variables, have any type you want them to have? 
>    - closures? 
A subclass of Code, e.g. Bare. 
>   - two examples of data sharing policies: 
>    - the border between the webapp and the browser is 
>      smudged by serialization and proxy objects 
>    - the border between the webapp and the browser is 
>      and distinct, and calls between the two are done by 
>      explicitly invoking one runtime from the other 
I'd like to have a pragma to switch between these policies. 

Reply via email to