Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Basile STARYNKEVITCH <basile@starynkevitch.net>
To: "caml-list@inria.fr" <caml-list@inria.fr>
Subject: Re: [oliver: Re: [Caml-list] Strings as arrays or lists...]
Date: Mon, 3 Mar 2003 22:32:30 +0100	[thread overview]
Message-ID: <15971.51694.912617.582567@hector.lesours> (raw)
In-Reply-To: <20030303210554.GA5245@force.stwing.upenn.edu>

>>>>> "William" == William Lovas <wlovas@stwing.upenn.edu> writes:

[...]

    William> You keep skirting around this question by saying that
    William> what he really wants is extensional polymorphism, but
    William> overloading is not the only way to get the same syntax
    William> for strings and arrays.  Another way is to have them
    William> simply *be the same thing*.  That is, is there any deep
    William> reason not to do

    William>     type string = char array

    William> right up front, and inherit all the Array module's
    William> functions?  We could still keep a String library with all
    William> string-specific functions in it, but we'd gain a
    William> unification of many function implementations, and the
    William> same notation for random access to boot.

It could be interesting, but I guess that adding such specifical
implementation may seriously increase the compiler complexity and
could even explode (or at least seriously increase) the generated
code.

    William> You mentioned that strings are packed -- meaning that
    William> they're more efficient than generic arrays?  But doesn't
    William> O'Caml already have compiler magic for making float
    William> arrays fast and efficient?  Why not just do the same
    William> thing for char arrays?

I do share the wish but would tend to believe that it is programmer
time consuming. For example, grep-ing (case insensitively) for float
in the compilers gives a lot of occurrences.

Perhaps a long term dream might be to be able to provide specific
implementations for different instances of variable types,
e.g. different implementations for sets of float versus sets of object
instances.

Regarding strings I would tend to think that separating mutable
strings from read-only strings could be useful, and 16bits or 32bits
unicode strings might be desirable.

Does any one have ideas on how to implement localisation &
internationalisation of applications?


-- 

Basile STARYNKEVITCH         http://starynkevitch.net/Basile/ 
email: basile<at>starynkevitch<dot>net 
alias: basile<at>tunes<dot>org 
8, rue de la Faïencerie, 92340 Bourg La Reine, France

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


  reply	other threads:[~2003-03-03 21:32 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-03 18:28 Oliver Bandel
2003-03-03 20:10 ` brogoff
2003-03-03 21:05   ` William Lovas
2003-03-03 21:32     ` Basile STARYNKEVITCH [this message]
2003-03-03 22:10     ` [Caml-list] [RANT] String representation (was: Strings as arrays or lists...) Nicolas George
2003-03-04 12:43       ` Diego Olivier Fernandez Pons
2003-03-04 16:14         ` William D. Neumann
2003-03-04 18:38           ` Xavier Leroy
2003-03-04 18:50             ` William D. Neumann
2003-03-04 19:01         ` Nicolas George
     [not found]       ` <Pine.A41.4.44.0303041312560.4431978-100000@ibm1.cicrp.juss ieu.fr>
2003-03-04 13:49         ` David Chase
2003-03-04  0:20     ` [oliver: Re: [Caml-list] Strings as arrays or lists...] Issac Trotts
2003-03-04  0:24       ` Alain.Frisch
2003-03-04  1:06         ` Issac Trotts
2003-03-04  0:39       ` Olivier Andrieu
2003-03-04  0:39     ` brogoff
2003-03-03 21:40   ` [Caml-list] extensional polymorphism james woodyatt
2003-03-04  1:10     ` brogoff
2003-03-04  2:04       ` james woodyatt

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=15971.51694.912617.582567@hector.lesours \
    --to=basile@starynkevitch.net \
    --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