Re: Abstract types in the revised syntax

["Nicolas Pouillard" <nicolas.pouillard@gmail.com>]

On 5/3/07, Till Varoquaux <till.varoquaux@gmail.com> wrote:
> 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 >? )

That way...

open Camlp4.PreCast;;

let mk_obj_type _loc fields types =
  let object_type =
    List.fold_right2 begin fun field typ object_type ->
      <:ctyp< $lid:field$ : $lid:typ$ ; $object_type$ >>
    end fields types <:ctyp<>>
  in
  <:ctyp< < $object_type$ > >>
;;

mk_obj_type (Loc.mk "<test>") ["f1"; "f2"] ["t1"; "t2"];;


>
> 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
> >
>


-- 
Nicolas Pouillard