>> > instance CpsForm t t where
>> This can't be right, can it?
> In general no: the CPS of a function certainly doesn't fit the above
> pattern. So, if the source language has abstractions (the language in
> the original message didn't), we have to add another instance for
> CpsForm.
But any othe
Stefan Monnier wrote:
> > instance CpsForm t t where
>
> This can't be right, can it?
In general no: the CPS of a function certainly doesn't fit the above
pattern. So, if the source language has abstractions (the language in
the original message didn't), we have to add another instance for
CpsFor
> instance CpsForm t t where
This can't be right, can it?
After CPS conversion a term of type "a -> b" won't have type "a -> b"
but rather something like "a * (b -> c) -> c".
Stefan
___
Haskell mailing list
Haskell@haskell.org
http://www.haske
Louis-Julien Guillemette wrote:
> Say we are using a GADT to represent a simple language of boolean
> constants and conditionals,
>
> data Term a where
>B:: Bool -> Term Bool
>Cnd :: Term Bool -> Term t -> Term t -> Term t
>
> and we would like to perform a type-safe CPS conversion ov
I'm sorry to open an old wound. I've just had an insight for
a clarification.
On Nov 26, 2003 Ken Shan wrote:
> Consider the following code, which uses type classes with functional
> dependencies:
>
> {-# OPTIONS -fglasgow-exts #-}
> module Foo where
> class R a b | a -> b where r ::
On 2003-11-27T07:51:37-0800, Brandon Michael Moore wrote:
> I agree that the typechecker could handle this better, but I don't see why
> you should need types like this. You should be able to use
>
> rr :: (R a b) => a -> (b,b)
>
> and
>
> data RAB a = forall b. (R a b) => RAB (a,b)
>
> equall
On Wed, 26 Nov 2003, Ken Shan wrote:
> Hello,
>
> Consider the following code, which uses type classes with functional
> dependencies:
>
> {-# OPTIONS -fglasgow-exts #-}
> module Foo where
> class R a b | a -> b where r :: a -> b
>
> -- 1
> rr :: (R a b1, R a b2) => a -> (b1,
Mark P Jones writes:
> | The issue I want to raise is whether constructor classes are
> | redundant in the presence of FDs
>
> No, they are not comparable.
>
Allow me to make the following bold claim.
Assume we are given a program that uses the Haskell functor class as in
class Functor f
Martin Sulzmann <[EMAIL PROTECTED]> writes:
> Yoann Padioleau writes:
> > nevertheless i found constructor class more elegant for many problems.
> > Your solution is less elegant that the one using constructor classes.
> >
>
> Yes, the current presentation of constructor classes might be easi
Martin,
| In my previous example I employed FD's to
| improve constraints. However, there are cases where FD's seem
| to be overly restrictive.
Yes, of course! So it will be for any extension of the
type system that retains both decidability and soundness.
The particular form of "improvement"
Hi Martin,
| The issue I want to raise is whether constructor classes are
| redundant in the presence of FDs
No, they are not comparable.
Let fds = functional dependencies
ccs = constructor classes
Example of something you can do with ccs but not fds:
data Fix f = In (f (Fix f))
Examp
Yoann Padioleau writes:
> nevertheless i found constructor class more elegant for many problems.
> Your solution is less elegant that the one using constructor classes.
>
Yes, the current presentation of constructor classes might be easier
to comprehend.
> I found too that type error message
Martin Sulzmann <[EMAIL PROTECTED]> writes:
> Hi,
>
> I was wondering whether other people made similiar observations.
> Functional dependencies seem to be expressiveness enough to encode
> some of the kinding rules required for Constructor Classes.
read this page:
http://cvs.haskell.org/Hugs/
At 2002-07-23 09:06, Simon Peyton-Jones wrote:
>Dead right! Imagine there was a method in class D:
>
> class C a b => D a where
> op :: a -> b
>
>The type of 'op' is
>
> op :: D a => a -> b
>
>You can't really expect that the 'b' here is determined by 'a'!
Agreed. If you we
I'm just catching up with some old mail here.
Iavor writes:
| class C a b | a -> b
| class C a b => D a
|
| vs.
|
| class C a b | a -> b
| class C a b => D a b
|
| Hugs accepts both of those, while GHC insists on the second.
| The first example is a little shorter and one might argue that i
Mark P Jones wrote:
| | Neat. And it solves a problem I was kludging around with explicit,
| | existentially quantified dictionaries.
|
| Great! Can I look forward to hearing more about that some time?
OK, it's to do with arrows:
> class Arrow a where
> arr :: (b -> c) -> a b c
>
Hi Fermin,
| Should redundant dependencies trigger an error or a warning? I'd
| say that if I'm writing some haskell code, I wouldn't mind if a
| redundancy is flagged as an error; most likely, it'd take a short
| time to fix. However, if someone is generating haskell automatically
| (maybe with
>
> | Also, you say a dependency with zero variables on the right side is
> | syntactically correct, but later you say it will be reported as an
> | error because it says nothing. Why bother?
>
> Point taken. In fact that same database text I mentioned above
> prohibits functional dependencies
| Neat. And it solves a problem I was kludging around with explicit,
| existentially quantified dictionaries.
Great! Can I look forward to hearing more about that some time?
| On a superficial note, how about
| class C a b c | (a,b) => c where ...
| for
| class C a b c | a b -> c w
Mark P Jones wrote:
> A couple of months ago, I developed and implemented an extension to
> Hugs that has the potential to make multiple parameter type classes
> more useful. The key idea is to allow class declarations to be
> annoted with `functional dependencies'---an idea that has previously
>
Hi Heribert,
Thanks for your feedback!
| at the end of section 2 of http://www.cse.ogi.edu/~mpj/fds.html you
| might want to mention that there is a "standard" work-around whenever a
| type constructor is needed but not available: Introduce a newtype.
Yes, an in fact this idea is mentioned at t
Hi Mark,
at the end of section 2 of http://www.cse.ogi.edu/~mpj/fds.html you
might want to mention that there is a "standard" work-around whenever a
type constructor is needed but not available: Introduce a newtype.
> import Bits
> class Collects e c where
>empty :: c e
>insert :: e ->
22 matches
Mail list logo
