[Caml-list] optional functions in modules

[Caml-list] optional functions in modules

[Yitzhak Mandelbaum]

Hi,

Is there any "common wisdom" regarding the inclusion of optional functions in a module signature?  The two most obvious approaches involve 1) a pair of boolean flag and a function, where the function raises an exception if unimplemented OR 2) using the option type. I see pros/cons to each approach, but am curious if there's any (unofficial) standard approach.

Yitzhak
-----------------------------
Yitzhak Mandelbaum

Re: [Caml-list] optional functions in modules

["Markus W. Weißmann"]

On 10 May 2012, at 14:22, Yitzhak Mandelbaum wrote:

> Is there any "common wisdom" regarding the inclusion of optional functions in a module signature?  The two most obvious approaches involve 1) a pair of boolean flag and a function, where the function raises an exception if unimplemented OR 2) using the option type. I see pros/cons to each approach, but am curious if there's any (unofficial) standard approach.
> 

I strongly favor option types over exceptions; in this case I would go for the option type and make the whole function "optional", not just its return type; e.g.:

module MYSIG : sig
  ...
  val f : (int -> int -> int) option
end


best regards

-Markus

-- 
Markus Weißmann, M.Sc.
Technische Universität München
Institut für Informatik
Boltzmannstr. 3
D-85748 Garching
Germany
http://wwwknoll.in.tum.de/

Re: [Caml-list] optional functions in modules

[Fabrice Le Fessant]

I would say that it depends on how likely it is that somebody is going
to handle the case where the function is not implemented. I would use
a boolean to detect if the function is implemented, and calling the
missing function would raise an exception (be careful to define the
corresponding exception, using failwith "not implemented" might be too
generic to be useful, although I always do it in my programs ;-) ). If
it is highly likely that the program is going to handle the missing
function, using a Some type for the function is better idea.

-Fabrice

On Thu, May 10, 2012 at 2:22 PM, Yitzhak Mandelbaum
<yitzhakm@cs.princeton.edu> wrote:
> Hi,
>
> Is there any "common wisdom" regarding the inclusion of optional functions in a module signature?  The two most obvious approaches involve 1) a pair of boolean flag and a function, where the function raises an exception if unimplemented OR 2) using the option type. I see pros/cons to each approach, but am curious if there's any (unofficial) standard approach.
>
> Yitzhak
> -----------------------------
> Yitzhak Mandelbaum
>
>
>
>
>
> --
> 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
>



-- 
Fabrice LE FESSANT

Re: [Caml-list] optional functions in modules

[David Rajchenbach-Teller]

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

I would personally use an [option] and a form of startup-time
configuration, quite comparable to the browser-feature detection in
JavaScript.

So, something like

let my_function = match Module.may_have_feature with
  | Some implementation -> implementation
  | None -> (*either a workaround or an error*)

Cheers,
 David

On 5/10/12 4:53 PM, Fabrice Le Fessant wrote:
> I would say that it depends on how likely it is that somebody is going
> to handle the case where the function is not implemented. I would use
> a boolean to detect if the function is implemented, and calling the
> missing function would raise an exception (be careful to define the
> corresponding exception, using failwith "not implemented" might be too
> generic to be useful, although I always do it in my programs ;-) ). If
> it is highly likely that the program is going to handle the missing
> function, using a Some type for the function is better idea.
> 
> -Fabrice
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [Caml-list] optional functions in modules

[Goswin von Brederlow]

Yitzhak Mandelbaum <yitzhakm@cs.princeton.edu> writes:

> Hi,
>
> Is there any "common wisdom" regarding the inclusion of optional functions in a module signature?  The two most obvious approaches involve 1) a pair of boolean flag and a function, where the function raises an exception if unimplemented OR 2) using the option type. I see pros/cons to each approach, but am curious if there's any (unofficial) standard approach.
>
> Yitzhak
> -----------------------------
> Yitzhak Mandelbaum

The extunix module has a trifold solution for this:

* First there is the ExtUnix.All module that has all functions in
  it. Functions that are not available raise Not_available with function
  name as an argument.

* Second there is ExtUnix.All.have : string -> bool option

  (** [have name]
    @return indication whether function [name] is available
    - [Some true] if available
    - [Some false] if not available
    - [None] if not known

    e.g. [have "eventfd"]
  *)

* Third there is ExtUnix.Specific containing only functions available on
  this platform.

MfG
        Goswin

Re: [Caml-list] optional functions in modules

[Yaron Minsky]

Core's approach to this is to use options.  (Technically, we use a
type called Or_error.t, which has a useful error message in the
error-variant, but it's the same idea.)

