On Tue, Mar 19, 2013 at 3:58 PM, Christopher Done chrisd...@gmail.comwrote:
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
(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 chrisd...@gmail.com
On 20 March 2013 06:58, Christopher Done chrisd...@gmail.com 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
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,
On Thu, Jul 1, 2010 at 2:09 PM, Andrew Coppin
andrewcop...@btinternet.com 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
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...
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
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.
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
On Thu, Jul 1, 2010 at 2:35 PM, Christopher Lane Hinson
l...@downstairspeople.org 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
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 function.
On 2 July 2010 04:48, David Menendez d...@zednenem.com 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
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
{-# 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
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?
(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 about
16 matches
Mail list logo
