Typings bikeshedding

[vendethiel]

Some time ago (#803) I had started working on a PR to add type hints to the language.

That's still something I miss to this day, so I want to bring it back up. There were a lot of discussions, so I think we should try to discuss it beforehand.

Typing symbol

I suggested the symbol @: to add a type annotation. Someone suggested ^. @gkz suggested ::.

The reason I want(ed) not to use :: is because it's rewritten to ID:prototype when it's parsed directly, at which point we have no info on whether it's going to be part of a signature of just a Parens (we only tag () as PARAM( and PARAM) after seeing ->). We'd need to go through the tokens to mark ID:prototype as ASCR (or whatever else). We'd also need to be careful not to tag in "defaults" – that is, (x = -> ::) ->, (x ? ::) ->, (x and ::) ->, etc...

where to allow typings

I'd suggest we only allow type annotations in:

• function declarations (function and ->/<-/...)
• var
• let

generics

I have one suggestion: [T](xs @: Array[T]) ->. The reason I suggest [] rather than <> is mostly for parse-ability (and because I'm used to Scala...). Tagging []() -> is easier than the ambiguities with <>, we just have to look for a ] when re-tagging a ( as a PARAM(, and cycle back to [ from there (since an array is never callable anyway). (since [T]() -> and xs[T]() -> make no sense anyway)

Parsing the @: Array[T] part is harder, but still simpler than @: Array<T>, where the > would be parsed as a BIOP because it's directly followed by a )...

---

@rhendric I'm interested in your PoV, because it's a sensible topic, considering all the ambiguities to keep in mind :-).

[rhendric]

Nice. Reviewing the thread, it occurs to me that my earlier discomfort with value-level forall also applies to my own proposal of ::>, so the only real difference between the two is readability and the consumption of a new keyword. If we do run with ::>, is there a reason to use square brackets there?

(Still kind of hoping one of us—or someone else—comes up with either an elegant implementation of []() -> (somehow...) or a new syntax proposal that doesn't suck.)

[Djeg]

Hello :). I'm late and probably out of subject but anyway. What about a type system inspired by the fantasy land specification and a bit of purescript ?

It could look like:

# var name: string = 'john'
let name :: String = 'John'

# var add: (a: number, b: number) => number;
# add = function (a, b) { return a + b; }
let add :: Number -> Number -> Number = (a, b) --> a + b

# multiline support and without curry
let sub
  :: (Number, Number) -> Number
  = (a, b) -> a - b

# Generic support:
let map
  :: a, b. (a -> b) -> Array a -> Array b
  = (f, arr) --> arr.map f
# var map: <A, B>(f: ((a1: A) => B), arr: Array<A>) => Array<B>;
# map = function (f, arr) => { return arr.map(f); }

# Interfaced generic support:
let map
  :: User a, b. (a -> b) -> Array a -> Array b
  = (f, arr) --> arr.map f
# var map: <A extends User, B>(f: ((a1: A) => B), arr: Array<A>) => Array<B>;
# map = function (f, arr) { return arr.map(f); }

For function keyword we could inverse the order:

function add x y :: Number -> Number -> Number
  x + y

Wich i think open the door to some inteligent pattern matching (i'm going too far ^^):

let addFiveToTen :: Number -> Number =
  | (10) -> 15
  | (a) -> a

By the way, very good work with livescript, i'm really enjoying it :)

[vendethiel]

What about the lambdas?

[Djeg]

Good point, like do -> 3 + 4 ? Maybe something like do :: () -> Number = -> 2 + 4 ?

I'm not sure to get a concrete use case of a lambda here, do you have any concrete example ?

[vendethiel]

The whole thread goes into detail about our ideas. I know it’s fairly long but have you read all proposals?