Version française
Home     About     Download     Resources     Contact us    
Browse thread
Building object types (Was: Abstract types in the revised syntax)
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Nicolas Pouillard <nicolas.pouillard@g...>
Subject: Building object types (Was: Abstract types in the revised syntax)
On 5/3/07, Till Varoquaux <till.varoquaux@gmail.com> wrote:
> 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 :)

Sorry for the late response...

Are you on the release310 branch?

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


-- 
Nicolas Pouillard