FAQ

[coffeescript] A compromise between Coco and CoffeeScript

George Zahariev
May 18, 2012 at 9:06 pm
Hi,
I, and maybe some of you, would like to take advantage of the extra
features and improvements provided by Coco <https://github.com/satyr/coco>,
but are put off by some of the syntactical incompatibilities with
CoffeeScript. For instance, I think doing x of list instead of x in list just
feels wrong. I decided to do something about this, and have created
LiveScript <http://gkz.github.com/LiveScript/> (github<https://github.com/gkz/LiveScript>)
- a fork of Coco which is much more compatible with CoffeeScript (while
also adding some functionally oriented features).

Unlike Coco, you can:
use x in list and x of object
use yes/no on/off as aliases to true/false
use CoffeeScript style switches, switch - when - else
use loop for while true
use == for ===
use isnt for !==
use undefined for undefined
use when guards in loops
use expressions in the range syntax instead of just number literals, eg. [x
to y]

I've created a guide for converting CoffeeScript to LiveScript:
http://gkz.github.com/LiveScript/#coffee-to-ls

I hope some of you find LiveScript useful!
reply

Search Discussions

21 responses

  • Mark Hahn at May 18, 2012 at 9:18 pm
    If someone offered a language with coco's features but was backwards
    compatible with coffeescript, I'd switch in a heartbeat. I can't switch
    now because i'd have to rewrite 10,000 lines of code.
    On Fri, May 18, 2012 at 2:06 PM, George Zahariev wrote:

    Hi,
    I, and maybe some of you, would like to take advantage of the extra
    features and improvements provided by Coco <https://github.com/satyr/coco>,
    but are put off by some of the syntactical incompatibilities with
    CoffeeScript. For instance, I think doing x of list instead of x in list just
    feels wrong. I decided to do something about this, and have created
    LiveScript <http://gkz.github.com/LiveScript/> (github<https://github.com/gkz/LiveScript>)
    - a fork of Coco which is much more compatible with CoffeeScript (while
    also adding some functionally oriented features).

    Unlike Coco, you can:
    use x in list and x of object
    use yes/no on/off as aliases to true/false
    use CoffeeScript style switches, switch - when - else
    use loop for while true
    use == for ===
    use isnt for !==
    use undefined for undefined
    use when guards in loops
    use expressions in the range syntax instead of just number literals, eg. [x
    to y]

    I've created a guide for converting CoffeeScript to LiveScript:
    http://gkz.github.com/LiveScript/#coffee-to-ls

    I hope some of you find LiveScript useful!
  • Mark Hahn at May 18, 2012 at 9:21 pm
    Why didn't you go all the way and make it compatible? Partly compatible is
    like partly pregnant. You have only substituted your preferences for the
    coco creator's preferences.
  • George Zahariev at May 18, 2012 at 9:24 pm
    Unfortunately being 100% backwards compatible with CoffeeScript would mean
    giving up some of the improvements that Coco has made. I've changed
    everything that I can without sacrificing Coco's advances. In the future
    I'd like to create a tool that will automatically convert CoffeeScript to
    LiveScript.
    On Friday, May 18, 2012 2:20:41 PM UTC-7, Mark Hahn wrote:

    Why didn't you go all the way and make it compatible? Partly compatible
    is like partly pregnant. You have only substituted your preferences for
    the coco creator's preferences.
  • Mark Hahn at May 18, 2012 at 9:41 pm
    Unfortunately being 100% backwards compatible with CoffeeScript would
    mean giving up some of the improvements that Coco has made.

    Can you give an example? I don't see how that is possible since there are
    always syntax alternatives. As long as the syntax is concise, I don't care
    what it looks like. it's all about the semantics, syntax means very little.

    It is not just an issue of how easy it is to port from LS to CS. It is a
    matter of the barrier to implementation. Giving potential users the
    ability to try LS features in their CS will win a lot more converts.
    Saying you have to make a one-way switch will deter experimentation and
    many possible converts, including myself.
    On Fri, May 18, 2012 at 2:24 PM, George Zahariev wrote:

    Unfortunately being 100% backwards compatible with CoffeeScript would mean
    giving up some of the improvements that Coco has made. I've changed
    everything that I can without sacrificing Coco's advances. In the future
    I'd like to create a tool that will automatically convert CoffeeScript to
    LiveScript.

    On Friday, May 18, 2012 2:20:41 PM UTC-7, Mark Hahn wrote:

    Why didn't you go all the way and make it compatible? Partly compatible
    is like partly pregnant. You have only substituted your preferences for
    the coco creator's preferences.
  • Mark Hahn at May 18, 2012 at 9:49 pm
    Here's an example of a backwards-compatible feature that I really could
    have used this morning ...

    @{a,b,c} = d

    which goes to

    {a: @a, b:@b, c:@c} = d

    I've got a million more I'd like to see.

    In general I'd like to see a language that is open to any new feature that
    doesn't cause problems for people that don't want to use that feature. In
    other words I'd like a coffee-script without such a picky BDFL. I'd donate
    to that.

    On Fri, May 18, 2012 at 2:40 PM, Mark Hahn wrote:

    Unfortunately being 100% backwards compatible with CoffeeScript would
    mean giving up some of the improvements that Coco has made.

    Can you give an example? I don't see how that is possible since there are
    always syntax alternatives. As long as the syntax is concise, I don't care
    what it looks like. it's all about the semantics, syntax means very little.

    It is not just an issue of how easy it is to port from LS to CS. It is a
    matter of the barrier to implementation. Giving potential users the
    ability to try LS features in their CS will win a lot more converts.
    Saying you have to make a one-way switch will deter experimentation and
    many possible converts, including myself.

    On Fri, May 18, 2012 at 2:24 PM, George Zahariev wrote:

    Unfortunately being 100% backwards compatible with CoffeeScript would
    mean giving up some of the improvements that Coco has made. I've changed
    everything that I can without sacrificing Coco's advances. In the future
    I'd like to create a tool that will automatically convert CoffeeScript to
    LiveScript.

    On Friday, May 18, 2012 2:20:41 PM UTC-7, Mark Hahn wrote:

    Why didn't you go all the way and make it compatible? Partly compatible
    is like partly pregnant. You have only substituted your preferences for
    the coco creator's preferences.
  • Josh W. at May 21, 2012 at 5:22 am
    This should work in Coffee:

    {@a,@b,@c} = d

    and this will work in LiveScript:

    @{a,b,c} = d

    If you also need to set local variables, you can do:

    {a,b,c} = @{a,b,c} = d
    On May 19, 5:49 am, Mark Hahn wrote:
    Here's an example of a backwards-compatible feature that I really could
    have used this morning ...

    @{a,b,c} = d

    which goes to

    {a: @a, b:@b, c:@c} = d

    I've got a million more I'd like to see.

    In general I'd like to see a language that is open to any new feature that
    doesn't cause problems for people that don't want to use that feature.  In
    other words I'd like a coffee-script without such a picky BDFL.  I'd donate
    to that.






    On Fri, May 18, 2012 at 2:40 PM, Mark Hahn wrote:
    Unfortunately being 100% backwards compatible with CoffeeScript would
    mean giving up some of the improvements that Coco has made.
    Can you give an example? I don't see how that is possible since there are
    always syntax alternatives.  As long as the syntax is concise, I don't care
    what it looks like.  it's all about the semantics, syntax means very little.
    It is not just an issue of how easy it is to port from LS to CS.  It is a
    matter of the barrier to implementation.  Giving potential users the
    ability to try LS features in their CS will win a lot more converts.
    Saying you have to make a one-way switch will deter experimentation and
    many possible converts, including myself.
    On Fri, May 18, 2012 at 2:24 PM, George Zahariev wrote:

    Unfortunately being 100% backwards compatible with CoffeeScript would
    mean giving up some of the improvements that Coco has made. I've changed
    everything that I can without sacrificing Coco's advances. In the future
    I'd like to create a tool that will automatically convert CoffeeScript to
    LiveScript.
    On Friday, May 18, 2012 2:20:41 PM UTC-7, Mark Hahn wrote:

    Why didn't you go all the way and make it compatible?  Partly compatible
    is like partly pregnant.  You have only substituted your preferences for
    the coco creator's preferences.
  • Mark Hahn at May 21, 2012 at 5:38 am

    This should work in Coffee:

    {@a,@b,@c} = d
    Cool, I didn't think of trying this. Thanks.

    Maybe many other of the million things I want can be done also. I don't
    know any way to discover these unless I read the code or try things at
    random. I don't have time to do either right now.

    Someone should write a "Tips And Tricks" book for CS. I'd happily donate
    to that.
  • George Zahariev at May 18, 2012 at 10:13 pm
    One example is that in Coco (and LS), = declares a variable in the *current
    *scope, := must be used to modify a variable from upper scopes. See
    https://github.com/jashkenas/coffee-script/issues/712. Being 100%
    compatible would mean reverting this improvement.
    On Friday, May 18, 2012 2:40:44 PM UTC-7, Mark Hahn wrote:

    Unfortunately being 100% backwards compatible with CoffeeScript would
    mean giving up some of the improvements that Coco has made.

    Can you give an example? I don't see how that is possible since there are
    always syntax alternatives. As long as the syntax is concise, I don't care
    what it looks like. it's all about the semantics, syntax means very little.

    It is not just an issue of how easy it is to port from LS to CS. It is a
    matter of the barrier to implementation. Giving potential users the
    ability to try LS features in their CS will win a lot more converts.
    Saying you have to make a one-way switch will deter experimentation and
    many possible converts, including myself.
    On Fri, May 18, 2012 at 2:24 PM, George Zahariev wrote:

    Unfortunately being 100% backwards compatible with CoffeeScript would
    mean giving up some of the improvements that Coco has made. I've changed
    everything that I can without sacrificing Coco's advances. In the future
    I'd like to create a tool that will automatically convert CoffeeScript to
    LiveScript.

    On Friday, May 18, 2012 2:20:41 PM UTC-7, Mark Hahn wrote:

    Why didn't you go all the way and make it compatible? Partly compatible
    is like partly pregnant. You have only substituted your preferences for
    the coco creator's preferences.
  • Mark Hahn at May 18, 2012 at 11:44 pm
    I don't see why using := for inner scope would be so bad. why do you care?
    On Fri, May 18, 2012 at 3:13 PM, George Zahariev wrote:

    One example is that in Coco (and LS), = declares a variable in the *current
    *scope, := must be used to modify a variable from upper scopes. See
    https://github.com/jashkenas/coffee-script/issues/712. Being 100%
    compatible would mean reverting this improvement.
    On Friday, May 18, 2012 2:40:44 PM UTC-7, Mark Hahn wrote:

    Unfortunately being 100% backwards compatible with CoffeeScript would
    mean giving up some of the improvements that Coco has made.

    Can you give an example? I don't see how that is possible since there are
    always syntax alternatives. As long as the syntax is concise, I don't care
    what it looks like. it's all about the semantics, syntax means very little.

    It is not just an issue of how easy it is to port from LS to CS. It is a
    matter of the barrier to implementation. Giving potential users the
    ability to try LS features in their CS will win a lot more converts.
    Saying you have to make a one-way switch will deter experimentation and
    many possible converts, including myself.
    On Fri, May 18, 2012 at 2:24 PM, George Zahariev wrote:

    Unfortunately being 100% backwards compatible with CoffeeScript would
    mean giving up some of the improvements that Coco has made. I've changed
    everything that I can without sacrificing Coco's advances. In the future
    I'd like to create a tool that will automatically convert CoffeeScript to
    LiveScript.

    On Friday, May 18, 2012 2:20:41 PM UTC-7, Mark Hahn wrote:

    Why didn't you go all the way and make it compatible? Partly
    compatible is like partly pregnant. You have only substituted your
    preferences for the coco creator's preferences.
  • Josh W. at May 21, 2012 at 7:01 am
    What George is saying is that in LiveScript and Coco, variables only
    modify local scope by default. To modify something in the upper scope,
    you need to use the new := operator which exists in LS and Coco but
    not in CoffeeScript.

    # Basic
    x = 10

    # Nondeclaring assignment using :=
    # := must be used to modify variables
    # in upper scopes unlike in CoffeeScript
    do ->
    x = 5
    x #=> 10

    do ->
    x := 2
    x #=> 2

    That eliminates the need for a `var` keyword in LS and has some other
    advantages (see "biggest coffeescript mistake" thread for fuller
    discussion) but has the big disadvantage of not making LiveScript
    backward compatible with CoffeeScript. Things compiled in LiveScript
    and CoffeeScript will not result in the same Javascript code because
    of this feature, among others (such as ~> vs. =>).
    On May 19, 7:44 am, Mark Hahn wrote:
    I don't see why using := for inner scope would be so bad.  why do you care?

    On Fri, May 18, 2012 at 3:13 PM, George Zahariev wrote:






    One example is that in Coco (and LS), = declares a variable in the *current
    *scope, := must be used to modify a variable from upper scopes. See
    https://github.com/jashkenas/coffee-script/issues/712. Being 100%
    compatible would mean reverting this improvement.
    On Friday, May 18, 2012 2:40:44 PM UTC-7, Mark Hahn wrote:

    Unfortunately being 100% backwards compatible with CoffeeScript would
    mean giving up some of the improvements that Coco has made.
    Can you give an example? I don't see how that is possible since there are
    always syntax alternatives.  As long as the syntax is concise, I don't care
    what it looks like.  it's all about the semantics, syntax means very little.
    It is not just an issue of how easy it is to port from LS to CS.  It is a
    matter of the barrier to implementation.  Giving potential users the
    ability to try LS features in their CS will win a lot more converts.
    Saying you have to make a one-way switch will deter experimentation and
    many possible converts, including myself.
    On Fri, May 18, 2012 at 2:24 PM, George Zahariev wrote:

    Unfortunately being 100% backwards compatible with CoffeeScript would
    mean giving up some of the improvements that Coco has made. I've changed
    everything that I can without sacrificing Coco's advances. In the future
    I'd like to create a tool that will automatically convert CoffeeScript to
    LiveScript.
    On Friday, May 18, 2012 2:20:41 PM UTC-7, Mark Hahn wrote:

    Why didn't you go all the way and make it compatible?  Partly
    compatible is like partly pregnant.  You have only substituted your
    preferences for the coco creator's preferences.
  • George Zahariev at May 21, 2012 at 9:14 am
    Thanks Josh for your much better explanation!
    On Monday, May 21, 2012 12:00:50 AM UTC-7, Josh W. wrote:

    What George is saying is that in LiveScript and Coco, variables only
    modify local scope by default. To modify something in the upper scope,
    you need to use the new := operator which exists in LS and Coco but
    not in CoffeeScript.

    # Basic
    x = 10

    # Nondeclaring assignment using :=
    # := must be used to modify variables
    # in upper scopes unlike in CoffeeScript
    do ->
    x = 5
    x #=> 10

    do ->
    x := 2
    x #=> 2

    That eliminates the need for a `var` keyword in LS and has some other
    advantages (see "biggest coffeescript mistake" thread for fuller
    discussion) but has the big disadvantage of not making LiveScript
    backward compatible with CoffeeScript. Things compiled in LiveScript
    and CoffeeScript will not result in the same Javascript code because
    of this feature, among others (such as ~> vs. =>).
    On May 19, 7:44 am, Mark Hahn wrote:
    I don't see why using := for inner scope would be so bad. why do you care?
    On Fri, May 18, 2012 at 3:13 PM, George Zahariev <
    z...@georgezahariev.com>wrote:





    One example is that in Coco (and LS), = declares a variable in the
    *current
    *scope, := must be used to modify a variable from upper scopes. See
    https://github.com/jashkenas/coffee-script/issues/712. Being 100%
    compatible would mean reverting this improvement.
    On Friday, May 18, 2012 2:40:44 PM UTC-7, Mark Hahn wrote:

    Unfortunately being 100% backwards compatible with CoffeeScript
    would
    mean giving up some of the improvements that Coco has made.
    Can you give an example? I don't see how that is possible since there
    are
    always syntax alternatives. As long as the syntax is concise, I
    don't care
    what it looks like. it's all about the semantics, syntax means very
    little.
    It is not just an issue of how easy it is to port from LS to CS. It
    is a
    matter of the barrier to implementation. Giving potential users the
    ability to try LS features in their CS will win a lot more converts.
    Saying you have to make a one-way switch will deter experimentation
    and
    many possible converts, including myself.
    On Fri, May 18, 2012 at 2:24 PM, George Zahariev <
    z...@georgezahariev.com>wrote:
    Unfortunately being 100% backwards compatible with CoffeeScript
    would
    mean giving up some of the improvements that Coco has made. I've
    changed
    everything that I can without sacrificing Coco's advances. In the
    future
    I'd like to create a tool that will automatically convert
    CoffeeScript to
    LiveScript.
    On Friday, May 18, 2012 2:20:41 PM UTC-7, Mark Hahn wrote:

    Why didn't you go all the way and make it compatible? Partly
    compatible is like partly pregnant. You have only substituted your
    preferences for the coco creator's preferences.
  • Mark Hahn at May 21, 2012 at 5:02 pm
    Things compiled in LiveScript and CoffeeScript will not result in the
    same Javascript code because
    of this feature, among others (such as ~> vs. =>).

    I understand that livescript is a new language not compatible with either
    coco or coffeescript. IMHO that is a big mistake since it is fragmenting
    the space instead of improving anything. We don't need one
    more incompatible language, no matter how great it is. The odds of getting
    a following are very low. Of course if it is just a fun experiment then I
    should shut up.

    I do understand now that `:=` changes semantics in that the Jeremey's
    method of declaring globals would be incompatible no matter what the new
    syntax is. So that semantic would have to be dropped and the `var` keyword
    used instead. That would fix the same problem. I don't see where one
    solution is better than the other.

    I would happily do my own fork if I had the time. At this point I can only
    bitch and moan and hope that someone with the time available will do it so
    i can use it. Actually there is no rush so if I get stuck with no job for
    a while i will take it on. Designing it would be easy. Just take
    semantics of coco and change the syntax to be compatible. I would just go
    down the list feature at a time.

    The new fork would have to pass all the unit tests of coffeescript.
  • George Zahariev at May 22, 2012 at 12:20 am
    My goal with LiveScript is not to make CoffeeScript++ but to make what
    CoffeeScript should have been. To do everything I can to make the best
    language for JavaScript development that I can, for me. I just introduced a
    new incompatibility in creating proper list comprehensions, but this in my
    mind is necessary in order to create the best language I can.

    The thing to do, and what will take a lot of effort, would be to create a
    program which transforms CoffeeScript into LiveScript, allowing people to
    automatically switch. I have another project I want to do after getting
    close to where I want to be with LiveScript, but after that I will have to
    take a long look at creating such a program.
    On Monday, May 21, 2012 10:01:59 AM UTC-7, Mark Hahn wrote:

    Things compiled in LiveScript and CoffeeScript will not result in the
    same Javascript code because
    of this feature, among others (such as ~> vs. =>).

    I understand that livescript is a new language not compatible with either
    coco or coffeescript. IMHO that is a big mistake since it is fragmenting
    the space instead of improving anything. We don't need one
    more incompatible language, no matter how great it is. The odds of getting
    a following are very low. Of course if it is just a fun experiment then I
    should shut up.

    I do understand now that `:=` changes semantics in that the Jeremey's
    method of declaring globals would be incompatible no matter what the new
    syntax is. So that semantic would have to be dropped and the `var` keyword
    used instead. That would fix the same problem. I don't see where one
    solution is better than the other.

    I would happily do my own fork if I had the time. At this point I can
    only bitch and moan and hope that someone with the time available will do
    it so i can use it. Actually there is no rush so if I get stuck with no
    job for a while i will take it on. Designing it would be easy. Just take
    semantics of coco and change the syntax to be compatible. I would just go
    down the list feature at a time.

    The new fork would have to pass all the unit tests of coffeescript.
  • Mike Austin at May 22, 2012 at 1:11 am

    On Monday, May 21, 2012 5:19:59 PM UTC-7, George Zahariev wrote:
    My goal with LiveScript is not to make CoffeeScript++ but to make what
    CoffeeScript should have been. To do everything I can to make the best
    language for JavaScript development that I can, for me. I just introduced a
    new incompatibility in creating proper list comprehensions, but this in my
    mind is necessary in order to create the best language I can.

    The thing to do, and what will take a lot of effort, would be to create a
    program which transforms CoffeeScript into LiveScript, allowing people to
    automatically switch. I have another project I want to do after getting
    close to where I want to be with LiveScript, but after that I will have to
    take a long look at creating such a program.
    The problem is when things are very similar but different, it causes
    confusion and fragmentation. I feel it's a similar scenario with the
    various LISPs and Android phones available. If it's not possible to extend
    CF vs change it, then I would change a lot more and make a new language
    that looks less like CS. Is it possible to extend the parser in the style
    of Scala plugins? Is the parser exposed so that you can extend CS from
    CS? I feel that would be more maintainable than modifying the parser.

    My 2¢

    Mike
  • Steve Howell at May 22, 2012 at 2:30 am
    All the compile-to-javascript languages interoperate with each other and with javascript.

    It's pointless to fight language evolution because of confusion and fragmentation.  It's inevitable.  Embrace it.

    Five years from now the most popular compile-to-javascript language will probably be something other than coffeescript, but your coffeescript code will still work fine in the general javascript ecosystem.

    Between coco, livescript, and coffeescript, I still like coffeescript the best, but I like the competition.  Coco has already influenced coffeescript in positive ways.  "Influence" is an understatement, probably.

    I like that livescript fixes coffeescript's comprehensions.


    ________________________________
    From: Mike Austin <mike.austin.1024@gmail.com>
    To: coffeescript@googlegroups.com
    Sent: Monday, May 21, 2012 6:11 PM
    Subject: Re: [coffeescript] Re: A compromise between Coco and CoffeeScript


    On Monday, May 21, 2012 5:19:59 PM UTC-7, George Zahariev wrote:
    My goal with LiveScript is not to make CoffeeScript++ but to make what CoffeeScript should have been. To do everything I can to make the best language for JavaScript development that I can, for me. I just introduced a new incompatibility in creating proper list comprehensions, but this in my mind is necessary in order to create the best language I can.

    The thing to do, and what will take a lot of effort, would be to create a program which transforms CoffeeScript into LiveScript, allowing people to automatically switch. I have another project I want to do after getting close to where I want to be with LiveScript, but after that I will have to take a long look at creating such a program.
    The problem is when things are very similar but different, it causes confusion and fragmentation.  I feel it's a similar scenario with the various LISPs and Android phones available.  If it's not possible to extend CF vs change it, then I would change a lot more and make a new language that looks less like CS.  Is it possible to extend the parser in the style of Scala plugins?  Is the parser exposed so that you can extend CS from CS?  I feel that would be more maintainable than modifying the parser.

    My 2¢

    Mike

  • Steve Howell at May 22, 2012 at 2:52 am
    The code below might be a good starting point for converting CS to LiveScript:

    https://github.com/showell/CoffeeCoffee/blob/master/round_trip.coffee


    It works off the AST.


    ________________________________
    From: George Zahariev <z@georgezahariev.com>
    To: coffeescript@googlegroups.com
    Sent: Monday, May 21, 2012 5:19 PM
    Subject: Re: [coffeescript] Re: A compromise between Coco and CoffeeScript


    My goal with LiveScript is not to make CoffeeScript++ but to make what CoffeeScript should have been. To do everything I can to make the best language for JavaScript development that I can, for me. I just introduced a new incompatibility in creating proper list comprehensions, but this in my mind is necessary in order to create the best language I can.


    The thing to do, and what will take a lot of effort, would be to create a program which transforms CoffeeScript into LiveScript, allowing people to automatically switch. I have another project I want to do after getting close to where I want to be with LiveScript, but after that I will have to take a long look at creating such a program.

    On Monday, May 21, 2012 10:01:59 AM UTC-7, Mark Hahn wrote:
    Things compiled in LiveScript and CoffeeScript will not result in the same Javascript code because
    of this feature, among others (such as ~> vs. =>).


    I understand that livescript is a new language not compatible with either coco or coffeescript.  IMHO that is a big mistake since it is fragmenting the space instead of improving anything.  We don't need one more incompatible language, no matter how great it is.  The odds of getting a following are very low.  Of course if it is just a fun experiment then I should shut up.


    I do understand now that `:=` changes semantics in that the Jeremey's method of declaring globals would be incompatible no matter what the new syntax is.  So that semantic would have to be dropped and the `var` keyword used instead.  That would fix the same problem.  I don't see where one solution is better than the other.


    I would happily do my own fork if I had the time.  At this point I can only bitch and moan and hope that someone with the time available will do it so i can use it.  Actually there is no rush so if I get stuck with no  job for a while i will take it on.  Designing it would be easy.  Just take semantics of coco and change the syntax to be compatible.  I would just go down the list feature at a time.


    The new fork would have to pass all the unit tests of coffeescript.
  • Pygy79 at May 22, 2012 at 1:26 pm

    On Friday, May 18, 2012 11:24:44 PM UTC+2, George Zahariev wrote:
    Unfortunately being 100% backwards compatible with CoffeeScript would mean
    giving up some of the improvements that Coco has made. I've changed
    everything that I can without sacrificing Coco's advances. In the future
    I'd like to create a tool that will automatically convert CoffeeScript to
    LiveScript.
    A lot of these features are awesome (the list of cool things is just too
    long to write here, basically almost everything :-)

    On the other hand, some incompatible choices in syntax (made either by you
    or satyr) appear gratuitous or IMO misguided. Here are a few suggestions:

    - Switch double and wavy arrows.
    - You may make the CS-style constructors optional...
    - Block comments: mixing the C style and the shell style feels akward.
    Once again, you could allow both styles at little expense.
    - Splats. It makes some sense to use the ES5 convention (I find it it
    easier to parse at a glance, personaly), but the CS one isn't bad either,
    and IMO good enough to be kept.
    - The humongous binary operators are, hum... I'd better not say what's
    on my mind ;-). The convention is ingrained, and you use what is usually
    their short forms idiosyncratically. I don't know of any language where &is cons and
    is function composition. To get back their short forms, you could:
    1. drop ^ for exponentiation. At worse, if you want to keep it, use ^^for XOR
    2. use &&& or *** for cons, for symmetry with +++ for list
    concatenation
    3. use <> for function composition, it looks like the circle operator
    used by mathematicians where (*f* ∘ *g*)(*x*) means *f*(*g*(*x*)). Having
    two composition operators is IMO confusing, because you have to remember
    which is which, and it doesn't add any functionality.
    4. I think that pipes for `case` and `when` are unambiguous and don't
    need backtracking, and the same goes for |>> and |> since |, >> and >are all binary operators. I may be wrong for the pipes, though, because I
    don't know how you handle expressions that span multiple lines.
    5. This frees &, |, <<, >>>, >> and perhaps ^.
    - This make me think that >< looks cool and isn't used anywhere (cross
    product?)...
    - <>< could replace <<<, and <<>< could mean <<<<, they are IMO more
    distinctive (the current ones are heavy look like bitwise ops), and easier
    on the eye. Imagine that the left object is a wriggling fish that sneaks
    into the right one :-). You could also make them represent explicitly
    whether they target arrays or objetcs: <[>< and <{><

    Subpoints 2 and 3 could be implemented even if you keep the long bitops...

    This would make LS a lot more compatiblewith CS.

    Kind regards, and thanks for the language.
    -- Pierre-Yves

    P.S.: Regarding the lack of efficiency of bit operators, it is essentially
    a matter of implementation. In Lua, all numbers behave as doubles. However,
    LuaJIT implements a dual numbering system where numbers are internally
    represented as ints where it is beneficial. This kind of optimisation may
    some day land in JS engines.
  • Satyr at May 22, 2012 at 2:49 pm
    On Tue, May 22, 2012 at 9:11 PM, <pygy79@gmail.com> wrote
    - Switch double and wavy arrows.

    We'll have to give up backcall for that.
    - Block comments: mixing the C style and the shell style feels akward.

    See
    https://github.com/jashkenas/coffee-script/issues/1050#issuecomment-690139for
    the rational.

    P.S.: Regarding the lack of efficiency of bit operators, it is
    essentially a matter of implementation. In Lua, all numbers behave as
    doubles. However, LuaJIT implements a dual numbering system where numbers
    are internally represented as ints where it is beneficial. This kind of
    optimisation may some day land in JS engines.
    Bitwise operations are pretty efficient among JS engines already.
  • George Zahariev at May 22, 2012 at 6:24 pm
    Thanks for the feedback!

    As Satyr mentioned, the wavy arrow ~> allows us to have symmetry with
    backcalls <~, <= is obviously taken already.
    Regarding the constructors, I'll think about it
    Satyr already talked about the comments rationale
    Regarding all the binary ops, inspiration was taken from F# - the piping
    operators |> and <|, the function composition operators, >> and <<, and the
    bitwise operators, &&&, |||, etc. are all as they are in F#, so I think
    there is reasonable precedence.

    In the end if I wanted harder for it to be even more compatible with
    CoffeeScript, I could do it, but I think the benefits of these
    changes outweigh that.

    I'm happy that other people find LS useful, feel free to contact me with
    any more feedback in the future :)

    @satyr I think I read something from crockford describing the bitwise
    operators as inefficient, but obviously I'll have to take a look at that
    again and maybe remove that rationale.

    - George
    On Tuesday, May 22, 2012 5:11:15 AM UTC-7, pyg...@gmail.com wrote:
    On Friday, May 18, 2012 11:24:44 PM UTC+2, George Zahariev wrote:

    Unfortunately being 100% backwards compatible with CoffeeScript would
    mean giving up some of the improvements that Coco has made. I've changed
    everything that I can without sacrificing Coco's advances. In the future
    I'd like to create a tool that will automatically convert CoffeeScript to
    LiveScript.
    A lot of these features are awesome (the list of cool things is just too
    long to write here, basically almost everything :-)

    On the other hand, some incompatible choices in syntax (made either by you
    or satyr) appear gratuitous or IMO misguided. Here are a few suggestions:

    - Switch double and wavy arrows.
    - You may make the CS-style constructors optional...
    - Block comments: mixing the C style and the shell style feels akward.
    Once again, you could allow both styles at little expense.
    - Splats. It makes some sense to use the ES5 convention (I find it it
    easier to parse at a glance, personaly), but the CS one isn't bad either,
    and IMO good enough to be kept.
    - The humongous binary operators are, hum... I'd better not say what's
    on my mind ;-). The convention is ingrained, and you use what is usually
    their short forms idiosyncratically. I don't know of any language where
    & is cons and >> is function composition. To get back their short
    forms, you could:
    1. drop ^ for exponentiation. At worse, if you want to keep it, use
    ^^ for XOR
    2. use &&& or *** for cons, for symmetry with +++ for list
    concatenation
    3. use <> for function composition, it looks like the circle
    operator used by mathematicians where (*f* ∘ *g*)(*x*) means *f*(*g*
    (*x*)). Having two composition operators is IMO confusing, because
    you have to remember which is which, and it doesn't add any functionality.
    4. I think that pipes for `case` and `when` are unambiguous and
    don't need backtracking, and the same goes for |>> and |> since |,
    and > are all binary operators. I may be wrong for the pipes,
    though, because I don't know how you handle expressions that span multiple
    lines.
    5. This frees &, |, <<, >>>, >> and perhaps ^.
    - This make me think that >< looks cool and isn't used anywhere (cross
    product?)...
    - <>< could replace <<<, and <<>< could mean <<<<, they are IMO more
    distinctive (the current ones are heavy look like bitwise ops), and easier
    on the eye. Imagine that the left object is a wriggling fish that sneaks
    into the right one :-). You could also make them represent explicitly
    whether they target arrays or objetcs: <[>< and <{><

    Subpoints 2 and 3 could be implemented even if you keep the long bitops...

    This would make LS a lot more compatiblewith CS.

    Kind regards, and thanks for the language.
    -- Pierre-Yves

    P.S.: Regarding the lack of efficiency of bit operators, it is
    essentially a matter of implementation. In Lua, all numbers behave as
    doubles. However, LuaJIT implements a dual numbering system where numbers
    are internally represented as ints where it is beneficial. This kind of
    optimisation may some day land in JS engines.
  • George Zahariev at Jul 9, 2012 at 8:04 pm
    Hey guys,
    Just a note, LiveScript took a big step toward more compatibility with
    CoffeeScript in the last version.
    - any expressions are allowed in the slicing syntax eg. list[1 to x]
    - constructors are now inherited
    - empty class definitions are allowed
    - bound methods (=> in CS, ~> in LS) are bound to the instance, not the
    class

    This means that the incompatibilities remaining are mostly ones that can be
    resolved with a simple search and replace
  • Robertj at Jul 10, 2012 at 10:26 pm
    Hi George,

    nice indeed.

    Any plans to include macros sometime?

    That would be the tipping point for me.

    Best regards

    Robert

    Am Montag, 9. Juli 2012 22:03:57 UTC+2 schrieb George Zahariev:
    Hey guys,
    Just a note, LiveScript took a big step toward more compatibility with
    CoffeeScript in the last version.
    - any expressions are allowed in the slicing syntax eg. list[1 to x]
    - constructors are now inherited
    - empty class definitions are allowed
    - bound methods (=> in CS, ~> in LS) are bound to the instance, not the
    class

    This means that the incompatibilities remaining are mostly ones that can
    be resolved with a simple search and replace

Related Discussions