caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* [Caml-list] Open datatypes
@ 2011-07-14 13:38 lpw25
  2011-07-14 14:48 ` Markus Mottl
  0 siblings, 1 reply; 5+ messages in thread
From: lpw25 @ 2011-07-14 13:38 UTC (permalink / raw)
  To: caml-list


Hi all,

I was wondering whether there was any particular reason why OCaml 
doesn't allow the user to create open extensible datatypes like exn.

I know that something similar can be created using local exceptions:

module T = struct
  type t = exn

  type 'a tvariant = (('a -> t), (t -> 'a option))

  let createVariant (type s) () =
    let module M = struct exception E of s end in
      (fun x -> M.E x), (function M.E x -> Some x | _ -> None)

  let mkTVariant ((cnstr, _) :	'a tvariant) (x: 'a) = cnstr x

  let matchTVariant ((_, destr) : 'a tvariant) (xt: t) = destr xt
end 

but it isn't very neat, and it seems that it would not be that difficult to 
allow the user to declare types with the same properties as exn.

Thanks,

Leo

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Caml-list] Open datatypes
  2011-07-14 13:38 [Caml-list] Open datatypes lpw25
@ 2011-07-14 14:48 ` Markus Mottl
  2011-07-14 15:10   ` Gerd Stolpmann
  2011-07-14 15:15   ` Leo P White
  0 siblings, 2 replies; 5+ messages in thread
From: Markus Mottl @ 2011-07-14 14:48 UTC (permalink / raw)
  To: lpw25; +Cc: caml-list

Hi,

it is possible to create open (i.e. extensible) datatypes with
polymorphic variants, even allowing recursion.  E.g.:

  type 't add_open = [ `Add of 't * 't ]
  type 't sub_open = [ `Sub of 't * 't ]

  let eval_add_open eval (`Add (l, r)) = eval l + eval r
  let eval_sub_open eval (`Sub (l, r)) = eval l - eval r

"add_open" and "sub_open" are clearly completely independent from each
other, both the datatypes and the evaluation functions.

Now we combine these two datatypes and evaluation functions, still
leaving the result extensible:

  type 't add_sub_open = [ 't add_open | 't sub_open ]

  let eval_add_sub_open eval = function
    | #add_open as t -> eval_add_open eval t
    | #sub_open as t -> eval_sub_open eval t

Eventually you will want to "close" the extensible definitions for
actual use.  This basically just means tying the open ends:

  type add_sub = add_sub add_sub_open

  let rec eval_add_sub t = eval_add_sub_open eval_add_sub t

In my experience using polymorphic variants for that purpose is hands
down the most elegant way of achieving extensibility and
composability.  It is especially useful for creating domain-specific
languages that can be quickly combined and extended.

Regards,
Markus

