Open pchiusano opened 3 years ago
This is a good idea.
Is there value to having names exposed for both versions that outweighs the complexity? Or should we just switch to the new ones?
Having the .impl version just means you can implement the other in pure Unison code by referencing the foo.impl name in the definition of foo. You could deprecate / delete the .impl versions after that's done, or perhaps the tooling has a convention where it filters out .impl functions by default in various list / find commands.
It would also be a pain I think to have the builtin directly do Exception
.
I was implying not including a name for the .impl
in the namespace, but I take it back. I think I'd just put the Exception
versions in base
(instead of derived functions in builtin
; we can try to figure out how to auto-generate them though, if that would save work.
I think that for the most part this is the case now. @runarorama do you think that we are in a place where this could be closed out?
There are still some places that use Either
where they should use Exception
A lot of the
IO
functions can return failures and this is expressed usingEither
which leads to a lot of awkwardness.First, a bit of renaming of abilities, let's distinguish between
Throw
, which is just early termination with a typed value (which might get used for control flow, like early termination from a deeply nested structure), andException
, which is "something went wrong, here's aFailure
":Next, go through the various
IO
functions that currently returnEither
, like:Suggestion is rename that to
openFile.impl
or similar, then in pure Unison (inIOSource.hs
), define:And so on for all
IO
builtins.It might be possible to do this programmatically by hooking into the
builtin.merge
command (consult @aryairani).