Types in a module default to private

[j14159]

Importing and exporting via import_type and export_type.

@danabr I'd be curious to hear any thoughts on these changes if you have a moment as they're based on an example you brought up.

[j14159]

Closes #48

[danabr]

If you have an exported function returning a value of an unexported type you will get an error like below in the module using that exported function:

{error,{bad_constructor,7,"Some"}}

I'm not sure that is what we want.

I think what we want is that all type names are exported, but that type representations are not. i.e. in the OCaml example from ticket #34, the type name radius is exported, but its implementation is unknown to calling modules. This forces the calling modules to use functions from the "Radius" module to create values of type Radius.radius. Only if we want to expose the representation of radius, we would use something like export_type. import_type type then becomes unnecessary.

It is some time since I thought about this last and there is probably some flaw in my reasoning above, but my main goal is to be able to define completely abstract data types.

[j14159]

Correct me if I'm wrong but that error should only occur if we're actually trying to use the implementation of an un-exported type, e.g. in pattern match on the value returned by the exported function. Isn't this relatively consistent with what you're after? I haven't yet tried a test out to confirm that this is correct on my part, mind :)

Having said that, your point about all names being exposed but implementations not so without explicit export does make a lot of sense. I expect you want to be able to include the type names in other (external to the defining module) types but not expose the implementation. Is that more or less accurate? I think there might be a role here still for import_type in that without it we'd require a fully qualified type/type constructor name. Comments/criticisms?

[danabr]

To answer your first question, consider this:

module radius

type radius = Radius int 

export make_radius/1, radius_to_int/1

make_radius i = 
  match i with
    x, is_integer x -> Radius x

radius_to_int r = 
  match r with
    Radius i -> i

module test_shape

test_radius () = (radius.radius_to_int (radius.make_radius 1)) 

This will fail with {error,{bad_constructor,13,"Radius"}}, which I think most people would find confusing.

Regarding your second question. Yes, you got it right.

And lastly, regarding import_type. Haskell gets away with a single import statement that can be used to import functions, data constructors and types. Maybe we can too. Something like import foo [bar, baz, boo] meaning "whenever you see bar, prefix with foo yielding foo.bar, etc.

[j14159]

Interesting - the error you're describing is a bug in the typer itself. I think it's typing functions in the environment of the module calling into the other with the private type rather than in the module that owns the function.

[j14159]

@danabr updated with a fix for that bug.

[j14159]

@danabr I've opened Issue #62 to refine and discuss this further.