I happen to very much dislike dangling free variables and therefore
think this would be a nice improvement.
Thanks for fixing my constraint issues.
BTW I still haven't figured out how to generate constraints (lets say
I have a list of strings [t1,..,tn] and a list of idents [c1...cn],
how do I generate the type < c1:t1; ... ; cn:tn >? )

Cheers,
Till

On 5/3/07, Nicolas Pouillard <nicolas.pouillard@gmail.com> wrote:
> Hello,
>
> This message concern the few people that use the revised syntax :)
>
> In the revised syntax, abstract types are expressed by defining them
> with an unbound type variable:
>
> (* Original *)
> type t;;
>
> (* Revised *)
> type t = 'a;
>
> The motivation is that looks like an existential type, which is a way
> of seeing abstract types.
>
> However I found this motivation misapplied since it doesn't look like
> an existential type, there is no exists keyword?!? (type t = exists
> 'a. 'a;)
>
> It's like a hot-dog without sausage?!?
>
> In fact, consequences of that choice are worst. If forces the
> parser/printer to do some semantical operation to convert back and
> forth between syntaxes.
>
> type t 'a = 'a; (* not abstract *)
>
> type t 'a = 'b; (* abstract *)
>
> It was considered acceptable, since the test for the freeness of a
> single type variable seemed simple because very local.
>
> Indeed only the list of parameters was consulted to compute the
> freeness of the type variable.
>
> It seems very weak since highly dependent of future evolution of the language.
>
> Nowadays it's no longer sufficient. Constraints can be added with a
> type declaration to constrain the type of parameters.
>
> type c 'a = 'b
>    constraint 'a = < b : 'b; .. >;
> (* Thanks to Till Varoquaux for it's bug report. *)
>
> Clearly I don't want to push that wrong choice further by making more
> semantic analysis in the parser/printer.
>
> So I revert back to << type t; >> for abstract types.
>
> Now, what's the new representation for abstract types. OCaml use a
> option type, where None represent the abstract type. We can't afford
> that, since we want a concrete syntax for everything.
> However we have a nil type that can be used as a default case (for
> lists of types or optional types).
>
> <:sig_item< type t >> === <:sig_item< type t = $ <:ctyp<>> $ >>
>
> Not that this will also concern abstract module types.
>
> Alas, this will affect existing code using the revised syntax, but
> will be easily caught at compilation.
>
> From a pragmatic point of view, a grep to show the usage of such types:
> grep -E "^[ \t]*type.*=[ \t]*'[^ \t]*[ \t]*;[ \t]*$" **/*.ml*
>
> Feel free to share your mind on that subject. The change is not yet
> applied to the CVS.
>
> Best regards,
>
> --
> Nicolas Pouillard
>