Sebastian Sylvan wrote:
On 6/14/08, Henning Thielemann <[EMAIL PROTECTED]> wrote:
On Sat, 14 Jun 2008, Sebastian Sylvan wrote:
On 6/14/08, Henning Thielemann <[EMAIL PROTECTED]> wrote:
On Sat, 14 Jun 2008, Sebastian Sylvan wrote:
On 6/14/08, Henning Thielemann <[EMAIL PROTECTED]> wrote:
The problem would be again that no one knows, where "Window" comes
from.
Better would be
I really don't see how this is a big problem. Lots of languages do
hierarchical import (e.g. .Net languages) and I don't think I've ever
heard
anyone complain about this particular aspect of it.
It's not a problem for you and thus you do not pay attention to these
complaints, I suspect. Maybe the people who would complain about the
importing style, simply don't use the mentioned languages.
The worst case scenario is that you need a little bit of tool support to
help you sort it out. Plus, it's not like you can't just qualify the
import
to make it easier to see where it comes from if you really think it's a
problem:
Cf.
http://www.haskell.org/haskellwiki/Import_modules_properly
Haskell can re-export modules, which makes tracing identifiers more
difficult. I want to be able to read modules without using a tool.
I'm not sure I understand you point. You're so opposed to the *option* of
allowing hierarchical exports (even though you can still import it
qualified
if you personally like having to specify at each callsite exactly where
some
identifier is coming from),
I was concerned with the _import_ part of your proposal. (I haven't thought
about the export part so far.)
that you'd rather any library making use of a module hierarchy is forced
to either make the user add dozens of boilerplate import statements (with
"qualified" and "as") or the more common strategy of prefixing each function
call with the module name (buttonNew)? To me a module system that requires
the latter in practice is horribly broken, and I'm suggesting a low-impact
way of fixing it. It may not be the best system available, but it's a tiny
extension of the current.
I really don't see why adding this option hurts you, when it clearly helps
enable doing what this thread advocates (use qualified modules to
distinguish between functions of the same name, rather than adding a bunch
of prefixes/suffixes to the functions).
Button.new is my favorite, because with current import variants I can
easily lookup, what Button and Button.new refer to. I understand your
proposal in that way that
import Graphics.UI.Gtk
brings module qualifications Window and Button into scope although they are
not explicitly mentioned. Thus I could no longer find out easily what
Butten.new means.
I don't see why this is so bad when it's exactly what we have for other
identifiers? E.g. if you import Control.Monad you get mapM, but you can't
really say for sure where this identifier comes from, which is no better
than not knowing where "Button.new" comes from. In both cases you have the
option to qualify the module import so you have to say "Monad.mapM" or
"GTK.Button.new" which makes it more apparent.
I suppose you would make the "hiding" clause and the "import list" thing
work with modules too for consistency, so if you really wanted to you could
list the modules/identifiers that you bring in.
yeah, we could come up with a syntax. one that gives privileged meaning
to hierarchy. If used according to "design your modules for qualified
import", it would still allow fairly easy use and looking up function uses.
import Graphics.UI.GTK (import qualified Button, import qualified Window)
then you get Button.f (because Graphics.UI.GTK wasn't imported
qualified), Graphics.UI.GTK.Button.f, (not f or Graphics.UI.GTK.f
because of qualified Button) ... they're normal import statements
inside. What it saves is the duplication of Graphics.UI.GTK and
"....Button as Button". Not sure I like how long "import qualified" is,
repeated there, but it seemed much less confusing than anything shorter.
import Data (import qualified Map, Map.Map)
or
import Data (import qualified Map, import Map(Map))
or a shortcut for that common pattern of importing a few things unqualified
import Data (import qualified Map and (Map))
aka. import qualified Data.Map as Map and (Map)
aka. import qualified Data.Map as Map (empty,singleton,...) and (Map)
or perhaps "unqualifying" rather than "and"
personally I would like it if we could also import (f as g) if we wanted
to rename an "f" we were importing, to "g" in the module and re-exports,
without having to be concerned about (for lowercase) monomorphism
restriction, (for types) whether a synonym will work properly everywhere
(not without extensions!), (for constructor, record fields, and classes)
simple *impossibility*. That wish is only related in that it's a
related generalization, though.
hmm.
-Isaac
Are you saying that you prefer the situation where to use GTK the user would
have to explicitly import every single sub-module in the hierarchy ("import
qualified Graphics.UI.GTK.X as X" where X = {Button,Window, ... etc})? I
don't think that's very nice at all, and I certainly don't like having to
add the module name to the functions... I think lots of libraries are like
that, and we need some mechanism of importing lots of related modules
together so that they come in qualified, without forcing the user to write a
gazillion lines of boilerplate import statements..
I think that if GTK did use this system (rather than append the module name
to the function and export them "flatly") a lot of people would resort to
ugly hacks like putting the import statements in a file somewhere and using
the C preprocessor to include it, yuck! (OTOH this may be just what's
required to convince everyone that we need to improve the module system)...
------------------------------------------------------------------------
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
