peter.michaux.ca

Scheme from Scratch - Royal Scheme v0.1 - Integers

2011-07-29T17:50:00

It took a while but the plan is back on track. Royal Scheme is a go.

I’ve been picking away at the project at a leisurely pace trying to determine exactly what it will be. Blog articles seem like a great way to keep folks informed about the state of development. Hopefully some folks will want to follow along creating their own implementations again like they did with Bootstrap Scheme. It was a whole bunch of fun.

I think a book format would be a better format for truly documenting the iterative development of a real Scheme interpreter that is implemented in C. I still haven’t found that book and if I was taking a university course then I’d want to take the course that has that book as its primary text. So a lot of what Royal Scheme development will be about is ensuring the order of introducing features is just right and that the concepts underlying the implementation are explained in code comments and in a book. It is a lofty goal. We’ll see how it goes. I’m hoping for feedback from you.

Just as Bootstrap Scheme started with integers, so does Royal Scheme.

$ ./scm
Welcome to Royal Scheme. Ctrl-c to exit.
> 123
123
> -123
-123
> +007
7
> ^C
$

I’ve put the code on github. I’m new to git and github which adds a bit more flavor to the project. You can browse the code at the following address

http://github.com/petermichaux/royal-scheme

and I created a branch specifically for this integers-only version

https://github.com/petermichaux/royal-scheme/tree/v0.1

You can get the code with the following command

$ git clone https://github.com/petermichaux/royal-scheme.git

You should be able to just run make and then the above REPL session example should work.

I’m hoping you will scrutinize the code and really give me grief that I’ve done something silly, stupid, overly complex, have a trailing space on a line, haven’t written a comment where a comment would be helpful, etc. I’m particularly interested in what you think of checking the return value of printf and scm_write in repl. It doesn’t feel right quite to me. Also the overflow checking in scm_read_number happens each iteration which is not as efficient as it possibly could be.

By the way, registration for the Scheme 2011 Workshop will open in August. I’m planning on going and hoping to talk with some people there about Royal Scheme.

Previous article: Introduction

JavaScript is Dead. Long Live JavaScript!

2011-06-25T20:21:00

For 16 years, JavaScript has been the language of the web browser. This language has enabled the building of compelling web applications and contributed to the success of the web. Other scripting languages could have filled the role JavaScript does but JavaScript was in the right place at the right time. Microsoft added Basic to Internet Explorer a long time ago but JavaScript was the language in all the browsers and so it won. Since JavaScript has been cross-browser and at least good enough, the browser makers have not needed to add other language interpreters to the browsers themselves.

But we still didn’t choose to use JavaScript. It has been the one option. It has powerful features like closures and we learned to love these features while turning a blind eye to the warty parts of the language. There has even been a lot of apologizing to the programming community along the lines of “Yes we know it is a pretty funky language but please give it a chance. I’m sure you’ll learn to love it.” It shouldn’t be that hard to sell the quality of the language. JavaScript has been described as an experiment that escaped the lab a little too early and we’ve been stuck with the warts ever since.

Still, JavaScript has been a great language. In 2007, Steve Yegge declared JavaScript as The Next Big Language and it has been. Between then and now JavaScript-based web-applications have become bigger and better. With JavaScript’s help, the web has continued to flourish even with the threat of native mobile apps taking over the same space.

In very recent times, JavaScript has been making its most successful attempt at being a server-side language. The Node.js platform, with its non-blocking I/O, may be solving a problem that programmers have needed solved for a long time. JavaScript is the language for Node.js and so JavaScript may go along for the ride to become a successful server-side language after many failed attempts in the past.

Overall, JavaScript has been a wild success. The most popular programming language in the world. But if the browser died today, how much new JavaScript code would be written tomorrow? Most likely JavaScript would become a fringe language overnight. But the browser isn’t dying tomorrow. We will be programming for it for years to come.

As JavaScript has been used for more and larger programs, the warts of the language have become more apparent and caused increasing amounts of grief for many developers. It may come as a surprise that even though I’ve written about JavaScript for years, I’m not a JavaScript fanboy. Most of my JavaScript articles have been about me working through the difficulties of finding a peaceful coexistence with the language. Yes I’ve enjoyed programming in JavaScript and have learned a lot but there certainly have been times when I’ve felt like I’m wallowing in the muck.

One of the most obvious deficiencies in JavaScript is with its user interface: its syntax. The inability to quickly improve its syntax has lead to the language’s downfall.

The Case for Syntax Extensions: Verbose Idioms

Here we look at just four of the many examples where JavaScript’s syntax could be improved to remove verbose idioms from our daily programming existences.

Optional Parameters and Default Values

JavaScript functions can be called with a variable number of actual parameters. This makes some of the formal parameters in the function’s declaration optional. Often times these optional parameters must be set to a default value if no actual parameter is supplied. I’m willing to bet you’ve written and seen plenty of code like the following.

function(a, b, option) {
    option = option || {};
    // ...
}

I have and still write code like this. This code is wrong. If a falsy value is passed to the function for option then the wrong thing happens. We should be writing the following.

function(a, b, option) {
    option = arguments.length > 2 ? option : {};
    // ...
}

Although this code expresses the intended thought of setting a default value if an actual parameter for option is not supplied, it is too verbose and less readable. The reader must count to determine which variable is has index 2. Beyond the awkwardness, the correct version is more difficult to maintain. It is easy to produce the following buggy code if the b parameter is removed.

function(a, option) {
    option = arguments.length > 2 ? option : {};
    // ...
}

If your application uses optional parameters with default values, some new syntax would be beneficial for you.

function(a, b, option = {}) {
    // ...
}

The addition of this new syntax tunes the language better to your application’s needs.

Let

Does the following buggy code look familiar?

for (var i=0, ilen=elements.length; i<ilen; i++) {
    var element = elements[i];
    LIB_addEventListener(element, 'click', function(event) {
        alert('I was originally number ' + i);
    });
}

All the elements were the same number?! The solution is to use an immediately evaluated function expression so each alert reports a different number. This is the “let” idiom after Lisp’s various let forms.

for (var i=0, ilen=elements.length; i<ilen; i++) {
    var element = elements[i];
    (function(num) {
        LIB_addEventListener(element, 'click', function(event) {
            alert('I was originally number ' + num);
        });
    }(i));
}

Sure sometimes delegate listeners might be better than the above code but sometimes the above code is the desired idea. In the above case, we are trying to bind the order of the elements when the loop runs. This order could be lost with the delegate pattern if the elements are rearranged in the DOM.

This syntax is particularly awkward because of the distance between the formal num and actual i parameters of the immediate function.

The immediate function could be factored out to another location and called inside the loop.

function attachListener(element, num) {
    LIB_addEventListener(element, 'click', function(event) {
        alert('I was originally number ' + num);
    });
}
for (var i=0, ilen=elements.length; i<ilen; i++) {
    attachListener(elements[i], i);
}

Even with this option, sometimes programmers still use the immediate function because it conveys better their intended message to readers.

If your application uses the let idiom, wouldn’t it be nice to have new syntax for it?

