Typescript: Out of Band Type Annotation Support for Signatures

[iclanzan]

I am not sure if it would be at all possible or feasible but I would really appreciate Hindley–Milner type signature support in TypeScript:

// stringLength :: String -> Number
const stringLength = word => word.length

I am writing a lot of code like this as I find it much easier to read but unfortunately TypeScript doesn’t understand this notation.

Some relevant reading:

• Ramda Type Signatures
• Mostly Adequate Guide to Functional Programming
• Sanctuary Types

[RyanCavanaugh]

What's the distinction vs this? Just the syntactic location, or the actual form of the signature type?

const stringLength: (s: string) => number = word => word.length;

[DanielRosenwasser]

Changing the title, since it doesn't actually have anything to do with Hindley-Milner which is an inference algorithm, not a syntactic style. Standard ML, for instance, doesn't use this syntax.

[mhegazy]

this would be my recommendation:

const stringLength = (word: string) => word.length;

[DanielRosenwasser]

I don't see enough of a motivation to depart from the ECMAScript-reserved syntax, especially given that there's a sufficient mechanism in place that doesn't have any specific problems. For what it's worth, this also took me a little getting used to when I moved from Haskell to Standard ML. Thanks for filing though!

[iclanzan]

Wow, this was closed fast. I was hoping for more discussion. I know there are other TypeScript users that would like to see something like this supported.

What's the distinction vs this? Just the syntactic location, or the actual form of the signature type?

  const stringLength: (s: string) => number = word => word.length;

I find something like the above very confusing/hard to read, and this is for the most basic example.

Changing the title, since it doesn't actually have anything to do with Hindley-Milner which is an inference algorithm, not a syntactic style.

Hindley-Milner is a type system, which does describe an inference algorithm, but also comes with a syntax which functional languages like Haskell and functional JavaScript libraries have adopted to use as type annotations.

I don't see enough of a motivation to depart from the ECMAScript-reserved syntax.

What do you mean by “ECMAScript-reserved syntax”? Since when are these type annotations ECMAScript-reserved syntax? With my proposed annotations I can use regular ECMAScript which allows me to use it in projects where the move to the TypeScript syntax is not desired.

[indiescripter]

Good you came back and explained further as I completely misunderstood your question in the first instance. Sure, this syntax is very familiar to Haskellers

// stringLength :: String -> Number
const stringLength = word => word.length

and, IIRC, Elm (compile-to-JS) language also makes use of the same .. so you are certainly not alone in having some affinity for it.

I'm just a casual observer though does seem like your issue was closed off & dismissed rather quickly. Maybe for the moment you will just have to accept putting your style of type annotations in alla-comment-style, which, btw, is something that I understand Flow people subsequently embraced.

[iclanzan]

I am totally fine and actually prefer putting my type annotations in comments. The problem is I get no help from TypeScript using these type signatures.

[masaeedu]

Today you can write:

type StringLength = (s: string) => number
const stringLength: StringLength = word => word.length

[naholyr]

Not even close :/

[seanpoulter]

Has anyone found a way to support these type annotations? I'm jumping into a JavaScript project using these annotations and would love to support these type annotations in comments like the original post above.

This seems like a good fit for a TypeScript Language Service Plugin.

cc @iclanzan