On Thu, 23 Mar 2006, Claus Reinke wrote:
class Graph (g e v) where
src :: e - g e v - v
tgt :: e - g e v - v
we associate edge and node types with a graph type by
making them parameters, and extract them by matching.
On Thu, 23 Mar 2006, Claus Reinke wrote:
Ah, I see. You are suggesting to introduce phantom type parameters to fake
polymorphism for types which aren't really polymorphic. This might be
acceptable as a temporary workaround but I don't think it is a good
long-term solution. The ML
On Mon, 20 Mar 2006, Claus Reinke wrote:
variant A: I never understood why parameters of a class declaration
are limited to variables. the instance parameters just have
to match the class parameters, so let's assume we didn't
have that variables-only
class Graph (g e v) where
src :: e - g e v - v
tgt :: e - g e v - v
we associate edge and node types with a graph type by
making them parameters, and extract them by matching.
If I understand correctly, this requires
you're right about interactions in general. but do you think constructor
classes specifically would pose any interaction problems with FDs?
You have to be more careful with unification in a higher-kinded setting.
I am not sure how to do that with CHRs.
to quote from the ATS paper: just like
welcome to the discussion!-)
(A) It's not as if every interesting program (or even the majority of
interesting programs) use(s) MPTCs.
well, I express my opinions and experience, and you express your's:-)
let's hope that Haskell' will accomodate both of us, and all the other
possible views
On Mon, Mar 20, 2006 at 10:50:32AM -, Claus Reinke wrote:
you reply to a message that is about a month old. since then, every
single example of FD trickyness presented here has been resolved
(or have we missed some example?), and as far as I'm concerned,
the remaining problems are due to
As understand it, you've proposed changes in context reduction to
restore confluence:
yes.
What is your plan to deal with non-termination (e.g. examples 6 and 16
of the FD-CHR paper)?
I haven't read all the suggestions that Martin, you, and others have
made in that area yet (still busy
Claus Reinke:
In fact, it's quite worrying that FDs have been around for so long and
still resisted a thorough understanding.
they don't resist. but as long as progress is example-driven and scary
stories about FDs supposedly being tricky and inherently non-under-
standable are more
Ross Paterson:
On Sun, Mar 19, 2006 at 11:25:44AM -0500, Manuel M T Chakravarty wrote:
My statement remains: Why use a relational notation if you can have a
functional one?
I agree that functions on static data are more attractive than logic
programming at the type level. But with
On 2006-03-20, Manuel M T Chakravarty [EMAIL PROTECTED] wrote:
IMHO if we consider deprecating a feature in Haskell'' again,
we should not include it in Haskell', but leave it as an optional extra
that some systems may experimentally implement and some may not.
Possibly true, but it still
For example, AFAIK the CHR formalisation doesn't consider higher
kinds (ie, no constructor classes).
you're right about interactions in general. but do you think constructor
classes specifically would pose any interaction problems with FDs?
I don't care whether I do my case a favour. I am
Hello Lennart,
Sunday, March 19, 2006, 4:05:03 AM, you wrote:
LA I have to agree with Manuel. I write a lot of Haskell code.
LA People even pay me to do it. I usually stay with Haskell-98,
when i wrote application code, i also don't used extensions very much,
i even don't used Haskell-98 very
On 3/18/06, Manuel M T Chakravarty [EMAIL PROTECTED] wrote:
Here addition and multiplication on Peano numerals using MPTCs and FDs:
data Z
data S a
class Add a b c | a b - c
instance Add Z b b
instance Add a b c = Add (S a) b (S c)
class
Bulat Ziganshin:
Hello Lennart,
Sunday, March 19, 2006, 4:05:03 AM, you wrote:
LA I have to agree with Manuel. I write a lot of Haskell code.
LA People even pay me to do it. I usually stay with Haskell-98,
when i wrote application code, i also don't used extensions very much,
i even
Hello Manuel,
Sunday, March 19, 2006, 7:25:44 PM, you wrote:
i had a class which defines default reference type for monads:
class Ref m r | m-r where
to be exact,
class Ref m r | m-r, r-m where
newRef :: a - m (r a)
readRef :: r a - m a
writeRef :: r a - a - m ()
or even worser:
On Sun, Mar 19, 2006 at 11:25:44AM -0500, Manuel M T Chakravarty wrote:
My statement remains: Why use a relational notation if you can have a
functional one?
I agree that functions on static data are more attractive than logic
programming at the type level. But with associated type synonyms,
Manuel M T Chakravarty writes:
The big question is: do we really want to do logic programming over
types? I'd say, no!
With ATs you're still doing logic programming if you like or not.
As Ross Paterson writes:
I agree that functions on static data are more attractive than logic
Claus Reinke:
however, the underlying problem is not limited to MPTCs, and FDs
are not the only attempt to tackle the problem. so I agree with Isaac:
getting a handle on this issue is imperative for Haskell', because it will
be the only way forward when trying to standardize at least those
Isaac Jones:
I'm forwarding an email that Martin Sulzmann asked me to post on his
behalf.
From: Martin Sulzmann [EMAIL PROTECTED]
Subject: MPTC/FD dilemma
- ATs (associated types) will pose the same challenges.
That is,
I have to agree with Manuel. I write a lot of Haskell code.
People even pay me to do it. I usually stay with Haskell-98,
and I don't think it's a great hardship. Sure, there's fancy
stuff I can't do then, but I'd much rather have a well understood
somewhat less powerful language.
I think the
John Meacham wrote:
On Thu, Mar 02, 2006 at 03:53:45AM -, Claus Reinke wrote:
the problem is that we have somehow conjured up an infinite
type for Mul to recurse on without end! Normally, such infinite
types are ruled out by occurs-checks (unless you are working
with Prolog III;-), so
@haskell.org
| Subject: relaxed instance rules spec (was: the MPTC Dilemma (please
solve))
|
| The specification is here:
|
http://www.haskell.org/ghc/dist/current/docs/users_guide/type-extension
s.html#instance-decls
|
| two questions/suggestions about this:
|
| 1. there are other termination
On Tue, Feb 28, 2006 at 07:12:28PM -, Claus Reinke wrote:
Anyway, there is already a ticket for overlapping instances, I think --
why don't you just add to that.
that might work. apart from the fact that I really, really hate the
braindead wiki markup processor, especially when editing
On Thu, Mar 02, 2006 at 03:53:45AM -, Claus Reinke wrote:
- Mul recurses down a type in its second parameter
- types in Haskell are finite
- there is a non-terminating Mul inference
the problem is that we have somehow conjured up an infinite
type for Mul to recurse on without end!
: the MPTC Dilemma (please solve)
|
| | Is the behaviour of GHC with -fallow-undecidable-instances (and
| | -fcontext-stack) well-understood and specifiable?
| I would not say that it's well-specified, no.
|
| to start improving that situation, could we please have a task ticket
| for document
continuing the list of odd cases in type class handling, here is a
small example where overlap resolution is not taken into account
when looking at FDs.
context: both hugs and ghc resolve instance overlaps in favour
of the most specific declaration.
so the following works in both ghc
] On Behalf Of
| Ashley Yakeley
| Sent: 21 February 2006 20:13
| To: haskell-prime@haskell.org
| Subject: Re: the MPTC Dilemma (please solve)
|
| Simon Peyton-Jones wrote:
|
| Of course -fallow-undecidable-instances still lifts all
restrictions,
| and then all bets are off.
|
| Is the behaviour
When I said type class acrobats I didn't mean to make fun
of people like you who use type classes in a very skillfull way.
Though, I tried (successfully :) ) to be provocactive.
I agree with you there's a real need for unrestricted type class
programming. After all, the Hindley/Milner subset of
PROTECTED] On Behalf Of
| isaac jones
| Sent: 11 February 2006 01:29
| To: haskell-prime@haskell.org
| Subject: the MPTC Dilemma (please solve)
|
| I've created a wiki page and a ticket to record solutions to what I'm
| calling the Multi Parameter Type Class Dilemma. It's summarized
| thusly
I'm forwarding an email that Martin Sulzmann asked me to post on his
behalf.
thanks. well, that is one view of things. but it is certainly not the only one.
first, about those acrobatics: my type-class-level programs tend to
start out as straightforward logic programs over types - no
On Sat, Feb 18, 2006 at 12:26:36AM +, Ross Paterson wrote:
Martin Sulzmann [EMAIL PROTECTED] writes:
Result2:
Assuming we can guarantee termination, then type inference
is complete if we can satisfy
- the Bound Variable Condition,
- the Weak Coverage Condition,
- the
Martin Sulzmann [EMAIL PROTECTED] writes:
- There's a class of MPTC/FD programs which enjoy sound, complete
and decidable type inference. See Result 1 below. I believe that
hugs and ghc faithfully implement this class.
Unfortunately, for advanced type class acrobats this class of
33 matches
Mail list logo
