Thanks, Leo --

This is exactly what I needed to know. I thought that the (type a) annotation was forcing the function to be polymorphic. For future reference, is there any way to write the annotation (that forces the function to be polymorphic) without having to write explicit 'fun's?

Thanks.

On Sun, Mar 27, 2016 at 12:04 AM, Leo White <leo@lpw25.net> wrote:
This is a guess since you didn't include the definition of
stream_declarations, but I suspect that:

> (* I have the following function, which seems to type check *)
> let stream_declarations (type a)
> : (internal_result,a) result_stream = ...

is not polymorphic. The `(type a)` annotation ensures that `a` is
abstract in the body of `stream_declarations` but does not enforce
that the result is polymorphic -- in particular I suspect that you
are running up against the value restriction. An easy way to check
would be to change the definition to:

  let stream_declarations : 'a. (internal_result,'a) result_stream =
  ...

or

  let stream_declarations : type a. (internal_result,a) result_stream =
  ...

both of which enforce polymorphism, and so will give an error if your
definition is actually monomorphic.

If `stream_declarations` does have the monomorphic type
`(internal_result, '_a) result_stream` then any attempt to use it as
`(internal_result, b) result_stream` would cause `b` to be unified with
`'_a` and thus escape it's scope.

Regards,

Leo



--
gregory malecha