Start working on type ascriptions

[vendethiel]

I would like everyone's input on this: the syntax, what we're compiling to, etc.
The idea is to compile down to TS or flow-compatible stuff

[heavyk]

could you give an example? I'm not sure I understand

[robotlolita]

So, basically:

(a @: Type, b @: Type) -> ...

Gets compiled to:

(function(a : Type, b : Type){ ... })

Is the idea to support things like TypeScript or Flow?

[vendethiel]

Yes, indeed. I'll make this clearer.

[robotlolita]

Ah. I'm not particularly fond of the @: symbol, but I also can't think of any other that is available and denotes a typing relationship well :(

I like the idea of compiling to TS/Flow though :3

[vendethiel]

Right? : and :: both doesn't work, so... I went for the one I could think of.

[heavyk]

oh, I see now. yea, I like the idea of compiling to TS/flow.

could this work?

fn = (:a Type, :b Number) ->

[vendethiel]

It'd make the lexer a bit more complex, which I'm not too fond of. But I'm open to opinions.

[robotlolita]

An alternative might be using the same symbol Clojure uses to declare types. It's reusing a symbol, but I don't think that's an issue for argument names:

foo = (a ^Type, b ^Another-Type) ^ReturnType -> ...
foo = (a ^Type = ^clone) -> ...

[vendethiel]

Yeah, but it's currently parsed as an infix MATH (power) :/

[vendethiel]

At least, the fact our unary clone got changed to ^^ helps (because we allow unary ops there)

[waynedpj]

Right? : and :: both doesn't work, so... I went for the one I could think of.

is there any interest in making some breaking changes to free up operators like : and :: that many already recognize as defining types, particularly : used in TypeScript+Flow? IMHO the type ascriptions would take precedence over most other uses of operators.

also, even the Livescript homepage seemingly uses :: for type ascriptions (in the 'Programmatic API' section):
LiveScript.compile(code :: String, options :: Object?) -> String

finally, there already seems to be some discussion on removing duplicated/etc. functionality:
#219
#721

peace

[vendethiel]

We can change the docs, that's very minor. It currently just mimics Haskell's syntax :-).

You're free to ping those issues to try and get some tractions ;-).

[gkz]

(x :: Number) ->

Seems to be a syntax error - maybe we could just support the syntax for function definitions?

[vendethiel]

Problem is just the lexer's complexity. We need to resort to per-nest flag (or something) to parse correctly (a :: Foo = -> ::) ->, say

[vendethiel]

Urgh, https://github.com/gkz/LiveScript/blob/master/test/cs-classes.ls#L289 doesn't parse correctly. Obviously. I guess I need to change the regexp to @:(?!:)...

[heavyk]

ok, if you don't like the atom syntax, what about c++ syntax?

lala = (a<Type>, b<Number> = 3) -> ...

[rightfold]

a isa number

[igl]

Arrow functions are fine and dandy but what aboot braceless function declarations?

function add : number a : number, b : number => a + b
function add @ number a @ number, b@number => a + b
function add @: number a @:number, b @:number => a + b
function add~number a~number, b~number => a + b
function add^number a^number, b^number => a + b
function add<number> a<number>, b<number> => a + b

C++ style looks best to me.

What do you guys think about type contracts like in contracts.coffee or elm?

[vendethiel]

I really don't like parenless function definitions, but anyway, all the signatures will look the same.

[unclechu]

I vote for :: it's easy to catch by eyes for me and I think this:

fn = (a :: Type, b :: Number) ->

is more obvious than that:

fn = (:a Type, :b Number) ->

[coachshea]

agreed
On Fri, Jan 15, 2016 at 06:21:01AM -0800, Viacheslav Lotsmanov wrote:

I vote for :: it's easy to catch by eyes for me and I think this:

fn = (a :: Type, b :: Number) ->

is more obvious than that:

fn = (:a Type, :b Number) ->

