Hi,
Yuval Kogman <nothingmuch <at> woobling.org> writes:
> On Thu, Aug 18, 2005 at 12:24:40 +0000, Ingo Blechschmidt wrote:
> > 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...:
>
> But it's still the runtime that runs them
>
> Compilation has a runtime that runs the compiler, and compile-time
> code. The output may be handed down to another runtime that actually
> "runs".
Oh, right, of course. I misread that.
> > 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).
>
> Not &code, but the return value of &code.emit
Hm, Str? Or possibly a subtype of Str, allowing:
$template.param("globaljs") = $emitted.global_section;
$template.param("js_of_a_div") = $emitted.main_section;
Of course, these additional methods wouldn't be available for
all backends.
> > > - 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?
>
> Not types in the "kind of value" type... Read it as:
>
> handling of data... what types of data... global variables are
> types of data
Ah. Normal globals can probably be freezed more or less exactly
like normal lexical variables, I don't see a big problem there.
WRT pads: Luckily, pads are constant, i.e. you can't inject
a new lexical variable at runtime (%MY::<new_var> = ...).
The backend does have to take care of read accesses, of course
(think $CALLER::, $::(...), %MY::, %OUR::, etc.).
FYI, this is how PIL2JS handles this currently:
my $foo; # is really
my $foo; %MY::<foo> := $foo;
sub foo {...}; # is really
sub foo {
my %MY:: = ();
push @*CURRENT_SUBPADS, %MY::;
LEAVE { pop @*CURRENT_SUBPADS };
...;
}
> > > - closures?
> >
> > A subclass of Code, e.g. Bare.
>
> How are they stored?
The code itself isn't much a problem, much more problematic
are access to outer lexical variables:
my $a = ...;
my $b = { ...$a... };
$b();
A backend can then either use the native closure support of the
runtime it targets (if existing) or it has to lambda lift, i.e.
my $b = { ...$a... }; # is really
my $b = -> $a { ...$a... };
$b(); # is really
$b($a);
> > I'd like to have a pragma to switch between these policies.
>
> I doubt a pragma is enough - we need full introspection and fine
> grained control for this, both in the lexical and the dynamic
> scopes.
Even better! :)
--Ingo
--
Linux, the choice of a GNU | The computer revolution is over. The
generation on a dual AMD | computers won. -- Eduard Bloch
Athlon! |
