Re: I saw your post on the PyPy list
Nathanael D. Jones
The idea to use continuations to 'pause' the logic flow, get user response, and continue the code based on user input.
IME Rhino is *extremely* slow. It's like, the polar opposite of PyPy in
that regard.
Are you going to be using a client-server model? There are a couple of
projects besides Rhino for doing general-purpose Javascript programming.
Node.js is a really nice choice for writing a server in Javascript. I
work on GPSEE, a similar project. I endeavor to add the Node API when I
find the time because it's a very good API.
Also could you link me to some materials discussing serializable
continuations? I'd like to be sure I understand what you're talking
about
Thanks for contacting me :)
On Tue, Jan 11, 2011 at 10:15:01AM -0500, Nathanael D. Jones wrote:
> I'm actually thinking about a javascript solution, although I prefer Python
> syntax.
>
> Rhino seems to have sandboxing solved and offers beta-level serialization
> support for continuations. I believe the apache Cocoon project exposes the
> continuation-based web framework that drove those additions to Rhino.
>
> I'm thinking about compromising and choosing Rhino since it seems to get the
> 80% done.
>
> Have you worked much with Rhino?
>
> Nathanael
>
>
> On Tue, Jan 11, 2011 at 10:46 AM, Donny Viszneki <do...@codebad.com> wrote:
>
> > I saw your post on the PyPy list and knew I had found a similar mind :)
> >
> > Please put me on a mailing list to be kept up to date on the
> > developments of your project!
> >
> > I have been working in my spare time on an extensible Javascript parser
> > for experimenting with extensions and restrictions upon the Javascript
> > programming language. Something like an RPython analog for Javascript,
> > for instance, would go a long way in terms of providing sandboxing.
> > Something like Stackless for Javascript would be great even for existing
> > web programming challenges where CPS is used to wrangle the
> > "event-oriented" design philosophy of asynchronous programming in web
> > browsers' Javascript engines.
> >
> > Good luck in all your endeavors ;)
> >
Donny Viszneki
> 1) Configurable sandboxes and execution contexts
> 2) Serializeable continuations
> 3) The "OS" portion that handles security and provides HTTP responses needs
> to be able to dynamically load scripts and execute them in a unique sandbox.
If my work for an RPython analog to Javascript bears fruit soon, that
would mean that anywhere you have Javascript, you have sandboxes :)
Node.js, GPSEE, and modern web browsers also support the "Web Worker"
API, which is a sandboxed thread of Javascript execution connected to
the main thread via an event-driven interface to two pipes. You post a
message to the other thread with a function, and you receive it with a
callback function (an "event.")
Because Javascript supports closures, a callback also has access to all
the local variables that exist in its scope.
> GPSEE and NodeJs both look awesome, but I couldn't find docs on whether they
> support reqs. 1-3 above.
>
> In essence, a continuation is a copy of the call stack, token index, and all
> accessible variables.
Continuations are used all the time now in Javascript on the web, but I
am not so sure about serializing them. Continuations have no formal
langauge support, but the combination of scope closures and first-class
functions makes it just as powerful, just a little more clumsy in terms
of syntax. To that end, there exists at least one project called
NarrativeJS, which is an extension to the Javascript language that
basically makes this less clumsy.
> The idea to use continuations to 'pause' the logic flow, get user response,
> and continue the code based on user input.
>
> if (ask() == "Go North")
> Print "You see the north pole"
> if (ask() == "Go east")
> Print "You can't go east, you're at the north pole. East doesn't exist."
> else if (ask() == "Go South")
> Print "You were eaten by an angry penguin."
>
> Expressing this without continuations would require that the logic be
> flattened and much more verbose, as well as less intuitive.
Yes I understand this problem!
With my work with extending and restricting the Javascript language,
besides creating a restricted Javascript (I'm calling it "RJavascript"
after the similar RPython) I also want to create a competitor to
NarrativeJS, and which might turn out to be a little bit like Stackless
Python.
http://www.neilmix.com/narrativejs/doc/
Tonight if I find the time, I will code up an example MUD using Node.js
and show it to you so you can see what it is like to solve the kinds of
design issues you face with Node.js. Then I will propose what it would
look like using NarrativeJS or something similar to make the program
flow more human-readable :)
Talk to you soon!