custom language constructs feature #2904

codekestrel opened this Issue Apr 3, 2013 · 7 comments


None yet

3 participants


Is there any thought on adding custom language constructs. I'd quite like to create one that makes integration with requirejs a little more seemless. for example using:

require-import >
    'cs!path/to/first/module' as Module1
    'cs!path/to/second/module' as Module1

compile to

], function(Module1, Module2) {


Thats just one case though. It would be nice if we could define snippet templates, even if the keywords needed to be prefixed to avoid later conflicts.


You might be interested in #2762
Closing for the same reason as #32 :

I'd rather not build in require() functionality -- it's outside the scope of the core language. It shouldn't be hard to have scripts interact. In Narwhal, or any CommonJS environment, use require() and the exports object, as you would in any other JS package.

Also see #331 #2513

@vendethiel vendethiel closed this Apr 3, 2013

The example I gave was misleading perhaps. The idea was to allow custom constructs and behaviors, like plugins. Whatever javascript is generated by the plugin is left solely up to the developer. The require example my just a use I personally would have for it.


close yes, i had the thought of adding abbreviations in mind at start up, however reading that i can see macros proving more useful to everyone. Just need something really, if you went for the plugin route, cs could take after jquery in incorporating the best plugins into the core library. Could also allow exploration of alternative syntax to suit more specific types of scripts, cs already turns json into yml which is fun. Implementing plugins should get more people involved though.


cs already turns json into yml which is fun

The other way ? And that's hardly yaml considering we have no listar, object deserializing etc


I was only commenting on its slight similarity. Another thought though is a subset framework which allows syntax subscriptions, coffeescript would be one subscriber, care would have to be taken to avoid conflicts between subscribers, but either way, customization becomes possible.


@codekestrel: macros have been turned down many times in an effort to keep the language consistent. Please read the other issues and comment there if you feel you still have something to add. Opening new issues just makes more work for us.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment