unison
unison copied to clipboard
unisonweb
(unimportant) editing an alias for a built-in adds invalid code to scratch file
Let's say that you create an alias for a builtin term:
.> alias.term ##Nat.+ plus
Now you want to load your whole namespace to a scratch file so you run .> find and then edit 1-24 (where 24 is the number for the last declaration spat out by find).
Inside your scratch file you'll now have a line like:
builtin plus : ##Nat -> ##Nat -> ##Nat
This is invalid Unison code, so your scratch file won't compile.
Generally I wouldn't expect users to run into this. I've run into it a few times when I've needed to use a built-in that hasn't yet been added to the base library, so I've created an alias for it.
I really don't know which part of this I think should change.
It seems reasonable that find includes this alias.
Maybe edit should reject trying to edit a builtin, and that would be fine when editing a single term, but it would be kind of annoying if a single built-in alias caused edit 1-24 to completely fail and forced the user to do something like edit 1-12 14-24.
The pretty-printer is giving a pretty reasonable printing of plus.
The only option that comes to mind that doesn't seem terrible is to add support for defining an alias in scratch files and special-casing builtin aliases to do something like: alias plus = ##Nat.+.
It's hard for me to imagine this ever being a priority for someone to work on, but I figured I might as well document the behavior.
Simple proposal:
What if editing a builtin term/type still adds it to your scratch file but comments it out? Something like:
-- builtin terms and types cannot be edited
-- builtin io.closeSocket.impl : io.Socket ->{IO} Either Failure ()
The "commented out" behaviour was how this used to work, but it was changed for a reason I can't remember.
I'd probably just have edit put it in a comment, but view can show it as is. Seems like a quick fix if desired.
