[Caml-list] [ANN] ppx_deriving 0.1

[Caml-list] [ANN] ppx_deriving 0.1

[Peter Zotov]

Hello,

I'm glad to announce an initial release of ppx_deriving,
a modular syntax extension for type-driven code generation.
It will be shortly available in OPAM.

I will introduce ppx_deriving with an example:

# #require "ppx_deriving";;
# type file = {
   kind : [ `File | `Dir ];
   name : string;
   perm : int [@printer fun fmt -> Format.fprintf fmt "0o%03o"];
} [@@deriving Show, Eq];;
type file = { kind : [ `Dir | `File ]; name : bytes; perm : int; }
val pp_file : Format.formatter -> file -> unit = <fun>
val show_file : file -> bytes = <fun>
val equal_file : file -> file -> bool = <fun>
# print_endline (show_file { kind = `Dir; name = "bin"; perm = 0o755 
});;
{ kind = `Dir; name = "bin"; perm = 0o755 }
- : unit = ()

A more thorough description is available in README[1].

While I intend this release to primarily serve as a preview for
the community and a means to gather feedback, it is fully usable
and documented. Some of the planned features (marked "TBD" in README)
are not yet implemented.

I hope that ppx_deriving can serve as a future replacement to both
ocsigen's deriving and JaneStreet's type_conv. If you are responsible
for these libraries, please get in touch. The OCaml ecosystem would
benefit from a single type-driven code generation mechanism.

I welcome any comments.

   [1]: https://github.com/whitequark/ppx_deriving/

-- 
Peter Zotov
sip:whitequark@sipnet.ru

Re: [Caml-list] [ANN] ppx_deriving 0.1

[Yotam Barnoy]

[-- Attachment #1: Type: text/plain, Size: 2511 bytes --]

Very nice.

I've never used any of the deriving extensions before, but I have an
aesthetic suggestions. Would it perhaps make sense to generate a module per
derived type? For example a type t would generate a module T_ (the
underscore or any other suffix would reduce mixups with pre-existing
modules). You could then use code such as

'if T_.(a = b && b = c) ...'

or  'T_.show x ...'

which allows you to keep the infix notation for = which is important IMO.

You could even generate T_ as having internal Eq, Ord, and Show modules (as
requested by the user), which would be included in the T_ module. This
would allow you to easily pass them as first class modules to functions
accepting Eq, Ord or Show signatures.

Yotam



On Wed, Jul 23, 2014 at 5:55 AM, Peter Zotov <whitequark@whitequark.org>
wrote:

> Hello,
>
> I'm glad to announce an initial release of ppx_deriving,
> a modular syntax extension for type-driven code generation.
> It will be shortly available in OPAM.
>
> I will introduce ppx_deriving with an example:
>
> # #require "ppx_deriving";;
> # type file = {
>   kind : [ `File | `Dir ];
>   name : string;
>   perm : int [@printer fun fmt -> Format.fprintf fmt "0o%03o"];
> } [@@deriving Show, Eq];;
> type file = { kind : [ `Dir | `File ]; name : bytes; perm : int; }
> val pp_file : Format.formatter -> file -> unit = <fun>
> val show_file : file -> bytes = <fun>
> val equal_file : file -> file -> bool = <fun>
> # print_endline (show_file { kind = `Dir; name = "bin"; perm = 0o755 });;
> { kind = `Dir; name = "bin"; perm = 0o755 }
> - : unit = ()
>
> A more thorough description is available in README[1].
>
> While I intend this release to primarily serve as a preview for
> the community and a means to gather feedback, it is fully usable
> and documented. Some of the planned features (marked "TBD" in README)
> are not yet implemented.
>
> I hope that ppx_deriving can serve as a future replacement to both
> ocsigen's deriving and JaneStreet's type_conv. If you are responsible
> for these libraries, please get in touch. The OCaml ecosystem would
> benefit from a single type-driven code generation mechanism.
>
> I welcome any comments.
>
>   [1]: https://github.com/whitequark/ppx_deriving/
>
> --
> Peter Zotov
> sip:whitequark@sipnet.ru
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 3714 bytes --]

Re: [Caml-list] [ANN] ppx_deriving 0.1

[Peter Zotov]

On 2014-07-23 18:36, Yotam Barnoy wrote:
> Very nice.
> 
> I've never used any of the deriving extensions before, but I have an
> aesthetic suggestions.

I humbly suggest trying to use it before proposing aesthetic changes.

> Would it perhaps make sense to generate a
> module per derived type? For example a type t would generate a module
> T_ (the underscore or any other suffix would reduce mixups with
> pre-existing modules). You could then use code such as
> 
> 'if T_.(a = b && b = c) ...'
> 
> or  'T_.show x ...'
> 
> which allows you to keep the infix notation for = which is important
> IMO.
> 
> You could even generate T_ as having internal Eq, Ord, and Show
> modules (as requested by the user), which would be included in the T_
> module. This would allow you to easily pass them as first class
> modules to functions accepting Eq, Ord or Show signatures.

I believe this is best left to the upcoming implicits, which will
hopefully be merged soon.

I have based the current design on existing patterns across OCaml
ecosystem; I don't want to change the way people structure their
modules, I want to reduce the amount of boilerplate to write.

-- 
Peter Zotov
sip:whitequark@sipnet.ru

Re: [Caml-list] [ANN] ppx_deriving 0.1

[Yotam Barnoy]

[-- Attachment #1: Type: text/plain, Size: 1639 bytes --]

OK, I was just making some suggestions based on experience I have with
haskell's deriving, which I use all the time, and trying to bring as much
of that ease of use as possible to ocaml.

Any idea where I can find some info on ocaml's upcoming implicits? A google
search was not particularly helpful.



On Wed, Jul 23, 2014 at 4:19 PM, Peter Zotov <whitequark@whitequark.org>
wrote:

> On 2014-07-23 18:36, Yotam Barnoy wrote:
>
>> Very nice.
>>
>> I've never used any of the deriving extensions before, but I have an
>> aesthetic suggestions.
>>
>
> I humbly suggest trying to use it before proposing aesthetic changes.
>
>
>  Would it perhaps make sense to generate a
>> module per derived type? For example a type t would generate a module
>> T_ (the underscore or any other suffix would reduce mixups with
>> pre-existing modules). You could then use code such as
>>
>> 'if T_.(a = b && b = c) ...'
>>
>> or  'T_.show x ...'
>>
>> which allows you to keep the infix notation for = which is important
>> IMO.
>>
>> You could even generate T_ as having internal Eq, Ord, and Show
>> modules (as requested by the user), which would be included in the T_
>> module. This would allow you to easily pass them as first class
>> modules to functions accepting Eq, Ord or Show signatures.
>>
>
> I believe this is best left to the upcoming implicits, which will
> hopefully be merged soon.
>
> I have based the current design on existing patterns across OCaml
> ecosystem; I don't want to change the way people structure their
> modules, I want to reduce the amount of boilerplate to write.
>
>
> --
> Peter Zotov
> sip:whitequark@sipnet.ru
>

[-- Attachment #2: Type: text/html, Size: 2501 bytes --]

Re: [Caml-list] [ANN] ppx_deriving 0.1

[Peter Zotov]

On 2014-07-24 00:37, Yotam Barnoy wrote:
> OK, I was just making some suggestions based on experience I have with
> haskell's deriving, which I use all the time, and trying to bring as
> much of that ease of use as possible to ocaml.

Thank you for the suggestion. I see some cases where modules would be 
useful,
(including, eventually, implicits), but as most deriving plugins 
generate
a single function now, I think it would be pointless to generate such 
modules.

>  Any idea where I can find some info on ocaml's upcoming implicits? A
> google search was not particularly helpful.

There are two articles by Alain Frisch:
http://www.lexifi.com/blog/implicit-values
http://www.lexifi.com/blog/implicit-arguments

They get the general idea across, but do not represent the ongoing work.
The ongoing work is being done in this git repository:
https://github.com/def-lkb/ocaml/commits/implicit-module

As far as I know, it is not yet documented in any way and it is not 
clear
whether it will be merged in OCaml at all.
However, I have high hopes for this feature.

> 
> On Wed, Jul 23, 2014 at 4:19 PM, Peter Zotov
> <whitequark@whitequark.org> wrote:
> 
>> On 2014-07-23 18:36, Yotam Barnoy wrote:
>> 
>>> Very nice.
>>> 
>>> I've never used any of the deriving extensions before, but I have
>>> an
>>> aesthetic suggestions.
>> 
>> I humbly suggest trying to use it before proposing aesthetic
>> changes.
>> 
>>> Would it perhaps make sense to generate a
>>> module per derived type? For example a type t would generate a
>>> module
>>> T_ (the underscore or any other suffix would reduce mixups with
>>> pre-existing modules). You could then use code such as
>>> 
>>> 'if T_.(a = b && b = c) ...'
>>> 
>>> or 'T_.show x ...'
>>> 
>>> which allows you to keep the infix notation for = which is
>>> important
>>> IMO.
>>> 
>>> You could even generate T_ as having internal Eq, Ord, and Show
>>> modules (as requested by the user), which would be included in
>>> the T_
>>> module. This would allow you to easily pass them as first class
>>> modules to functions accepting Eq, Ord or Show signatures.
>> 
>> I believe this is best left to the upcoming implicits, which will
>> hopefully be merged soon.
>> 
>> I have based the current design on existing patterns across OCaml
>> ecosystem; I don't want to change the way people structure their
>> modules, I want to reduce the amount of boilerplate to write.
>> 
>> --
>> Peter Zotov
>> sip:whitequark@sipnet.ru

-- 
Peter Zotov