Open mitchellwrosen opened 3 months ago
FWIW I've probably written as much Unison code as anybody and outside of recreating a bug in a transcript, I can't recall the last time that I used add
instead of update
.
Yeah we don't need a separate add
and update
, but we should
add <defn...>
gives us now). However; this may be a pain. Probably, having a "preview" command for this would reduce the pain.It brings its own complexity to the "slurp" algorithm that parses a
scratch.u
file and tries to classify its contents as adds, updates, aliases, and term-constructor conflicts.
This is not part of whether add
and update
commands are separate though, this is more about whether the user should consider them separate outcomes or not.
We currently have separate
add
andupdate
commands.update
is strictly more powerful thanadd
–add
will only add the new definitions defined in ascratch.u
file to the codebase and namespace, whereasupdate
will add those, and also the updates.Generally speaking I think it's fine to have redundant commands, or commands with some overlapping functionality, but in this particular case, maintaining
add
isn't free for us. It brings its own complexity to the "slurp" algorithm that parses ascratch.u
file and tries to classify its contents as adds, updates, aliases, and term-constructor conflicts.Especially with some sort of "delete directive" and/or "alias directive" on the horizon,
update
is feeling like the wholemeal, declarative "do the thing in thescratch.u
file" command, whereas I'm not exactly sure howadd
is intended to fit into the picture long term. For example, surely we don't want an analogousdelete2
that applies only the delete directives in the scratch file, but not the adds nor updates – and that suggests to me we don't really wantadd
either.Related to #5089