including and extensions

[weepy]

Extensions are an excellent idea. I was wondering whether it would make best sense to be able to indicate to the CoffeeScript compiler that a particular extension should be used on a per file basis. Something at the top of the file like:

using "funky_interpolations"

[matehat]

Since extensions are used to compile scripts, it would require a kind of preparser to check for those, before initializing the parsing.

Also, I thought it could be nice to have a kind of cake task to install extensions into the user coffeescript distribution. That way, third-party libraries using extensions could include and install them together along their own scripts.

[olsonjeffery]

When this was first discussed, I suggested that a command-line flag like '--extend filename.coffee' would be nice.. a cake task to install it into the stdlib could lead to versioning issues.. id much rather get behind a "for this run of the compiler only, use this script to extend syntax" .. it's easily automated and not permanent.

[matehat]

I agree, but a for-this-run-only strategy would be exceedingly confusing and awkward for many if not most real-world situations. For instance, when importing a third-party library that uses a particular language extension, every user should specify the given extension and get errors if he forgets to do so.

Also, I don't think we would see much versioning on language extensions.

[weepy]

the necessary extensions should be marked up within the script itself in some manner. otherwise the scripts are not portable enough.

[matehat]

Agreed. It would be dead simple when we want to use a particular set of language extension grouped under a certain name to just specify it somewhere in the file, using a keyword like :

using functional

The proper check could occur in CoffeeScript.compile() function. The raw content would be preparsed, detecting the given keyword (e.g. using ..) and capturing extension names. If these extensions happens to be resolvable, in a yet-to-be-determined way, they would be put on the Lexer's extensions stack, later used for actual parsing.

I may take a look at it later this week, when I get more time.

P.S. resolving language extensions could be module-based. E.g. we could look for a module of the specified name, that would export a function named something like language_extension. Just an idea.

[matehat]

Given they were module-based, a cake task to install them, as much as any other module, seems as natural as sudo rake install.

[matehat]

Hey, I pushed changes on http://github.com/matehat/coffee-script/tree/extensions, that allows one to use the statement :

#use package

to include a language extension. As a side effect, it works perfectly on the REPL. Here, package should be a module resolvable with a regular require('package') instruction. That module, for the moment, is looked for an exported function named EXTENSION that will act as the actual language extension and extend the active Lexer instance. All this happens before the actual parsing.

You might be wondering why I propose a commented syntax. I think that, to allow greater portability, a user running a third-party script should not have to worry about what other module he should compile along that script to make it work, for instance. Also, I don't think that including every findable language extension be a good option. Finally, using modules, any third-party program wishing to use a particular language extension could just include it together with the rest of its dependencies in its package definition. Dependencies on extensions, then, stays just as simple as dependencies on modules. Also, I thought leaving it neutral (commented) in the resulting script should be nice.

It reminds us all of ANSI-C compile instructions, as a mnemonic.

[weepy]

I don't quite get the commented syntax argument. Without the extension being run, the script won't work ?
I agree that each script should be compiled against only the dependencies that are defined within it - to maximise portability.

[matehat]

It's commented because parsing of this statement does not take place at compile time, but right before it. Before compiling, a special function looks for this kind of statement and updates the lexer accordingly. Then, when compiling occurs, since its commented, it does not interfere with actual code.

[jashkenas]

This is a great ticket, but I think a little premature. Before we add pragmas for extensions, we need to have some actual extensions, and we need to settle the appropriate syntax for writing them. Let's leave this on hold for the time being, and come back to it when there are a couple of extensions that could use it.

[yozlet]

Has there been any more discussion of the extensions feature in the past year-and-a-half since this issue was closed? I ask since I've been looking at a number of extension candidates:

• contracts.coffee
• the "defer" work
• Coco's many additions
• and the many, many extensions already available for JS

I'd love to use some of these.