Stop Writing JavaScript Compilers, Make Macros Instead

http://jlongster.com/Stop-Writing-JavaScript-Compilers--Make-Macros-Instead

by jlongster • 13 years ago

242 133 13 years ago

johmacindu• 13 years ago

Don't tell me what to do. If I want to write a JS compiler, I can write a JS compiler, and it's nobody's business to tell me not to.

pork2• 13 years ago

Don't post garbage on Hacker News.

pork2• 13 years ago

Very interesting! I've often thought that Javascript could actually be a pretty language with some syntactic sugar. It'd be even more interesting if you could run it client-side without preprocessing an sjs file into js first, sort of like how you can include LESS stylesheets and load a JS module to compile them in the browser.

chc3• 13 years ago

This is basically just saying "Choose Sweet.js in combination with some unknown array of macro libraries as your only language that compiles to JavaScript."

But because the article doesn't really frame it this way, it doesn't really explain to me why I would choose Sweet.js over ClojureScript or Scala.js or Black Coffee or whatever.

sync• 13 years ago

I'd be afraid of inheriting any codebase that made extensive use of these JS macros.

You really have no idea what this is doing (the canonical example from sweetjs.org):

  class Person {
    constructor(name) {
      this.name = name;
    }

    say(msg) {
      console.log(this.name + " says: " + msg);
    }
  }

It's not javascript -- it's your own made up "language" of macros.

I do believe with a steady hand this could lead to some great things, but the example on sweetjs.org seems rather heavy handed. Having different `class` macro definitions between codebases that use sweet.js will devolve into madness.

jlongster5• 13 years ago

You're absolutely right, and we need to establish a good culture that doesn't abuse macros. Of course, some people always will and let's hope we don't have to work with that code.

There are a lot of ripe ES6 features to implement as macros. That `class` macro is actually taken from ES6 and has been standardized for JavaScript, so it's not exactly random.

pfraze• 13 years ago

The syntax "crowding" could be solved by scoping macro rules. Maybe `macro class, foo, bar` at the top of the file?

drivingmenuts• 13 years ago

we need to establish a good culture that doesn't abuse macros

I'm sure everyone who has ever looked at C macros has thought the same thing. It's a great theory.

In practice, having macros will lead to someone abusing them and eventually, that abuse will be become institutionalized.

Don't say "it could never happen here" because it can and it inevitably will.

I don't have a specific problem with all of this, except I keep thinking a better solution would be to hammer browser manufacturers to keep their shit up to date or explain why they are not doing so.

windsurfer2• 13 years ago

Do you know exactly what your compilers are doing? Do you open your compiled C programs in a disassembler? I don't think worrying about "correctness of the implementation" is constructive.

RussianCow• 13 years ago

I think it's less about correctness of implementation and more about abuse of the interface. Not that I agree, but I think it's a completely valid criticism, in the same way that you could argue against operator overloading in OOP languages.

nawitus5• 13 years ago

It doesn't matter what the assembly looks like, if the definition of language is well-defined. With macros this is not true, different 'macro' definitions probaly work in a lot of different ways.

It's true that different compilers and interpreters sometimes do slightly different things, but atleast there's a standard which should improve over time. I don't see that happening with macros.

Not sure how modularity is achieved with macros either.

EpicEng• 13 years ago

Ummm... yes? Sometimes you have to. I was looking into a bug about a year ago that was caused by the compiler I was using (Intel) wasn't properly saving the return address in some situations. This led to seemingly random crashes and thrashed memory.

So yeah, "correctness of implementation" is something to worry about, you just haven't had to (yet).

Mikeb85• 13 years ago

Agree. Implementing classes with macros is not only useless and potentially harmful, but also redundant, since ES6 has classes (which can be used today with dev versions of Firefox, or compiled with Traceur).

aaronem8• 13 years ago

You and the comment to which you respond both seem to be mistaking the specific example on the sweet.js homepage, which is explicitly described as providing ES6-standard functionality early, for the limit of the possibilities inherent in a hygienic macro system. This is a pretty grave mistake, in that it makes understanding the proposition at hand nearly impossible.

