Hacker News Reader

Comment by lhorie | Hacker News Reader

Types in Javascript? Blasphemy! :)

Jokes aside, you could easily write a preprocessor to do that. If the syntax you want is along the lines of

  keyword identifier { body }
  keyword identifier

it's just a matter of matching tokens, counting brackets and then replacing forms.

With that being said, the examples sounds like making busy-work for yourself. The "module" would still suffer from monkeypatching-related collisions (e.g. think document.getElementsByClassName in old versions of Prototype.js).

Also, javascript has both statements and expressions, so hypothetical macro-enhanced code like this

  var a = module A {}

would break depending on what "module" expands to.

View on HN

The "module" would still suffer from monkeypatching-related collisions (e.g. think document.getElementsByClassName in old versions of Prototype.js).

I'm not sure what you mean. I'm thinking you would annotate the beginning of foo.xjs (extended JavaScript) with

   /*macros: modules.jsm*/

Then run the preprocessor, which will generate foo.js - a plain old JavaScript file.

The `s' in `defs' stands for "statement", so your example would throw the same error as "var a = if (x==4) ..."

    var a = module A {}
            ^

error: expected expression

   /*macros: modules.jsm*/

Whenever I see stuff intended for non-human consumption (doc-comments don't count, because they are just a standardization of a format so they can be more easily consumed by humans, and things like vim modelines don't count because they are not intended to change the meaning of the rest of the file) inside comment markers, I'm reminded of this old JWZ rant about the CDDB format http://www.jwz.org/doc/cddb.html

>> The "module" would still suffer from monkeypatching-related collisions

I mean that the module implementation will be a leaky abstraction because I can still do something like "Object.prototype.boom = true" inside a module and cause widespread brokenness. This encapsulation/robustness problem isn't something a simple macro can fix very easily, unfortunately, so both the module proposal that you linked to and your macro proposal sound like using a hammer as a screwdriver for that particular problem.

>> The `s' in `defs' stands for "statement"

Ah, that clears things up. I'd prefer something like a "defexpression" though, which would allow

  var a = module A {}

On a side note, var a = if (blah) would be cool to see too (well actually, I'd be more interested in var a = for(blah) ).

Ah, that clears things up. I'd prefer something like a "defexpression" though, which would allow

defexpression makes sense, too (but I'd call it `defe' - the more often you use something, the shorter it should be). For some reason, I had the intuition that it would be easier to add statements than expressions, but I don't see why it can't be as simple, as long as they start with some kind of unique token that can be considered a reserved keyword when parsing.

>> but I'd call it `defe' - the more often you use something, the shorter it should be

I was going to write that, but I got the feeling you'd wonder what the "e" stood for :)

counting brackets will get you in trouble if you have to read over strings.

there's no way around a real tokenization.

Crap, you're right. I completely forgot about strings and regexps (and E4X, for that matter) when I wrote that.

Reply on news.ycombinator.com