Idea: Type Inference

[goatslacker]

Have you thought about adding some sort of optional type system along with type inference?

Roy has types.

This can also be something similar to contracts.coffee, except the type checking happens at compile time instead of runtime so you don't get the performance hit.

[gkz]

Well this is going to be really complicated. I'd need to do some reading on the subject before I can consider it.

[gkz]

Better idea: create some sort of optional type specification system which properly compiles to the Google Closure Compiler type annotation comments, so that the compiled js can be run through that and checked if desired.

[goatslacker]

That's a good idea. Will the types still be inferred or will the compiler delegate the type annotating responsibilities to the developer?

[gkz]

The creator of Roy says he is working on a library for Roy that might be able to be adapted to LiveScript.

[ghost]

That would be so cool

[paulmillr]

I've translated python version of damas-hindley-milner type inference algorithm in LiveScript: https://gist.github.com/3130749 (of course it's .ls not .coffee).

I've fixed bugs except ones at lines L358 and L372. Would be nice if someone'll find this bugs.

[jasonkuhrt]

+1. I would welcome some form of type safety.

@goatslacker performance hits could be limited to development via a compile flag (this is what coffee.contracts does). If you make runtime type checking impossible you apparently lose some features (quote):

In fact, since contracts are checked at runtime, they can enforce properties that static type systems can only dream of.

Prime = (x) -> # ...

f :: (!Prime) -> !Prime
f = (x) -> x

Eat your heart out, Haskell :)

[felixSchl]

I am interested in type safety / inference also. I'm also very interested in contributing such functionality. What has been done so far? What happened to that Roy library? Is there someone else working on this? @gkz What's your take on all this? Do you have ideas / opinions on how to approach this? I'm interested in contributing but would likely need some form of mentoring because this is all new land to me. I am currently still familiarising myself with the source code as it stands.

[goatslacker]

https://github.com/puffnfresh/roy/tree/master/src check out typeinference.js

you can probably adapt that to livescript, it's going to be a tough task though since livescript is more lenient in what you can do than roy.

[texastoland]

It'd make more sense to support ES6 optional type annotations and a TypeScript target than implementing from scratch. @puffnfresh is smarter than the average bear (read his blog or check out his contributions) and it's no small task to implement competent structural (duck-typed) type inference. No sense reinventing the wheel. Also I haven't heard talk of LS2 in a while.

[ozra]

I'm also interested in all things type inference.
I was at a Haskell / Erlang seminar recently in Örebro and when I hinted
the speaker of LiveScript he hinted back about PureScript, with
Haskell-like typing.. Might be another source of implementation ideas.

[ed: removed gmail cruft]

[igl]

There is also Scala.js.
LiveScript has a nice niche in functional js-alts by staying close to JS structures and not being a lisp.

It'd make more sense to support ES6 optional type annotations...

ES6 type annotations are a myth?

[apaleslimghost]

ES6 type annotations are a myth?

There's a Traceur experimental feature that supposedly supports this, but it's non-standard, and I'm pretty sure it just compiles to runtime contracts.

[vendethiel]

I think TS wants this kind of stuff to be part of ES7? Not before though...

[apaleslimghost]

Turns out Traceur type annotations are part of AtScript, Google's altjs language they're creating for Angular. They intend to add static verification.

[vendethiel]

But... Isn't atscript supposed to be a superset or typescript that's supposed to be a superscript of ES6?

I know we're not innocent, but it still makes my head fuzzy.

[apaleslimghost]

Future of AtScript and TypeScript

Both of these languages are solving similar problems. The fundamental difference today is that TypeScript is based on ES5 and AtScript is explicitly based on ES6. Once TypeScript aligns with ES6, we intend to be a strict superset of TypeScript. We are collaborating with the TypeScript team on this effort.

[goatslacker]

Currently, there aren't any static typing proposals for ES6 or ES7.

https://github.com/tc39/ecma262

[Delapouite]

Another good place to look at is the strawman list on the wiki :

http://wiki.ecmascript.org/doku.php?id=strawman:strawman

[kay-is]

Is this an Option? http://flowtype.org

[vendethiel]

Nope. Facebook can't even get their projects working correctly with each other (think JSX and flow), so no way we can.

[igl]

Typescript announced union-types too leaving flow dead in the water.
With google making AtScript a superset of Typescript... It looks to me like TS may be the defacto standard for typed javascript.

http://blogs.msdn.com/b/typescript/archive/2014/11/18/what-s-new-in-the-typescript-type-system.aspx

[vendethiel]

Looks to me they're lightyears behind purescript

[michaelficarra]

If you want purity checking and you want to model effects in your type system, there is no alternative. Unfortunately, it doesn't do totality checking yet. That would be awesome!

[vendethiel]

I'm sure Idris2js works as well :)

[igl]

They will probably stay in obscurity and AtScript is what you will have to do at your job in a few years. :P
Something must replace coffeeshit sooner or later. It won't be Pure or Idris and it will probably look like java.

[robotlolita]

TC39 doesn't want to do half-assed (i.e.: optional/unsound type systems) types for JS, afaik.

I think gradual logical types (the way flow does it) could work well for LS.

[vendethiel]

Maybe I should really to see how sweet-js/sweet-core#421 can go without breaking the world, then try to see if I can composably add a "types" readtable thingie (oh, macro and types together, this can be but fun. Well, to be fair, success typings or gradual logical types would make it less of a pain).

(GorillaScript was a contender, but has runtime type checks and very bad codegen)

[ozra]

I'm longing for types. Now that it really is starting to popup both here and there in the JS community, compatibility of type system become something to have in mind - for cross-module type-checking. I do like what I've seen so far in the Flow concept. If say Flow or TypeScript was to take on, and an eco system of modules would grow, it would be nice to be compat with that.
In any event I'd prefer a type system that does static checking only by default, and optionally has RTTI as an option for dev/debug-builds.

[robotlolita]

You don't need to reify type information unless you want to make that available for reflection.

[ozra]

@robotlolita - think "non type aware foreign modules that may or may not behave" and own 'smart dynamic code' that may or may not behave in dev. phase.
@igl - afaiu FlowType also has type unions

Some of my loose opinions:

FlowType

• pros: Primitive types (also strings in this context) are not considered descendants of Object. mixed or any takes primitives or objs.
• cons: Too lenient, the same identifer is allowed to change type, even implicitly, in the same context:

a = 4
a += 43
a = "4"
a += "7"

TypeScript

• pros: allowing widening or change of type must be explictly stated, the "narrower path" is the implicit one
• cons: Sticking with JS native ideology of all types being descendants of Object, which in the type-checking situation is not the primary want imo. That types Object, {}, any all practically mean the same thing doesn't tick with me.

Just my 2 mBTC.

[jepotter1-archive]

What's the status of this now?

[igl]