comment syntax

[lhorie]

Hey, cool project. Was wondering if you're planning on supporting comment syntax. I use that w/ flow.js to avoid a build step. Would be great if hegel had something similar

[sirinath]

Alongside the normal flow syntax following also might be considered, where the type specification is completely separated, then comments in the middle of code.

/*:: function method(value: MyAlias): boolean */
function method(value) {
  return value.bar;
}

Maybe we do not need the function here as this information is found elsewhere and also can be inferred:

/*:: method(value: MyAlias): boolean */
function method(value) {
  return value.bar;
}

[Darkle]

Hindley-Milner comments would be cool to have too:

//  capitalize :: String -> String
const capitalize = function(s) {
  return toUpperCase(head(s)) + toLowerCase(tail(s));
}

[lhorie]

With flow.js, I tend to use this pattern:

/*::
type Upper = string => string
*/
const upper /*: Upper */ = string => string.toUpperCase();

It's about as close as I can get to haskell-style type annotations in a typed superset of js, but not quite there... Flow's syntax also has some weird quirks I don't like (like the ability to arbitrarily change the effective AST, e.g. const a = {b: 1}/*::['lol']*/). Something like @dankle's idea would be ideal IMHO.

[sirinath]

I believe we have to keep one set of syntax closer to JS syntax as much as possible with support for Hindley-Milner style also.

[raveclassic]

Ideally there should be a single way to write type annotations - something as close as possible to existing widespread solutions like typescript/flow. Otherwise it will end in a terrible conflicting buggy mess.

[Kapelianovych]

Why do not use JSDoc? This is widely spread and TypeScript supports it.

[JSMonk]

Hmm. We need to think about the way to declare the type in a comment. And the cost of the support of multiple comment syntax is too high. Need to think about it :)

[JSMonk]

And thank you all for your contribution ^_^.

[ikabirov]

JSDoc support will allow using Hegel with Google Closure Compiler.

[hinell]

I think it would be nice to couple Hegel with:

• JSDoc
• TSDoc (checkout source code for parser/tags) - I think this could be purely optional and supplied with plugin.

[serapath]

@JSMonk I personally thinkg - in order for people to really use it - which i would love to - the comment version of it should be really conscise and I think @flow does a much better job than @JSdoc which is just old. If people want tradition, they will anyway continue to use JSDoc and TypeScript, but somebody who is forward thinking and want a lean and unintrusive way to add this, they want the best possible developer experience that is straight to the point, so the in-line way @flow uses or the above mentioned hindley-milner comments and @sirinath comments :-)

Otherwise, great job :-) I really like hegel.js so far and will use it as soon as it allows a comment style version of it :-)

[JSMonk]

Thank you a lot. We will try to choose a better decision for the community. And thank you for your opinion. I have the same one :)

[sirinath]

My opinion now is to stick to Flow, JSDoc, TSDoc, ESDoc, etc format without any extensions, But support all, but one style would be consistently used within a file or project. This support can be through a set of language plugins which provides the type information for further processing. This way new formats can be added and if one is uninterested in any format then they can be removed for the whole project of selected files. Each dependency will use the relevant plugin within itself without forcing it to the end-user of the library or beyond library boundaries or in some cases file boundaries.