LiveScript 2.0.0

[celicoo]

Any plans for a second version?

[dk00]

Related discussions: #683, #705, #811, #821, #903, #910

I believe that converting LS AST to Babel AST is the most easier way to generate latest ES code, and already started working on it.

The preliminary convert function can handle Var, Assign, Block, Fun, converted AST of this:

a = -> (a) -> a = b = (b) -> a = b = it

generates this:

let a;

a = function (it) {
  return function (a) {
    let b;
    return a = b = function (b) {
      let a;
      return a = b = it;
    };
  };
};

Basic node types (Literal, Parens, Return, Chain, Call, Index, Key, Assign, Binary, Unary, Arr, Prop, Obj, If) will be added soon, and then import and export.

The plan is turn import to this at top scope into ES import, and an option for output type of export, so we can use import like using require!

import lodash
import lodash: _
import lodash: *: _
import lodash: {merge, set, omit: skip}
import \side-effect

or

import
  lodash
  lodash: _
  lodash: *: _
  lodash: {merge, set, omit: skip}
  'side-effect'

to

import lodash from 'lodash'
import _ from 'lodash'
import * as _ from 'lodash'
import {merge, set, omit as skip} from 'lodash'
import 'side-effect'

and

import options: location: {host, port}

to

import location$ from 'options'
const {host, port} = location$

and

export {name0: local, name1, module: {name2, alias: external}}

to

export {local as name0, name1}
export {name2, external as alias} from 'module'

[determin1st]

don't go to the dark side. const's, let's and other classes just go imerative way. It's right there, in Ecma, why not using ES? - just don't make LS worse.

[askucher]

I am interested. By the way, Livescript 2.0 should support html (jade's structure) syntax inside in order to use React

product-row = React.create-class do
  render: ->
    <tr
      <td
        <span
          if @props.product.stocked
            style:
              color: 'red'
          @props.product.name
      <td @props.product.price

[dk00]

We can use React in similar way at this time, with additional commas:

require! react: createElement: h
#Coming s∞n: import react: createElement: h

function product-row product: {stocked, name, price}
  h \tr,,
    h \td,,
      h \span if stocked then style: color: \red else,
        name
      h \td,, price

+1 for HTML-like syntax. Maybe we can omit < after first level?

function product-row product: {stocked, name, price}
  <tr
    td
      span if stocked then style: color: \red
        "#name"
    td "#price"
    "additional text"

[unclechu]

@askucher I don't see any profit of specific syntax for that, React already provides React.DOM object that you could use, it contains most of html-tags (React html-tags) that you need provided as object keys.
Example: https://bitbucket.org/unclechu/react-learn/src/210d9cd6a71d22f84cc2162010e77d37b291212e/src/js/main.ls?at=master&fileviewer=file-view-default#main.ls-60:83

[sra448]

I would very much welcome development on Livescript. It is my favourite compile-to-javascript language, but it gets increasingly more difficult to justify its use to customers and even employers, as everybody seems to love ES6 so much.

Personally, I think Livescript could use some streamlining (like, do we need it?). It would also be huge, if we were able to get some better tooling (like ESLint) and maybe even optional types (haskell style 😜 ).

[unclechu]

@sra448 I personally need it. Good type system would make LiveScript just perfect. I would personally just like to see custom operators in LiveScript, like we do it in Haskell.

[determin1st]

Separation of concerns?

[celicoo]

I think we need make official, we have the people to help, so let's do it! I think we need first create a repo like https://github.com/coffeescript6/discuss to discuss new implementations and collect some proposals.

[dk00]

The name livescript is taken but not used at all, could we claim it and use it as our organization name?

[sevvie]

I'd love to help with the development. I'm looking for a pet project.

…

On Sat, Jan 21, 2017 at 7:49 PM, dk00 ***@***.***> wrote: The name livescript <https://github.com/livescript> is taken but not used at all, could we claim <https://help.github.com/articles/name-squatting-policy/> it and use it as our organization name? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#943 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABlJuLMIcX6FHx1vDrQ0_S-4or1WO3m8ks5rUqeCgaJpZM4LWpWh> .

[KyelSinOo]

[gkz]

Re: @dk00 if you start a new project, I would prefer you choose a new name so there is no confusion (like I chose a new new when I forked coco)

[dk00]

@gkz
I'm working on an external version of #862 (discussed in #821), a function turns the result of LiveScript.ast code into something acceptable for Babel.transformFromAst or some other good ES code generators.

I'm satisfied with LiveScript and not going to start a new project.

[gkz]

Cool!

[tpisto]

Hi! I created slack team for all livescript lovers:
https://livescript.slack.com/shared_invite/MTM0NDI1NzkzOTA2LTE0ODU4MDIxODktNGFlNmNiM2Q3Nw

Please join and let's discuss there about the ES6 path. I'm willing to put some effort for that too.

[tpisto]

What comes to React, I think its not necessary to try include JSX. I have been perfectly happy with
window.$ = React.createElement. Quite the same as @dk00 example of require! react: createElement: h

That way I can write (like React Native) code easily like

  render: ->
    $ View, style: { flex: 1 },
      $ Text, null, 'Hello World!'

This removes all the JSX limitations and allows very easy and readable if/else structures too.

And if you want to work visually more conveniently with dom, you can simply

for key, value of React.DOM
  window["$#{key}"] = value

Then just

render: ->
  $div className: 'my-hello-world',
    $ul className: 'my-list',
       $li className: 'my-list-item', 'Hello World From List'

[unclechu]

@tpisto we already have #livescript on freenode, I vote NO for shlack. It have been discussed before.

[askucher]

@unclechu You example looks ugly. React provides the syntax where you can combine html + js + css natively and people really LOVE it. This concept generates final javascript which does not require additional treatment and library to support it. And please do not think that livescript language is already developed. Most of people do not think so. Overwhelming majority. Most of them think it is abandoned.

[unclechu]

@askucher It doesn't matter about what I think about is it developed or not. My point is I don't think that your example makes any sense at all, what the different between yours and my example? It's just one single thing - you'd just added < symbol before every tag name, is this changing whole sense? I don't think so. I don't mind if you develop separated extension to make it works (like jsx developed as extension for javascript) but things like this one is definitely shouldn't be part of livescript core.

But I wonder, what specific thing makes my example 'ugly' and your example, I don't know, 'perfect' or 'okay'? That one additional foreign symbol added to every tag name? I won't believe it.

And about this:

This concept generates final javascript which does not require additional treatment and library to support it.

Is that to? Isn't JSX just syntactic sugar for React.createElement wrapper? Or any other wrapper that in case depends on context ? So I don't think it's correct, it IS require a library to make it work.

[foxbunny]

React provides the syntax where you can combine html + js + css natively and people really LOVE it.

That's true, but adding < in front of a tag name does not even begin to approach JSX.

[dk00]

I have contacted GH staff and claimed the name livescirpt for our organization, invitations are sent to contributors.

[askucher]

Hi Guys

Let me share my thinking about LiveScript 2.0

https://hackernoon.com/react-livescript-livescript-2-0-164d35ca5373#.nkdlaygmw

I would like to recommend to discuss there

[determin1st]

https://www.pandastrike.com/posts/20150311-react-bad-idea

[caasi]

@askucher:

I think algebraic data types can help me more than syntactic sugars when I am using React + Redux.

[ozra]

Sorry for making a hasty comment here before reading the thread, but I'll just input my 2 satoshis, while I have some seconds to spare:

1. Call it something else than LiveScript 2 - rather something that hints towards the heritage, I think a ground rule should be that when "a language" breaks backwards compat (except if compat-mode/layer is avail), it shouldn't be called the same name. Period.
2. MUST... HAVE... TYPES!!!!!

:-)