for (var i=0, ilen=elements.length; i<ilen; i++) {
    var element = elements[i];
    let (num = i) {
        LIB_addEventListener(element, function(event) {
            alert('I was originally number ' + num);
        });
    };
}

With num and i together it is much easier to read this code and a new scope containing new has been introduced so the closure works properly. Once again, the addition of new syntax can tune the language better to your application’s needs.

Modules

One of the most common idioms in JavaScript programs we all know and love is usually called “the module pattern.” This idiom provides the benefits of encapsulated variables that are private to the module and imparts sanity to our code.

var event = (function() {

    // private variables
    var listeners = [];
   
    function addEventListener(f) {
        listeners.push(f);
    }

    function clearEventListeners() {
        listeners = [];
    }
    
    // ...
    
    // export the module's API
    return {
        addEventListener: addEventListener,
        clearEventListeners: clearEventListeners
        // ...
    };
}());

The goal of encapsulation here isn’t security. It is to ensure that other developers keep their dirty, monkey-patching hands off your module’s data.

The exporting can be done a few ways but no matter which way there is some boiler plate.

Importing is verbose also

(function() {

    // import desired properties of the event module
    var addEventListener = event.addEventListener;
    var clearEventListeners = event.clearEventListeners;
    
    // ...
}());

Some new syntax would be nice to convey the intent of the module pattern better.

module event {
    
    // private variables
    var listeners = [];
   
    export function addEventListener(f) {
        listeners.push(f);
    }

    export function clearEventListeners() {
        listeners = [];
    }
    
    // ...
}

(function() {

    import event;
    
    // ...
}());

The module pattern is almost everywhere and some new syntax to better express this idiom would better tune the language to all of our applications.

Inheritance

These idiom examples have been growing in how they each span an increasing number of lines of code. The JavaScript idiom that potentially spans the most lines of your program may be the inheritance idiom.

function Employee(first, last, position) {
    // call the superclass constructor
    Person.call(this, first, last);
    this.position = position;
};
// inherit from Person
Employee.prototype = Object.create(Person.prototype);
Employee.prototype.constructor = Employee;

// define an overridding toString() method
Employee.prototype.toString = function() {
    // call superclass's overridden toString() method
    return Person.prototype.toString.call(this) +
           ' is a ' + this.position;
};

What a mess. Yes JavaScript makes single inheritance like this possible by linking prototypes but it takes a lot of code to manually make super things happen they way you might like inheritance to work.

If there could be a maintenance nightmare that is it. The strings “Person” and “Employee” are sprawled throughout the code for the Employee “class”.

If classes with inheritance are a big part of your application, some syntax would really help clean up the code. Perhaps something like the following.

class Employee extends Person {
    constructor(first, last, position) {
        super(first, last);
        public position = position;
    }
 
    update(camera) {
        return super.update() + ' is a ' + position;
    }
}

That is a major improvement.

Learning from Idioms

These common idioms make it clear that JavaScript could use some new syntax for several reasons. The ability to do what we want is usually in JavaScript somewhere. The verbosity of the idioms is sometimes too much. We cut corners. Sometimes we avoid certain algorithms because the idioms are too verbose. The idioms are not self explanatory. They are inside secrets of the community and the intent is not easily recognized by outsiders.

The ECMAScript committee has recognized that the above idioms, and others idioms, are common across a wide variety of applications. There are proposals for all of these syntax cases in Harmony. Some of them may make it into the next version of ECMAScript and into the browsers for your use. If new syntax gets there eventually then you can use use it.

Idioms may have emerged in your application that do not appear in a wide variety of applications. For example, Node.js’s non-blocking I/O and heavy reliance on callbacks will undoubtedly result in idioms that do not appear in browser scripts. Syntax specific to just your applications will likely never make it into ECMAScript.

If you would like to use specialized syntax for the general idioms like those shown above or you would like syntax for your own idioms, what can you do?

If Only We Had Macros

Lisp languages have had full-blown macros for decades. Through macros, Lisp gives programmers the ability to tune the language’s syntax to best match their own applications. Because of its macros, Lisp has been described as “the programmable programming language.” Powerful stuff.

Lisp’s s-expression syntax, you know, the syntax with all those parens, gives the language a special property called homoiconicity. It roughly means the syntax of the language is also the syntax of its data structures or that a program’s parse tree uses the languages data structures. This homoiconicity makes Lisp’s macros possible.

JavaScript doesn’t have macros. A major reason for this is that adding macros to languages with C-like syntax, languages that are not homoiconic, is still a research topic. Excerpts from a short conversation on Twitter with littlecalculist, Dave Herman, Ph.D., ECMAScript committee member, and Mozilla Researcher:

@petermichaux

I believe @littlecalculist knows more about the research and possibilities for macros in ECMAScript. I’d like to know more also.

@littlecalculist

I have thoughts on it for sure. But macros for non-sexp languages is still very much a challenging research topic

@petermichaux

[...] We’ll turn blue waiting for macros.

@littlecalculist

Might I suggest you keep breathing? ;-) Seriously, I do hope to try, but trust me, macro system design is hard.

The message is pretty clear. JavaScript macros are not just around the corner.

Harmony Syntax ETA

Perhaps the syntax extensions in Harmony are all you dream of and more. If Harmony becomes ECMAScript 6 and ECMAScript 6 becomes ubiquitous then you’ll be all set. So all you need to do is wait...patiently.

First, let’s look at browser adoption. Unfortunately I’ll pick on Internet Explorer a bit, which has almost become a cliche, but not because I have something against the Internet Explorer development team at Microsoft or the newest versions of Internet Explorer. It is necessary to look at this browser because it is perhaps the most important case study for estimating when features will be available for all visitors to your web site.

As of May 2011, w3schools, which has relatively tech-savvy visitors, reports Internet Explorer 6 still has 2.4% market share. Net Market Share reports Internet Explorer 6 still has 10.36% market share. Your site probably has a market share somewhere between those two numbers but this browser is still hanging on even though it was superseded by Internet Explorer 7 in November 2006. How many people are still using Internet Explorer 6 or 7? The w3schools site shows 7.7% and Net Market Share shows 18.2%. These browsers just aren’t going away fast enough. A publicly available site (e.g. Amazon) cannot afford to ignore market share numbers this large.

There is no point in spending any energy moaning that users should upgrade their browsers or that “IE should die!” It won’t happen. I don’t know if it is true but someone once said to me “Internet Explorer users upgrade their browser when they upgrade their hardware.” For the past few years, hardware has certainly become sufficient that people don’t need to upgrade anything to use email, Facebook, Twitter, etc.

Suppose your web app is sufficiently advanced that you’ve decided that you only care about users with “modern” browsers. Google Apps recently announced that on August 1, 2011 they will stop supporting Internet Explorer 7. That is almost 5 years after Internet Explorer 7 was released.

