caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: tab@snarc.org (Vincent Hanquez)
To: "Bünzli Daniel" <daniel.buenzli@erratique.ch>
Cc: caml-list List <caml-list@inria.fr>
Subject: Re: [Caml-list] [OSR] Exceptionless error management
Date: Tue, 5 Feb 2008 12:06:41 +0100	[thread overview]
Message-ID: <20080205110641.GA4712@snarc.org> (raw)
In-Reply-To: <9A13D5E1-E455-4019-B0BA-D8D7DD4CE49E@erratique.ch>

On Tue, Feb 05, 2008 at 11:26:00AM +0100, Bünzli Daniel wrote:
>> I can see lots of people are concerned by using polymorphic variant (and
>> I certainly agree with those), and people asking for a monadic approch
>> (haskell's either like).
>
> Still I think this is a little bit sad. Using polymorphic variants isn't 
> that bad at all as long as we just use the following _closed_ type [ `Value 
> of  ... | `Error of ... ].

imho, polymorphic variants ""weaken"" the type system and are a royal PITA
when something is wrong in the code and you need to find it.

for example something plain _stupid_ as:
returning or matching `VAlue instead of `Value

since it will be created "dynamicly" (you don't need to define it), ocaml
will be perfectly happy to return/match it, but you'll have a "weird" error
somewhere else:

# let f x : [`Error | `Value of int ] = if x <= 0 then `Error else `Value x;;
val f : int -> [ `Error | `Value of int ] = <fun>

# let g y = match f y with `Error -> "error" | `VAlue x -> "value"

This pattern matches values of type [< `Error ]
but is here used to match values of type [ `Error | `Value of int ]
The first variant type does not allow tag(s) `Value

with normal variant i'll have a nice error:

	Unbound constructor VAlue

And that's just one thing on the list of 'against' polymorphic variants;
i'm sure people have their own set of bad experiences with polymorphic
variants.

> This would allow us to move forward despite that 
> fact that Pervasives is frozen (and no I'm not interested in forking it). 

This is not "forking", for me that's patching.
We _can_ provide the same interface+improvements (no breaking of
previous programs) easily _without_ forking with minimal intrusion as a
patchqueue on top of ocaml stdlib. the compiler might be forbidden
fruit (license, INRIA expertise, etc) and that's probably a bad idea to
fork it anyway, but stdlib should be where we could add major improvement
to the language (a rich and nice stdlib just like all other languages).

Also a proposal that define exceptionless without having the core
library like Hashtbl, Map, Set, List, conforms to this "standard" is
just bound to failure. Either they are modified (bad idea for
compability), Copied+forked into another module (nobody going to use it
+ you're forking some of the stdlib) or the proposal is moot.

> Sure we can have monadic stuff, new types, new infrastructure etc. but I 
> try to design solely within the constraint of the ocaml system as it stands 
> because I know that's something has been there for more than 10 years and 
> continues to be maintained.
> Polymorphic variants have the advantage to 
> allow us to standardize across modules without needing changes to the ocaml 
> system.

they might be standard in ocaml (as in available through the compiler),
but not much library use them.

people should have that in mind when trying to propose them as an OSR;
lots of people are not confortable with them imo.

-- 
Vincent Hanquez


  reply	other threads:[~2008-02-05 11:06 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-31  8:55 Bünzli Daniel
2008-01-31  9:57 ` [Caml-list] " Till Varoquaux
2008-01-31 11:01   ` Bünzli Daniel
2008-01-31 14:09     ` Andrej Bauer
2008-01-31 14:16       ` Michael Ekstrand
2008-01-31 19:28         ` David Teller
2008-01-31 19:59           ` Michael Ekstrand
2008-01-31 20:05           ` blue storm
2008-01-31 20:03       ` Bünzli Daniel
2008-01-31 20:25         ` David Teller
2008-01-31 20:40           ` David Teller
2008-01-31 21:16           ` Bünzli Daniel
2008-01-31 21:31             ` David Teller
2008-01-31 21:35           ` Jon Harrop
2008-01-31 22:01           ` Christophe Raffalli
2008-02-01  7:27         ` Michaël Grünewald
2008-02-01  7:47           ` Bünzli Daniel
2008-02-01 10:50             ` Till Varoquaux
2008-02-01 11:31               ` Bünzli Daniel
2008-02-01 15:59                 ` Vincent Hanquez
2008-02-01 18:37                   ` Bünzli Daniel
2008-02-01 19:43                     ` Vincent Hanquez
2008-02-01 16:04                 ` David Allsopp
2008-02-01  8:31 ` David Teller
2008-02-01 12:19   ` Yaron Minsky
2008-02-05 10:00 ` David Teller
2008-02-05 10:12   ` Vincent Hanquez
2008-02-05 10:26     ` Bünzli Daniel
2008-02-05 11:06       ` Vincent Hanquez [this message]
2008-02-05 13:46         ` Jon Harrop
2008-02-05 11:36       ` Frédéric van der Plancke
2008-02-06  8:45       ` Michaël Grünewald
2008-02-08 13:09         ` Bünzli Daniel
2008-02-05 14:12     ` David Teller
2008-02-11  8:12 ` David Teller
2008-02-11  9:09   ` Bünzli Daniel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080205110641.GA4712@snarc.org \
    --to=tab@snarc.org \
    --cc=caml-list@inria.fr \
    --cc=daniel.buenzli@erratique.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).