Re: [Haskell-cafe] Trouble with types
Hi Konstantin, Here is yet another possible approach: Perhaps you really meant what you wrote in your definition of firstFunction - namely, that it needs to be polymorphic, so that it can convert to _any_ type that is an instance of SecondClass. In that case, you might want to add another method to SecondClass: class SecondClass a where secondConstructor :: Double - a secondFunction :: a - Double instance SecondClass SecondData where secondConstructor = SecondData secondFunction (SecondData d) = d Now you can say: instance FirstClass FirstData where firstFunction (FirstData d) = secondConstructor d In short, it all depends on what exactly you are trying to do. Hope this helps, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Printing and Referential transparency excuse
On Mon, 24 Dec 2007, Cristian Baboi wrote: While reading the Haskell language report I noticed that function type is not an instance of class Read. I was told that one cannot define them as an instance of class Show without breaking referential transparency or printing a constant. f :: (a-b)-String f x = bla bla bla How can I define a function to do the inverse operation ? g :: String - ( a - b ) This time I cannot see how referential transparency will deny it. What's the excuse now ? Like 'show' generating [(0,0), (1,1), (4,2), (9,3), for 'sqrt', 'read' could parse only value tables. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Trouble with types
Hello Konstantin, Tuesday, December 25, 2007, 8:11:34 AM, you wrote: class FirstClass a where firstFunction :: (SecondClass b) = a - b this looks like one more attempt to use OOP thinking in Haskell. look at http://haskell.org/haskellwiki/OOP_vs_type_classes and especially papers referenced there -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Printing and Referential transparency excuse
On Mon, 2007-12-24 at 11:15 +0200, Cristian Baboi wrote: While reading the Haskell language report I noticed that function type is not an instance of class Read. I was told that one cannot define them as an instance of class Show without breaking referential transparency or printing a constant. f :: (a-b)-String f x = bla bla bla How can I define a function to do the inverse operation ? g :: String - ( a - b ) This time I cannot see how referential transparency will deny it. What's the excuse now ? Referential transparency has nothing to with this. The problem here is parametricity. However, if you give a non-parametric type (or add appropriate class constraints on a and b, or add (phantom) type information to the input), e.g. String - (Int - Int) then there is no trouble at all. The compiler (or something non-portably using extremely unsafe features) could provide a primitive String - a that reads in a string and interprets it somehow as a value of type a. If the value represented by the string doesn't match the type that a is instantiated to, something bad is going to happen. Adding such a primitive would utterly destroy parametricity. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Printing and Referential transparency excuse
On Tue, 25 Dec 2007 11:05:59 +0200, Derek Elkins [EMAIL PROTECTED] wrote: On Mon, 2007-12-24 at 11:15 +0200, Cristian Baboi wrote: How can I define a function to do the inverse operation ? g :: String - ( a - b ) This time I cannot see how referential transparency will deny it. What's the excuse now ? Referential transparency has nothing to with this. The problem here is parametricity. However, if you give a non-parametric type (or add appropriate class constraints on a and b, or add (phantom) type information to the input), e.g. String - (Int - Int) then there is no trouble at all. Thank you. I finished reading the Haskell Language Report and I noticed that the class Show and Read are toys. I'll try to define some String - (a - b) functions some other time. I wonder if parametricity is the only problem. I guess that I'll have some problem with the arity of the result, but currying may help. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Printing and Referential transparency excuse
Hi Cristian, Cristian Baboi wrote: While reading the Haskell language report I noticed that function type is not an instance of class Read. I was told that one cannot define them as an instance of class Show without breaking referential transparency or printing a constant... How can I define a function to do the inverse operation ? g :: String - ( a - b ) This time I cannot see how referential transparency will deny it. What's the excuse now ? ...I finished reading the Haskell Language Report and I noticed that the class Show and Read are toys. Actually, they are not toys at all. They are very useful, and they do their job well. But it looks like they are not the right tool for what you want to do. What exactly are you trying to accomplish? Why would you want there to be instances like that? Are you thinking of program development and debugging? There are great tools for that. Are you thinking of reflection? There are great tools for that also. But because of the power of Haskell's type system, you need that much less than in many other languages. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ambiguous types although 'asTypeOf'
I thought I understand monomorphism restriction. But it seems, I don't. I have boilt down my problem to the following test. Don't try to make any sense of it, it is just the smallest code I could come up with. test :: (Integral a, RealFrac a) = a test = let c = undefined in asTypeOf (round c) c When compiling I get: Compiling StorableInstance ( src/StorableInstance.hs, interpreted ) src/StorableInstance.hs:38:17: Warning: Defaulting the following constraint(s) to type `Double' `RealFrac a' arising from use of `round' at src/StorableInstance.hs:38:17-21 In the first argument of `asTypeOf', namely `(round c)' In the definition of `test1': test1 = let c = undefined in asTypeOf (round c) c ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ambiguous types although 'asTypeOf'
As i understand it, the monomorphism restriction applies to constrained type variables, but c :: forall a. a, so it remains polymorphic and each of its uses can be instantiated to a different type. 2007/12/25, Henning Thielemann [EMAIL PROTECTED]: I thought I understand monomorphism restriction. But it seems, I don't. I have boilt down my problem to the following test. Don't try to make any sense of it, it is just the smallest code I could come up with. test :: (Integral a, RealFrac a) = a test = let c = undefined in asTypeOf (round c) c When compiling I get: Compiling StorableInstance ( src/StorableInstance.hs, interpreted ) src/StorableInstance.hs:38:17: Warning: Defaulting the following constraint(s) to type `Double' `RealFrac a' arising from use of `round' at src/StorableInstance.hs:38:17-21 In the first argument of `asTypeOf', namely `(round c)' In the definition of `test1': test1 = let c = undefined in asTypeOf (round c) c ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why does this blow the stack?
Since it's possible to support laziness for Integer (while still avoiding any stack overflow), I think it makes sense to do so. What if you have some big complicated program like the following: x = some big slow computation y = [x..] lots of code z = length $ take 10 y Why bother computing x if you don't have to? And as an added benefit, if you keep laziness, you don't have to worry about possibly breaking any programs that depend on the current lazy behavior. Laziness would NOT make sense for Int, since Int is bounded. You can't tell how long [(x::Int) ..] is without evaluating x. On 12/22/07, Don Stewart [EMAIL PROTECTED] wrote: People shouldn't be writing code that depends on this! One of the main features of Haskell is that it's lazy. I don't think it's wrong to write code that depends on laziness. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ambiguous types although 'asTypeOf'
On Dec 25, 2007 4:27 PM, Henning Thielemann [EMAIL PROTECTED] wrote: test :: (Integral a, RealFrac a) = a test = let c = undefined in asTypeOf (round c) c When compiling I get: Compiling StorableInstance ( src/StorableInstance.hs, interpreted ) src/StorableInstance.hs:38:17: Warning: Defaulting the following constraint(s) to type `Double' `RealFrac a' arising from use of `round' at src/StorableInstance.hs:38:17-21 In the first argument of `asTypeOf', namely `(round c)' In the definition of `test1': test1 = let c = undefined in asTypeOf (round c) c Interesting, I don't see this behaviour at all. $ cat t.hs module Main where instance Integral Double test :: (Integral a, RealFrac a) = a test = let c = undefined in asTypeOf (round c) c main = print (test :: Double) $ ghc --make t.hs [1 of 1] Compiling Main ( t.hs, t.o ) t.hs:3:0: Warning: No explicit method nor default method for `quotRem' In the instance declaration for `Integral Double' t.hs:3:0: Warning: No explicit method nor default method for `toInteger' In the instance declaration for `Integral Double' Linking t ... $ ./t t: Prelude.undefined $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.6.1 -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
