cashew-s
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [CASHeW-s] [Fwd: RE: Restricted Types and Infinite Loops]


From: Andrew John Hughes
Subject: Re: [CASHeW-s] [Fwd: RE: Restricted Types and Infinite Loops]
Date: Fri, 11 Feb 2005 22:58:11 +0000

On Fri, 2005-02-11 at 12:00 +0000, Simon D. Foster wrote:
> The answer from the man himself ;). Looks like I hit a true gold bug.
> 
> -Si.
> email message attachment, "Forwarded message - RE: Restricted Types
> and Infinite Loops"
> On Fri, 2005-02-11 at 12:00 +0000, Simon D. Foster wrote:
> > Simon
> > 
> > You've found an interesting case. 
> > 
> > First, you are skating on thin ice here.  GHC's ability to build
> > recursive dictionaries is quite experimental, and you are relying on it
> > completely.  
> > 
> > But you're right: it "should" work.  I can see why it isn't but I have
> > not got it clear enough in my head to know the best way to fix it.
> > Still less do I have a formal story about what should type-check
> > (without loops) and what should not.
> > 
> > So this is going to continue to fail in 6.4, but it's on my list to look
> > at.
> > 
> > Simon
> > 
> > 
> > 
> > | -----Original Message-----
> > | From: address@hidden
> > [mailto:glasgow-haskell-users-
> > | address@hidden On Behalf Of Simon David Foster
> > | Sent: 27 January 2005 14:11
> > | To: GHC Users
> > | Subject: Restricted Types and Infinite Loops
> > | 
> > | Hi,
> > | 
> > | (I've attached the full code for this problem)
> > | 
> > | First I'll explain the problem description, I have two class ClassA
> > and
> > | ClassB, the former has two parameters and the latter has one. The
> > second
> > | parameter of ClassA is constrained by ClassB.
> > | 
> > | class ClassB a where
> > | class ClassB b => ClassA a b where
> > | 
> > | Because I wish to effectively pass the context of ClassA around, I
> > need
> > | to create a pair of dictionary types (as in Restricted Data Types in
> > | Haskell, Hughes 99), one to represent ClassA (DictClassA) and one to
> > | represent ClassB (DictClassB). DictClassA also contains a term of type
> > | DictClassB since ClassA is a subclass of ClassB. I should then be able
> > | to call all the functions of ClassB via the appropriate term of
> > | DictClassA, like so (assuming we want to use func2);
> > | 
> > | *Test> func2D (classBD (dict::DictClassA Int String)) "hello"
> > | "bye"
> > | 
> > | So far so good, but now suppose I want Class A to have the further
> > | constraint
> > | 
> > | class (Data (DictClassA a) b, ClassB b) => ClassA a b where
> > | 
> > | (so as to make ClassA a subclass of Data)
> > | 
> > | If we now try and do
> > | 
> > | *Test> func2D (classBD (dict::DictClassA Int String)) "hello"
> > | 
> > | We go into an infinite loop. Why? The expression still type-checks ok
> > | and I can't see what it is trying to do. All the functions of ClassA
> > can
> > | be accessed ok, but not ClassB.
> > | 
> > | *Test> funcD ((dict::DictClassA Int String)) "hello" 5
> > | "hello"
> > | 
> > | Is it something to do with ClassB only having one parameter?
> > | 
> > | I'm running GHC 20041231.
> > | 
> > | -Si.
> > | 
> > | --
> > | Simon David Foster <address@hidden>
> _______________________________________________
> CASHeW-s mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/cashew-s
> 

Indeed!  I had the idea that this was a regression, rather than something you 
hadn't tried before,
but, in either case, the future doesn't look bright for it.
-- 
Andrew :-)

Please avoid sending me Microsoft Office (e.g. Word, PowerPoint)
attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html

No software patents in Europe -- http://nosoftwarepatents.com

"Value your freedom, or you will lose it, teaches history. 
`Don't bother us with politics' respond those who don't want to learn." 
-- Richard Stallman

"We've all been part of the biggest beta test the world has ever known
--
Windows" 
-- Victor Wheatman, Gartner


Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]