Feature request: Arrow instead of def keyword, Babel by default, IIFE creation in loops

[m1sta]

Just throwing this all out there for discussion.

I'd love to see CokeScript evolve to be a wrapper above Babel so that we basically got ES7 (or whatever Babel is able to support) but with more terse and more easy to read syntax.

Being able to conciously grab one compliation package would be great. Especially if the result is that any normal javascript would work fine, plus there are a few little shortcuts that can be included too.

The things that jump out in my mind..

• optional curly brackets when indentation is used.
• shorthand skinny-arrow function definition (with optional '=' character where function definition can be directly linked to use of the 'let' keyword)
• multipurpose for-in syntax with automatic inclusion of 'let' keyword
• inline try/catch
• automatic inclusion of 'let' for 'catch variables' in the 'finally' part of try/catch/finally blocks
• optional curly brackes for object literals, and square bracks for array declaration where bracket location can be confidently inferred
• automatic generation of IIFE to help with the loop/closure ugliness (see use of #i in example2 below)
• support for typescript and/or flow style type definition, standard javascript, and JSX passthrough (ie. transform what you can and leave everything else free to progress through the pipeline)
• automatic inclusion of 'async' function prefix where await is used
• automatic wrapping of functions such that they return a promise when resolve and reject keywords are used
• automatic marking of functions as generators where yield is used
• sourcemaps

    let example1 (callback) ->
        try 
            let dataToStore = JSON.stringify(hello:'world')
            await db.put(id: 123, data: dataToStore)
            let resultString = await db.get(id: 123)
            let resultJSON = try JSON.parse(resultString) catch resultString
        catch (err)
            if (err.status !== 409) throw err;
       finally
            callback(err, resultJSON)

    let example2 ->
        let funcs = {}
        for (i in 1,2,3) funcs[i] = (msg, #i) -> msg + i
        for (key, value in funcs) 
            let expected = "Value should be " + key
            let actual = value("Actual value is ")
            console.log(expected, actual)

I'm personally not a fan of automatic variable declaration outside of for loops and try/catch/finally combinations, makes picking up typos more difficult, and classes and array destrucuring are part of the new JS spec. I left these out deliberatley.

[batiste]

• optional curly brackets: No curly brackets for block is a defining characteristic of CokeScript and I don't see many compelling argument why they should be added even optionnaly.
• skinny arrow func def: CokeScript already have def and dom. How would you express the dom func with the skinny arrow?
• multipurpose for-in: What can't you accomplish with the current implementation?
• inline try/catch: Seems like a very isolated use case... But why not
• automatic inclusion of 'let' for catch var: Sorry but you will need to explain that in more detail. Maybe in a ticket by itself.
• optional curly bracket for object literals, and square brackets for array declaration: I like this. Especially in passing a object literal in a function, but I am afraid it might make the grammar quite complex. I would like to give a try though.
• IIFE are a bit awkward right now in CokeScript it is true (probably a consequence of no brackets). I don't understand the point with #1
• Types: I had no time for this. But I would like to have type for e.g. generate more efficient loop depending of the iterated type.

• Async: I haven't even had the time to see what it means.

  "I'm personally not a fan of automatic variable declaration"

In the contrary I find it refreshing. Look at the code of the compiler itself (there is a syntactic coloration file for sublime in lib/). The absence of any let/var is quit a big win of this language in my book.

It would be nice to see some of these points detailed in their own ticket and I encourage you to do so. In the other hand it seems you want to change the language so much it wouldn't quite look like the original design at all. I am not sure all the changes you want are compatible although I am very open to change things especially now that the only software written in CokeScript is the compiler itself.

Cheers

[m1sta]

Thanks Batiste for replying.

• optional curly brackets: the only reason you'd allow them is so that you can optionally include inline javascript unmodified. I think conceptually this is important. You should be able to take the coffeescript concept of 'its just javascript' a big step forward. Start with javascript, then trust the whitespace, then start using the extra language features. One step at a time.
• skinny arrow func def: I just personally prefer how the arrow looks vs the def keyword. I'm used to it from C# and coffescript. Can't comment on the dom keyword.
• multipurpose for-in: the current implementation is perfect. Not looking for this to be changed, just listing it because I see it as an important feature.
• automatic inclusion of 'let' for catch var: this is so that if you have catch(err) you can use the variable err in the associated finally statement, if one exists. Basically just generating let err = undefined before the try statement when it has an associated catch and finally defined. It's only relevant when variables are declared automatically as a general rule (which is obviously my preference)
• optional curly bracket for object literals: I think it should only be allowed in a direct variable assignment or where the delimited list is surrounded by parens. Coffeescript has this but its flexible rules allow for too much ambiguity. I'd not support things like fn(a,b,c:d, e:f) but it's unfortunatley accceptable in coffescript.
• types, async etc: these are largely pass-through type things related to either es7 or other compliers which I'd imagine would be used in the same build pipeline as CokeScript (eg. babel.js)
• I totally understand what you mean about it being too much of a change from the original intent. I'd love to take epeg.js or coffeescript-redux or babel and have a stab myself but it'd take me a very long time given my current capacity and skill level when it comes to parsers.
  • IIFE: it's not a CokeScript problem. It's a javascript problem, but I think I came up with a solution that can help.

Referring to this: http://stackoverflow.com/questions/750486/javascript-closure-inside-loops-simple-practical-example, I'd imagine that...

var funcs = []
for (var index = 0; index < 3; index++)
   funcs[index] = (#index) -> console.log("My value: " + index)

would complie to this...

var funcs = [];
for (var index = 0; index < 3; index++) {
    funcs[index] = (function(index) {
        return function() {
            console.log("My value: " + index);
        };
    }(index));
}

The hash symbol indicates a parameter that should pushed into an IIFE to ensure that it the required closure is created. In my head I think of it as a 'lock' symbol. Similar in concept to Coffescripts do but with an, imho, easier to understand syntax.

[m1sta]

Appologies, I edited my original comment while you were obviously in the midst of replying.

The rational for the automatic function decoration stuff is conceptually along the same lines as the multpurpose for-in that you've already got.

The promises stuff is in recognition of the fact that people will be writing stuff like this a lot now that promises are formally part of the javascript spec...

function get(url) {
  return new Promise(function(resolve, reject) {
    var req = new XMLHttpRequest();
    req.open('GET', url);

    req.onload = function() {
      if (req.status == 200) {
        resolve(req.response);
      }
      else {
        reject(Error(req.statusText));
      }
    };
    req.onerror = function() {
      reject(Error("Network Error"));
    };
    req.send();
  });
}

we could make it look more like...

getUrl = (url) ->
    req = new XMLHttpRequest()
    req.open('GET', url)
    req.onload ->
        if (req.status == 200) resolve req.response
        else reject Error(req.statusText)
    req.onerror -> reject Error('Network Error')
    req.send()

In the end CokeScript ends up generating a few different function types...

• Inline by default using skinny arrow
• Hoisted when function is directed declared on a variable
• Bound when using fat arrow per es6 spec
• Async keyword decorated when a await is used in function body
• Asterix (aka generator) decorated when yield is used in function body
• IIFE wrapped when hash (aka lock character) is used in function parameter name
• new Promise wrapped when resolve keyword is used in function body

[m1sta]

If inferring the function type (generator, promise creating, async etc) is too difficult, which I'm hoping it's not, then being able to simply write fn = async(a,b) -> await a.get(b) and fn = generator(a,b) -> yield a + b and fn = promise(a,b) -> resolve a + bmight be an option.

I prefer the more concise code with the function type inference but I can see an argument for this approach. It's easier on the parser and it makes it very quick to see the type of function that you're working with.

[m1sta]

On the absence or inclusion of let/var outside for loops and catch statements, I think it'd be great to see them not required by default, but if you use them in a scope, you need to use them everywhere. Ie. inclusion of the let or var keyword anywhere in the scope block switches off general purpose automatic variable declaration (which is on by default)

[batiste]

I like the conciseness of this:

req.onerror -> reject Error('Network Error')

Although I think it would be better to have

req.onerror -> reject(Error('Network Error'))

I really dislike optional parenthesis. My brain cannot parse the code without it.

[m1sta]

I totally agree. I hate optional parenthesis too. One of three things that really bug me about coffeescript. I was actually thinking of a keyword at the time but in retrospect it was just stupid. req.onerror -> reject(Error('Network Error')) is better. reject and resolve should are a little like arguments or this in my head (ie. they're not explicitly defined and they can be re-assigned).

This is actually where my thinking has evolved to over the last couple of days: https://gist.github.com/m1sta/218b793d105a5590bc85. Realistically it's looking more like an evolution of coffeescript than anything else. With the exception of the whitespace->brackets conversion the rest can probably be implemented in sweet.js macros.