-
Notifications
You must be signed in to change notification settings - Fork 10
Why Spaces?
For a long time I wanted a language that programmers could redefine syntax, for the purposes of being more explicit about what they were trying to do. This meant being able to add new control structures, or new ways of defining entities or concepts in a program, but without making it look like we're playing tricks with the existing programming language. I wanted new concepts to look like they were built-in and first class.
At first I thought this would require serious syntax-level macro processing. I liked Lisp macros and their flexibility but I felt Lisp's syntax held it back from most programmers, so the solution was getting macros into a language with infix operators: and this was Dylan.
But macros are complicated things. They shouldn't be, of course, but they are. They are just a bit more complicated than regular functions, which are the primary means for programmers to redefine their language. Unfortunately, functions are just a little bit inflexible, which is why macros were invented in the first place. But, with dynamic languages, especially those with reflection a second nature, like JavaScript and Ruby, functions become the primary means of meta-programming too. Still though, syntax for functions is a little off, and they are still treated as second class to the host language's built-in control structures.
With macros too complex, and with functions too second-class, I wondered how we could merge the two. Not in any serious meta-programming way, but just in syntax. Could a function call look like a control structure, like if
, or try {} catch {}
? Well, yes. What happens next is that control structures are functions and use lambda: the ultimate imperative. Just like Smalltalk. No need for special knowledge in meta-programming, or how macros really work under the hood, just higher-order functions that look classy.
Smalltalk gave something else to this too: the idea that each argument could be identified as part of the call. I found this idea too intoxicating to let go, and with arguments mixed up in the name of the call, we get a much better representation of the programmer's intention.
Not to say that I don't like macros, at all. In fact, many of the so-called built-in language constructs are indeed implemented as macros, albeit, internally defined. We'll get a macro API soon enough.
According to the documentation, you can have Closure Compiler add the sourceMappingURL to the bottom of the script with something like this:
--output_wrapper "%output%
//# sourceMappingURL=output.js.map"
being added to your call. Not that you cannot use "\n" here, and you need a newline literal. On a Linux shell this works just fine (if you're inside of quotes when you press enter, the command doesn't get executed).