As I mentioned further up in the email, I think this needs to be done at
compile time. However, I'm not sure type classes are the right mechanism, as
they don't guarantee that the polymorphism is resolved at compile time.
Perhaps type families, in some form, is the right solution.
There is
Hello *,
For simple-kinded type variables, instances of the type
instance NFData a = NFData [a]
instance NFData a = NFData (Maybe a)
instance (NFData a, NFData b) = NFData (a, b)
are common and can be defined effortless; now I wanted do something
similiar for a type with a
Gershom Bazerman gershomb at gmail.com writes:
... I want to put forward
at least one strong motivation for global field names (aka
SORF-style) rather than locally declared field names as a default.
Hi Gershom,
One of the things that's surprised me contributing to this thread
Hi.
Here's a way that seems to work for me. I haven't tested in detail.
There may be problems, or also easier ways to achieve the same. The
DataKinds extension isn't essential. I've just used it for fun.
Cheers,
Andres
--
Andres Löh, Haskell Consultant
Well-Typed LLP,
Gershom Bazerman gershomb at gmail.com writes:
Gershom, an implementation question for your proposed approach to
representation-hiding:
(It's always easy to wave away awkwardness if you don't show the full
mechanism. Please write up your proposal on the wiki to the same level of
detail as
Arie Peterson writes:
Is there a good reason that partially applied type synonyms cannot be made
instances of classes?
[...]
Partially applied type synonyms are, in a sense, the anonymous functions
at the type level, and one might argue that they deserve the same
'first-class member
On Mon, Mar 5, 2012 at 06:55, Herbert Valerio Riedel h...@gnu.org wrote:
Arie Peterson writes:
Is there a good reason that partially applied type synonyms cannot be
made
instances of classes?
http://www.haskell.org/pipermail/glasgow-haskell-users/2005-April/008340.html
Does anyone here
Andres Löh and...@well-typed.com writes:
Here's a way that seems to work for me. I haven't tested in detail.
There may be problems, or also easier ways to achieve the same. The
DataKinds extension isn't essential. I've just used it for fun.
looks interesting
If I get it right, the trick is
Hi.
If I get it right, the trick is to use a *-kinded (instead of a
*-*-kinded) argument for the class instances and have a type
function that is able to phantom-retag an already applied
type-constructor `Foo_ Unres` to a differently applied type-constructor
`Foo_ Res`.
Yes.
The only
There are actually four problems with overloaded record update, not three as
mentioned on the SORF page. This is an attempt to solve them.
The SORF update mechanism.
--
SORF suggests adding a member set to the class Has which does the actual
updating just as get
Thanks so much for stepping up and attempting a solution at our big
problem, Barney!
I would ask everyone restrict their comments on this for now solely as
to figuring out whether it makes updates work. There has been a lively
debate about ideal details on a record implementation, but until
On 03/03/2012, AntC anthony_clay...@clear.net.nz wrote:
Apart from the Quasifunctor bit, I think you'll find your proposal is a rather
cut-down version of DORF, just using different syntactic sugar.
(Oh, and with the arguments to Has in a different order, just to be
confusing.)
Not so. I
On 3/5/12 12:03 AM, Gershom Bazerman wrote:
So, suppose we have a locally declared fields solution (such as DORF).
Now, where do these fields live? Arguably, we want a module per record.
Rather, part of the point of all this is precisely that we *don't* want
one module per record. That's the
On 12-02-29 09:30 PM, Brent Yorgey wrote:
I wonder about the possibility of making a simple tool to parse the
output of cabal install -v3 and visualize/organize it in some sort of
way to make this process easier. What might such
visualization/organization look like?
The most useful
14 matches
Mail list logo
