Forked and made to support OS X: https://github.com/tcr/_why-spool-osx

Makes me excited for a forthcoming Emscripten => Brainfuck compiler.

I experimented with a CoffeeScript-like Lisp in JavaScript once. It's pretty opinionated, but provides interesting syntax possibilities (infix notation, non-significant parentheses and commas for clarity, JSON-compatible syntax): https://github.com/tcr/syrup

    range = fn: [i]
      loop: [i, r = []]
        if: (i == 0) r
          continue: (i - 1), concat: (i - 1), r
    
    print: range: 5                # [0, 1, 2, 3, 4]

For specific audiences, using Gists as data storage is really useful. I did the same for my "reverse StackOverflow": http://askedtheinter.net/

Users own all their data, they can revise their answers, and other users can fork them; just like small Git repositories, and just the use-case that gists generally solve. Compare: http://timcameronryan.askedtheinter.net/q/1318314 with https://gist.github.com/1318314

Hey all, I'm posting this to HN to see if there's any interest in a full-fledged JavaScript port to Lua. Colony right now is a proof-of-concept, but there might be a real use case out there for embeddable JavaScript where solutions like V8 would simply be too large.

Since it's a source-to-source compiler, you can use Colony generally wherever Lua source is required. For example, I was able to follow the beginners tutorials of the Corona SDK (http://www.anscamobile.com/corona/, a cross-platform mobile SDK that uses Lua) by programming CoffeeScript instead, which was surprisingly fun.

Interesting idea and possibly worth tossing out to the World of Warcraft addons/scripting community (single largest Lua end-user install base in the world, I believe) as well?

BTW, the name seems a bit tacky for a language developed in Brazil given the colonial history. Was there another reason for naming it that I've missed?

Hmm, you could target iphone wax https://github.com/probablycorey/wax to make a coffescript dev environment for iOS. Wax is a really nice environment.

Using javascript as a language instead of Lua for scripting though seems odd, as Lua is pretty easy to use instead.

If you like CoffeeScript you should try out http://moonscript.org

CoffeeScript inspired syntax that compiles right to Lua.

This is reworked from my other project, IERange (https://github.com/timcameronryan/IERange).

Rather than include a full duplication of DOM Ranges for old IE browsers, this API normalizes the most important capabilities of DOM Ranges and TextRanges (getting/setting anchors, and directionality). This can be included in a JavaScript library without much overhead, and any other essential DOM Range capability (deleteContents(), setStartBefore(), etc.), can be duplicated as needed by working with the DOM itself.

Sometimes. The primitive types Mug can work with are `double`, `boolean`, `String`, and `JSObject`. This allows arithmetic operations and conditionals to be compiled without wrapping objects, and actual object invocations to be autoboxed as they are in JavaScript (like "a = 10" vs "a = new Number(10)")

The gaudy part is that there is only one type of function signature, basically "invoke(Object, Object, Object...)" which means Mug has to convert doubles to Doubles and booleans to Booleans across function calls... so it's somewhat of a tradeoff.

As al_james metioned, in order to emulate a dynamic language, you have to take a lowest-common-denominator approach. Thus all objects are of the type JSObject, which has functions for get() set() invoke() etc.-- basically a glorified HashMap+Runnable.

However, you don't need to wrap objects for arithmetic operations. At the moment Mug can determine the result of some types of expressions. If you're adding two doubles, it doesn't wrap the numbers before adding them. If you're calling (10).toString(), then it will autobox the number just as defined in the ECMAScript spec (the [[ToObject]] operation).

Deterction currently only works where types are explicit (a number literal will always be a number, etc.) The next step is to do type analysis on local variables, which will allow loops like for (var i = 0; i < 10; i++) { ... } to be compiled without wrapping primitives at all, greatly improving speed.

Right. Technically Mug will conform to the ECMAScript 3 Compact Profile: http://www.ecma-international.org/publications/files/ECMA-ST... Which doesn't include eval() or the with(){} statement (both used infrequently enough that it's not worth the overhead).

A REPL would still be possible, however, it would require some work to maintain the current scope between input.

Is there a reason you are not targeting ECMA5 (with the exclusions you mentioned)?

Much of the runtime has been developing by trying out existing code, then adding support gradually. Of course most of the code I tried out was ECMA3 compliant.

I expect to add in support for ECMAScript 5's Object extensions API (defineProperty, getters/setters) as Mug supports them internally, just as Mug already has a global JSON object. The features which could cause incompatibility with existing code is something I'd have to consider separately, so it depends when a majority of authors start writing ECMA5-compliant code (no function.callee, implicit this object bound to global, etc.)