Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

custom language constructs feature #2904

Closed
codekestrel opened this Issue · 7 comments

3 participants

@codekestrel

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

define([
     'cs!path/to/first/module',
     'cs!path/to/second/module'
], 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.

@vendethiel
Collaborator

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
@codekestrel

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.

@codekestrel

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.

@vendethiel
Collaborator

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

@codekestrel

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.

@michaelficarra
Collaborator

@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
Something went wrong with that request. Please try again.