Misha Aizatulin wrote
> I am using existential boxes like
> > data Box cxt = forall a . Sat (cxt a) => Box a
> here Sat is taken from [1]:
> > class Sat a where dict :: a
> The result is a box type which can have variable context imposed on
> its contents. What I noticed is that sometimes I
Misha Aizatulin wrote:
The question I'd like to ask is whether there is some trickery to
circumvent this problem. In the f function I'd like to be able to hint
to the compiler that I want Show to be derived from cxt which is
attached to the Box, but I see no way of doing that.
An explicit wa
Did I say TICs?
Assuming that you want to "tuple up" many constraints, I should have said TIPs
of course.
The SYB3 code distribution actually exercises some related chaining of
contexts; cf. PairCtx.
However, what's missing is the "obliviousness dimension" for irrelevant
constraints.
So you may
Misha,
This feels like you would compose dictionary types in heterogeneous lists and
then have a type-driven lookup from the dictionary list; this would be very
similar to the lookup operation for TICs in the HList lib, only that the
driving type is of kind *->* and that the traversing instance
hi,
I am wondering whether it would be possible to use the existing
haskell type system to simulate a certain feature. Namely, I am trying
to apply ideas from [1] to existential datatypes. First I will describe
the problem and later say something about the context in which it arose.
I am usin