—
Reply to this email directly or view it on GitHub.*

[igl]

Unfortunately :: compiles to prototype in LS.
There is also 'function-bind' a es7 proposal using :: it's only a proposal though.

[AriaMinaei]

How about declaring the function type in a separate line?

add :: (Number, Number) -> Number
add = (a, b) ->
  a + b

I think the other syntax (defining the type in the same line as declaring the function) creates too much visual clutter, and it just doesn't go with LiveScript's terse syntax, but that might be a matter of taste.

[unclechu]

@AriaMinaei may be as alternative, but if you have a lot of arguments, inline declaration will be easier to read.

add :: (
  number
  number
  string
  boolean
  Object
  Date
  string[]
) -> number
add = (
  foo
  bar
  test
  test2
  abc
  def
  zyx
) ->
  a + b

In this case I can't say immediately what type does have test2.
And in case with inline type declaration we keep it short and readable:

add = (
  :foo   number
  :bar   number
  :test  string
  :test2 boolean
  :abc   Object
  :def   Date
  :zyx   string[]
): number ->
  a + b

[AriaMinaei]

@unclechu Correct, but how many functions would have that many arguments? A function invocation with more than five or six arguments would be a bit unreadable, unless the arguments are named (through a config object).

Also, writing type annotations in the same line as function declaration makes even simple functions like this overly verbose. I'm not even sure if that is a matter of taste.

[focused]

I love this one style of type declaration:

add :: (Number, Number) -> Number
add = (a, b) ->
    a + b

@unclechu I think we should not pass more than 4 or 5 arguments, in this case we should use data structures (Array, Object). Look:

count-leaves :: (Tree, BranchSide) -> Number
count-leaves = (t, s) ->
  ...

[dead-claudia]

@vendethiel Status?

[vendethiel]

@isiahmeadows still undecided on which token. Overloading :: seems risky (and hard to parse in cases like (a = -> x::) ->, say).

[ghost]

Maybe JavaScript types in TypeScript ?
Uses JSDoc for type information.

[dead-claudia]

@thelambdaparty I really dislike JSDoc type annotations. They are almost a joke in their verbosity.

[rightfold]

They are almost a joke

As is TypeScript.

[dead-claudia]

@rightfold To be honest, Java's type system are better than JSDoc annotations in my opinion. And I really don't like Java. The only thing they're worth using for are for external API documentation, and even that's disputable.

I wasn't comparing them to powerful type systems like Haskell's.

[rightfold]

Who said anything about Java?

[dead-claudia]

I was drawing a comparison to clarify what I meant. Basically, I feel JSDoc
types would suck more than the type system of a really bad language.
Especially for a concise language.

On Mon, Feb 22, 2016, 07:49 I moved to Bitbucket [email protected]
wrote:

Who said anything about Java?

—
Reply to this email directly or view it on GitHub
#803 (comment).

[chrisfls]

So many options...

(a & Type, b & Type) -> ...
(a @: Type, b @: Type) -> ...
(a ::{Type}, b ::{Type}) -> ...
(a ::<Type>, b ::<Type>) -> ...
(a &<Type>, b &<Type>) -> ...
(a <:Type:>, b <:Type:>) -> ...
(a {:Type:}, b {:Type:}) -> ...
(a {.Type.}, b {.Type.}) -> ...

(I really like the syntax of the last two, reminds me of nim's pragmas)

[dead-claudia]

I'm okay with any of those except the ones with ampersands (I would
consistently misread them as type union, which TypeScript isn't the only
one using that syntax).

On Tue, Feb 23, 2016, 06:30 Christian Ferraz Lemos de Sousa <
[email protected]> wrote:

So many options...

(a & Type, b & Type) -> ...
(a @: Type, b @: Type) -> ...
(a ::{Type}, b ::{Type}) -> ...
(a ::, b ::) -> ...
(a &, b &) -> ...
(a <:Type:>, b <:Type:>) -> ...
(a {:Type:}, b {:Type:}) -> ...
(a {.Type.}, b {.Type.}) -> ...

