Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

comment syntax #82

Open
lhorie opened this issue Apr 12, 2020 · 13 comments
Open

comment syntax #82

lhorie opened this issue Apr 12, 2020 · 13 comments
Labels
enhancement

Comments

@lhorie
Copy link

@lhorie lhorie commented Apr 12, 2020

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
Copy link

@sirinath sirinath commented Apr 12, 2020

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
Copy link

@Darkle Darkle commented Apr 12, 2020

Hindley-Milner comments would be cool to have too:

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

@lhorie
Copy link
Author

@lhorie lhorie commented Apr 12, 2020

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
Copy link

@sirinath sirinath commented Apr 13, 2020

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
Copy link

@raveclassic raveclassic commented Apr 13, 2020

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.

@YevhenKap
Copy link
Contributor

@YevhenKap YevhenKap commented Apr 13, 2020

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

@JSMonk
Copy link
Owner

@JSMonk JSMonk commented Apr 14, 2020

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
Copy link
Owner

@JSMonk JSMonk commented Apr 14, 2020

And thank you all for your contribution ^_^.

@ikabirov
Copy link
Contributor

@ikabirov ikabirov commented Apr 14, 2020

JSDoc support will allow using Hegel with Google Closure Compiler.

@JSMonk JSMonk added the enhancement label Apr 24, 2020
@hinell
Copy link

@hinell hinell commented May 3, 2020

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
Copy link

@serapath serapath commented May 17, 2020

@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
Copy link
Owner

@JSMonk JSMonk commented May 17, 2020

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
Copy link

@sirinath sirinath commented May 23, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement
Projects
None yet
Development

No branches or pull requests

9 participants