Type signature with private type

OK, so here's an obscure corner of the language:

Haskell allows you to export an identifier who's type signature mentions a type that is not exported. What exactly is the semantics of this?

For example, suppose I have

module Foobar (bar) where

data Foo = ...

bar :: String -> Foo

Foo is not exported, while bar is. The type of bar mentions Foo , though. Many programming languages wouldn't let you do this, but Haskell does.

So what now? It seems that I can call bar , but then can't do much with its result. I particular, I (presumably) cannot utter the name of the result type, which is kinda weird. Presumably if the module exported some functions that take Foo as input, I ought to be able to call those with my result as input... yet all the whole I can't say so in a type signature.

For sure, doing something like the above is not a good idea; I'm not proposing to do this in actual code. I'm just curious as to what it actually does.


It might be more interesting if Haskell were to forbid you from exporting types of your own which infer Foo s---this would make the situation here behave a bit more like existential typing which is A Good Idea for module systems.

Instead, the type information leaks. So does the instance information. For "instance" the following is unsafe

module Foo ( foo ) where

  data Foo ...
    deriving (Data, Typeable) -- for internal use

  foo :: Foo -> IO ()

since using foo will allow an "evil" user to unify Data.Data.fromConstr ... with Foo even if users are not supposed to be able to generate Foo values.

-- mkFoo :: Constr -> Foo       (except I have to let this be inferred)
mkFoo c = out where
  out     = fromConstr c
  ignored = foo out

Ultimately, I'd consider this to be a poor API. If you want to emphasize the use of a type without allowing the user to construct it, export the type.

链接地址: http://www.djcxy.com/p/20196.html

上一篇: 为什么DataGridRow IsSelected绑定在DataGrid上不起作用

下一篇: 输入私人类型的签名