[determin1st]

@ozra

1. agree.
2. why you think it must have types (strong types?). dont you find merging type feature useful? for example:

if (someVariable) { /* do something */ }

(or var reuse)

isnt a nice construct? (if you know that someVariable may be [A][B][C] type and to what it will covert)
please explain your vision. imo, the typeless system may be upgraded somehow without taking hard-rock typing style from imperative languages..

[AriaMinaei]

I think @dk00's livescript-next is going exactly in the right direction. Hats off to him for doing such a great job.

[ozra]

@determin1st - I have strong opinions on types in "real" languages (check out Onyx if you want, which syntax I've been inspired heavily from LS for example) (wow, that came out harsch - well, I code probably 2 hours livescript every day, for everything not system-code, so you know I love LS :-) ), but for a new "livescript-like" I'd be happy with just about anything in way of types :-)
@AriaMinaei 👍

[unclechu]

@determin1st I think it's okay when your application isn't more than hundred on lines of code. When application is big enough I can't be sure it's [A][B][C] anymore, I mean I can make a mistake and when compiler doesn't help me to realize it and my app fails in runtime I'm starting to hate this compiler. In my personal experience I could tell that even when my app is more than 15 lines of code it's easy to make a mess that could be cleaned up by having strong type system.

[determin1st]

@unclechu

imo, you are wrong. it doesnt depend on number of lines of code. it depends on state isolation technique. For example, common imperative style:

function
var closestHandle, index, thisVarTellsYouSomething, ... (and more alike, var flood)

compared to this:
function
var a, b, c, ... (number depends on largest state isolation block in the function)

any way, we should compare what we are talking about in code examples. we may use some tools related to language, which may affect our style. but it's not the language itself. it's all about tools, libs and frameworks.

btw, you can define as many 'strong types' with scope you like using only functions. no need to inject them into base layer - language.

@ozra

i've checked Onix readme. why did you select "--" as a comment? it pushes me to doubt that "b[--a]" syntax may be used some day.

[ozra]

@determin1st - Yes, let's not hijack thread here, but it simply was the most natural comment prefix I could thinkg off: that's how I always write comments on paper when i pseudo-code at a cup of coffee. I've tried to find the most "natural" ways of expressing the code I would think of. --/++ are intentionally avoided, and will not be part of Onyx. </ end of off topic>