DAVE'S LIFE ON HOLD

A New Style of Javascript

So my Self in Javascript project has been coming along nicely, especially since I've only been dedicating a few hours a week to it. Today, I made a good deal of progress due to mostly being self-confined to an enclosed space for a few hours with nothing but my cellphone, laptop, and air conditioner. There is now finally the beginnings of a parser / tokenizer and compiler for the language. But most importantly, I've started actually using the core Javascript bits as a web framework for building both a sample editing application and the rebuilding of my blog itself. The key concept here is what is probably now my favorite bit of javascript:

_ = function() <br>        var _ = function() { return arguments.callee.eval.apply(arguments.callee,arguments) ;
if (arguments0) windowarguments[0] = _;
return _ }

What I find so compelling about this function is that it defines an object as a function that dispatches its arguments to itself, optionally naming it in the global namespace. This means I can declare well named objects using a very simple syntax:

_('window')

Or create an anonymous object with even less effort:

_()

And while this is more work than typing , it has an added advantage of that each function/object returned obeys this simple property:

_()('selector', ... arguments ...)

Which effectively turns Javascript into an object oriented LISP. In fact, I've done one better, and turned Arrays into a representation for object oriented LISP:

Array.does(
'eval',function() <br>                var self = eval(this[0]);<br>                return self.apply(self, this.after(0))<br>        ,

Wherein does is a method on Object which extends the Array.prototype (because I dislike typing). With this you can effectively say:

object, 'selector', arguments ... .eval()

And poof! We have the basis for being able to interpret any list in an object oriented fashion. I don't know if this is going to be terribly useful though, as I would need to add a little bit to this definition to iterate over the contents of the list first running .eval() on any nested Arrays to produce a more LISP like interpreter, but that would make for transforming syntax trees into executable fairly simple. This level of meta-representation may only be useful in an intermediate fashion if I want to do something like macro, 'quote', some, list, of properties in order to do LISPy things like macro expansion and AST transformations. I dislike the idea of implementing special forms though, and would require more work than it is worth.

Back to the web stuff, the LISPishness of the resulting Javascript can be sceen most clearly in my HTML object:



I'm using a gist here to show the syntax highlighting. Everything in red is a string. No seriously, this has everything you need to produce any web page, with CSS styles, and text, images, video, and audio to your site. If I added one more line, it could also embed swfs, and invoke plugins. Hint: copy and paste the line for src: and replace the letters src with data. With this one object you can build entire guis, and attach behaviors to any element you can produce in the DOM. The 'on:' method, (which should be named on: Do: but I haven't gotten that far in the necessary infrastructure to support), will bind a DOM event handler to a function or a compiled function (NB: compiled functions are strings that get .compile() called on them) and performs the behavior.

As you can see in this example, there are a number of what I'd call "compiled functions" which are basically strings in a special syntax that get compiled into Javascript functions. Currently this syntax supports:

@ -> this
^ -> return
x y z ... | body -> function (x, y, z, ...)  body [; return self; /* if no return in body  */ ]

These extra little features make for less typing, and in line with some of CoffeeScript's and ES.next's features. I found that the translation to Self is pretty much a matter of dropping @ and a whole lot of stupid parentheses. In fact, almost everywhere in the code where /\\)\\s\\(/ would match is roughly equivalent to the Smalltalk ; and Self .. Since the 'does:' method returns this each time it adds a new method to the object, HTML is chained across each invocation as the return value, which is then invoked by the subsequent function call. Each line in this file represents a function call on the return value of the previous function. While this may seem horrible from a stack unwinding standpoint, it really isn't, as each call is operating upon the return value of the next. It is the object defined in the first line that is receiving each of the messages:

_('HTML')

This has also given rise to the idea of building a "web tool kit":



which for the time being is a minimalistic tool built upon the HTML object to embed text, images, video, and audio into a webpage. It also supports a simple 'box' model, where you can use the style: method of the HTML entity itself to position and maneuver each element. I'm going to add a set of methods for doing drag and drop styling of each of these elements as well, which will mean one could compose UIs and leave all the style info as a JSON object on a server. Since style: takes a JavaScript object that maps to the CSS attributes of the HTML entity, it is pretty trivial to add an XHR or script tag based theme system on top of the tool kit.

As the parser and compiler start to get more functional, I will slowly replace these files with straight up Self that will get compiled to this representation. This will remove a lot of the unnecessary, and frankly dangerous, punctuation which muddies up the beauty of this sort of solution. But it definitely has potential!