Just Hindley-Milner type inference is exponential, making the type
system more complex isn't going to make things better.
2009/2/26 Ben Franksen ben.frank...@online.de:
Hi
the attached module is a much reduced version of some type-level assurance
stuff (inspired by the Lightweight Monadic
Here's the reference
http://portal.acm.org/citation.cfm?id=96748
Deciding ML typability is complete for deterministic exponential
time -- Harry G. Mairson.
Ben.
On 27/02/2009, at 10:12 AM, Ben Franksen wrote:
Hi
the attached module is a much reduced version of some type-level
Try again without missing out the list...
Peter Padawitz wrote:
Jules Bean wrote:
Incidentally, I question why the compFoo are methods. Why not just
make them polymorphic functions? They don't look like you expect
instances to change them. The code continues to compile if I make them
Jules Bean wrote:
Try again without missing out the list...
Peter Padawitz wrote:
Jules Bean wrote:
Incidentally, I question why the compFoo are methods. Why not
just make them polymorphic functions? They don't look like you expect
instances to change them. The code continues to compile if
Peter Padawitz wrote:
What is so bad about making compFoo part of the class? It reduces the
code (constraints can be avoided) and reflects the close connection
between a signature Sig (implemented by the class) and the evaluation
(compFoo) of Sig-terms in Sig-algebras.
making it part of the
Peter Padawitz wrote:
Jules Bean wrote:
Peter Padawitz wrote:
What is so bad about making compFoo part of the class? It reduces the
code (constraints can be avoided) and reflects the close connection
between a signature Sig (implemented by the class) and the
evaluation (compFoo) of
Jules Bean wrote:
Peter Padawitz wrote:
Jules Bean wrote:
Peter Padawitz wrote:
What is so bad about making compFoo part of the class? It reduces
the code (constraints can be avoided) and reflects the close
connection between a signature Sig (implemented by the class) and
the
Peter Padawitz wrote:
Jules Bean wrote:
I don't see why!
In the class
class Foo a where
f :: a - Int
g :: b - Integer
g = fromIntegral . f
The equations within the class are defaults, not equations.
I must admit that I didn't know this... Nevertheless, won't you agree that
Peter Padawitz wrote:
Functional dependencies don't work in my case. Actually, I don't see why
they should.
Ah well, it's cruel to say that without explaining to us why!
I'm not sure why a complete cyclic dep a - b - c - d - a isn't what
you want.
What seems to be needed here is a type
Functional dependencies don't work in my case. Actually, I don't see why
they should.
What seems to be needed here is a type class construct with a kind of
record parameter so that instance conflicts cannot occur.
Jules Bean wrote:
Ben Franksen wrote:
Ryan Ingram wrote:
On 12/5/07, Ben
Peter Padawitz wrote:
Jules Bean wrote:
Peter Padawitz wrote:
Functional dependencies don't work in my case. Actually, I don't see
why they should.
Ah well, it's cruel to say that without explaining to us why!
Cause I don't see why the instantiation conflicts pointed out by others
On Dec 7, 2007 6:57 PM, Peter Padawitz [EMAIL PROTECTED] wrote:
Jules Bean wrote:
Peter Padawitz wrote:
Cause I don't see why the instantiation conflicts pointed out by
others would vanish then.
They would.
If it's really true that there is only one possible choice of b,c,d
for
Peter Padawitz wrote:
So the fundep would solve the problem.
But, actually, it doesn't :-(
But actually, it does!
Ben Franksen's answer from yesterday compiles fine for me if I add the
missing fundep, block - command.
Your original code compiles without error, given the fundep. Exact
On Dec 7, 2007 5:57 PM, Peter Padawitz [EMAIL PROTECTED] wrote:
type Block = [Command]
data Command = Skip | Assign String IntE | Cond BoolE Block Block | Loop
BoolE Block
data IntE= IntE Int | Var String | Sub IntE IntE | Sum [IntE] | Prod
[IntE]
data BoolE = BoolE Bool | Greater
Jules Bean wrote:
Peter Padawitz wrote:
Jules Bean wrote:
Peter Padawitz wrote:
Functional dependencies don't work in my case. Actually, I don't
see why they should.
Ah well, it's cruel to say that without explaining to us why!
Cause I don't see why the instantiation conflicts
Jules Bean wrote:
Peter Padawitz wrote:
Functional dependencies don't work in my case. Actually, I don't see
why they should.
Ah well, it's cruel to say that without explaining to us why!
Cause I don't see why the instantiation conflicts pointed out by others
would vanish then.
I'm
Ryan Ingram wrote:
On 12/5/07, Ben Franksen [EMAIL PROTECTED] wrote:
You would have to use functional dependencies or associated types to
eliminate this error. Alternatively, you can add a dummy argument of type
block and pass undefined :: BlockType in to help choose the instance
Ben Franksen wrote:
Ryan Ingram wrote:
On 12/5/07, Ben Franksen [EMAIL PROTECTED] wrote:
You would have to use functional dependencies or associated types to
eliminate this error. Alternatively, you can add a dummy argument of type
block and pass undefined :: BlockType in to help choose the
Brent Yorgey wrote:
Well, first of all, the definition of compCommand should use calls to
compBlock, not recursive calls to compCommand. But that's not the main
source of your problems.
What exactly are you trying to accomplish? And why do you need a type
class?
Whatever the code is
On Dec 5, 2007 10:38 PM, Ben Franksen [EMAIL PROTECTED] wrote:
data Command = Skip
class Java block command where
block_ :: [command] - block
compBlock :: [Command] - block
--compBlock = block_ . map compCommand
compCommand :: Command - command
My guess is that nothing's
On 12/5/07, Ben Franksen [EMAIL PROTECTED] wrote:
data Command = Skip
class Java block command where
block_ :: [command] - block
compBlock :: [Command] - block
--compBlock = block_ . map compCommand
compCommand :: Command - command
This compiles ok. But when I ask ghci for the type of
If only for those watching from home, here are some references.
jeff p [EMAIL PROTECTED] wrote in article [EMAIL PROTECTED] in
gmane.comp.lang.haskell.general:
Better yet,
how about LambdaProlog (
http://www.lix.polytechnique.fr/Labo/Dale.Miller/lProlog),
which generalizes from Horn
Conal Elliott wrote:
I keep running into situations in which I want more powerful search in
selecting type class instances. One example I raised in June, in which all
of the following instances are useful.
instance (Functor g, Functor f) = Functor (O g f) where
fmap h (O gf) = O (fmap
Am Mittwoch, 1. August 2007 14:41 schrieb apfelmus:
[…]
The problem with the Functor/Cofunctor instances is that they are
ambiguous as soon as a type constructor X is made an instance of both
Functor and Cofunctor . Of course, such an X cannot exist in a
mathematically useful way
On 8/1/07, apfelmus [EMAIL PROTECTED] wrote:
There are some fundamental problems/design choices for type classes
in conjunction with separate compilation/modularity that need to be
researched before trying anything like that. In particular, any
ad-hoc Prolog, CHR or
On 7/31/07, jeff p [EMAIL PROTECTED] wrote:
Hello,
My understanding is that this sort of instance collection doesn't
work together because instance selection is based only on the
matching the head of an instance declaration (part after the
=). I'm wondering why not use the
Conal Elliott [EMAIL PROTECTED] wrote in article [EMAIL PROTECTED] in
gmane.comp.lang.haskell.general:
I keep running into situations in which I want more powerful search in
selecting type class instances.
I agree that it's quite useful for instance search to backtrack, if not
desirable in all
Here are some other instances that could work with backward chaining:
\begin{code}
instance Monad m = Applicative m where
pure = return
(*) = ap
instance (Applicative f, Monoid a) = Monoid (f a) where
mempty = pure mempty
mappend = liftA2 mappend
instance (Applicative f, Num a) =
Thanks for these pointers, Ken. And belated thanks to Oleg for his reply in
June. Impressive tricks!
Perhaps I'm not the only person who'd prefer a more straightforward
formulation of backtracking search? Cheers,
- Conal
On 7/31/07, Chung-chieh Shan [EMAIL PROTECTED] wrote:
Conal Elliott
Hello,
My understanding is that this sort of instance collection doesn't work
together because instance selection is based only on the matching the head
of an instance declaration (part after the =). I'm wondering why not use
the preconditions as well, via a Prolog-like, backward-chaining
[EMAIL PROTECTED] wrote:
Incidentally, Hugs reports the overlapping errors eagerly. It would
still complain about the changed code, because the error is with
instances rather with their use.
Thankyou for your patience. I think I'm getting what's going on now.
The flags that allow undecidable
Adrian Hey wrote:
-- Instances of GT are instances of Eq --
instance (GT map key, Eq a) = Eq (map a) where
map1 == map2 = assocsAscending map1 == assocsAscending map2
...
Overlapping instances for Eq [(key, a)]
arising from use of `==' at Test.hs:10:16-59
Matching
[EMAIL PROTECTED] wrote:
Adrian Hey wrote:
-- Instances of GT are instances of Eq --
instance (GT map key, Eq a) = Eq (map a) where
map1 == map2 = assocsAscending map1 == assocsAscending map2
...
Overlapping instances for Eq [(key, a)]
arising from use of `==' at Test.hs:10:16-59
Adrian Hey wrote:
[EMAIL PROTECTED] wrote:
Adrian Hey wrote:
-- Instances of GT are instances of Eq --
instance (GT map key, Eq a) = Eq (map a) where
map1 == map2 = assocsAscending map1 == assocsAscending map2
...
Overlapping instances for Eq [(key, a)]
arising from use of `=='
Also, I suspect I'm still missing something important here, for
example I don't understand why, if it overlaps for [], it doesn't
overlap with other instances (like Maybe for example). Or am I
just not getting the error for Maybe because ghc stops after
the first error?
One may think of
Sorry, forgor the precise URLs
http://pobox.com/~oleg/ftp/Haskell/poly2.hs
http://pobox.com/~oleg/ftp/Haskell/poly2.txt
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Paul Govereau wrote:
BTW, The above program is a translation of an idiomatic use of
functors in ML (pardon my syntax):
module A : sig type t = ... end
module B : funsig(X:SHOW where t = A.t) sig bar : A.t - string end
module C : SHOW where t = A.t
open A
open B(C)
ML modules
Ben Yu wrote:
class Rule r u u' m where
apply :: r - u - m u'
data And = And
data Bin a b o = Bin a b o
instance (Monad m, Rule r1 u u' m, Rule r2 u' u'' m) =
Rule (Bin r1 r2 And) u u'' m where
apply (Bin r1 r2 _) u = apply r1 u = apply r2
Ghc complains about Could not
On Mon, 10 Nov 2003, Simon Peyton-Jones wrote:
| Also, I tried to update and rebuild, but the makefiles seem to have
the
| dependencies wrong or something. I compiles THSyntax.hs by hand, then
ran
| into some trouble with files that needed some modules from GHCI trying
| (and dying) to
A bug thank you; now fixed.
Please send bug reports about GHC to [EMAIL PROTECTED],
not to the Haskell mailing list.
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Brandon
| Michael Moore
| Sent: 08 November 2003 13:20
| To: [EMAIL PROTECTED]
There's another possible fix which makes use of scoped variables.
instance (RT r1 t1, RT r2 t2, TPair t t1 t2) = RT (RPair r1 r2) t where
rtId (RPair r1 r2) t = RT (RPair ++ rtId r1 t1 ++ ++ rtId r2 t2 ++)
where (t1::t1,t2::t2) = prj t
^^
scoped variables
Dean Herington wrote:
Can someone explain why the following doesn't work?
{-# OPTIONS -fglasgow-exts #-}
class R r where
rId :: r - String
class (R r) = RT r t where
rtId :: r - t - String
data RPair r1 r2 = RPair r1 r2
instance (R r1, R r2) = R (RPair r1 r2) where
rId (RPair
| I'm wondering if the general method of avoiding non-termination can be
| made to work in these more complex cases.
|
| Incidentally, the constraint solver stack overflow problem can be
| turned to our advantage. The typechecker's exhausting the stack should
| be considered a failure to match
| b) at the moment dictionaries have the property that you can always
| evaluate them using call-by-value; if they could be recursively
| defined (as you suggest) that would no longer be the case
|
| Mind you, GHC doesn't currently take advantage of (b), so maybe it
| should be
On 28 Aug 2003, Carl Witty wrote:
On Thu, 2003-08-28 at 13:10, Brandon Michael Moore wrote:
Unfortunately I don't have a useful syntatic condition on instance
declarations that insures termination of typechecking. If types are
restriced to products, sums, and explicit recursion, then
On Thu, 2003-08-28 at 13:10, Brandon Michael Moore wrote:
Unfortunately I don't have a useful syntatic condition on instance
declarations that insures termination of typechecking. If types are
restriced to products, sums, and explicit recursion, then termination is
ensured if we restrict the
On Fri, 22 Aug 2003, Simon Peyton-Jones wrote:
Brandon writes
| An application of Mu should be showable if the functor maps showable
types
| to showable types, so the most natural way to define the instance
seemed
| to be
|
| instance (Show a = Show (f a)) = Show (Mu f) where
| show
Brandon writes
| An application of Mu should be showable if the functor maps showable
types
| to showable types, so the most natural way to define the instance
seemed
| to be
|
| instance (Show a = Show (f a)) = Show (Mu f) where
| show (In x) = show x
|
| Of course that constraint didn't
I defined type recursion and naturals as
newtype Mu f = In {unIn :: f (Mu f)}
data N f = S f | Z
type Nat = Mu N
An application of Mu should be showable if the functor maps showable types
to showable types, so the most natural way to define the instance seemed
to be
instance (Show a =
On Sun, 17 Aug 2003 [EMAIL PROTECTED] wrote:
I defined type recursion and naturals as
newtype Mu f = In {unIn :: f (Mu f)}
data N f = S f | Z
type Nat = Mu N
An application of Mu should be showable if the functor maps showable types
to showable types, so the most natural way to
At 13:15 2002-01-22 -0500, Hongwei Xi wrote:
...
In Haskell, I guess that the one implemented later is always chosen.
Why can't I have two different implementations for an interface?
Actually, I can't think of situations where I would desire this.
Could you please give an example?
Another
You can also export the type without exporting the constructors. That
way importers can use the type in type signatures and instance
declarations while still not being able to use anything but the
exported interface.
E.g. instead of
Module Set
( emptySet
, makeSet
On Sat, 19 Jan 2002, [EUC-KR] ¾È±â¿µ wrote:
I prefer Haskell style type classes because
using them one can overload functions.
e.g.
\begin{code}
class Container a where
celem :: Eq b = b - a b - Bool
cmap :: (Eq b, Eq c) = (b-c) - a b - a c
data MyList a = MyList [a] deriving Show
Hmm ... How do you solve this in Haskell ?
Original Message
Subject: Re: type class VS struct/functor
Date: Sat, 19 Jan 2002 01:34:32 GMT
From: [EMAIL PROTECTED] (Neelakantan Krishnaswami)
Reply-To: [EMAIL PROTECTED]
Organization: ATT Broadband
Newsgroups: comp.lang.functional
On Sat, 17 Feb 2001, Ken Shan wrote:
On 2001-02-16T09:52:41+0100, Lars Lundgren wrote:
This is ad hoc overloading, and IMHO bad style, at least in haskell. As I
understand it, haskell type classes were never intended to support this.
Well, whether this is ad hoc overloading depends on
On 2001-02-16T07:56:42+, Marcin 'Qrczak' Kowalczyk wrote:
test2 = apply [int 3] (apply [(+)::Int-Int-Int] [int 5])
The monomorphism restriction bites again. A variable binding without
a type signature is monomorphic...
But, but, but... The type *is* monomorphic, in the sense that it
On Thu, Feb 15, 2001 at 02:37:09PM -0500, Ken Shan wrote:
test2 = apply [int 3] (apply [(+)::Int-Int-Int] [int 5])
What's strange is that when I tried this just now, the identical line at
the interpreter prompt returned the correct answer [8]. This is with
Hugs from February 2000; I'm
On 2001-02-15T21:38:54-0500, Dylan Thurston wrote:
On Thu, Feb 15, 2001 at 02:37:09PM -0500, Ken Shan wrote:
test2 = apply [int 3] (apply [(+)::Int-Int-Int] [int 5])
What's strange is that when I tried this just now, the identical line at
the interpreter prompt returned the correct
Thu, 15 Feb 2001 21:08:13 -0500, Dylan Thurston [EMAIL PROTECTED] pisze:
On Thu, Feb 15, 2001 at 02:37:09PM -0500, Ken Shan wrote:
test2 = apply [int 3] (apply [(+)::Int-Int-Int] [int 5])
What's strange is that when I tried this just now, the identical line at
the interpreter prompt
Hi Mark,
Thanks for the references you provided!
Mark P Jones wrote:
My instinct (which perhaps somebody will prove incorrect) is that this will
not help. Suppose, for example, that you needed to unify ([a],[b]) with f c
as part of the type inference process. How would you solve this
Hi Zhanyong,
| In Haskell, instances of a type class can only be well-formed type
| constructors ...
| Note there is no type constructor abstraction.
|
| In practice, I found this rule too restrictive.
There are good reasons for the restrictions that were alluded to in
my constructor classes
Simon Peyton-Jones [EMAIL PROTECTED] writes:
| How about extending TC with a branch for abstraction: | | TC ::= ...
| | /\a. TC -- abstraction | | This is too powerful and will get out
of control -- we surely
| don't want to give TC the full power of lambda-calculus. So let's
impose
a |
| How about extending TC with a branch for abstraction:
|
| TC ::= ...
| | /\a. TC -- abstraction
|
| This is too powerful and will get out of control -- we surely
| don't want to give TC the full power of lambda-calculus. So let's impose
a
| restriction: in /\a.TC, a must occur free in
Simon Peyton-Jones [EMAIL PROTECTED] writes:
| How about extending TC with a branch for abstraction:
|
| TC ::= ...
| | /\a. TC -- abstraction
|
| This is too powerful and will get out of control -- we surely
| don't want to give TC the full power of lambda-calculus. So let's
64 matches
Mail list logo
