On 20 March 2013 06:58, Christopher Done wrote:
> From the paper Fun with Type Funs, it's said:
>
>> One compelling use of such type functions is to make type
>> coercions implicit, especially in arithmetic. Suppose we want to be able to
>> write add a b to add two numeric values a and b even if o
(But I get annoyed about having to convert between five string types
(String, Text, lazy Text, ByteString, lazy ByteString), so maybe I'm
just generally more bothered by the whole “not being able to just
write the program” than others.)
On 20 March 2013 00:22, Christopher Done wrote:
> On 20 Marc
On 20 March 2013 00:05, Johan Tibell wrote:
> I prefer the current way (which is interestingly what Go chose as well).
> With implicit casts it's easy to shoot yourself in the foot e.g. when doing
> bit-twiddling.
I don't think it's an either-or case, though, is it? I would use the
magic implicit
On Tue, Mar 19, 2013 at 3:58 PM, Christopher Done wrote:
> From the paper Fun with Type Funs, it's said:
>
> > One compelling use of such type functions is to make type
> > coercions implicit, especially in arithmetic. Suppose we want to be able
> to
> > write add a b to add two numeric values a a
On 2 July 2010 04:48, David Menendez wrote:
> Maybe you're thinking of equality superclasses. In another thread,
> this example came up:
>
> | class (DerivedOf a ~ derived) => Typecheck a derived where
>
> which doesn't work yet, but should work in 6.14.
I've asked Manuel Chakravarty about this,
On Thu, Jul 1, 2010 at 2:26 PM, Christopher Lane Hinson <
l...@downstairspeople.org> wrote:
> class (Path p, CompletePath (CompletedPath p)) => IncompletePath p where
>> type CompletedPath p :: *
>>
>
> AIUI, this isn't implemented yet. You'll have to place the constraint on
> each
> involved fun
On Thu, Jul 1, 2010 at 2:35 PM, Christopher Lane Hinson
wrote:
> On Thu, 1 Jul 2010, Christopher Lane Hinson wrote:
>
>>
>>> Something like this should work:
>>>
>>> class (Path p, CompletePath (CompletedPath p)) => IncompletePath p where
>>> type CompletedPath p :: *
>>>
>>
>> AIUI, this isn't
GADTs?
data CompletePathEv p where CompletePathEv :: CompletePath p =>
CompletePathEv p
class Path p => IncompletePath p where
type CompletedPath p :: *
completedPathEv :: CompletePathEv (CompletedPath p)
Later you can pattern-match on completedPathEv and get your
CompletePath inst
On Thu, 1 Jul 2010, Christopher Lane Hinson wrote:
Something like this should work:
class (Path p, CompletePath (CompletedPath p)) => IncompletePath p where
type CompletedPath p :: *
AIUI, this isn't implemented yet. You'll have to place the constraint on
each
involved function.
Fri
Something like this should work:
class (Path p, CompletePath (CompletedPath p)) => IncompletePath p where
type CompletedPath p :: *
AIUI, this isn't implemented yet. You'll have to place the constraint on each
involved function.
Friendly,
--Lane
_
David Menendez wrote:
Something like this should work:
class (Path p, CompletePath (CompletedPath p)) => IncompletePath p where
type CompletedPath p :: *
Oh, you can do that? (I.e., mention the CompletedPath function before
you've defined it.) Sweet...
___
On Thu, Jul 1, 2010 at 2:09 PM, Andrew Coppin
wrote:
> Consider the following:
>
> class Path p where ...
>
> class Path p => CompletePath p where ...
>
> class Path p => IncompletePath p where
> type CompletedPath p :: *
>
> Obviously, the idea is that CompletedPath Foo (where Foo is an
> In
Consider the following:
class Path p where ...
class Path p => CompletePath p where ...
class Path p => IncompletePath p where
type CompletedPath p :: *
Obviously, the idea is that CompletedPath Foo (where Foo is an
IncompletePath) should yield some type which is a CompletePath. However
Hi Ryan.
Thanks a lot, that was exactly the information I needed.
Concerning the type classes, there are methods, but I dropped them,
because they were not necessary for the problem. However, you are right.
Implementation hiding is what I need.
One suggestion. Maybe a HaskellWiki page on design
First, a comment. I don't understand why you have so many classes!
What proof invariants are they helping you enforce? Do you really a
constraint that says that something is a "Rule"? Are you going to
write functions that are polymorphic over CRule? How can you do so
when CRule has no methods?
> {-# OPTIONS_GHC -fglasgow-exts #-}
> module Test where
>import qualified Data.Set as S
Hi. I try to model the following: Hypotheses are build up from Rules,
which itself are made of the type Rule. Because I may change the
implementation later, I want to use type classes, which define the
signa
(I've moved this from haskell' to haskell-cafe, because it's more a
question about associated types than about resolving the MPTC dilemma.)
Bulat Ziganshin writes:
> Hello Manuel,
>
> MMTC> My statement remains: Why use a relational notation if you can
> MMTC> have a functional one?
>
> how ab
17 matches
Mail list logo