sweet.js is more or less a Lisp macro system for Javascript. Gaining some familiarity with Lisp macros would probably serve you well in terms of being better able to understand what's on offer here and how useful it can potentially be.

moron4hire• 13 years ago

I think the idea would be to do something like Racket's approach to Scheme, wherein the vast majority of the language is implemented via macros on a very small core language.

badman_ting2• 13 years ago

Having different `class` macro definitions between codebases that use sweet.js will devolve into madness.

Urgh, I just got a sinking feeling in my stomach because I know how right you are.

yid• 13 years ago

Having different `class` macro definitions between codebases that use sweet.js will devolve into madness.

As long as you don't have different definitions in the same JS file, it's not really a problem because each file can be compiled down to JS independently of the others. I'd imagine you could even add a package.json flag to specify which version of a sweet.js "syntactic sugar" library to use for a given package, and npm could compile the files automatically on install.

The more transparent the sweet.js workflow can be (much like LESS/SASS is for CSS), the more likely it is to be adopted.

davexunit2• 13 years ago

Being able to define a language tailored to your problems is a wonderful thing. Don't be afraid of it.

Scheme and other Lisps macros to build new syntax on top of a small core language.

Are you tired of typing (function() { ... })() and other such forms? If so, you will like macros.

smrtinsert2• 13 years ago

unless I can import a macro like clojure then no thanks. javascript debugging is already a major nightmare since any object can be edited anywhere, i dont need macros multiplying that disaster.

CCs2• 13 years ago

Right. Look at the many wonderful and widely used applications or websites implemented in those heavy DSL systems!

Here is the full list:

hajile• 13 years ago

Do we get madness because different libraries have different implementations of AJAX?

In most lisp dialects, macros are lexically scoped.

As long as sweetJS follows lexical scoping, a set of macros could be contained within a self-executing lambda like most libraries already are.

mattgreenrocks• 13 years ago

Why is this a problem with JS and not, say, Clojure?

wonderzombie• 13 years ago

You're more or less making up a "language" every time you write an API. Among other things, the extent to which you notice this depends on the degree to which one API interoperates well with another one, and the degree to which an API is specific. (See also DSLs in such as Ruby.)

I'm not saying you're wrong, exactly, because there are qualitative differences. Manipulating syntax is definitely more powerful, and enables some truly crazy and wonderful constructs. It should be used responsibly.

But when we define an API, we're inventing a new system of primitives for the problem at hand. It's really not as conceptually dissimilar from a language as we'd like to think.

jarrett• 13 years ago

The difference, though, is that the sweet.js example of classes aims to implement something that is traditionally a language feature. APIs tend not to do this.

You might argue that the distinction between APIs and language features is arbitrary. But I'd say there is a meaningful difference. An API helps you tackle a particular problem domain, such as making an HTTP request, communicating over a USB port, or writing an image. Whereas a language feature is much more generic. It's not limited to any particular problem domain. Rather, it cuts to core of how we express problems in general.

If we're all ostensibly writing JavaScript, I don't think we should be using multiple, incompatible variants of the same language features.

discreteevent• 13 years ago

As Dave Thomas (of OTI not pragprog) said once. "Its important to be able to debug at the level of the abstraction". So in theory making up a language is the same as writing an API. In practice when you are in a hurry trying to fix something and your livelihood depends on it you may end up cursing the macro writer. I do think they can work when there's only one person on the team, which sometimes happens, or if the team are mature and disciplined, which rarely happens. They can also work in any team for trivial stuff like logging etc.

klibertp9• 13 years ago

