When macros will get in, will the core get slimmed in favour of macro-definitions?

# Herby Vojčík (9 years ago)

Hello,

in fact, I am just interested on the answer to the question placed in the subject, in the light of recent discussion emphasizing minimality.

Thanks,

# C. Scott Ananian (9 years ago)

I think you will note that many of the "built in" methods in the spec are already implemented in JavaScript code in many implementations (v8, firefox). Similarly the ability to implement more fundamental features in terms of macro definitions may well be pursued by the implementations. But note that the spec does not mandate that these built-ins are defined 'natively' in JavaScript (the spec does not use JavaScript to define the required behavior), and I would expect that macros would be treated similarly: that is, the spec definitions will not be written as applications of macros, but implementations are free to use macros to implement them were appropriate.

I would certainly expect a macro proposal to be evaluated more favorably if it were powerful enough to allow some implementation refactoring of this sort. And in fact, I wouldn't be surprised for a successful macro proposal to have been prototyped in the implementation of one of the major engines.

This is not an official position, of course. But I believe you can use history as a guide. --scott ​

# Brendan Eich (9 years ago)

Sure, we'd want that. And sweet.js can handle a lot (it handled classes, destructuring, and other ES6 features before they were implemented in popular engines). This may take a while. Best way to ensure this outcome: more people learning, using, and helping improve sweet.js.

# Andreas Rossberg (9 years ago)

I doubt this will be possible in a backwards compatible manner. With ES6, we missed the opportunity to take more of a desugaring approach for new features. As a consequence, there now is a fair amount of micro variation between seemingly related features that is only describable in terms of lower-level spec language.