Types as comments syntax?

[piranna]

(Crossposted from https://github.com/JSMonk/hegel/issues/387)

Hegel inference system is really powerful, so types are usually not needed, but some times they are. For that, a Typescript / Flow syntax is being used, that later needs to be removed. In the same spirit of type annotations proposal where types syntax should be treated as comments by Javascript runtimes so there's no need of transpilation, what about if we add a comments-based syntax so we don't need it either? Two options I find here are respect JsDocs when they are defined, that are pretty common but verbose, or allow to use inline comments. This can be verbose too, so to minimize them, I propose to use inline comments, and consider them Hegel types if the first token inside the comment would be a valid Hegel type token:

const num /*:number*/ = 42;

function func(a/*:number*/, b/*:number*/)/*:number*/
{
  return a + b
}

/*
type A
{
  name: string
}
*/

class B /*implements A*/{}

Syntax would need to be developed in more detail, but you get the idea, and I think that would be the most minimal solution.

[ReinsBrain]

@piranna - I believe one the goals of this proposal is to bring typescript (sorry i don't know too much about flow) back into the fold because it's a notable fork. also, the trans-pile step is frustrating and already being eliminated in many places (like bun for example). your suggestion, while interesting, doesn't really meet the goal.

although it might be nice to point this suggestion towards JSDoc as a (potentially) cleaner alternative/option to it's current method of annotating type information which is a bit clunky :)

[piranna]

I believe one the goals of this proposal is to bring typescript (sorry i don't know too much about flow) back into the fold because it's a notable fork

No, it isn't, or at least not in theory. It's true original syntax proposed in the spec is very much aligned to the Typescript types syntax, but I think that's mostly because it's a proposal initiated by Microsoft developers. In the spec they say very clear the DON'T want to add all Typescript types system and custom types, and would like to get comments from developers of other types systems like Flow or Clojure, to try to get a common space.

the trans-pile step is frustrating and already being eliminated in many places (like bun for example)

I think it's not being eliminated, but hidden by being automatic by the runtimes, but it's not a feature of the languages, and definitely that would not work on web browsers.

your suggestion, while interesting, doesn't really meet the goal.

Just the oposite, I think totally make sense and it's core to the spirit of the proposal, since initially it was intended that types were considered as comments, but later it get merged with defining a typing syntax, and I think that's what got us bikesheding with the problem and get no advances in two years.

In that way, I think it makes a lot more sense to follow a path similar to what Python did, allow to have type annotations without any actual syntax in them, just being a free form string attribute, and later there would be other alternatives that implemented the actual types checking, like mypy and others. After getting some common syntax between them, then it started to get integrated in the language itself. I think my proposal can help on that way, and can be implemented just today.

although it might be nice to point this suggestion towards JSDoc as a (potentially) cleaner alternative/option to it's current method of annotating type information which is a bit clunky :)

I didn't though about propose it to JsDoc, definitely that would be a nice idea :-)

[piranna]

although it might be nice to point this suggestion towards JSDoc as a (potentially) cleaner alternative/option to it's current method of annotating type information which is a bit clunky :)

Made JsDoc proposal at https://github.com/jsdoc/jsdoc/issues/2098.

[azder]

@piranna I don't like the infix notation because it puts too much into a small place. I like how in Haskell it's solved by commenting before the definition (if really necessary since the compiler is good at inference).

Also, we've already discussed comments as the way, so you might want to check here https://github.com/tc39/proposal-type-annotations/issues/176 and similar connected issues (if you follow the links and mentions).

[piranna]

I don't think "it puts too much into a small place", it's similar to how https://tsdoc.org/ works for Typescript, just only the types are commented instead of being new syntax that the Javascript engine needs to parse or a transpiler needs to remove.

[azder]

Just because it is done in in JSDoc or even TS, that isn't a license to repeat the same mistakes. JSDoc was mentioned in that whole thread and if there were 2 sides that were for and against types in comments, the one thing that they agreed is that JSDoc wasn't the solution

[piranna]

just because it is done in in JSDoc or even TS, that isn't a liccense to repeat the same mistakes

What mistake do you see here?

the one thing that they agreed is that JSDoc isn't the solution

True, it's pretty verbose, that's why I find TsDoc aproach better.

[azder]

It is verbose because it is a tool for docummenting code in a language that has static type system copied almost verbatim for a language that doesn't have such a system.

The other mistakes are just copying the syntax of C++ through Java, C#, TypeScript instead of looking a bit further than just rehashing the same stuff.

Look at how cleaner Haskell type declarations are vs what Java used to have i.e. boilerplate, especially with needing to declare the exceptions thrown forcing people to just go throws RuntimeException as a way to remove it.

Source code should be for people's eyes first, then for compilers. You can optimize compilers better than how people read code. And if that's the case, you could use more white space, separating the types in their own line instead of inline wherever you try to solve the problem etc.

It's a bit more of a philosophical answer, but I'm not a professional code stylist, so I don't know the proper words to express the issues at hand.