Hi,
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,
Indeed!
> 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
clear
> 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.
--Ingo
