In the last year AJAX has become a significant technology. Now with perl 6 compiling to javascript and perl 5 and what not, i think there is a big future when you merge the two and remove the details.
The way HTML::Prototype works is:
you get an OO interface, which is clean and simple
you use it to generate mostly functions
the functions can be thought of as closures, sometimes being
curried by your values
the functions are in a foreign language, and cannot be executed
- they are really strings that work in another runtime.
Now, in the foreseable future I think it's plausible that the Ajax
libraries will be written in the server side's native language. When
the code is serialized by a template, the template will say to what
language to compile it, and the result is the PIL code, or compiled
foreign language code that will work on the remote side.
What I'm saying is that in the future HTML::Prototype could be
implemented in Perl 6, and the code in question is compiled by the
web app (this is more than quasiquoting - the code is actually
parsed into the native language - full macros, code reuse and so
forth).
The perl 6 code will just be suited for the runtime that a browser
presents, including DOM manipulations, for example.
Now, one step further - ruby is compiled to PIL. Ruby guys maintain
HTML::Prototype, because it's their thing. It's written in ruby, and
perl 6 code gets to use the ruby code, and compile that code down to
javascript for IE, but to PIR for firefox with embedded parrot.
How's that for code reuse and lack of vendor lock-in?
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:
- this is basically the interface to the code emitters - they
need lots of control in terms of optimization flags, and so
forth, and command line options (which are just like named
arguments) absolutely do not scale, as any makefile can tell
you.
- These need to be defined and stabilized:
- runtime (the virtual machine and more)
- version
- features
- target language (The actual code)
- architechture
- definition version
- environment
- browser
- command line
- web server
- ...
- system
- $?OS (this should not be "browser")
- ...
- compiler (the thing that makes your language into PIL)
- emitter (the thing that makes PIL into a language)
- handling included code (libraries could be compiled to static
JS files that are fetched)
- on the fly generation + caching
- precalculation
- standalone serialization (a single function has everything
it needs)
- what exactly is a code object?
- a wrapper for some PIL code
- that can be executed by the runtime
- what exactly is &code.emit
- also an object?
- comparable to other emissions?
- further transformable?
- when is it just text or bytes?
- handling of data
- types of:
- globals?
- closures?
- serialization? proxying?
- 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
--
() Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
/\ kung foo master: /me whallops greyface with a fnord: neeyah!!!!!!!
pgpsqQdbcPMIn.pgp
Description: PGP signature