I have only one thing to say here, to you and to all people who are opposed to macros and new languages in general: go learn some more (let's say 5) languages and then come back[1]. Don't bother before that.

Why? Because learning languages gets easier every time you do it. And it opens your eyes to languages' internal structure, the way languages are composed, which makes using given language effectively easier.

So now you know 5 or 8 languages and you discovered a few basic principles behind most of them and you understand how semantic constructs compose and you know about various syntactic representation of any given semantic statement (and the other way around, similar syntactic constructs having different meanings). And you come upon a macro, like the one in the example.

You don't know what it's doing - well, you just check the docs and then you know. It's as easy as learning what a function does, really. So what was learning those other languages for? It was just to reduce your fear of introducing new syntax for things. You won't think "oh, how dangerous this could be" but rather you just start using it, because you do it (change syntactical constructs you use) all the time when you switch between languages.

At this stage you can learn some Lisp. And write some real macros. And maybe try Nimrod, which has wonderful macros too. And maybe Rust, which I didn't try but I read good things about. After this you'll understand what macros are, how they are constructed and how they compose - and write many of your own - and then you look at the class example above and you instinctively[2] know that there has to be a syntax transformer which matches class keyword, a keyword and a block, and then there has to be another transformer, perhaps recursive (like in Scheme) or just iterating over the body (like in defmacro) and that all they do is to add some keywords here and there and a statement or two at the top of the block. In short - you know exactly what to look for and even docs are unneeded, you just take a quick look at a macro source and go on using it happily. Alternatively you can look at generated code and work out macro implementation from it easily, too.

I'm a happy user of LiveScript, and CoffeeScript before that. The only reason for not switching to JS with sweet.js is the fact that I would need to write a whole host of macros by myself, while in CS and especially LS they are already written. And of course modifying their grammar is not that hard either. Had I somehow been unable to use LiveScript, I'd use sweet.js for sure. What I'd implement? Probably some kind of "let" statement for sane scope management, a loop macro for iterating over custom collection classes (loop in CL, for/* in Racket, also in others), function currying (partial application) and maybe something like "with" context managers from Python would be among the first. There are many things which are better abstracted with syntax than with (for example) functions.

Would the language be JavaScript? Well, hard question, it would be a superset with underlying semantics intact, but it sure wouldn't "feel" like JS. But would that matter? Not at all - syntactic extensions would save me a ton of time and I'm used to many different syntaxes anyway. And I expect anyone who'd like to work with me to be able to pick up any language in reasonable time - the ability to pick up a few additional syntactic constructs on top of already known language is essentially the same thing, so I think such person would have no problems with it either.

Anyway, macros are good; using them is good; the only dangerous thing is having many people implement essentially the same macro over and over again, but I think this could be solved with a sane module system for macros which I read is already planned. There should be more languages rather than less; more exploration of different syntaxes and semantics for things, not less - and macros are one way of making this happen. And if you have problems with learning what a "class name body" does, then I can only refer you to the first paragraph.

[1] After I wrote this post I realized I could sound a bit rude. It was not my intention and I'm sorry if I offended anyone; while written generally, it's actually only a description of a road I personally traveled, so obviously YMMV.

[2] I know completely nothing about sweet.js in particular, so I'm completely just guessing.

novaleaf• 13 years ago

it seems like you are validating @sync's concerns: you are saying it's ok to make up your own language if you have collected good patterns from other languages.

please correct me if i'm misunderstanding.

retrogradeorbit• 13 years ago

macros are good; using them is good;

Unless your problem doesn't absolutely need them. It's considered bad style to use them when not absolutely necessary because they are much harder to reason about.

Macros can be dangerous in the 'give a man a hammer, everything looks like a nail' way. Like when some Python people went mental over meta classes using them everywhere they weren't needed.

I love macros (in lisp) but you shouldn't need to use them that much. They aren't always good.

nostrademons2• 13 years ago

I have written non-trivial programs in C, C++, Java, Javascript, ActionScript, PHP, Python, Haskell, Scheme, Go, and Sawzall, and also played around with prototypes or toy-quality programs in Common Lisp, Ocaml, Dylan, Erlang, Ruby, and Perl. I've written compilers, templating languages, desktop GUIs, web GUIs, mobile GUIs, parsers, machine-learning based data extractors, and distributed systems. I also lead a team, and I'm trying my hardest to bring a large, heavily used product into the modern era when it comes to web technologies. I was a huge fan of macros in college and the few years immediately afterwards. I've now done almost a complete 180 on them, and would encourage anyone I work with not to use them.

The reason is because I've come to understand that social factors trump technical factors nearly every time. The hardest part of writing a software system is almost never solving engineering challenges or writing code, it's communicating the solution to everyone who will have to touch it. Over a software system's lifetime, you will have to read code much more often than you will have to write code. Macros make writing code really easy and communicating everything about what it does, how it does it, and what invariants need to hold for it really hard. That's usually a poor trade-off for anything non-trivial.

fhd2• 13 years ago

I have only one thing to say here, to you and to all people who are opposed to macros and new languages in general: go learn some more (let's say 5) languages and then come back[1]. Don't bother before that.

You know nothing about sync, I presume, yet you assume he/she only knows very few languages because you don't agree. Don't do that.

I don't agree with sync, just pointing out that "go home and learn some programming first" is not a great argument.

gcb0• 13 years ago

good. now you know how everyone else thinks of you using compilers.

Can we all agree that each project needs to use a set of utility functions and move on?

bickfordb• 13 years ago

I suppose you're not the first person to attack macro systems, but can you be clear why it would devolve into madness? It seems like you're saying that developing a common language within an organization is madness, even though this just appears to be factoring common work into syntax.

In the example you cited, it seems like a pretty good language versus other examples I have seen for defining Javascript types?

ScottBurson• 13 years ago

As someone with decades of Lisp experience, I can assure you that macros can devolve into madness. They have to be applied judiciously -- just like, say, operator overloading, and for similar reasons: you're not just adding new APIs to the language, you're adding new syntax.

So there will be newbies who make messes with macros. It's happened in the Lisp world for decades -- though not as often, probably, as some people fear -- and it will surely happen here. Some people will overreact to that (as they have to misapplication of operator overloading) and prohibit their teams from using them. Eventually, knowledge of how to use them well will spread wide enough that most people will be able to be trusted using a language that has them, even if that means, in many cases, that they know they don't have the experience to use them properly and so avoid writing their own.

In this vein I'll close with a quote from the great Lisp hacker David Moon: Functions compute; macros translate.

joubert• 13 years ago

isn't that valid ES6? http://wiki.ecmascript.org/doku.php?id=strawman:maximally_mi...

specialist• 13 years ago

I'd be afraid of inheriting any codebase that made extensive use of these JS macros.

I will not be doing metaprogramming again any time soon.

I'm doing just fine using composition/iteration and creating better, more fluent APIs.

orthecreedence• 13 years ago

Glad someone finally wrote a post about this. Coming from the lisp world, that's the thing I constantly see missing from languages wrapping javascript. They generally change the syntax a bit, add a few features to minimize boilerplate in some areas, and call it a day. Why would I want to learn a new syntax to program in a language I already know well? Unless you give me the tools to write code that writes code, I'm not going to bother learning/using a new javascript syntax.

nawitus5• 13 years ago

At least TypeScript brings to the table something very valuable: optional type checking.

aaronem8• 13 years ago

And sweet.js macros can be used to implement the type system of your choice in otherwise stock Javascript. (For that matter, you could un-overload the + operator so that it only works with numbers, and invent a . operator to do string concatenation.)

I can see a potential argument that doing type checking via macros costs more than precompilation in efficiency terms, but on the other hand, that's not necessarily so. How does TypeScript do type checking for non-constant values? That is, if I define function foo(bar: string) in a TypeScript library, then compile it, load the library in a Javascript interpreter, and call foo(Integer.parseInt("42")), what happens? I'm guessing that either foo() misbehaves, or that foo() throws an exception.

In the former case, there is no benefit to TypeScript because your type annotations are evanescent and misleading -- you can't rely on them, so you either have to write fences around input values just like you would without them, or risk your code misbehaving because it's written to rely on unreliable type annotations.

In the latter case, TypeScript is adding those fences automatically, so that a function which expects an integer argument can check whether it actually got one and fail if it didn't. That's basically what a macro system implementing type checking would do, too, and it seems to me that in both cases optimization would be merely an implementation detail.

ek• 13 years ago

Unfortunately this contribution is inhibited from being significant in value by the fact that TypeScript doesn't support full gradual typing [0] and has an intentionally unsound type system [1].

[0] http://siek.blogspot.com/2012/10/is-typescript-gradually-typ...

[1] https://typescript.codeplex.com/discussions/428572

lightblade• 13 years ago

sweetjs was a good idea, but I've found it hard to use, or rather..it's not the using part that's hard, but writing your own macro.

sweetjs has this hygienic thing that renames identifiers. To prevent it from renaming, there are many hoops that you have to jump through to prevent it.

sweetjs introduces of a lot of new concepts. These concepts are not as easy to understand as the ones in C. The macros are certainly more powerful. It's just that assuming it's C-like macro will give you the wrong kind of expectation with sweetjs.

aaronem8• 13 years ago

Of course! These aren't C "macros"; they're Lisp macros, which is a wholly different, and far more valuable and reliable, proposition.

Granted, I'm not sure how much I like the idea of a macro system which finds macro instances by string-matching the source it's given. But in a non-homoiconic language, I'm not sure anything else is feasible, and I can easily see how something like this could improve Angular.js's dependency injection, for example.

taejo• 13 years ago

Unhygienic macros aren't a C-ism: hygiene was an innovation (I think originally in Scheme). Ordinary Common Lisp macros are unhygienic.

sheetjs• 13 years ago

Since sweet.js code can't be directly run in the browser, you need some "compiling" or "interpreting" step. It's not obvious why this is any different from a compile-to-js language that had support for macros.

For example, someone wrote a macro system for coffeescript: https://github.com/mrluc/macros.coffee

jlongster5• 13 years ago

This isn't intended for people interested in other languages; if you like CoffeeScript, certainly use it. I really like ClojureScript myself. But there's a lot of reasons you already need a build step for JS anyway (especially for client-side), and this gives you a lot of power without having to completely switch languages.

It's worth noting that sweet.js is a robust macro system grounded in academic research (the core of it from the Honu paper). That CoffeeScript system is a bit of a hack and its flaws would show it the whole community started using it (I don't have time to go into this right now, but things like hygiene, etc are really difficult).

mr_luc• 13 years ago

Hi, I made macros.coffee, and I'd like to say that this guy is right. It's non-hygenic (on purpose) and it's a hack.

And purely a labor of love! Slides: http://mrluc.github.io/hammy/12-7-rum-macros/deck.html#1 Code: http://mrluc.github.io/macros.coffee/docs/macros.html

I wanted to see how easily I could add (non-hygenic) macros to CoffeeScript, and if I could do it as an npm-installable module instead of a fork of the language.

It was also an experiment in making macros very clear to myself. Non-hygenic (CL-style) macros are very simple conceptually.

But the basic hack that made it possible to get true CL-style macros also makes the whole thing incredibly dependent on the structure of the CoffeeScript AST. Which makes it fragile.

I'm excited by BlackCoffee, actually. This is the first I've heard of it. Thanks a lot for giving me a nod in the github PR, and of course let's mention Oran Looney as well, who wrote the best deepcopy ever for Javascript (I wrapped this up as owl-deepcopy and made an npm module for it).

aaronem8• 13 years ago

The Lisps in which this concept has its heritage call that step "macro expansion". Granted that that won't happen properly if you use script tags to load a file of Javascript with macros -- but consider, for example, the possibilities inherent in making macro expansion an integral part of the loading process carried out by a library like Require.js. Macro expansion tends to be a lot lighter-weight than compilation does, because it's a simpler transformation; there's no obvious reason why integrating it into Require, or a similar library, should be particularly difficult to accomplish.

phamilton• 13 years ago

You can think of sweet.js like a modular compiler. Let's say you wanted to use the @ syntax or the -> function syntax from coffeescript. Include a macro that does it rather than build a full compiler to do it. Coffeescript could then be a collection of macros rather than it's own compiler. Those macros could be shared across other projects or you can pick one or two for a lightweight Coffeescript-esque experience without having to port your whole codebase.

There's a point where I think this breaks down. It's great for syntactic sugar but I think things like type analysis would become a bit more difficult.

Fishrock123• 13 years ago

I find the title kind of ironic, given that sweet.js is still a compiler. :P

However, it is true it would be better to have one standard-ish compiler that can just execute whichever macros you throw into it.

That being said, you still run into the issue that `sync` brought up.

cromwellian• 13 years ago

JavaScript compilers aren't only for syntax sugar. Closure Compiler, Dart2JS, and GWT are optimizing compilers. Most large Google applications for example would be hideously large without an optimizing compiler.

jlongster5• 13 years ago

Definitely. It was a terse statement for simplicity. I was hoping that my sentence "it's not good for extending javascript" clarified that.

badman_ting2• 13 years ago

I'm not super into the idea of code running on code because I likes it as simple as I can gets it. But, I know this notion is popular with lispers so I get it.

kaoD2• 13 years ago

Don't be fooled by a legion of old-time lispers. Macros are a last resort in real-life Lisp (aka Clojure).

Hard to write (way harder than a function), hard to debug, hard to reason about, they're not functions (so fit worse in the rest of the language)... but powerful when you really need them.

"When you have a hammer...", and a desire to stand out from other languages made the lisp-macro myth flourish.

aaronem8• 13 years ago

Modern Lispers (and modern Lisp learners' resources such as Seibel's Practical Common Lisp) talk about macros in exactly this fashion. I'd be willing to argue that the lesson has been learned.

6cxs2hd63• 13 years ago

Well actually, in a modern lisp (like Racket), you use macros in a variety of ways.

In addition to "deep" things, often you use them as practical, simple alternatives to using stuff like "snippets" or heavy IDEs. You can "DRY" annoying patterns, without resorting to external tooling.

Although macros used badly can be mysterious, so can any excessive pre-processing and build magic.

Macros provide "an API for the compiler", and since the compiler is involved, it can be smarter than external tools.

lispm• 13 years ago

'real-life Lisp' (aka Clojure) is just bullshit.

There are many more real-life Lisp applications which are not written in Clojure.

I'm a long-time user of Scheme and especially Common Lisp. Macros are a consequence of Lisp. Lisp is originally about computation with symbolic expressions (see McCarthy). Application of that to Lisp itself leads to macros and similar. Macros were introduced 1963 to Lisp, extremely early on.

As a Lisp programmer one needs to understand what macros are for and when they are useful. By default I write functions. I also tell people to think in functions first.

But in real life, the more advanced Lisp applications are full of macro usage and macro definitions.

Sure they are harder to debug. But Lisp programmers have developed tools to deal with that. Not everyone wants to learn such a complex language, or is able to learn it or has time to learn it. There are a lot of simpler tools and even simpler Lisps - but for those who want and need this, a language like Common Lisp will provide the necessary flexibility.

yuchi• 13 years ago

Did you had a look at [gorillascript](http://ckknight.github.io/gorillascript/)? Its [prelude](https://github.com/ckknight/gorillascript/blob/master/src/js...) is written in gorilla macros :)

al2o3cr• 13 years ago

Sup dawg, I heard you wanted to stop writing JS compilers and start using macros so here's a JS compiler that implements macros.

/head asplodes

kirtijthorat• 13 years ago

I would also recommend the WISP: A homoiconic JavaScript dialect with Clojure syntax, s-expressions and macros. More details at: https://github.com/Gozala/wisp

nessus42• 13 years ago

I enjoyed the article. I just have a factual correction: Lisp had real macros as early as the 70s, not the 80s. (Maybe even earlier, for all I know.)

daniel-cussen• 13 years ago

Lisp macros were introduced in 1963 by Tim Hart at MIT.

pmcjones• 13 years ago

Here's the original technical report:

ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-057.pdf

rcarmo• 13 years ago

Best way I know of using macros in JS is https://github.com/Gozala/wisp, which generates pretty readable code. If you're going to pre-process, you might as well write in a nicer language...

ahunt092• 13 years ago

So, after puzzling around with the macro for swap a bit, it seems like macros are like functions, except without the scoping rules, which suggests to me that we now have two kinds of functions, to keep track of in the code, each of which look identical, but behave differently. swap(a,b) looks like a function, but can interact with all the variables in the same scope (or above) as when it's called (is this the same for global functions?). Maybe I'm missing something big, but that seems dangerous when the macro is declared in another file, and I have to go figure out how it behaves.

MBlume• 13 years ago

Macros are not functions, macros are a mechanism for adding features to the language itself.

ahunt092• 13 years ago

Maybe I wasn't clear. I am not saying that macros are functions. I'm saying that without seeing the implementation, both look identical, and thus could be conflated, but do not treat scope identically.

skrebbel• 13 years ago

I strongly agree with everything the author writes, but I believe that sweet.js might not go far enough. For example, I am very fond of TypeScript. I'm also very fond of React's JSX. Yet, I cannot mix the two, and neither JavaScript extension could be expressed as Sweet.js macros.

smrtinsert2• 13 years ago

There are many reasons why people are writing *->js compilers, lack of macros isn't the least of the problems for js. Please keep the compilers coming, no productive coder really wants to write js.

bryanlarsen• 13 years ago

The author's point is that the best way to implement Javascript sugar like CoffeeScript is by writing sweet.js macros rather than by writing compilers.

14113• 13 years ago

So wait, what does this have that's better than C macros apart from hygiene? I'm afraid I really don't follow.

norswap• 13 years ago

If you need the same for Java: https://github.com/norswap/caxap

Dewie• 13 years ago

I think things like syntactic sugar is perfectly fine, as long as I can desugar it in a straightforward way. I want to be able to programmatically desugar some piece of code, not have to Google it each time I am curious.

I think that if it is easy to investiage things like syntactic sugar, and not have it be buried in something like a compiler or lang spec, then DSL/language implementers (and anyone else, if the language permits it) could get away with implementing things that objectively make the language more complex to deal with, because to decipher it is only a query away, anyway.

charlieflowers2• 13 years ago

Right. IDE features would be needed such as Emacs features which show the expansion of the macro you're on.

chromanoid• 13 years ago

How do you deal with naming collisions of macros from different developers? Are you considering to introduce name spaces? To me macros as well as other surprise code modification stuff seem unfeasible in teams with more than a few developers. Don't you think you risk maintainability with a huge macro apparatus?

disnet2• 13 years ago

We're working on integrating macros and modules to address this. Once it's implemented you'll be able to do something like `import { m } from "macros.js"`.

charlieflowers2• 13 years ago

>>> "What if JavaScript actually adopted macros natively so that we never even had to run the build step?"

Honestly, that's pretty damn exciting. In my book, if JavaScript did that, it would very nearly complete a "worst to almost-first" transformation as a language. Starting with its early versions and all their ugly "bad parts", and advancing all the way to one of the most exciting, expressive languages to work with.

aryastark• 13 years ago

I barely trust Guy Steele with macros. You know who I don't trust with macros? Random JS coder dudes that haven't learned what true hardship is, when debugging a macro that is 5 levels deep and subtly changes the language because, hey, I have a macro! And having a macro means using a macro.

Language design is hard. Scheme has gotten it wrong. Over. And over. And over. They didn't get hygiene right for more than a decade. They still don't have it right. But people think they can easily invent new syntax that somehow doesn't do unexpected things. Your clever macro isn't so clever when some poor son of a bitch has been beating his head on a bug all day long just to find out your macro-that-looks-like-a-function isn't evaluating all its arguments because your macro-that-looks-like-a-function is really a function-that-is-a-macro. Don't get me started on missing IF branches and undefined behavior...

vpj• 13 years ago

You can also use C macros with Javascript http://vpj.svbtle.com/coffeescript-and-macros-clean-and-fast

voidr• 13 years ago

You won't have good IDE support.

You won't be able to directly debug your code.

Also it can be really fun to reason about nested macros.

Stop Writing JavaScript Compilers, Make Macros Instead

Related Stories