removing features

[gkz]

So far (on master), slated for removal (and currently with compiler notices upon use):

• short function syntax - f(x) = x - [currently has notice] why: hacky implementation, duplicating functionaly use --> to make curried functions
• +++ concat op [currently has notice] why: added ++ as concat op, which is shorter and better
• where statement - relatively useless - just use local var assignment or a let statement [currently has notice]
• undefined alias for void - added for CoffeeScript compatibility, but with coffee2ls that is not an issue [currently has notice]
• !? inexistence op [currently has notice]

---

discussion:

• choose one of ** or ^ for power op?
• remove import and importAll?
• remove x is not y to mean x isnt y, have it mean x is !y instead
• yes/no/on/off aliases - added for CoffeeScript compatibility, but now with coffee2ls, this is not an issue

More controversial:

• remove standalone use of @
• remove standalone or hanging use of ::

[vendethiel]

I like ** more for power op. Maybe remove either . or << ? Not sure about import/importAll, but with implements, it became less useful

Discussion : simplify switch

[michaelficarra]

** has been accepted as the exponentiation operator in CoffeeScript (see jashkenas/coffee-script#2026), definitely go with that. Already implemented in CoffeeScriptRedux at michaelficarra/CoffeeScriptRedux@6bc355d027326d5d1e42650d9178dae8eb5554cf.

[michaelficarra]

Also, regarding yes/no/on/off, I actually use yes and no all over the place in my CoffeeScript code. It's probably a 9:1 ratio of yes/no to true/false. They just make more grammatical sense when they're used as the answer to a question.

[DavidSouther]

I rarely use import/importAll, much preferring <<< and <<<<

[apaleslimghost]

import and import all are much more readable and obvious, especially as functions, i.e. map (import a:5).

[cocodrino]

yes quarterto..I think the same..import is much more obvious, the livescript syntax is great but it has too much symbols (a good haskell son :D) I'm much more ocaml syntax fan and I think the symbols only are goods when they're used so much or use a keyword could be so long...

I really like ++ for concat over +++ ...

[gkz]

Also thinking of removing inexistance !? as it conflicts with call with no args + existence. Eg. f()? is different that f!?

[vendethiel]

+1. It's a mess and not readable at all.

[gkz]

Also:

• remove undefined as alias to void
• remove x is not y to mean x isnt y, have it mean x is !y instead

[gkz]

More controversial:

• remove standalone use of @
• remove standalone or hanging use of ::

[vendethiel]

I quite like @ when in a call blah(@)... but I see your point. I don't for ::

[DavidSouther]

Standalone use of @:

I regularly use @ standalone at the end of a function to return this;

Hanging :::

I regularly use Type:: <<< to quickly assign several properties to a prototype.

---

David Souther http://davidsouther.com

On Sun, Dec 30, 2012 at 2:52 PM, George Zahariev [email protected]:

More controversial:

• remove standalone use of @

• remove standalone or hanging use of ::

  — Reply to this email directly or view it on GitHubhttps://github.com/gkz/LiveScript/issues/219#issuecomment-11768087.

[apaleslimghost]

@DavidSouther we have ::= as sugar for .prototype import.

[DavidSouther]

You learn something new every day! @quarterto Thanks!

[craigyk]

my 2¢: remove it as automatic assignment to single argument function calls.

Is it just me? When I first saw LiveScript I thought, 'cool, look at all these features', but my second thought was: 'they can't hope to keep more than half of these in the long run'. The problem is I don't know which half. Was that the idea?, to throw everything and see what shakes out?

[vendethiel]

A lot is coming from @satyr/coco, and it's been since around two years I think (maybe more ?). These are features thought before by satyr. LiveScript came, added back some coffee compatibility, and of course functional sugar.

[vendethiel]

Remove with BLOCK, I can't see where you can't do that with do/cascade. The cloneport could maybe be changed to use another keyword ... We have with/when/where, maybe we could avoid having 3 different keywords (when they don't have a so different meaning)

[satyr]

I can't see where you can't do that with do/cascade.

Cascade sometimes is inconvenient as a prog1 due to the requirement of at least one ref in its body (as of satyr/coco#179).

[vendethiel]

why just not use do then ?

a do
  do
    some instructions
    d

Also, LS removed withstatement as argument as per #53 (we have <| do as a replacement)

[satyr]

That's a progn, not prog1.

[vendethiel]

That's a progn, not prog1.

(we have <| do as a replacement)

but I suppose it is inconvenient

[texastoland]

remove import and import all?

import/import all is very nice for static mixins (maybe there's a better way?) cf.:

class A extends B implements C
  import all B, C

class A extends B implements C
  @ <<<< B
  @ <<<< C

9:1 ratio of yes/no to true/false

:+1: from ObjC but I see their redundancy.

@ standalone at the end of a function to return this;

:+1:

Remove with BLOCK

:+1: :+1:

[ming-codes]

I think the where statement can make better styling when used appropriately.

promise.then resolve, resolve where resolve = (fate) ->

# vs.

resolve = (fate) ->
promise.then resolve, resolve

result.join('&')
  where result = for key, value of data
    switch
    | typeof value in <[ number boolean string ]> => "#{key}=#{value}"
    | value.length => (for item in value => "#{key}=#{item}").join('&')
    | otherwise => ''

# vs.

result = for key, value of data
  switch
  | typeof value in <[ number boolean string ]> => "#{key}=#{value}"
  | value.length => (for item in value => "#{key}=#{item}").join('&')
  | otherwise => ''
result.join('&')

[jorgebg]

I regularly use @ standalone at the end of a function to return this; import and import all are much more readable and obvious, especially as functions, i.e. map (import a:5). 9:1 ratio of yes/no to true/false

:+1:

And please :smile: let me remind #297:

[...] allowing the use of implements outside class definitions in order to be able to declare functions and variables with the implements id

[PkmX]

+1 @lightblade. I also would like to keep where in Livescript, it really helps readability when skimming over code because it moves the important parts of body to the top of function definition. This is like reading an article: the first line should give you a rough idea what a function does and the implementation is followed in case you need to get into the detail.

[PkmX]

Also favoring the removal of on and off for gkz/prelude-ls#55. Personally I haven't found them to be very useful in increasing readability, YMMV. Maybe we can move them to prelude-ls as const on = true and const off = false.

[robotlolita]

I share @PkmX and @lightblade POVs on where, so I'm :+1: -ing it here.

[karamfil]

I regularly use @ standalone at the end of a function to return this;

I am doing this a lot - allows chaining.

Also using it together with jQuery is quite nice: $(@)

[vendethiel]

this standalone allows chaining too

[DavidSouther]

Well, sure, but it's the aesthetic of the bare @ that draws me to it. Three less characters, and it looks like a little hook hanging there at the end of the method, just begging the next coder to hook in to it.

---

David Souther http://davidsouther.com

On Thu, Jul 25, 2013 at 1:30 PM, Nami-Doc [email protected] wrote:

this standalone allows chaining too

— Reply to this email directly or view it on GitHubhttps://github.com/gkz/LiveScript/issues/219#issuecomment-21570515 .