> I'm adding it to the known bugs list but not planning to try fixing this
> anytime soon (unless it's really hurting someone).
Well, I can avoid using "module Foo( module Bar ) where", but it's
inconvenient. I'll explain what I'm up to, so you can see why.
I'm putting together a tutorial paper and presentation on programming with
first-class events in Haskell/Fran. The running example is a poly-Bezier
curve editor (because Windows GDI has the drawing function), with load &
save, visual highlighting, and undo (so far). At this point, there are
seven modules, each one being an improvement over the previous one.
Rather than copying and modifying the code, I import and override. For
instance:
module Editor6 (module Editor6, module Editor4) where
import Editor4 hiding ( editXPoint, editXPointTest, editCurve
, editor, main)
Because of the module export bug in both GHC and Hugs, I instead have to
explicitly export each imported name, e.g.,:
module Editor6 ( XPoint, renderXPoint, editXPoint, pSize, grabDist
, renderCurve, EditCurve, editCurve
, editorWith, editor, main
) where
import Editor4 hiding (editXPoint, editCurve, editor, main)
Note that in this situation, I have to export more than I normally would,
so that revised function definitions can see definitions on which they
depend.
Now the bug is fixed in GHC, but I can't benefit from their fix until Hugs
is likewise fixed.
Having said all this, I must admit that I am a bit more selective about
what I export than I had been, and that is perhaps a good thing.
So that's what I'm up to. I can live with the bug for now, but please let
me know when it's fixed.
Thanks,
- Conal
-----Original Message-----
From: Alastair Reid [SMTP:[EMAIL PROTECTED]]
Sent: Thursday, January 29, 1998 8:22 AM
To: Conal Elliott
Cc: '[EMAIL PROTECTED]';
'[EMAIL PROTECTED]'
Subject: Re: Strange module exportation behavior
This is a bug in Hugs.
Hugs doesn't try to remember what entities it brought into scope
from which
module so when you write:
module Foo( module Bar ) where
it exports everything exported from module Bar instead of everything
that Foo
imported from module Bar.
It's much simpler to implement and easier to understand - but not
what we're
supposed to be doing.
I'm adding it to the known bugs list but not planning to try fixing
this
anytime soon (unless it's really hurting someone).
Alastair
> Section 5.1.1 of the Haskell 1.4 report says:
>
> The set of all entities brought into scope from a module m by
one or
> more unqualified import declarations may be named by the form
`module
> m', which is equivalent to listing all of the entities
imported from
> the module.
> I'm getting strange behavior from both GHC and Hugs w.r.t. module
> exportations. They disagree with each other somewhat and both
seem wrong,
> although I'm not certain I understand the report on this matter.
>
> Here are two test programs. First Test1.hs:
>
> module Test1 (module Test1) where
> main = putStrLn "Test1's main"
> foo = "Test1 foo"
>
> In Test2.hs, I want to modify and extend Test1, keeping "foo" but
> replacing main.
>
> module Test2 (module Test1, module Test2) where
> import Test1 hiding (main)
> main = putStrLn "Test2's main"
> bar = foo ++ " plus Test2 bar"
>
> I also have test programs TMain1.hs:
>
> module Main where
> import qualified Test1 as Test
> main = Test.main
>
> and TMain2.hs:
>
> module Main where
> import qualified Test2 as Test
> main = Test.main
>
> and makefile rules:
>
> test1.exe : Test1.o TMain1.o
> test2.exe : Test2.o Test1.o TMain2.o
>
> Compiling and running these guys under GHC, I get:
>
> c:\Users\conal\Fran\demos\CurveEditor>test1
> test1
> Test1's main
>
> c:\Users\conal\Fran\demos\CurveEditor>test2
> test2
> Test1's main
>
> Under Hugs, I get this same behavior
>
> c:\Users\conal\Fran\demos\CurveEditor>runhugs TMain1
> Test1's main
>
> c:\Users\conal\Fran\demos\CurveEditor>runhugs TMain2
> Test1's main
>
> Swapping the export order in Test2 gives me what I want in Hugs:
>
> c:\Users\conal\Fran\demos\CurveEditor>runhugs TMain2
> Test2's main
>
> but no change in GHC.
>
> c:\Users\conal\Fran\demos\CurveEditor>make test2.exe
> rm -f Test2.o
> /fptools/bin/i386-unknown-cygwin32/ghc-2.09/ghc
-fglasgow-exts
> -concurrent -recomp -cpp
>
-i../../src:../../src/GHC:../../gc/GHC:/fptools/lib/i386-unknown-cygwin32/gh
> c-2.09/win32 -c Test2.hs -o Test2.o -ohi Test2.hi
> Module version unchanged at 3
> /fptools/bin/i386-unknown-cygwin32/ghc-2.09/ghc
-fglasgow-exts
> -concurrent -recomp -cpp
>
-i../../src:../../src/GHC:../../gc/GHC:/fptools/lib/i386-unknown-cygwin32/gh
> c-2.09/win32 -optl-u -optl_NoRunnableThreadsHook -o test2 \
> Test2.o Test1.o TMain2.o -L../../src
> -L/fptools/lib/i386-unknown-cygwin32/ghc-2.09/win32 -lFran -lWin32
> -L../../SpriteLib -lSpriteLib -luser32 -lgdi32
>
> c:\Users\conal\Fran\demos\CurveEditor>test2
> Test1's main
>
> Section 5.1.1 of the Haskell 1.4 report says:
>
> The set of all entities brought into scope from a module m by
one or
> more unqualified import declarations may be named by the form
`module
> m', which is equivalent to listing all of the entities
imported from
> the module.
>
> - Conal
