caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Gerd Stolpmann <info@gerd-stolpmann.de>
To: Alain Frisch <alain@frisch.fr>
Cc: caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] Immutable strings
Date: Wed, 09 Jul 2014 20:04:04 +0200	[thread overview]
Message-ID: <1404929044.4384.159.camel@e130> (raw)
In-Reply-To: <53BD49B1.6000203@frisch.fr>

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

Am Mittwoch, den 09.07.2014, 15:54 +0200 schrieb Alain Frisch:
> On 07/08/2014 02:24 PM, Gerd Stolpmann wrote:
> > It will create confusion even with actively maintained code bases. What
> > could help here is very clear communication when the change will be the
> > standard behavior, and how the migration will take place.
> 
> It's a very different kind of criticism from your initial point about 
> the decision of going into the current direction.

Right, but the question how the user process will look like is just the
next one. The design of the change so far is minimalistic, and it is
obvious that some abstraction is missing, and my only explanation is
that there wasn't a consensus in the OCaml team (but that's just a wild
guess). I don't want to say that the OCaml team is ignoring any
problems, but it looks like the missing abstraction is somehow offloaded
to the users, namely whether it is needed at all in the stdlib (maybe
nobody is complaining), or which style is preferred. (I just want to say
that there is IMHO a connection between the minimalistic design, and the
social embedding.)

>   Point taken: the 
> development team will need to communicate about the expected timeline 
> and migrate path.  But note that 4.02 is not even out, and since the 
> default behavior is the previous one, there is no hurry, and it's fine 
> if people wait a few months before trying the new mode.

My thinking here is that 95% of the users will have no problems at all
when they convert their programs. It's the other 5% for which the
current design is not really sufficient. Let's just hope these users
aren't immediately discouraged when they find it out.

>    It doesn't 
> seem crazy to wait for some early user feedback and synchronize with 
> them before deciding on a more precise plan for the wider community. For 
> instance, you feedback about porting ocamlnet is quite useful and the 
> current discussion shows that several solutions compete and need further 
> thought.  Without the new compiler switch, this discussion would not 
> have taken place.

Fully agreed.

> > I think it would be quite important to have that in the stdlib:
> >
> >   - This sets a standard for interoperability between libraries
> >   - The stdlib can exploit the details of the representation
> >   - It would be possible to use stringlike directly in C interfaces
> 
> Note that if it goes to stdlib, one cannot refer to bigarrays.  (One 
> might want to have bigarrays in stdlib, but we are not there yet.)

Right, but this isn't a big deal. (Bigarray also uses Unix.file_descr,
but this dep is easy to work around by anchoring file_descr in
Pervasives.)


Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
My OCaml site:          http://www.camlcity.org
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  reply	other threads:[~2014-07-09 18:04 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-04 19:18 Gerd Stolpmann
2014-07-04 20:31 ` Anthony Tavener
2014-07-04 20:38   ` Malcolm Matalka
2014-07-04 23:44   ` Daniel Bünzli
2014-07-05 11:04   ` Gerd Stolpmann
2014-07-16 11:38     ` Damien Doligez
2014-07-04 21:01 ` Markus Mottl
2014-07-05 11:24   ` Gerd Stolpmann
2014-07-08 13:23     ` Jacques Garrigue
2014-07-08 13:37       ` Alain Frisch
2014-07-08 14:04         ` Jacques Garrigue
2014-07-28 11:14   ` Goswin von Brederlow
2014-07-28 15:51     ` Markus Mottl
2014-07-29  2:54       ` Yaron Minsky
2014-07-29  9:46         ` Goswin von Brederlow
2014-07-29 11:48         ` John F. Carr
2014-07-07 12:42 ` Alain Frisch
2014-07-08 12:24   ` Gerd Stolpmann
2014-07-09 13:54     ` Alain Frisch
2014-07-09 18:04       ` Gerd Stolpmann [this message]
2014-07-10  6:41         ` Nicolas Boulay
2014-07-14 17:40       ` Richard W.M. Jones
2014-07-08 18:15 ` mattiasw
2014-07-08 19:24   ` Daniel Bünzli
2014-07-08 19:27     ` Raoul Duke
2014-07-09 14:15   ` Daniel Bünzli
2014-07-14 17:45   ` Richard W.M. Jones
2014-07-21 15:06 ` Alain Frisch
     [not found]   ` <20140722.235104.405798419265248505.Christophe.Troestler@umons.ac.be>
2014-08-29 16:30     ` Damien Doligez

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=1404929044.4384.159.camel@e130 \
    --to=info@gerd-stolpmann.de \
    --cc=alain@frisch.fr \
    --cc=caml-list@inria.fr \
    /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).