Now think about this: Internet Explorer 10 is not out yet but, of course, even it won’t have Harmony’s syntax extensions. Let’s estimate that Harmony is approved as ECMAScript 6 in mid-2012 and Internet Explorer 11 is released in early 2013 with support for all of Harmony’s syntax. Five years after that, in 2018, the Google Apps team can drop support for Internet Explorer 11 and finally use Harmony syntax freely. (On August 1, 2011, they are also dropping support for the four-year-old Safari 3 and two-year-old Firefox 3.5 so the waits are still long-ish for other browsers too.)

Amazon developers might need to wait an additional 5 years before they can use Harmony syntax. That’s 2023!

Will you be satisfied waiting 7-12 years before you can start using syntax that would be helpful developing your web apps today? Being more optimistic, even if the wait is just 5 years, will you wait?

JavaScript is Dead.

Cause of death: semicolon cancer.

Perhaps due to JavaScript’s syntax alone, JavaScript does not have macros now and won’t have them soon if ever. Millions of programmers use JavaScript now and plenty of them are tired or tiring of the verbose idioms confronting them daily. They want new syntax now and won’t wait. For this growing group of developers, JavaScript the source code language is dead.

You had a good reign, JavaScript. We had some good times and wrote some cool apps together. May you rest in peace.

Long Live JavaScript!

Programmers like to control their own destiny and they are taking action. You can have all the new syntax you want for your browser scripts, right now, if you write in another source language and compile to the ECMAScript 3 dialect of JavaScript for the billions of browsers in the wild. By compiling to ECMAScript 3 you are completely freed from JavaScript’s syntactic evolution. As an added bonus, you can even fix some of JavaScript’s semantic gotchas with a sufficiently sophisticated compiler. JavaScript’s new life is as a compilation target.

Languages that Compile to JavaScript

There have been compilers to JavaScript for years now. In 2007, I started collecting a list of languages with compilers to JavaScript. There were JavaScript extension languages: the now-defunct ECMAScript 4, Narrative JavaScript, and Objective-J. There were pre-existing languages: Scheme, Common Lisp, Smalltalk, Ruby, Python, Java, C#, Haskell, etc. There were even brand new languages HaXe, Milescript, Links, Flapjax that were designed to address web programming needs.

Of these compiler projects, Google’s GWT Java-to-JavaScript compiler has probably been the most successful but I don’t see programmers who first learned a language other than Java rushing to use Java as their source code language. In fact, none of these compiler projects have accrued a significant long-term user base. At least in the parts of the web that I frequent, with the exception of GWT, it is rare to read about programmers using these compilers for any real projects. There are several legitimate reasons not to use one of these compilers.

Imagine you build a big project using one of these compilers and part way through find a bug in the compiler. The one maintainer of the compiler may have lost interest or time. Do you want to maintain a compiler? Does anyone on your team have the skills to do that? That ulcer is going to get pretty big while you prepare to explain to the CEO that you now need to rewrite the UI in JavaScript.

Just the thought of debugging compiled code when a production bug is filed makes my stomach churn. Core dump. What line number in the source code matches the line number Firebug is reporting for the compiled code? HURRY! That bug needs to be fixed now!!!!

You’ve used Objective-J for a big project and now you need to hire a new good programmer. What are your chances of finding the right person? They are probably very low. Just finding an available JavaScript programmer is difficult enough. If you use one of these alternate languages, it is very likely you’ll need to train each new person you add to your team.

Even without these compiler projects being wildly successful, the list of languages that compile to JavaScript has continued to grow. There is no doubt that writing a to-JavaScript compiler is a very cool project. Please pay me to write one.

There is one notable new entry in the list of languages that compile to JavaScript that is actually causing a big stir and is possibly changing the game for good.

CoffeeScript

I can tell you right now, I don’t know why CoffeeScript has the magic combination of features to garner the attention it has when other projects have failed. Significant whitespace and arrow function syntax. My gut reaction is yuck. There is plenty of things to like: default parameter values, rest parameters, spread, destructuring, fixing the whole implied global mess, even classes if you’re into that kind of thing and more. Many of CoffeeScript’s features are part of Harmony and so may be in browsers sometime in the future but if you use CoffeeScript then you can have them now. There is nothing like instant gratification.

Programmers are bursting with affection for CoffeeScript.

@pyronicide

Being able to use default values for function arguments in #coffeescript makes me immensely happy.

@_jdpage

CoffeeScript is wonderful. Now I am spoiled and will complain whenever I have to write JavaScript instead.

At the TXJS 2011 conference, Douglas Crockford apparently shared that he thinks “CoffeeScript is clearly good stuff.”

There is one aspect of the CoffeeScript project that I really like and it is summed up by the following two quotations. The first comes from Trevor Burnham, author of CoffeeScript: Accelerated JavaScript Development.

@trevorburnham

[...] It’s not about turning JS into Ruby/Python; it’s about having a syntax better suited to JavaScript’s inner goodness.

The second is from The Little Book on CoffeeScript.

CoffeeScript neatly sidesteps these [JavaScript issues], by only exposing a curated selection of JavaScript features.

The attitude expressed in these quotations really is great and genius marketing too. It is not CoffeeScript verse JavaScript. It is CoffeeScript enhancing the JavaScript programming experience. Could some different syntax and a restricted subset of JavaScript’s features really be better than plain old JavaScript?

Douglas Crockford seems to think so. For years, his JSLint has been hurting our feelings and demanding that we use very specific whitespace and syntax and that we avoid dangerous JavaScript features. Source code that passes JSLint has access to a true subset of JavaScript: the subset that he calls “the good parts.” This dialect of JavaScript deserves a name. Maybe GoodScript? After all, you are only allowed to use JSLint for good and not for evil.

The ECMAScript committee also thinks this is a good idea. The "use strict" pragma introduced in ECMAScript 5 not only restricts some language features like with, strict mode even changes/fixes the semantics of some parts of the language. Because of the semantic changes, ECMAScript 5 strict is a different language or at least a different dialect than ECMAScript 5 non-strict.

CoffeeScript, GoodScript, and ECMAScript 5 strict share common goals of keeping you away from the dangerous parts of JavaScript while giving you access to the valuable, safe parts. Each enforces these goals differently but they are enforced one way or another. You don’t get new syntax with GoodScript. It is already JavaScript and ready for the browser. You don’t get to use ECMAScript 5 strict because it is not available in all browsers yet and won’t be for years.

So CoffeeScript seems to be targeting a particular need of web development and maybe that is something other to-JavaScript compilers haven’t done or haven’t done well before.

CoffeeScript is also a reasonably thin skin over JavaScript. One consequence of this is that the compiled JavaScript code is reasonably easy to read and not brutal to debug (so I’m told.) This reduced debugging fear is contributing to interest in CoffeeScript.

CoffeeScript almost feels like a set of macros for writing JavaScript programs.

Since CoffeeScript compilers are in the hands of developers rather than the visitors to sites, you control which version of CoffeeScript you are using. You can upgrade at will. This also means CoffeeScript does not need to be standardized and go through the subsequent painfully slow growth of a standardized language. CoffeeScript can grow at the rate of its community’s imagination and desire. JavaScript standardization was essential to the success of the web but the same constraints do not apply to CoffeeScript.

