Re: [Haskell] Real life examples
I've replied to the cafe, as per requests... Peek and poke are instances of the Storable class, I can re-implement storable, and provide the alternative definition by giving ghc some -i<something> arguments. I don't even need to recompile your module, simply providing the alternate Storable module at link time is sufficient. So I restate my point, it _can_ be done in Haskell as it stands at the moment, and yor proposal would break this. Keean. Adrian Hey wrote:
On Friday 26 Nov 2004 11:39 am, Keean Schupke wrote:
Adrian Hey wrote:
Well it can be written in Haskell, but not using a module that was specifically designed to prevent this.
Well, It can be written in Haskell as it stands at the moment...
No it can't. If I have a device driver that's accessing real hardware (peeking and poking specific memory locations say), how are you going to emulate that? You need to make peek and poke parameters of the module.
That is certainly possible, but if the author of the driver module didn't anticipate your emulation needs, you'd be stuck I think.
Regards -- Adrian Hey
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Keean Schupke wrote:
[...] I don't even need to recompile your module, simply providing the alternate Storable module at link time is sufficient. [...]
[ Completely off-topic for this thread ] But this *won't* work in the presence of cross-module inlining, e.g. when you are using GHC with -O or -O2. And IMHO this aggressive inlining is a very good thing. Haskell is not C. :-) Cheers, S.
Hi, Sven Panne wrote:
Keean Schupke wrote:
[...] I don't even need to recompile your module, simply providing the alternate Storable module at link time is sufficient. [...]
[ Completely off-topic for this thread ] But this *won't* work in the presence of cross-module inlining, e.g. when you are using GHC with -O or -O2. And IMHO this aggressive inlining is a very good thing. Haskell is not C. :-)
If a function is exported it cannot be inlined, can it? When I edit a module I generally don't have to recompile my whole program even if I compile with -O2... After all the fuss about certain type class extensions breaking separate compilation it would be a bit odd if it was broken already? Keean.
Keean Schupke wrote:
If a function is exported it cannot be inlined, can it? When I edit a module I generally don't have to recompile my whole program even if I compile with -O2... After all the fuss about certain type class extensions breaking separate compilation it would be a bit odd if it was broken already?
Again: Haskell is not C. Exported functions are exported including their implementation if GHC thinks that "they are worth it". What this exactly means can be tuned by a few parameters. A simple example: --------------------------------------------------------------------------- module Foo where bar :: Bool -> Int bar False = 123 bar True = 456 --------------------------------------------------------------------------- panne@jeanluc:~> ghc -O2 -c Foo.hs panne@jeanluc:~> ghc --show-iface Foo.hi interface "Main" Foo 1 6030 where export Foo bar module dependencies: package dependencies: base orphans: Foreign.C.Types Foreign.Ptr GHC.Base GHC.Float GHC.Int GHC.List GHC.Word bar :: GHC.Base.Bool -> GHC.Base.Int {- Arity: 1 HasNoCafRefs Strictness: Sm Unfolding: (\ ds :: GHC.Base.Bool -> case @ GHC.Base.Int ds of wild { False -> lvl1 True -> lvl }) -} lvl :: GHC.Base.Int {- HasNoCafRefs Strictness: m Unfolding: (GHC.Base.I# 456) -} lvl1 :: GHC.Base.Int {- HasNoCafRefs Strictness: m Unfolding: (GHC.Base.I# 123) -} --------------------------------------------------------------------------- You can see that every little detail is exported here. This is extremely important for good performance and I happily trade separate compilation (in the traditional sense) for this. Note that 'ghc --make' easily handles the recompilation issue for your own programs. Libraries where you want some kind of binary backwards compatibility are another story. Here you have to trade (just like C!) efficiency against flexibility, e.g. by writing some kind of facade compiled without -O. Cheers, S.
Sven Panne wrote:
You can see that every little detail is exported here. This is extremely important for good performance and I happily trade separate compilation (in the traditional sense) for this. Note that 'ghc --make' easily handles the recompilation issue for your own programs.
Libraries where you want some kind of binary backwards compatibility are another story. Here you have to trade (just like C!) efficiency against flexibility, e.g. by writing some kind of facade compiled without -O.
Seems like a reasonable trade, presumably you can use noinline to stop this happening (even with -O2) if you want to produce a stable binary interface (like you want for plug-ins). I assume this does not affect the ability to replace Storable when compiling from source though? Keean.
participants (2)
-
Keean Schupke -
Sven Panne