Lisp Interpreter in JavaScript

After checking out this JavaScript file, and another similar approaches, I found out that this is not exactly what I was looking for. Here's what I have in mind, for a virtual machine on the client-side:

• I need it to run code specifically designed to it. (Right now, anything must do, but I need it to be able to translate it to valid client actions - aka, use something like JavaScript, DOM, CSS, etc, etc.
• I need it to be modified from the server (i.e., to upload code changes)
• I need to have some sort of support for a set of language constructs and basic types, including continuations. So I probably need to serialize everything.
• I need to consider the drawbacks of maintaining all of the variables in the continuation's environment. One simple closure may be small, but the full environment - needed to make good use of dynamic variables - can become quite large. Note that some tests are in order to make this assert valid!

The downside of the Lisp Interpreter I checked is that everything is automatically translated to a Javascript object. That's not what I need, since I need the code to be able to travel back into the server. I only need it to be evaluated on JavaScript. (This also means I can use a portion of this code, like the tokenizer and/or parser!)



More to come...

The Law of Notepad

Taken from Continuing Intermittent Incoherency blog:

The Law of Notepad: if creative people can’t make something awesome using the lamest of production tools, your platform is gonna loose.

OpenAjax Hub

Here is a quote from Coach's blog, related to the main challanges that OpenAjax is trying to address to get interoperability:



coachwei.com :: OpenAjax Update - Addressing Key Challenges for Ajax Adoption :

• # Toolkit “loading and unloading”(the capability to load and unload more than one Ajax toolkits into one page): For example, right now a lot of toolkits overload the “onload” function, which will certainly cause collision with another toolkit;
  
  
• # Name collision (the capability to deal with variable and function name collision). For example, quite a few Ajax toolkits today use “$” as a function name. When they are all loaded onto the same page, what happens?
  
  
• # Event Hub (The capability to have interaction between different Ajax toolkits). The key requirement here is to enable some kind of “event” propagation so that an event generated from toolkit A can be processed by toolkit B. An example is that the user drags an item from Toolkit A and drops it on Toolkit B – how should this two toolkits communicate the information related to this event? The proper solution is to provide a common event hub that each Ajax toolkit can publish and subscribe events. Initially, we do not have to define the details of different event objects, which can be defined in the future.
  
  
• # Markup scanning (the capability for an Ajax toolkit to scan an HTML document to pick up the interested markup segments for processing): many Ajax toolkits allow the usage of markup to define components within an HTML page but they all have their own mechanism of scanning the document. If more than one toolkit is loaded, the HTML document maybe scanned multiple times with the danger of causing significant inefficiency and collision. Providing a common mechanism to scan an HTML document would solve this problem.
  
  
• # Network Hub (server connectivity management): most browsers allow only limited number of connections to the server (for example, Internet Explorer allows only two). If each Ajax toolkit uses its own mechanism to handle server connectivity, it is highly likely collision will happen if more than one Ajax toolkits are loaded on the same page. A proper solution is to provide a common mechanism that centrally manages server connectivity and serves all registered toolkits.;

Apart from this list, they point out other missing factors, but that shall not be addressed by OpenAJAX. They are performance issues, the multiple toolkit bloating problem, whether there are security issues with AJAX, and if so, how do they die. Other interesting problems arise with mobility and offline execution of AJAX-based code, as well as with application development and maintenance.



These last two are particularly interesting to my work. The mentioned post talks about a blog with mobility issues: SitePen Blog » mobile.

HTTP is dead. All hail Web Messaging Protocols!

It has become very clear that HTTP doesn't serve current Web needs and purposes. So why does it remains the sole winner of the communication protocol in the Web? This is simple, really. Every browser knows how to speak HTTP, and since it's a pretty simple protocol, nobody seems eager to move a multitude of users into a paradigm shift.



The tough question is related to the solution, instead of being centered on the problem space. Where do we go from HTTP? What do we need? Most aplpications today are struggling to find a proper way to communicate with the server. Comet strategies provide bi-directional messaging between a client and a server. Internet Messaging Bus goes a step further, granting the following properties to the communication protocol:

• Guaranteed message delivery
• Guaranteed order of delivery
• Once and only once delivery
• Both client pull and server push data fetching models.
  
  

This seems to be the end of the AJAX hype, as it is know. That is, the XMLHttpRequest, by itself, doesn't grant all those nice things to any WebApp. However, the word seems to be catchy, and people seem to want to stick with it for a bit longer, and the current bet is a messaging protocol.



See:

• XmlHttpRequest BAD - Messaging GOOD - Greg's blog
• Comet: Low Latency Data for the Browser
• Web 2.0 Communication Layer: from HTTP to Comet to Internet Mess
• coachwei.com :: Web 2.0 Communication Layer: from HTTP to Comet to Internet Messaging Bus
• OpenAjax Alliance White Paper

Process execution mode swapping

Another aspect that is relevant for my PhD is the exchange of information between the client(s) and the server(s). To make a pictorical description, imagine a situation where a client walks into a web application, which is running entirely on the server. The server then sends some of the computations to be executed on the client, e.g., for performance reasons. After a while, the client may take too long to execute a certain computation and transfers it, along with the already processed information, back to the server.



This situation can be compared to the Java Bytecode execution done by the Just In time compiler. The VM starts by interpreting code, then after a few iterations, it boosts up the compiler and the code that was being called is now fetched from a compiled source.



What I mean to inspect is if I can take some of these ideas and port them into a Web architecture.



In SISC - Documentation, we can see that the Scheme interpreter can also run byte-compiled Java code. I must now find out how does it swap the execution context between those two modes, and what considerations are being done.

Interpreters in JavaScript

Before discussing Termite (it deserves a post for itself), I'll post a series of links to attempts to write language interpreters in JavaScript.



First, the motivation: As I need to create a framework to build web applications with certain characteristics built-in the client-server communication infrastructure, I need to do constant experimentations with the client capabilities. Considering that the majority of clients are able to run a javascript interpreter within the browser, it seems to be the best bet, for compatibility sakes.



A list of links to different approaches follows. For some pages, The only interesting reading material is on the Javascript that is embbeded in the source html code, so you have to dig into that.

• Interactive Scheme (see http://fresh.homeunix.net/~luke/jscm/scm.js.txt)
  
  
• Lisp Interpreter in JavaScript
  
  
• A Brainfuck interpreter in JavaScript
• The Little JavaScripter and the Little Scheme
• Joe Ganley's Lisp in JavaScript
  
  

Conclusions on whether this will or will not be usefull may come up on future posts!

A Common Lisp Post

This is my first post sent via my Common Lisp Atom interface. It uses the JLinker to call the Java Google client API methods.

Termite - concurrent and parallel programming in Lisp

This is a simple tutorial for Termite, made by its author:



Bill Clementson's Blog: Update on Termite (A Lisp for Concurrent/Parallel Programming)





After reading the paper on it I'll make a proper review, but I like the side remark on a file upload procedure definition:

this program has about the same number of lines of code as a minimal "hello world" program in Java.