Abstract types in the revised syntax

Abstract types in the revised syntax

[Nicolas Pouillard]

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

Re: Abstract types in the revised syntax

[Till Varoquaux]

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
>

Re: Abstract types in the revised syntax

[Nicolas Pouillard]

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

Re: Abstract types in the revised syntax

[Till Varoquaux]

Nope,

This doesn't work for me (using a cvs version of ocaml about 2hours
old). I ran in the exact same problem, maybe I was actually doing it
right :)

camlp4orf test.ml
File "test.ml", line 6, characters 28-36:
While expanding quotation "ctyp":
  Parse error: EOI expected after [quotation of type] (in [quotation of type])

cheers,
Till
On 5/3/07, Nicolas Pouillard <nicolas.pouillard@gmail.com> wrote:
> 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
>

Re: Abstract types in the revised syntax

[Nicolas Pouillard]

On 5/3/07, Nicolas Pouillard <nicolas.pouillard@gmail.com> wrote:
> Hello,
>
> This message concern the few people that use the revised syntax :)
[...]

> So I revert back to << type t; >> for abstract types.

Committed in CVS (release310 branch).

-- 
Nicolas Pouillard