[Haskell-cafe] Module visibility of data type constructors
Hello. I have a simple question for data type constructors visibility. Take a look: module Foo (Bar) where data Bar = Bar In ghc this allows me to use Bar, the type constructor, in another module, although it shouldn't be visible outside Foo. On the other hand, if I change Bar's definition as: data Bar = Baz Baz isn't visible outside Foo. Is this the correct behavior or is it bug in ghc? Cheers. -- Slavomir Kaslev ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Module visibility of data type constructors
On Sat, Nov 04, 2006 at 09:39:39PM +0200, Slavomir Kaslev wrote: To: haskell-cafe@haskell.org From: Slavomir Kaslev [EMAIL PROTECTED] Date: Sat, 4 Nov 2006 21:39:39 +0200 Subject: [Haskell-cafe] Module visibility of data type constructors Hello. I have a simple question for data type constructors visibility. Take a look: module Foo (Bar) where data Bar = Bar In ghc this allows me to use Bar, the type constructor, in another module, although it shouldn't be visible outside Foo. On the other hand, if I change Bar's definition as: data Bar = Baz Baz isn't visible outside Foo. Is this the correct behavior or is it bug in ghc? It's not the correct behavior. The question is whether the bug is in your code or in ghc (with me it's usually the former :-). I can't reproduce this with my ghc 6.4. Which version are you using? Can you post the other module you are talking about? matthias signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Module visibility of data type constructors
On 11/4/06, Matthias Fischmann [EMAIL PROTECTED] wrote: On Sat, Nov 04, 2006 at 09:39:39PM +0200, Slavomir Kaslev wrote: To: haskell-cafe@haskell.org From: Slavomir Kaslev [EMAIL PROTECTED] Date: Sat, 4 Nov 2006 21:39:39 +0200 Subject: [Haskell-cafe] Module visibility of data type constructors Hello. I have a simple question for data type constructors visibility. Take a look: module Foo (Bar) where data Bar = Bar In ghc this allows me to use Bar, the type constructor, in another module, although it shouldn't be visible outside Foo. On the other hand, if I change Bar's definition as: data Bar = Baz Baz isn't visible outside Foo. Is this the correct behavior or is it bug in ghc? It's not the correct behavior. The question is whether the bug is in your code or in ghc (with me it's usually the former :-). I can't reproduce this with my ghc 6.4. Which version are you using? Can you post the other module you are talking about? matthias -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFFTPl+TXPx/Y0ym6oRAibjAJ9uG6ZP37xOnCRRRAaraewnCn/tmQCgkZB/ xLL/q1iDHAhBUCuojOZsvuA= =jWQR -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Actually you're right. It was my mistake, I don't know what tricked me. I was evaluating in ghci, not noticing even (silly me) *Foo. Sorry for the noise. I probably need some more coffe in this time of the day. -- Slavomir Kaslev ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fractional/negative fixity?
Hello Dan, Saturday, November 4, 2006, 5:07:15 AM, you wrote: Here's an idea that (I think) is useful and backwards compatible: fractional and negative fixity. yes, i think the same. for example, once i've tried to define postfix 'when' operator like those in perl/ruby print msg `on` mode==debug but failed because my code frequently contains '$' and there is no way to define operation with a lower precedence really, there is another alternative to solve my particular problem: make `op` applications having fixed -1 precedence. such applications look heavyweight and once i have a wonderful debugging story just because for my eyes it was obvious that (a `div` b+1) means do add before div -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re[2]: [Haskell] GHC inferred type different for pointed/point-free defs?
Hello Dan, Saturday, November 4, 2006, 3:49:13 AM, you wrote: You might want to rename your () and (|||), though, since they clash with those defined in Control.Arrow. I found that by defining (???) then way I did, I could use (Control.Arrow.|||) as-is for the second part. i just not use arrows because i don't understand them. my definitions of and ||| is like those in C/perl/ruby and most times i use them alone: debugging debug_info, first_time ||| putStrLn in the far future, i will be glad to see and || redefined in this way (or some like this; it should just provide ruby's lookfeel plus extensibility). although for my own program this may be solved by just not importing Prelude. hmmm, i should think about it.. but and || functions is not exactly the same as ?: operator (nor in C, nor in standard Haskell, nor in my implementation). with these operations condition is tested _twice_ and if second argument has false value, third one will be returned anyway: True False || True = True True ? False : True = False btw, it may be extended slightly more by adding application version: a . f = a (f a) example: str . (debug info: ++) now such function named unlessNull that is not so neat -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A type class puzzle
On 11/2/06, Yitzchak Gale [EMAIL PROTECTED] wrote: GHC says: Functional dependencies conflict between instance declarations: instance Replace Zero a a (a - a - a) instance (...) = Replace (Succ n) a [l] f' Not true. The type constraints on the second instance prevent any overlap. GHC doesn't take constraints into account when checking fundeps. You're looking for Sulzmann's Chameleon, which does all sorts of constraint magic. http://www.comp.nus.edu.sg/~sulzmann/chameleon/ Also, I'd be surprized if Oleg didn't have a work-around in GHC. Jim ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe