On Tue, 1 Sep 2009, Jason Dagit wrote:
On Mon, Aug 31, 2009 at 2:32 PM, Ganesh Sittampalam<[email protected]> wrote:
Yes, I now see what you mean, but I'm not convinced that Witnessed makes the
situation any worse than it already is.
It would be nice to reach consensus on these changes. Is there anyone
else who would like to speak up about them?
OK, here is hopefully an accurate summary of the situation as I see it
following some discussions I had with Jason by private email and also on
IRC.
There are two significant issues with witnesses in general, which
in some ways my patch makes worse, or at least continues down the same
wrong line ;-)
(1) is that they allow you to implement a full unsafeCoerce. In fact, this
isn't a real problem yet, because if you did actually write and use a
proper unsafeCoerce, then in the *non* witnesses build (i.e. how we build
the real darcs binary), it would fail to compile. It's also quite unlikely
that you'd do it by accident.
Nevertheless, there are a couple of possible ways to deal with that, and
they both revolve around restricting what the witness types can possibly
be instantiated to. Solution (a) involves introducing an uninhabited type
class that they are constrained to. Jason has already mentioned that this
was considered rather heavyweight, given the need to introduce class
constraints on lots of functions. Solution (b), which I sent a patch for
last night, makes the kind of the witnesses be a complicated kind which I
arbitrarily chose which it's extremely unlikely you'd actually have a real
datatype for.
I'm not particularly bothered about which solution we use, and I don't
really mind deferring the decision indefinitely either; my patch would be
easy to update for future code changes. I could in fact live with not
having any solution even after we switch to witnesses completely.
Problem (2) is that the whole type witnesses idea necessarily has holes in
it, because witnesses are supposed to be proxies for specific repository
states, but at some point you need to make them up out of thin air; and
this is possible anywhere that the constructor for the underlying datatype
is visible. This problem is just that there are holes in the extra
guarantees provided by the witnesses; i.e. things are no worse than they
would be in darcs without witnesses.
My patch makes (2) worse by introducing a general Witnessed constructor
which is freely accessible by other code, and I will therefore amend it to
hide things behind abstraction boundaries better. However this is a
problem with other code too, most notable the Prim patch type whose
constructors are exported quite widely, and we should think more about
what we can do to improve the situation. The annoying thing is that it is
not possible to export a constructor just for pattern matching without
making it also available for constructing data.
Cheers,
Ganesh
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
