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 information
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 o
On 03/03/2012, AntC 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 chose this order to make it
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
update
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 do
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
Andres Löh 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 to use a *-kinded (i
On Mon, Mar 5, 2012 at 06:55, Herbert Valerio Riedel 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 k
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 st
Gershom Bazerman 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 SORF -- at
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, http://www.well-typed.co
Gershom Bazerman 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 is not j
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 ph
> 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 i
14 matches
Mail list logo