Well then I’m going to invent my own language.

You can do this and it would be a great exercise. You’ll be able to call yourself a compiler writer which is pretty darned prestigious.

The danger of inventing your own language lies in the thinking that you can do better than JavaScript has done in the long run. Language design is hard and I bet your language will grow its share of unsightly hairs. Maybe not as many hairs as JavaScript but still. CoffeeScript hasn’t hit puberty yet but there are already signs that hair follicles may exist.

@maxsamukha

CoffeeScript: The way variables in outer scopes can be accidentally overwritten is fishy. How bad is it in practice?

You were so proud that your simple, readable compiled code was easy to debug. That will become harder as you realize the compiled code’s semantics aren’t quite what they were supposed to be in corner cases.

Idioms will appear in your language and someone will fork your compiler to do away with those idioms (unless your language happens to have macros.)

Enough with this nay saying. Go and write your own language right now. You’ll be a better programmer for it.

What’s missing from JavaScript the target language?

JavaScript is embarking on a new life as a compilation target. It is a capable target for many language features but it could use improvement. In his JSConf.US talk, Brendan Eich stated that one the goals for Harmony is to be a better target for to-JavaScript compilers.

Compiled JavaScript can run slower than hand-written JavaScript just like compiled C can be slower than hand-written Assembly (though not always.) Some inefficiency in compiled JavaScript is tolerable because JavaScript virtual machines are fast and the DOM is the bottleneck anyway. That said, some potential source code languages have semantics sufficiently far from JavaScript’s semantics that the compiled code is so inefficient that it cannot realistically be used in production web apps. There are already features in Harmony that will enable some of these languages to be compiled to efficient code and thus make these viable source code languages.

Proper Tail Calls

Programs in Lisp languages depend heavily on recursive calls to properly tail recursive procedures. The proper tail calls proposal in Harmony will allow these programs to be compiled to JavaScript without the inefficient trampoline technique currently necessary to avoid overflowing the call stack. Awesome! Let’s look at that in a bit more detail.

The following JavaScript is an example of mutually recursive functions which would work fine in Lisp but since JavaScript currently does not have proper tail calls, will overflow the JavaScript call stack when number is large.

function isEven(number) {
    if (number === 0) {
        return true;
    }
    else {
        return isOdd(number - 1);
    }
}

function isOdd(number) {
    if (number === 0) {
        return false;
    }
    else {
        return isEven(number - 1);
    }
}

isEven(100000); // InternalError: too much recursion

In the above code, a call to isEven(100000) isn’t complete and removed from the call stack until isOdd(99999) returns which isn’t complete and removed from the call stack until isEven(99998) returns and so on. That’s a lot of calls on the call stack! And there is no need for them all to be on the call stack. isEven(100000) doesn’t have anything intelligent remaining to do once it calls isOdd(99999) because the call to isOdd(99999) is the very last thing in isEven(100000). The call is said to be in tail position. isEven(100000) is just waiting to return the value returned by isOdd(99999) and a clever language can just pop isEven(100000) off the call stack and replace it with the call to isOdd(99999) thus saving space on the call stack.

With trampolines we can ensure that even in JavaScript the call stack doesn’t grow large. The following is just a sketch of how trampolines might be implemented and how isEven and isOdd might be compiled for a JavaScript interpreter that doesn’t have proper tail calls.

function bounce(ret) {
    while (typeof ret === 'function') {
        ret = ret();
    }
    return ret;
}

function isEven(number) {
    if (number === 0) {
        return true;
    }
    else {
        return function() {
            return isOdd(number - 1);
        };
    }
}

function isOdd(number) {
    if (number === 0) {
        return false;
    }
    else {
        return function() {
            return isEven(number - 1);
        };
    }
}

bounce(function() {return isEven(100000);}); // true

You can see the extra overhead of the bounce function which implements the trampoline calls is quite onerous. It creates closures for each continuation, doubles the number of calls, and must examine the returned value after each bounce; however, isEven(10000) does complete and is removed from the callstack before isOdd(99999) is called. The full computation completes in constant call stack space.

The bottom line is trampolines incur too much overhead. They incur so much overhead that when Rich Hickey created Clojure, his Lisp for the JVM, he decided his language could not have proper tail calls because trampolines were too expensive. That must have been a painful decision for someone who loves the Lisp family of languages.

The good news is that the ECMAScript committee has recognized this deficiency in JavaScript and has added proper tail calls to Harmony. This will benefit programmers writing directly in JavaScript and developers of to-JavaScript compilers.

Lambdas

Another strawman proposal not yet promoted to Harmony is the Block Lambda Revival which combines some new syntax with a new language construct called a lambda. A lambda is a callable thing, like a function, but it obeys Tennent’s Correspondence Principle. Tennent’s Correspondence Principle states that wrapping an expression or block of code in an immediate lambda should not change the meaning of that wrapped code. JavaScript functions are not lambdas and do not obey Tennent’s Correspondence Principle. For example,

function one() {
    return 1;
}

one(); // 1

is not the same when the return line is wrapped in an immediate function

function one() {
    (function() {
        return 1;
    }());
}

one(); // undefined

The syntax of the block lambda proposal for a lambda that takes two arguments and sums them is {|a, b| a + b}

Using the syntax of the block lambda proposal we can wrap the return line in an immediate lambda without changing the meaning.

function one() {
    ({||
        return 1;
    }());
}

one(); // 1

Thanks to lambdas obeying Tennent’s Correspondence Principle, the return still means return from the function one.

You may ask “Who cares about this computer science-y stuff?” to which I reply “Did any of that macro business seem useful?” because lambdas are a fundamental building block in the code generated by many macros. And since lambdas play nicely with JavaScript’s return, arguments, and this, lambdas would be a valuable addition to the language for compiler writers.

I’m focusing on the JavaScript-as-a-target aspect of the block lambda proposal. If you plan on writing in JavaScript forever after, the proposal has other benefits for you too that don’t matter to compiler writers.

The block lambda strawman has not yet been promoted to Harmony and so currently doesn’t have a path into ECMAScript 6 and browsers around the world. The standardization process is slow. Maybe there will be another decade stall in evolving the language like there was after ECMAScript 3. Maybe the next edition of ECMAScript will be the last edition. Better to get the best stuff in there than hope to get it in later. If you care about the future of JavaScript and think lambdas would be a benefit to the language then let the ECMAScript committee know by sending a message to the es-discuss mailing list in support of the block lambda proposal. Powerful, orthogonal language features like tail calls and lambdas which have no efficient workarounds may be the most important additions in the next edition of ECMAScript.

What’s missing from the browser?

The browser can help JavaScript succeed in its new life as a compilation target. The browser interprets compiled JavaScript and complains when the compiled code has an error. The error messages contain line numbers in the compiled code but you want to know the line number in source code.

The Mozilla crowd has an open ticket and a dev tools project to ease debugging source code by mapping compiled code lines to source code lines. Since you control the browser in which you primarily develop and test, you can use this feature as soon as it is ready.

Somewhere I read that the Webkit folks are developing similar source code debugging assistance but I cannot find any concrete evidence.

