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

Add signatures to all stub files #226

Closed
MatthijsBlom opened this issue Jan 12, 2022 · 2 comments · Fixed by #227
Closed

Add signatures to all stub files #226

MatthijsBlom opened this issue Jan 12, 2022 · 2 comments · Fixed by #227

Comments

@MatthijsBlom
Copy link
Contributor

I notice it is a recurring source of annoyance to me that I have to figure out the signatures myself. Not seeing any real benefit to omitting them, I propose to add them to all stub files.

I'm prepared to do this myself; I'm opening this issue in the hope of hearing your thoughts.

@emiel
Copy link
Contributor

emiel commented Jan 12, 2022

Thanks for reaching out @MatthijsBlom. I think this is reasonable and I see other languages do this as well:

Feel free to start on a pull request.

I suppose it would be nice that the stub builds and raises an error indicating the function needs to be implemented. Something along the lines of: https://github.com/exercism/haskell/blob/main/exercises/practice/bob/src/Bob.hs

@MatthijsBlom
Copy link
Contributor Author

Great. I'll get started on a PR sometime in the near future.

I suppose it would be nice that the stub builds and raises an error indicating the function needs to be implemented.

Yes. I see four options:

  • Use ?todo, which raises a compile error, which is 👍, but also prevents a successful build, which is 😢.
  • Use crashWith, which requires Partial 👎 and thereby breaks the build 😢.
  • Use Undefined.undefined, which allows for build 👍 but results in an inscrutable runtime error 👎.
  • Use unsafeThrow, which allows for build 👍 and gives a slightly better runtime error 🤷.

In my experience a successful build is important to get the language server going, so I guess we should go with unsafeThrow and accept its short-lived import and normalization of unsafe.

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

Successfully merging a pull request may close this issue.

2 participants