search

unisonweb / unison

A friendly programming language from the future
https://unison-lang.org
Other
5.75k stars 269 forks source link

Idea: have typechecker complain if ignoring a thunk with effects #4466

Open pchiusano opened 10 months ago

pchiusano commented 10 months ago

https://unisonlanguage.slack.com/archives/CLUNF0J5S/p1701712200962469

Motivating example was:

myParser = do
  _ = Parse.space
  ...

That should be !Parse.space but due to the _ = ... the typechecker doesn't complain and the parser doesn't actually consume any spaces.

This is sort of a general issue with any sort of polymorphic ignoring syntax or function - you the programmer have an assumption about what the type of value you're ignoring is, but if that assumption is wrong, the typechecker doesn't alert you.

Proposal is to have the typechecker complain when _ = ... syntax is used to ignore an effectful thunk (or maybe just any effectful function), since frequently this is a sign that the call is under-saturated.

The user can always do ignore Parser.space if they really want, or they can say ignored = Parser.space.

There was a concern with this approach that functions like '{IO} ('{IO} a) would be more verbose to ignore. But are there a lot of functions of this shape which people often want to ignore? Might be an okay tradeoff.

ChrisPenner commented 10 months ago

For posterity, my initial proposal was to warn if discarding the result from a RHS which doesn't perform any effects, rather than checking if the return type is a thunk, which allows us to detect statements that are completely redundant and error on them. It handles the '{IO} ('{IO} a) case.

I think this provides the best end-user experience, but it may be trickier to implement.

ceedubs commented 10 months ago

my initial proposal was to warn if discarding the result from a RHS which doesn't perform any effects

I'm not sure if by RHS you specifically mean an assignment like _ = RHS, but I just want to bring up something that I use a lot:

foo =
  ignore do {{ this is an inline comment that I use to document non-obvious code }}
  "bar"

I don't think that we can drop support for something like this unless we replace it with an alternative (and hopefully better) for inline comments. Adding the comment to foo.doc really doesn't currently work as an option, because when you edit a term its doc isn't printed to the scratch file (and even if you edit both it might not appear directly above the term).