- Glasgow-haskell-users

RE: deriving weirdness on newtypes
by Simon Peyton-Jones 08 Oct '02

08 Oct '02

| newtype Foo = Foo Int deriving (Num) | instance Show Foo where { show = undefined } | | then, the value of 'show (Foo 5)' is undefined, but the value of 'show | (5::Foo)' is "5". definately *WRONG*. You're right. This is all a bit more complicated than I (or John H) thought. Thinking cap on. But don't hold your breath. Simon

1 0

RE: -package-name
by Ashley Yakeley 08 Oct '02

08 Oct '02

At 2002-10-08 04:26, Simon Peyton-Jones wrote: >Ah, it's the -package flag we are planning to get rid of! Aha. So how will GHC find all the various module imports? I'd rather be using "-package foo" than "-i/usr/local/share/foo/haskell/imports". Or is there going to be some standard, official place for everyone's .hi files to be installed in, such as the GHC imports directory? -- Ashley Yakeley, Seattle WA

1 0

RE: -package-name
by Simon Peyton-Jones 08 Oct '02

08 Oct '02

| Definitely not worthwhile? Should I be using "-package-name foo" when | compiling for my package foo? Yes, you definitely should do that. That's how GHC knows what package the module is a part ot. | >Packages are the unit of distribution, and the unit of | >library archive, in GHC. | >If you import a module Foo, GHC has to figure out which libBaz.a to | >link. | | I assumed that GHC linked to all libraries mentioned in all those | packages specified with "-package". Ah, it's the -package flag we are planning to get rid of! Simon

1 0

RE: -package-name
by Ashley Yakeley 08 Oct '02

08 Oct '02

At 2002-10-08 03:04, Simon Peyton-Jones wrote: >Definitely not. Definitely not worthwhile? Should I be using "-package-name foo" when compiling for my package foo? >Packages are the unit of distribution, and the unit of >library archive, in GHC. >If you import a module Foo, GHC has to figure out which libBaz.a to >link. I assumed that GHC linked to all libraries mentioned in all those packages specified with "-package". -- Ashley Yakeley, Seattle WA

1 0

RE: -package-name
by Simon Peyton-Jones 08 Oct '02

08 Oct '02

Definitely not. Packages are the unit of distribution, and the unit of library archive, in GHC. If you import a module Foo, GHC has to figure out which libBaz.a to link. Simon | -----Original Message----- | From: Ashley Yakeley [mailto:ashley@semantic.org] | Sent: 07 October 2002 08:17 | To: GHC List | Subject: -package-name | | | Is the "-package-name" mechanism still worthwhile now that we have | hierarchical modules? | | -- | Ashley Yakeley, Seattle WA | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

1 0

Seeking clues
by mgross＠dorsai.org 07 Oct '02

07 Oct '02

I have now made several failed attempts to compile various versions of the fptools package with parallel support (way=mp). The Debian packages I have tried come in without the _mp libraries, and all of the different variations I have tried on building from source have failed with nasty errors during make. Thus: Have any of the readers here gotten one of the source packages available from Haskell.org to build with parallel support? Would ya' be good enough to give me the clues so I can repeat your success and be forever grateful? Thanks, Murray Gross

2 1

-package-name
by Ashley Yakeley 07 Oct '02

07 Oct '02

Is the "-package-name" mechanism still worthwhile now that we have hierarchical modules? -- Ashley Yakeley, Seattle WA

1 0

IO security
by Ch. A. Herrmann 04 Oct '02

04 Oct '02

Hi GHC users, I'm looking for secure compile and run-time methods to ensure automatically that Haskell modules cannot perform particular IO operations. Therefore, I've got some questions that might be interesting for other people using GHC as well. o There are functions like "unsafePerformIO". How many of these unsafe functions exist and what are their names? Is there a possibility to tell GHC to reject programs in which such functions occur? Concerning, e.g., the rewrite-rule system, how can we prevent that these functions are applied by some trick, invisible by an automatic inspection of the source code? o Is the function "print" secure in the sense that all stuff it produces is restricted to go to stdout, even if strange sequences of control characters appear? o Is there a way to tell the GHC run-time system to block file operations or system calls coming from the application program, while permitting input/output via stdin/stdout? Thanks in advance -- Christoph Herrmann

3 2

Question about the notation of (# ... #)
by David Sabel 04 Oct '02

04 Oct '02

Hi, can somebody explain what the notation (# ... #) means? For example it is used in the definition of unsafePerformIO: unsafePerformIO :: IO a -> a unsafePerformIO (IO m) = case m realWorld# of (# _, r #) -> r Thanks, David

2 1

deriving weirdness on newtypes
by Hal Daume III 03 Oct '02

03 Oct '02

So I love the fact that I can derive anything I want on newtypes. However, there seem to be problems with it. If I write: newtype Foo = Foo Int deriving (Show) x = show (Foo 5) Then x is "Foo 5" However, if I do newtype Foo = Foo Int deriving (Num) x = show (Foo 5) Then the definition of 'x' claims that there is no Show instance of Foo. However (this is where it gets weird). If I do: newtype Foo = Foo Int deriving (Num) x = show ((Foo 5) + 4) then x is *valid* and has value "9", not "Foo 9". Moreoever, I can even do: x = show ((5::Foo) + 4) and this x has value "9". Futhermore, if I do: newtype Foo = Foo Int deriving (Show,Num) then "show (Foo 5)" has value "5", not "Foo 5". IMO, the correct value of "show (Foo 5)" no matter which of the above we have is "Foo 5". I think the deriving mechanism should be changed in two ways. (1) If you derive X on a newtype and X is a subclass of Y, you must have an instance of Y on that newtype. This is how it works on data types, and I think makes sense. For instance, newtype Foo = Foo Int deriving (Ord) should be just as illegal as data Foo = Foo Int deriving (Ord) (2) The derived Show instances for newtypes in the presense of derived Num instances should be fixed so that the constructor is also printed. Rational: adding something to the list of derived classes should *not* change previously derived instances. There is yet another thing. If we have: newtype Foo = Foo Int deriving (Num) instance Show Foo where { show = undefined } then, the value of 'show (Foo 5)' is undefined, but the value of 'show (5::Foo)' is "5". definately *WRONG*. - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

2 1