Polyglot

JavaScript’s monopoly in the browser has meant front-end programmers all speak the same language. This has given the community a lingua franca enabling good communication and code sharing. We are now headed for a polyglot future where you choose the language(s) you want to learn and use for developing browser applications. Maybe you are only using a few JavaScript language extensions via Traceur and compiling templates to JavaScript with Mustache. This still means that the CoffeeScript programmer won’t understand your source code immediately.

This divergence was inevitable as it has happened on all previously successful platforms. There have been multiple languages for building native applications almost forever. C is still common but C++, Objective-C, and many other languages are available. The JVM was intended to run programs written in Java but clever developers have added other languages like Clojure and JRuby as options. Microsoft recognized what seems to be a human psychological need for a variety of languages and developed its .NET CLR platform for multiple languages from the beginning. Programs written in Basic, C#, IronPython, etc can all be run on the CLR.

Barriors to communication in the front-end community are not new anyway. A developer using Dojo cannot immediately understand the source code of an application written with jQuery or YUI. There is a plethora of libraries, some very different, that add the ideas of class-based inheritance to JavaScript. So we already have our barriors even within JavaScript.

Having multiple source languages will increase the barriers in our community. Programmers will still need to know JavaScript, at least for a while, but in a few years they may know other source languages better then they know JavaScript.

Choice is a blessing and a curse.

Summary

It is great having the opportunity to watch JavaScript’s transition to a new life as it happens. It’s impossible to say which languages will end up winning market share in the to-JavaScript compilation but it is sure to be interesting. CoffeeScript is gaining momentum now but I think many other successful source code languages will follow.

What do you think will happen?

SICP Classes for JavaScript

2011-06-05T11:56:00

Warning: This article is intended for JavaScript programmers. Parens are coming but only briefly and you can handle it and it will be good for you.

In Structure and Interpretation of Programming Languages Second Edition (SICP) on page 182, the authors introduce the idea of message passing with the following example in Scheme of a complex number constructor function.

