caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jon Harrop <jon@ffconsultancy.com>
To: caml-list@yquem.inria.fr
Cc: "Vincent Hanquez" <tab@snarc.org>,
	"Bünzli Daniel" <daniel.buenzli@erratique.ch>,
	"caml-list List" <caml-list@inria.fr>
Subject: Re: [Caml-list] [OSR] Exceptionless error management
Date: Tue, 5 Feb 2008 13:46:29 +0000	[thread overview]
Message-ID: <200802051346.29869.jon@ffconsultancy.com> (raw)
In-Reply-To: <20080205110641.GA4712@snarc.org>

On Tuesday 05 February 2008 11:06:41 Vincent Hanquez wrote:
> 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.

Exactly. Whatever everyone wants to call it, the stdlib desperately needs 
improving and tacking on more third party libraries (ExtLib, AnnexLib, 
PagodaCore, Baird, ...) is not the way to do it.

I personally want to see lots of simple, minimal improvements to the stdlib 
but I'm afraid that lots of other people are going to want to push their 
untested Obj-riddled codebases into any improvement, which scares me.

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

Jacques Garrigue's libraries (e.g. LablGL) do and they work very well.

This is one area where OCaml is much nicer than F# (inherited from .NET). For 
example, in F# you write CullFace.Both or ControlStyles.DoubleBuffer but in 
OCaml you just write `Both or `DoubleBuffer.

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

I would recommend avoiding recursive polymorphic types in library APIs but I 
have no problems with small, simple, non-recursive definitions like [ `Value 
of 'a | `Exception of 'b ].

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e


  reply	other threads:[~2008-02-05 14:13 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
2008-02-05 13:46         ` Jon Harrop [this message]
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=200802051346.29869.jon@ffconsultancy.com \
    --to=jon@ffconsultancy.com \
    --cc=caml-list@inria.fr \
    --cc=caml-list@yquem.inria.fr \
    --cc=daniel.buenzli@erratique.ch \
    --cc=tab@snarc.org \
    /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).