On Thu, Jul 14, 2011 at 09:38,  <lpw25@cam.ac.uk> wrote:
>
> Hi all,
>
> I was wondering whether there was any particular reason why OCaml
> doesn't allow the user to create open extensible datatypes like exn.
>
> I know that something similar can be created using local exceptions:
>
> module T = struct
>  type t = exn
>
>  type 'a tvariant = (('a -> t), (t -> 'a option))
>
>  let createVariant (type s) () =
>    let module M = struct exception E of s end in
>      (fun x -> M.E x), (function M.E x -> Some x | _ -> None)
>
>  let mkTVariant ((cnstr, _) :  'a tvariant) (x: 'a) = cnstr x
>
>  let matchTVariant ((_, destr) : 'a tvariant) (xt: t) = destr xt
> end
>
> but it isn't very neat, and it seems that it would not be that difficult to
> allow the user to declare types with the same properties as exn.
>
> Thanks,
>
> Leo
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa-roc.inria.fr/wws/info/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

-- 
Markus Mottl        http://www.ocaml.info        markus.mottl@gmail.com


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Caml-list] Open datatypes
  2011-07-14 14:48 ` Markus Mottl
@ 2011-07-14 15:10   ` Gerd Stolpmann
  2011-07-14 16:05     ` Leo P White
  2011-07-14 15:15   ` Leo P White
  1 sibling, 1 reply; 5+ messages in thread
From: Gerd Stolpmann @ 2011-07-14 15:10 UTC (permalink / raw)
  To: Markus Mottl; +Cc: lpw25, caml-list

Am Donnerstag, den 14.07.2011, 10:48 -0400 schrieb Markus Mottl:
> Hi,
> 
> it is possible to create open (i.e. extensible) datatypes with
> polymorphic variants, even allowing recursion.  E.g.:
> 
>   type 't add_open = [ `Add of 't * 't ]
>   type 't sub_open = [ `Sub of 't * 't ]
> 
>   let eval_add_open eval (`Add (l, r)) = eval l + eval r
>   let eval_sub_open eval (`Sub (l, r)) = eval l - eval r
> 
> "add_open" and "sub_open" are clearly completely independent from each
> other, both the datatypes and the evaluation functions.
> 
> Now we combine these two datatypes and evaluation functions, still
> leaving the result extensible:
> 
>   type 't add_sub_open = [ 't add_open | 't sub_open ]
> 
>   let eval_add_sub_open eval = function
>     | #add_open as t -> eval_add_open eval t
>     | #sub_open as t -> eval_sub_open eval t
> 
> Eventually you will want to "close" the extensible definitions for
> actual use.  This basically just means tying the open ends:
> 
>   type add_sub = add_sub add_sub_open
> 
>   let rec eval_add_sub t = eval_add_sub_open eval_add_sub t
> 
> In my experience using polymorphic variants for that purpose is hands
> down the most elegant way of achieving extensibility and
> composability.  It is especially useful for creating domain-specific
> languages that can be quickly combined and extended.

Especially, polymorphic variants are not restricted to monomorphic types
as exn is.

For a complete example look here:
https://godirepo.camlcity.org/svn/lib-pxp/trunk/src/pxp-engine/pxp_xpath.ml. It's an attempt to define xpath as an open polymorphic variant. The type open_expr is the open version of the xpath terms, expr is the closed. The corresponding evaluators are eval_open_expr and eval_expr.

There is also a paper by Jacques Garrigue about this topic, but I cannot
find it anymore in the web.

Gerd


> 
> Regards,
> Markus
> 
> On Thu, Jul 14, 2011 at 09:38,  <lpw25@cam.ac.uk> wrote:
> >
> > Hi all,
> >
> > I was wondering whether there was any particular reason why OCaml
> > doesn't allow the user to create open extensible datatypes like exn.
> >
> > I know that something similar can be created using local exceptions:
> >
> > module T = struct
> >  type t = exn
> >
> >  type 'a tvariant = (('a -> t), (t -> 'a option))
> >
> >  let createVariant (type s) () =
> >    let module M = struct exception E of s end in
> >      (fun x -> M.E x), (function M.E x -> Some x | _ -> None)
> >
> >  let mkTVariant ((cnstr, _) :  'a tvariant) (x: 'a) = cnstr x
> >
> >  let matchTVariant ((_, destr) : 'a tvariant) (xt: t) = destr xt
> > end
> >
> > but it isn't very neat, and it seems that it would not be that difficult to
> > allow the user to declare types with the same properties as exn.
> >
> > Thanks,
> >
> > Leo
> >
> > --
> > Caml-list mailing list.  Subscription management and archives:
> > https://sympa-roc.inria.fr/wws/info/caml-list
> > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> > Bug reports: http://caml.inria.fr/bin/caml-bugs
> 
> -- 
> Markus Mottl        http://www.ocaml.info        markus.mottl@gmail.com
> 
> 

-- 
------------------------------------------------------------
Gerd Stolpmann, Bad Nauheimer Str.3, 64289 Darmstadt,Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
Phone: +49-6151-153855                  Fax: +49-6151-997714
------------------------------------------------------------


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Caml-list] Open datatypes
  2011-07-14 14:48 ` Markus Mottl
  2011-07-14 15:10   ` Gerd Stolpmann
@ 2011-07-14 15:15   ` Leo P White
  1 sibling, 0 replies; 5+ messages in thread
From: Leo P White @ 2011-07-14 15:15 UTC (permalink / raw)
  To: Markus Mottl; +Cc: caml-list


Hi,

Polymorphic variants aren't really the same as open datatypes like exn.

Firstly the typechecking for polymorphic variants is much weaker, i.e. the 
same variant can be used with any polymorphic variant type.

Secondly it is not possible to create a reference to a proper open 
polymorphic variant, while references to exn are allowed.

And lastly it is not possible to create local polymorphic variants, along 
the same lines as a local exception.

Regards,

Leo


On Jul 14 2011, Markus Mottl wrote:

>Hi,
>
>it is possible to create open (i.e. extensible) datatypes with
>polymorphic variants, even allowing recursion.  E.g.:
>
>  type 't add_open = [ `Add of 't * 't ]
>  type 't sub_open = [ `Sub of 't * 't ]
>
>  let eval_add_open eval (`Add (l, r)) = eval l + eval r
>  let eval_sub_open eval (`Sub (l, r)) = eval l - eval r
>
>"add_open" and "sub_open" are clearly completely independent from each
>other, both the datatypes and the evaluation functions.
>
>Now we combine these two datatypes and evaluation functions, still
>leaving the result extensible:
>
>  type 't add_sub_open = [ 't add_open | 't sub_open ]
>
>  let eval_add_sub_open eval = function
>    | #add_open as t -> eval_add_open eval t
>    | #sub_open as t -> eval_sub_open eval t
>
>Eventually you will want to "close" the extensible definitions for
>actual use.  This basically just means tying the open ends:
>
>  type add_sub = add_sub add_sub_open
>
>  let rec eval_add_sub t = eval_add_sub_open eval_add_sub t
>
>In my experience using polymorphic variants for that purpose is hands
>down the most elegant way of achieving extensibility and
>composability.  It is especially useful for creating domain-specific
>languages that can be quickly combined and extended.
>
>Regards,
>Markus
>
>On Thu, Jul 14, 2011 at 09:38,  <lpw25@cam.ac.uk> wrote:
>>
>> Hi all,
>>
>> I was wondering whether there was any particular reason why OCaml
>> doesn't allow the user to create open extensible datatypes like exn.
>>
>> I know that something similar can be created using local exceptions:
>>
>> module T = struct
>>  type t = exn
>>
>>  type 'a tvariant = (('a -> t), (t -> 'a option))
>>
>>  let createVariant (type s) () =
>>    let module M = struct exception E of s end in
>>      (fun x -> M.E x), (function M.E x -> Some x | _ -> None)
>>
>>  let mkTVariant ((cnstr, _) :  'a tvariant) (x: 'a) = cnstr x
>>
>>  let matchTVariant ((_, destr) : 'a tvariant) (xt: t) = destr xt
>> end
>>
>> but it isn't very neat, and it seems that it would not be that 
>> difficult to allow the user to declare types with the same properties as 
>> exn.
>>
>> Thanks,
>>
>> Leo
>>
>> --
>> Caml-list mailing list.  Subscription management and archives:
>> https://sympa-roc.inria.fr/wws/info/caml-list
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Caml-list] Open datatypes
  2011-07-14 15:10   ` Gerd Stolpmann
@ 2011-07-14 16:05     ` Leo P White
  0 siblings, 0 replies; 5+ messages in thread
From: Leo P White @ 2011-07-14 16:05 UTC (permalink / raw)
  To: Gerd Stolpmann; +Cc: Markus Mottl, caml-list


While exn is monomorphic I don't think that this needs to be true of 
an open datatype in general.

Again, while polymorphic variants are similar to open datatypes like exn, 
there are cases where a polymorphic variant can not be used (for reasons 
related to their subtyping) and others where they are not as appropriate as 
exn.

So my question is whether there is any particular reason that they would be 
difficult to integrate with the rest of the language.

Thanks,

Leo


On Jul 14 2011, Gerd Stolpmann wrote:

>Am Donnerstag, den 14.07.2011, 10:48 -0400 schrieb Markus Mottl:
>> Hi,
>> 
>> it is possible to create open (i.e. extensible) datatypes with
>> polymorphic variants, even allowing recursion.  E.g.:
>> 
>>   type 't add_open = [ `Add of 't * 't ]
>>   type 't sub_open = [ `Sub of 't * 't ]
>> 
>>   let eval_add_open eval (`Add (l, r)) = eval l + eval r
>>   let eval_sub_open eval (`Sub (l, r)) = eval l - eval r
>> 
>> "add_open" and "sub_open" are clearly completely independent from each
>> other, both the datatypes and the evaluation functions.
>> 
>> Now we combine these two datatypes and evaluation functions, still
>> leaving the result extensible:
>> 
>>   type 't add_sub_open = [ 't add_open | 't sub_open ]
>> 
>>   let eval_add_sub_open eval = function
>>     | #add_open as t -> eval_add_open eval t
>>     | #sub_open as t -> eval_sub_open eval t
>> 
>> Eventually you will want to "close" the extensible definitions for
>> actual use.  This basically just means tying the open ends:
>> 
>>   type add_sub = add_sub add_sub_open
>> 
>>   let rec eval_add_sub t = eval_add_sub_open eval_add_sub t
>> 
>> In my experience using polymorphic variants for that purpose is hands
>> down the most elegant way of achieving extensibility and
>> composability.  It is especially useful for creating domain-specific
>> languages that can be quickly combined and extended.
>
>Especially, polymorphic variants are not restricted to monomorphic types
>as exn is.
>
> For a complete example look here: 
> https://godirepo.camlcity.org/svn/lib-pxp/trunk/src/pxp-engine/pxp_xpath.ml. 
> It's an attempt to define xpath as an open polymorphic variant. The type 
> open_expr is the open version of the xpath terms, expr is the closed. The 
> corresponding evaluators are eval_open_expr and eval_expr.
>
>There is also a paper by Jacques Garrigue about this topic, but I cannot
>find it anymore in the web.
>
>Gerd
>
>
>> 
>> Regards,
>> Markus
>> 
>> On Thu, Jul 14, 2011 at 09:38,  <lpw25@cam.ac.uk> wrote:
>> >
>> > Hi all,
>> >
>> > I was wondering whether there was any particular reason why OCaml
>> > doesn't allow the user to create open extensible datatypes like exn.
>> >
>> > I know that something similar can be created using local exceptions:
>> >
>> > module T = struct
>> >  type t = exn
>> >
>> >  type 'a tvariant = (('a -> t), (t -> 'a option))
>> >
>> >  let createVariant (type s) () =
>> >    let module M = struct exception E of s end in
>> >      (fun x -> M.E x), (function M.E x -> Some x | _ -> None)
>> >
>> >  let mkTVariant ((cnstr, _) :  'a tvariant) (x: 'a) = cnstr x
>> >
>> >  let matchTVariant ((_, destr) : 'a tvariant) (xt: t) = destr xt
>> > end
>> >
>> > but it isn't very neat, and it seems that it would not be that 
>> > difficult to allow the user to declare types with the same properties 
>> > as exn.
>> >
>> > Thanks,
>> >
>> > Leo
>> >
>> > --
>> > Caml-list mailing list.  Subscription management and archives:
>> > https://sympa-roc.inria.fr/wws/info/caml-list
>> > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> > Bug reports: http://caml.inria.fr/bin/caml-bugs
>> 
>> -- 
>> Markus Mottl        http://www.ocaml.info        markus.mottl@gmail.com
>> 
>> 
>
>

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2011-07-14 16:05 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-07-14 13:38 [Caml-list] Open datatypes lpw25
2011-07-14 14:48 ` Markus Mottl
2011-07-14 15:10   ` Gerd Stolpmann
2011-07-14 16:05     ` Leo P White
2011-07-14 15:15   ` Leo P White

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).