(define (make-from-real-imag x y)
  (define (dispatch op)
    (cond ((eq? op 'real-part) x)
          ((eq? op 'imag-part) y)
          ((eq? op 'magnitude)
           (sqrt (+ (square x) (square y))))
          ((eq? op 'angle) (atan y x))
          (else
           (error "Uknown op -- MAKE-FROM-REAL-IMAG" op))))
  dispatch)

The important part to note here is that the value returned by the make-from-real-imag constructor function is actually a dispatch procedure that you can call with a message argument. You can send messages to get the real part or magnitude of the complex number.

(define c (make-from-real-imag 3 4))
(c 'real-part) ; 3
(c 'imag-part) ; 4
(c 'magnitude) ; 5
(c 'angle)     ; 0.927295218001612
(c 'asdf)      ; ERROR: Uknown op -- MAKE-FROM-REAL-IMAG: asdf

Let’s see what the above code looks like in JavaScript, our lingua franca.

function makeFromRealImag(x, y) {
    function dispatch(op) {
        switch (op) {
            case 'realPart': return x;
            case 'imagPart': return y;
            case 'magnitude':
                return Math.sqrt(x*x + y*y);
            case 'angle': return Math.atan2(y, x);
            default:
                throw 'Unknown op -- makeFromRealImag: ' + op;
        }
    }
    return dispatch;
}

var c = makeFromRealImag(3, 4);
c('realPart');  // 3
c('imagPart');  // 4
c('magnitude'); // 5
c('angle');     // 0.9272952180016122
c('asdf');      // "Unknown op -- makeFromRealImag: asdf"

Now this probably doesn’t look like any object-oriented JavaScript you’ve seen before but it illustrates an important point. In JavaScript, we can represent the idea of an object as a function of its messages. The constructor function returns a dispatch function that you wrote that can dispatch any message any way that you want it to. This immediately gives you Spidermonkey’s __nosuchmethod__, Smalltalk’s doesNotUnderstand, and Ruby’s method_missing. Powerful stuff but unfortunately the JavaScript code above runs very slowly. We can move towards a faster and more familiar JavaScript style.

SICP page 223, introduces the idea of mutable objects but the most interesting point is the variation on the dispatch procedure.

(define (make-account balance)
  (define (withdraw amount)
    (if (>= balance amount)
        (begin (set! balance (- balance amount))
               balance)
        "Insufficient funds"))
  (define (deposit amount)
    (set! balance (+ balance amount))
    balance)
  (define (dispatch m)
    (cond ((eq? m 'withdraw) withdraw)
          ((eq? m 'deposit) deposit)
          (else (error "Unknown request -- MAKE-ACCOUNT"
                       m))))
  dispatch)

(define account (make-account 10))
((account 'deposit) 5)  ; 15
((account 'withdraw) 3) ; 12

Converting this to JavaScript we have the following.

function makeAccount(balance) {
    function withdraw(amount) {
        if (balance >= amount) {
            balance = balance - amount;
            return balance;
        }
        return "Insufficient funds";
    }
    function deposit(amount) {
        balance = balance + amount;
        return balance;
    }
    function dispatch(m) {
        switch (m) {
            case 'withdraw': return withdraw;
            case 'deposit': return deposit;
            default:
                throw "Unknown request -- makeAccount: " + m;
        }
    }
    return dispatch;
}

var account = makeAccount(10);
account('deposit')(5);  // 15
account('withdraw')(3); // 12

The way the dispatch function works for accounts is quite different than in the complex numbers case. In the case of complex numbers, when a message was sent to the dispatch function, it executed the associated operation (i.e. the method) immediately. In contrast, the account dispatch function returns the method associated with the message and that method can then be called.

This is very similar to how JavaScript’s reciever.message(arg) syntax works and we can move to a more familiar object-oriented JavaScript style.

function makeAccount(balance) {
    function withdraw(amount) {
        if (balance >= amount) {
            balance = balance - amount;
            return balance;
        }
        return "Insufficient funds";
    }
    function deposit(amount) {
        balance = balance + amount;
        return balance;
    }
    return {
      withdraw: withdraw,
      deposit: deposit
    };
}

var account = makeAccount(10);
account.deposit(5);  // 15
account.withdraw(3); // 12

In this last version, we’ve stopped writing our own dispatch logic and use JavaScript’s built-in property lookup. This increases speed significantly. We’ve lost the ability to do the __noSuchMethod__ type of dispatching when using standard ECMAScript but that doesn’t seem to be commonly useful anyway.

For the well-read JavaScript programmers out there, you may recognize this last version as durable objects from Douglas Crockford’s book JavaScript: The Good Parts.

I find it interesting that the word “inheritance” does not appear in SICP’s index even though the book goes on to implement complex programs like language interpreters and compilers in a message passing style. That shows this simple style of object-oriented programming can take you far.

The moral of the story is that old books are worth reading and can change the way you program today. You can even read SICP for free.

Now with Tweets

2011-05-29T20:01:00

I'm giving Twitter a try. If you follow me then you can watch the experiment unfold.

MVC To-do Application

2011-04-02T11:59:00

The MVC Architecture for JavaScript Applications article was well received. The clocks application showed a complete working MVC application but more examples are helpful when exploring new ideas.

Today I’m posting another complete example: a to-do application. For best results, use the application but do not look at the source code. Try to program the application yourself and then compare and contrast source code. Then try to extend the application by adding features.

JavaScript Weekly Email Newsletter

2011-04-02T11:23:00

A few weeks ago I subscribed to the JavaScript Weekly email newsletter. A nice collection of links to new JavaScript articles arrives in my email inbox each Friday. Perfect for weekend reading. It fills a hole left by Ajaxian’s demise. You might like it too.

http://javascriptweekly.com/

JavaScript Weekly back issues

MVC Architecture for JavaScript Applications

2011-02-24T22:05:00

There isn’t enough discussion to read about using the model-view-controller architecture for client-side JavaScript web application development and it’s a shame.

History

When I first ventured into client-side web development, “graceful degradation” or “progressive enhancements” were all the rage. Most web pages were required to work in browsers that did not have JavaScript enabled or had very poor JavaScript support. This is still true in many cases.If feature tests showed that the browser supported the required JavaScript then little bits of interactivity were added to the page usually to save full page reloads or make a little animation. The bits of JavaScript were often so small that they didn’t require being architected. Spaghetti code was just fine and anything fancier was overkill.

Early server-side programs were similar. The mainly disorganized CGI scripts accomplished their simple tasks with spaghetti code but they were manageable. Web applications became more sophisticated and the server-side shouldered the brunt of the workload as the client-side was too wimpy to do its share. The server-side code quickly grew larger and required organization. Eventually the Struts server-side web framework came along with its “Model 2” architecture and ever since most server-side web frameworks (e.g. Rails, Catalyst, etc) have touted “MVC” as the optimal way to take requests and generate responses. The request arrives to the controller. The controller gathers data from a model that talks with a database. The controller finally forwards that data to a view template to generate the response. It doesn’t have to work exactly like that but it usually does. Somewhere along the line, the terms “Model 2” and “MVC” became unnecessarily conflated but that can be left as a side discussion. Whatever you call it, the Struts-style architecture has been highly successful at organizing server-side code for its specific request-response functionality and at the very least is MVC-like...but it is definitely not the classic MVC architecture.

It seems that history will mark the release of GMail as the turning point to big “Ajax” client-side web applications. The browsers had grown powerful enough and JavaScript programmers had figured out clever ways of using its features that had been around for a while. The client-side could really start doing some thinking of its own. Full blown “one-page apps” that had functionality resembling desktop application were, and still are, exciting to use. The problem is the code is big and the spaghetti style that is fine for small enhancements is definitely not fine anymore. Some kind of architecture is required for developer sanity.

Many web developers have heard about MVC and have probably been introduced to it in the non-traditional Struts-like incarnation. There have even been attempts to subdue client-side program complexity by porting the Struts-style MVC that was designed for a request-response application to the client-side. Ugg. Not the right choice.

I struggled looking for books on the right way, or even just a good way, to organize large bodies of JavaScript code. I was disappointed that I couldn’t find any. I started venturing out to books on design patterns, Scheme, Java, and one particularly good book ostensibly on ActionScript but more importantly about design patterns. I learned that the classic MVC that started in the Smalltalk world and works so well for desktop applications is a perfect fit for what we do as JavaScript web application developers. I’ve been building JavaScript web applications this way for several years now and feel like there is an MVC hole in my collection articles. This article is an attempt to fill that hole.

Real MVC

In a nutshell the classic MVC architecture work like this. There is a model that is at the heart of the whole thing. If the model changes, it notifies its observers that a change occurred. The view is the stuff you can see and the view observes the model. When the view is notified that the model has changed, the view changes its appearance. The user can interact with the view (e.g. clicking stuff) but the view doesn’t know what to do. So the view tells the controller what the user did and assumes the controller knows what to do. The controller appropriately changes the model. And around and around it goes.

This description is probably a nice summary for those who already understand the MVC architecture but it is way too short for someone who doesn’t know it already. Describing all the ins and outs of MVC is a task I’m not going to attempt in full. I will do three things:

Recommend the books I found that explain MVC well.
Describe some tips about MVC for JavaScript web applications in particular that I have found helpful.
Provide a complete example.

Good MVC Books

There at two books in particular that were a big help for me understanding the classic MVC architecture.

Without question, the best description of MVC I’ve read is in Colin Moock’s book “Essential ActionScript 2.0”. His follow-up book “Essential ActionScript 3.0” does not contain the in depth MVC discussion so make sure you find the correct edition. Although the book examples are in ActionScript, ActionScript is pretty darn close to JavaScript as they are both ECMAScript implementations. I don’t think I could improve on Moock’s discussions of the observer pattern and MVC. Although I’ve had the book for many years, I re-read the MVC chapter last night and it was a treat. I must be getting old if I’m drawing inspiration from books that are out of print. Maybe actually reading paper books is enough of an indicator that I’m getting old.

The other book I found that covers MVC accessibly is “Head First Design Patterns”. The examples are in Java. Even if Java is not your favourite language, it is a perfectly suitable language for depicting an object-oriented architecture like MVC. This book gives a solid description of why the architecture is beneficial. There is also a section on the Model 2 architecture so you can compare and contrast the two.

Another book worth mention is the standard on design patterns. “Design Patterns: Elements of Reusable Object-Oriented Software” describes the three patterns that comprise MVC: observer, composite, and strategy.

I feel a bit like I’m hawking books here but my earned Amazon affiliate commissions over the years is a measly $9.22. I guess I’m not a good salesman. Anyway these books are all well worthwhile and if you can borrow them from a friend or library then you are doing yourself a great favour.

MVC Example

I was planning on giving the example third but perhaps now is a better time.

The MVC clock example is a port to JavaScript of the MVC example in Moock’s book. It is a fancy stopwatch. There is a single clock model. There are two views, digital and analog, that show the model’s time. There is another view that allows the user to click on knobs and a single controller that knows how to handle those clicks to manipulate the model. Click on “start”, “stop”, and “reset”.

To ensure the MVC concepts are shown clearly I have not used a library like YUI, jQuery, etc. The example uses addEventListener directly. It uses canvas with no feature testing. These choices make the MVC aspects of the example much more accessible which is the goal. Use a modern version of Firefox, Safari, or Chrome and all will be well.

You can meditate on the example for days and days. I have. There is no doubt that you will see bits of the code and decide you would do things differently. If that is the case then both you and the example are doing your jobs well. I use the Scheme-style OOP that Crockford has promoted. You may not. I use has-a composition for the observer pattern. You may use is-a inheritance. I use a pull model for the observer pattern here. You may want to use a push model.

To be completely honest, and slightly heretical, I don’t always use MVC properly myself. Gasp! I haven’t found that the flexibility provided by the strategy pattern (i.e. separation of view and controller) is always beneficial in the type of applications I program. Sometimes I glue them together into widgets and this does save a bit of code. I guess I could tell people I use a model-widget architecture. Here is a MW clock example which is close to how I sometimes program. Please feel free to flame me for my lack of separate views and controllers in the comments but at least do it nicely and in good humour.

MVC in JavaScript

Model

The model is all about data and the model is where the primary data in the system lives.

If your application needs to gather data from the server, local storage, cookies, etc then the model is where this should happen. In fact, the model is the only place in the whole system that should know anything about XMLHttpRequest, for example. You may have code in the model layer that loads code for you and creates model objects. For example,

// model constructor function
//
var makeEmailModel = function(data) {
    // ...
    
    return {
        // ...
    };
}; 

// load data from the server and create
// model objects
//
var loadEmails = function(callbacks) {
    doXHR('GET', '/emails', {
        on200: function(xhr) {
            var emailsData = fromJSON(xhr.responseText);
            var emails = [];
            for (var i=0, ilen=emailsData.length; i<ilen; i++) {
                emails.push(makeEmailModel(emailsData[i]));
            }
            callbacks.success(emails);
        },
        onComplete: function(xhr) {
            callbacks.failure();
        }
    })
};

The loadEmails function above is called by bootstrap or controller code. Give the callback properties names like “success”, “failure”, and “invalid” that are semantically meaningful to the calling code as shown in the example. Don’t use names like “on200”, “on500”, and “on400” as those names are related to the mechanics of the actual data getting. Only the model should know about those mechanics and those mechanics may change.

When the model notifies its observers, the model should tell the observers what happened to the model. A model may say “hey, I changed!” and the observers then decide what they do based on that information. The model should never tell the observers what they need to do. The model will never say “you need to redraw the time you are displaying” because the model has no idea if there is any view that is drawing time. The model is oblivious to what its observers might be doing.

The model can notify different groups of observers. For example some observers may only be interested in withdrawals in the following account model.

var makeBankAccountModel = function() {

    var balance = 0;
    var depositObservableSubject = makeObservableSubject();
    var withdrawalObservableSubject = makeObservableSubject();
    
    var deposit = function(amount) {
        if ((typeof amount !== 'number) || (amount <= 0)) {
            throw new Error('deposits must be positive numbers');
        }
        balance += amount;
        depositObservableSubject.notifyObservers(amount);
    };
    
    var withdrawal = function(amount) {
        if ((typeof amount !== 'number) || (amount <= 0)) {
            throw new Error('withdrawals must be positive numbers');
        }
        if (amount > balance) {
            throw new Error('not enough money in account');
        }
        balance -= amount;
        withdrawalObservableSubject.notifyObservers(amount);
    };
    
    return {
        getBalance: function() {
            return balance;
        },
        addDepositObserver: depositObservableSubject.addObserver,
        addWithdrawalObserver: withdrawalObservableSubject.addObserver
    };
};

Note also that this bank account example pushes the amount of the deposit or the withdrawal to the observers. That information is not available for the observers to pull from the model so pushing the data helps give a more complete description of what happened to the model.

If you have limited time for code reviews start by reviewing the models.

The model definitely should know nothing about the DOM. That would be a break down of all that is good.

View

The view is what you see and what you click.

The view is the only part of the system that knows about the DOM. (Except perhaps some of the bootstrapping code.)

Do your best to avoid using id attributes on DOM elements in the view. The ability to put two views of the same class in a page twice depends on not having the same id value in the two views. There are other strategies but you should not need to find elements in the page if your views are well constructed.

When a user clicks on something in the view, the view is too stupid to know what to do. In the clock example, when the user clicks the “start” button, the view doesn’t understand the user’s desire to get the clock model to start ticking. The view has to rely on its controller to make that decision. Since the view doesn’t know what should be done, it should be calling methods on the controller that explain what happened in the view. For example, the view could call a controller method named “handleStartClick”. The view should not be calling a controller method named “startTheClock” because ironically some other interchangeable controller may not start the clock when the start button is clicked.

A templating library that generates HTML is not a view and this is a confusion that seems to come from the Struts-style architecture. In the classic MVC, a view is a living object that observes a model and stays in sync when the model changes. A view might call a templating library to help update the view but the template is not the view. For example,

var makePersonView = function(personModel) {

    var rootEl = document.createElement('div');

    var personModelChangeObserver = function() {
        // The view calls a templating library to generate
        // HTML that shows the person's name.
        rootEl.innerHTML =
            processTemplate('personTemplate',
                            {name: personModel.getName()});
    };

    personModel.addObserver(personModelChangeObserver);

    return {
        // ...
    };
};

Controller

The controller is a decision maker. When a user clicks in the view, the view forwards that event on to the controller so the controller can decide what needs doing.

There is nothing particularly JavaScript-specific about controllers. They don’t know about host objects like those in the DOM or about XMLHttpRequest.

Controllers mutate models and sometimes mutate views. Controllers mutating views is often not the right choice however. Suppose you have a to-do list web app. When the user checks an item as completed, the click is forwarded to the controller. The controller modifies the model item as complete which makes an async save to the server. The controller could tell the view to show a throbber while the model is saving. For example, suppose we have the following to-do model

var makeTodoModel = function() {
    // The id is used in server's database.
    // It is set here when to-do is created.
    var id = '';
    var complete = false;
    var saving = false;
    var changeObservableSubject = makeObservableSubject();

    // ...

    var saveAsComplete = function(callbacks) {
        var saving = true;
        changeObservableSubject.notifyObservers();
        doXHR('POST', '/todo/'+id+'?complete=true', {
            on200: function(xhr) {
                saving = false;
                complete = true;
                changeObservableSubject.notifyObservers();
                callbacks.success();
            },
            onComplete: function() {
                saving = false;
                changeObservableSubject.notifyObservers();
                callbacks.failure();
            }
        });
    };

    return {
        saveAsComplete: saveAsComplete,
        addChangeObserver: changeObservableSubject.addObserver,
        getId: getId,
        getDescription: getDescription,
        getComplete: getComplete,
        getSaving: getSaving
        // ...
    };
};

There are two ways we could use the above model in the view and controller interaction. The first is the controller turns the throbber on in the view.

var makeTodoView = function(todoModel, todoController) {
    var rootEl = document.createElement('div');
    
    var todoEl = document.createElement('div');
    rootEl.appendChild(todoEl);
    
    var throbberEl = document.createELement('div');
    throbberEl.style.display = 'none';
    throbberEl.innerHTML = 'saving...';
    rootEl.appendChild(throbberEl);
    
    var todoModelChangeObserver = function() {
        todoEl.innerHTML =
            (todoModel.getComplete() ? 
                'complete' : 'incomplete') +
            ': ' + todoModel.getDescription;
    };

    todoModel.addChangeObserver(todoModelChangeObserver);

    var showThrobber = function() {
        todoEl.style.display = 'none';
        throbberEl.style.display = '';
    };
    
    var hideThrobber = function() {
        throbberEl.style.display = 'none';
        todoEl.style.display = '';
    };
    
    todoEl.addEventListener('click', function() {
        todoController.handleTodoClick(todoModel);
    }, false);

    // ...

    return {
        showThrobber: showThrobber,
        hideThrobber: hideThrobber
        // ...
    };
};

var makeTodoController = function() {
    
    var handleTodoClick = function(todoModel) {
        if (!todoModel.getComplete()) {
            todoModel.showThrobber();
            todoModel.markAsComplete({
                success: function() {
                    todoModel.hideThrobber();
                },
                failure: function() {
                    todoModel.hideThrobber();
                }
            });
        }
    };
    
    // ...
    
    return {
        handleTodoClick: handleTodoClick
        // ...
    };
};

The potential problem with the above example is if the to-do is represented in the UI twice and that when the to-do is being saved to the server both representations should show the throbber. The fix is to have the view show the throbber based on the model state. Since the model above notifies observers when it is saving we can write the following for the view and controller.

var makeTodoView = function(todoModel, todoController) {
    var rootEl = document.createElement('div');
    
    var todoEl = document.createElement('div');
    rootEl.appendChild(todoEl);
    
    var throbberEl = document.createELement('div');
    throbberEl.style.display = 'none';
    throbberEl.innerHTML = 'saving...';
    rootEl.appendChild(throbberEl);
    
    var todoModelChangeObserver = function() {
        if (todoModel.getSaving()) {
            showThrobber();
        }
        else {
            hideThrobber();
        }
        todoEl.innerHTML =
            (todoModel.getComplete() ?
                'complete' : 'incomplete') +
            ': ' + todoModel.getDescription;
    };

    todoModel.addChangeObserver(todoModelChangeObserver);

    var showThrobber = function() {
        todoEl.style.display = 'none';
        throbberEl.style.display = '';
    };
    
    var hideThrobber = function() {
        throbberEl.style.display = 'none';
        todoEl.style.display = '';
    };
    
    todoEl.addEventListener('click', function() {
        todoController.handleTodoClick(todoModel);
    }, false);

    // ...

    return {
        // ...
    };
};

var makeTodoController = function() {
    
    var handleTodoClick = function(todoModel) {
        if (!todoModel.getComplete()) {
            todoModel.markAsComplete({
                success: function() {
                    // nothing to do
                },
                failure: function() {
                    // nothing to do
                }
            });
        }
    };
    
    // ...
    
    return {
        handleTodoClick: handleTodoClick
        // ...
    };
};

Because the view now depends on the model’s saving state data, all instances of the same to-do visible to the user will stay in sync: when the model is being saved all related views will show the throbber. This is the power of the primary data kept in the model.

Boostrap

The boostrap code is likely a bit messy to get the whole big one-page app up and running at window.onload. Models, views, and controllers need to be created and their relationships need to be established. There is no standard way to do these things. Find a way that is appropriate for your application and try to keep the mess as small as possible.

Conclusion

Hopefully everyone noticed that an MVC framework is not required to build an application using the MVC architecture. It is great that people get excited about a new design pattern or architecture but that doesn’t mean it needs to become a framework. A few helper libraries like the library for observable subjects is sufficient.

Using an MVC style has helped me tame the complexity of some of the bigger projects I’ve work on and it might help you too. If you have experience with the MVC architecture then please leave a comment with any tips that you’ve discovered about how to implement using MVC in the JavaScript world. I’m very curious what others have learned through their experimentation.

I've added another example in a follow-up article: MVC To-Do Application

JSMentors Mailing List

2010-11-25T09:34:00

Recently I was pointed towards a new JavaScript mailing list called JSMentors. The list of mentors is an impressive group of experienced JavaScript programmers. If you are looking for a place to discuss JavaScript-related topics (and cannot stomach Usenet's comp.lang.javascript) then the JSMentors mailing list might be just the community for you.

Scheme from Scratch - Royal Scheme Stall

2010-11-23T09:45:00

Clearly the Royal Scheme project has stalled. I have real work and plenty of it filling my brain. Hopefully Royal Scheme can get going again in the future but I don’t know when that might be.

Scheme from Scratch - Royal Scheme Planning

2010-08-06T15:45:00

The Scheme from Scratch introduction included a list of several possible Scheme implementations. Bootstrap Scheme covered one of those possibilities: a quick and dirty C implementation of a Scheme interpreter. Folks reported that they enjoy the Bootstrap Scheme series and the way the interpreter was developed incrementally. I really enjoyed the feedback and that others were actually following along, coding their own interpreters, and experiencing the excitement when they saw their REPL’s running. I’m excited to continue the Scheme from Scratch series but which implementation next?

The next implementation I will attack is a bytecode interpreting virtual machine which I’m calling Royal Scheme. This kind of implementation is actually both a compiler and an interpreter. The source code is read and converted to an abstract syntax tree. The AST is then compiled to bytecode. Finally the bytecode is interpreted by the virtual machine. The fact that the compiler and virtual machine can both be written in ANSI C means that the implementation can be portable and there is no need to learn hardware-specific machine code.

I want Royal Scheme to be a good-enough Scheme implementation. A Scheme implementation that can actually be used for real programming. An engine that can be embedded in other C programs. Real garbage collection. Real error handling. A foreign-function interface. Even with these features, I’m hoping Royal Scheme won’t top 8000 lines of code. It will still be a simple version of the Scheme family of languages. It won’t be R6RS. It might be R4RS. It doesn’t need to be the world’s fastest Scheme. I’ll trade some speed for source code readability. It does need to be fast enough for some real world applications like writing a blog web application or writing a simple vim/emacs-like text editor.

Implementing a bytecode interpreting Scheme has been written about. You may already have the books. Chapter 5 of Structure and Interpretation of Computer Programs and chapter 7 of Lisp in Small Pieces both present byte-code interpreting virtual machines for Scheme that are implemented in Scheme. I’ve spent a lot of time reading these chapters and thinking about how they might port to C.

Chibi Scheme is a small byte-code interpreting virtual machine for Scheme that is implemented in C. Chibi is an admirable implementation and I think will influence certain parts of Royal Scheme. I’ve talked with Alex Shinn, author of Chibi, about this and he is ok with such influence.

One thing I am sure about is that the pace of the project will be slower than Bootstrap Scheme. Readers kept me excited and moving faster than I thought I would but the coding plus a blog post per day was tall order. Once the Royal Scheme project is genuinely under way, I’m thinking something along the lines of a post per week would be better this time around.

A major detail still up in the air is how to document the project. Bootstrap Scheme was small and simple. The incremental development seemed to work well. I’m not sure that the same will work well for a fully fledged Royal Scheme. Perhaps something along the lines of Knuth’s literate programming style would be better. After all, the interpreters in chapters 5 of SICP and 7 of LiSP are presented much like the woven output of the literate programming style. I haven’t programmed in the literate style before but have thought an interpreter would be an ideal subject for such a style. Any thoughts on documenting the project? What would you like to see in your feed reader?

If you are interested in watching when things start moving, I have made a place holder project on Github. There is not much there for now. I was impressed that fitzgen already found the new repository and is following it.

http://github.com/petermichaux/royal-scheme

Previous article: Bootstrap Scheme Conclusion
Next article: Integers