CS2 Discussion: Features: Type Annotations

[rattrayalex]

I've assumed it'd be next to impossible to add type annotations to CoffeeScript, but thought we should open an issue to discuss if it might be possible. Static Typing is undergoing a renaissance of sorts these days, with developers flocking to new statically typed languages and adding static annotations to dynamic languages like Python (see PEP484) and JavaScript (via Flow and TypeScript).

Flow supports gradual typing for JavaScript, and has some decent tooling to make development easier. They have loose plans to ingest an ESTree AST, which could allow integration of Flow and CS6.

I don't think TypeScript would be a viable target for CS6, as it doesn't play well with Babel (a probable target of CS6) and requires "complete type coverage", which wouldn't likely gel well with CoffeeScript developers, who don't like typing (pardon the pun).

While this would be awesome, I struggle to see how it could work, at least with Flow-like syntax and readability:

obj: {[id:string]: number} = 
  thing: 7
myFn(a: []number, b: number): []number ->
  a.map(x -> x + b)
myFnThatTakesACallback(a: number, cb: (id: number) => Promise<number>): Promise<number> => 
  cb(a).then(x => x + 1)

[realJoshByrnes]

Types? K.I.S.S.

(String a) = ->
  return "You said #{ a }"

The resulting JS would have to be something like:

function () {
  testType(String, a);
  return "You said " + a;
}

and inserted up top would be something like:
testType = function(type, data) { if (data !instanceof type) throw TypeError 'Expected type' }

Thoughts?

[rattrayalex]

Static types are definitely preferable to runtime types, as they can be useful during development. Flow has a lot of tooling built around it already, and performs a lot of valuable, complex inference work.

[rattrayalex]

It'd also be nice to keep the typing syntax as close to Flow/TypeScript as possible, given that they are the community standards for typed JavaScript.

[dadleyy]

I'm not too inclined to see a type system make it into this project. I think it would be a significant departure from the original language and takes away some of the simplistic beauty of it. Type systems are amazingly helpful in compiled languages like go and c++ but in browser-side applications there is a lot of power in weak typing; I'm thinking about error-first callbacks that either accept an Error or Boolean type as their first argument, and that distinction indicates the successfulness of the function. It would be very cool if there was a strongly typed "sister-language" that could come out of this project but the important distinction is that it would be separate (think scss and sass maybe?)

[MemoryChips]

In typescript there is a type 'any' which I would guess covers your issue.
To leave out typing is a mistake IMO. Angular 2 uses typescript to good effect. You would have trouble getting me to go back to coffeescript without a type system.
Rob

[rattrayalex]

@dadleyy I think if you familiarize yourself with Flow and/or TypeScript, you will find that your concerns do not apply.

[JimPanic]

Flow looks really nice, but I'd have to (again) get used to inline type specs.

Elixir handles this in a different way that is really easy on the eyes as it doesn't clutter the actual function signature, but you only annotate it:

defmodule LousyCalculator do
  # ...
  @spec add(number, number) :: number_with_remark
  def add(x, y), do: {x + y, "You need a calculator to do that?"}
end

http://elixir-lang.org/getting-started/typespecs-and-behaviours.html

Maybe it is possible to incorporate Flow with Coffeescript in the long run, though? (Instead of implementing our own…)

[dadleyy]

@rattrayalex I guess as long as any sort of typing is optional my concerns are moot but that needs to be the case, otherwise we're talking about a not-insignificant departure from the original coffeescript (and es6 too). Would there be any sacrifices/breaking-changes to the language's grammar because of typing?

I have to imagine that building a single compiler that supports optional typing is much more difficult to build than one without typing at all though, and holding up support for all the es6 goodies we're trying to bring to coffeescript because sometimes we want to add types to our symbols seems like a bummer. What if however, while building the new compiler if we were to keep tying in mind and make it easy to extend the compiler to support them and later created some sort of coffeescript++ typed compiler? Supporting two compilers would be a nightmare I suppose though. I just think we can come up with a solution wherein typeless coffeescript users are not in anyway effected by the desire to add types.

Flow seems like it's very much a "post-processing" system; wouldn't a tool like that just belong in a codebase's build system after having compiled coffeescript into js? In the same regard, isn't solid test coverage using tools like jasmine/mocha also a good defense against the problems that a typing system try to solve?

[rattrayalex]

@dadleyy again, I think it'd be very helpful if you familiarized yourself with Flow (read the docs, install, add the types to a toy project, read up on the benefits of static typing, etc).

But, yes, I should be explicit that types would be both optional and gradual. This issue is to add support for Flow for those who want to use it, not to require usage of Flow for all users.

For example, Babel has flow support built-in (enabled via a plugin) but most Babel users do not use Flow.

[carlsmith]

Worth mentioning that we could maybe reuse some ideas from ASM here. It converts this C code...

int f(int i) {
  return i + 1;
}

...into this JavaScript...

function f(i) {
  i = i|0;
  return (i + 1)|0;
}

[carlsmith]

It's also worth mentioning that once you add a feature, everyone has to use it, whether they want to or not. You can't just opt out of a feature, unless you can disable it entirely, as other people will use it, and you will need to read their code.

I can decide not to use an English word in my own sentences, but I still have to use the word whenever someone else includes it in one of their sentences. Just reading a word is still using it.

[MemoryChips]

You may prefer to not see types in other peoples code but I think it helps the readability.

In Typescript, you can set the compiler to implicit any which which allows you to avoid the requirement for types in your code.
In my opinion if Coffeescript6 does not have type checking, it will lose much of its potential users base.

Rob

[rattrayalex]

@carlsmith - in some languages, types are required everywhere. For example, you can't write any Java code without using types.

I'm not proposing this kind of requirement for coffeescript.

[carlsmith]

I know??

I was responding to @ozjd, where he said "The resulting JS would have to be something like"...

function () {
  testType(String, a);
  return "You said " + a;
}

We may not need to have type-checking functions if we use ASM style type-casting, and let the JS engine throw errors. Perhaps not though. I haven't thought this through, but it seemed worth mentioning, as it might solve at least some of the problems that would come up if we added typed variables to CoffeeScript.

I also responded to your comment that types would be optional, which is a perfectly valid point, but people often confuse that with meaning that you don't have to use them if you don't want to, which is a bit of an overstatement. We would still be complicating the language for every user.

Personally, I'm totally against adding static types to CoffeeScript. You can't change anything more fundamental than a language's type system. The original proposal was for type hints, so the compiler would treat them like comments, except that they are in the AST for other tools to work with. They have no semantics, only syntax. I'm not in favour of type hints, but am happy to discuss it and see if anyone can make a compelling case for them. Statically typed CoffeeScript is another language entirely.