(I really like the syntax of the last two, reminds me of nim's pragmas)

—
Reply to this email directly or view it on GitHub
#803 (comment).

[kay-is]

Do they need to be non-valid js identifiers (like : or ^ etc.)?

If they can be anything, how about § ?

§ is a bit associated with laws (which types essentially are)

my-func = (a §Number, b §String) §Boolean -> 
my-func = (a §Number, b §String) -> §Boolean 

my-func = §Boolean (§Number a, §String b)-> 

[dead-claudia]

I would prefer ASCII symbols to denote types, BTW. And preferably, yes,
they should. I already run into issues occasionally with is and _.

On Sat, Feb 27, 2016, 19:09 Kay Plößer [email protected] wrote:

Do they need to be non-valid js identifiers (like : or ^ etc.)?

If they can be anything, how about § ?

§ is a bit associated with laws (which types essentially are)

my-func = (a §Number, b §String) §Boolean ->
my-func = (a §Number, b §String) -> §Boolean

my-func = §Boolean (§Number a, §String b)->

—
Reply to this email directly or view it on GitHub
#803 (comment).

[heavyk]

I have the § key on my keyboard and I would have suggested it also but the us kbd does not have the key. I always thought it was ascii, but upon looking - alas it is not - I guess it was one of the iso standards.

I'm also ok with whatever cept for ampersands. I suppose the clearest to my eyes is the a @: Type one

[focused]

I have no such key, and many of us

[heavyk]

sorry, that wasn't the point.

I suppose the clearest to my eyes is the a @: Type one

[rhendric]

I know this is a closed PR, but since @dk00 is still linking to it, it seems useful as a repository for bikeshed suggestions. Here's mine:

(a (Number), b (String)) -> ... # not sure what to do about return types though
x (foo: String || Number) = get-object-with-foo-property!

Advantage of this syntax over most of the above: it already parses into an AST, and definitely won't at least the first line probably doesn't conflict with any valid LS since you can't assign to a function call.

(Edit: made some some overconfident assertions there, huh?)

[vendethiel]

I'm not sure what that 2nd line describes? The : is pretty complex to parse correctly.

[rhendric]

Ascriptions for variable declaration.

[vendethiel]

is x or foo the variable?

[rhendric]

x is a variable, with a type that asserts it has a property named foo with value that is a String or a Number. As elsewhere in LS, foo: String || Number is shorthand for { foo: String || Number }.

[vendethiel]

Isn't this ambiguous with x((foo: String || Number) = get-foo!) (declare a variable inside a funcall)?

[rhendric]

Gah, yes, you're right! Righto, that's what I get for tossing off half-baked thoughts in passing.

[vendethiel]

It might be better, at least at first, to only allow type ascription when using declarators (var/const) (maybe in lets as well).

[ozra]

Another soft ball in the air: foo = (x ^Number, y ^String) ^String -> "#{x}, #{y}" [ed: what was I thinking].

A method I'm biased towards (used in my own lang) is that types are required to be Capitalized, while all value identifiers are required to be initial lowercase: foo = (x Number, y String) String -> "#{x}, #{y}" - that's a breakingly breaking rule in an existing language though :-/

Too bad @kay-is suggestion of § isn't us-keymap and us-charset friendly, I considered that one also for my pet lang before :-/

The Haskellish way posed earlier in the issue is a good bet too, and when non-clashing symbology can be figured out - both the inline- and pre- typedecl would be awesome imo.

[vendethiel]

Well, there's always the solution of writing the type signature before the object itself, and not inline. That'd remove a good chunk of ambiguities.

[danielo515]

What is the status of this ?

[rhendric]

Exactly what it looks like. There's the occasional idea being tossed around in #999, if you feel like helping out.

[danielo515]

I'll take a look at that issue.
Thanks