On Thu, May 10, 2012 at 2:44 PM, Goswin von Brederlow <goswin-v-b@web.de> wrote:
> Yitzhak Mandelbaum <yitzhakm@cs.princeton.edu> writes:
>
>> Hi,
>>
>> Is there any "common wisdom" regarding the inclusion of optional functions in a module signature?  The two most obvious approaches involve 1) a pair of boolean flag and a function, where the function raises an exception if unimplemented OR 2) using the option type. I see pros/cons to each approach, but am curious if there's any (unofficial) standard approach.
>>
>> Yitzhak
>> -----------------------------
>> Yitzhak Mandelbaum
>
> The extunix module has a trifold solution for this:
>
> * First there is the ExtUnix.All module that has all functions in
>  it. Functions that are not available raise Not_available with function
>  name as an argument.
>
> * Second there is ExtUnix.All.have : string -> bool option
>
>  (** [have name]
>    @return indication whether function [name] is available
>    - [Some true] if available
>    - [Some false] if not available
>    - [None] if not known
>
>    e.g. [have "eventfd"]
>  *)
>
> * Third there is ExtUnix.Specific containing only functions available on
>  this platform.
>
> MfG
>        Goswin
>
> --
> 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
>

Re: [Caml-list] optional functions in modules

[Yitzhak Mandelbaum]

Thanks to everyone who responded.  FWIW, I found the argument in favor of options most compelling as a general approach.

Yitzhak

On May 10, 2012, at 8:55 PM, Yaron Minsky wrote:

> Core's approach to this is to use options.  (Technically, we use a
> type called Or_error.t, which has a useful error message in the
> error-variant, but it's the same idea.)
> 
> On Thu, May 10, 2012 at 2:44 PM, Goswin von Brederlow <goswin-v-b@web.de> wrote:
>> Yitzhak Mandelbaum <yitzhakm@cs.princeton.edu> writes:
>> 
>>> Hi,
>>> 
>>> Is there any "common wisdom" regarding the inclusion of optional functions in a module signature?  The two most obvious approaches involve 1) a pair of boolean flag and a function, where the function raises an exception if unimplemented OR 2) using the option type. I see pros/cons to each approach, but am curious if there's any (unofficial) standard approach.
>>> 
>>> Yitzhak
>>> -----------------------------
>>> Yitzhak Mandelbaum
>> 
>> The extunix module has a trifold solution for this:
>> 
>> * First there is the ExtUnix.All module that has all functions in
>>  it. Functions that are not available raise Not_available with function
>>  name as an argument.
>> 
>> * Second there is ExtUnix.All.have : string -> bool option
>> 
>>  (** [have name]
>>    @return indication whether function [name] is available
>>    - [Some true] if available
>>    - [Some false] if not available
>>    - [None] if not known
>> 
>>    e.g. [have "eventfd"]
>>  *)
>> 
>> * Third there is ExtUnix.Specific containing only functions available on
>>  this platform.
>> 
>> MfG
>>        Goswin
>> 
>> --
>> 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
>> 
> 
> 
> -- 
> 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
> 

-----------------------------
Yitzhak Mandelbaum

Re: [Caml-list] optional functions in modules

[David Rajchenbach-Teller]

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

On 5/17/12 7:43 PM, Yitzhak Mandelbaum wrote:
> Thanks to everyone who responded.  FWIW, I found the argument in favor of options most compelling as a general approach.
> 
> Yitzhak
> 

Note that there is a drawback to that approach: loss of polymorphism.

# let mmap = Some List.map;;
val mmap : (('a -> 'b) -> 'a list -> 'b list) option = Some <fun>

# let mmap2 = match mmap with | None -> failwith "Nope" | Some x -> x;;
val mmap2 : ('_a -> '_b) -> '_a list -> '_b list = <fun>

I suspect that first-class modules can help here, but I have not really
had time to toy with them yet.

Cheers,
 David


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [Caml-list] optional functions in modules

[Gabriel Scherer]

You can regain that polymorphism at a moderate efficiency cost by eta-expanding:

   let mmap2 f = match mmap with | None -> failwith "Nope" | Some x -> x f;;
   val mmap2 : ('a -> 'b) -> 'a list -> 'b list = <fun>

On Fri, May 18, 2012 at 5:24 PM, David Rajchenbach-Teller
<David.Teller@ens-lyon.org> wrote:
> On 5/17/12 7:43 PM, Yitzhak Mandelbaum wrote:
>> Thanks to everyone who responded.  FWIW, I found the argument in favor of options most compelling as a general approach.
>>
>> Yitzhak
>>
>
> Note that there is a drawback to that approach: loss of polymorphism.
>
> # let mmap = Some List.map;;
> val mmap : (('a -> 'b) -> 'a list -> 'b list) option = Some <fun>
>
> # let mmap2 = match mmap with | None -> failwith "Nope" | Some x -> x;;
> val mmap2 : ('_a -> '_b) -> '_a list -> '_b list = <fun>
>
> I suspect that first-class modules can help here, but I have not really
> had time to toy with them yet.
>
> Cheers,
>  David
>

Re: [Caml-list] optional functions in modules

[Nicolas Braud-Santoni]

It's quite different : the exception will be thrown whenever the
function is applied.
However, I can't find how to fix this without loosing polymorphism right now.

2012/5/18 Gabriel Scherer <gabriel.scherer@gmail.com>:
> You can regain that polymorphism at a moderate efficiency cost by eta-expanding:
>
>   let mmap2 f = match mmap with | None -> failwith "Nope" | Some x -> x f;;
>   val mmap2 : ('a -> 'b) -> 'a list -> 'b list = <fun>