On Mon, Jun 8, 2009 at 9:57 AM, Petr Rockai <[email protected]> wrote:
> Jason Dagit <[email protected]> writes: > > > My recommendation is to make that field hold a Maybe instead of the raw > > value. I can see myself, or someone else, not understanding this > invariant > > and 'accidentally' using that slot when it is undefined. If you instead > use > > Maybe then it is much easier to see how to use this safely. Your > description > > above makes me quite concerned about the robustness of the code. > > It also makes it harder to read other code -- it becomes either unsafe > (using > fromJust) or littered with useless conditionals. Moreover, there are > zillions > of things that are implicit in darcs, often much more involved and less > documented (think just about exceptions versus Slurpy, leading to a bug > that > has been very hard to track down). I think that adding documentation to the > few > relevant places is adequate. Plus flipping undefined to error with unique > message will make any bugs involving this "unsafeness" trivial to track > down. Petr, yes the number of implicit invariants in darcs is part of why it can be hard to hack on darcs. I'm advocating fewer of these, but the use of undefined/somevalue instead Nothing/Just adds one more implicit thing to keep track of. We also have plenty of elegant ways to deal with functions that return Maybe. On the other hand, combine this preference for undefined/error with the push to release this code with minimal internal testing makes me quite afraid of the next release. I don't mean to sound like a jerk, but what your suggesting is a huge turn off for me as a darcs user. Also, as Eric points out, the problem doesn't have to be about Maybe. There are other ways to deal with this that do not involve Maybe. Jason
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
