[oliver: Re: [Caml-list] Strings as arrays or lists...]

[oliver@first.in-berlin.de (Oliver Bandel)]

ooops,

forgotten to Cc: to the list.


Ciao,
   Oliver

----- Forwarded message from oliver -----

To: brogoff@speakeasy.net
Subject: Re: [Caml-list] Strings as arrays or lists...

On Mon, Mar 03, 2003 at 09:12:32AM -0800, brogoff@speakeasy.net wrote:
> Yes, Xavier is right here, and I apologize for posting an "explode" function 
> on this list. I'll appeal for leniency, mentioning that I didn't post 
> "implode", and that I only posted the former function to demonstrate that 
> it could be done, and to point out that one of the many reasons strings as 
> char lists is wrong as a basic type is that you get an abstraction inversion. 


What is an abstraction inversion?
Sounds very interesting, but I don't understand, waht this means.


What I first have written about the string-stuff,
was: It's not FP-like, but I also would be happy
with a syntax, that would allow me, to use Array-functions
for the Strings.

If there maybe is a typing-reason, why not strings AND
arrays should have same syntax
( e.g. both <name>.[index]  or both <name>.(index) )
then maybe it would be possible to add the typical
Array-functions (or List-functions) to the String-Library?

Why not converting a string to a list with
String.to_list
or to an array with
String.to_array

Arrays can be converted with Array.to_list (or vice versa
with Array.of_list). Why not such stuff for strings?
If they are already array-like, why not using such
functions?

Why not using a  String.map  for application of
char-based functions to each char?

To write more abstract String-manipulation is also ok,
so that the char-wise stuff would be on a lower level
(inside the library, maybe implemented in C or is some
imperative Ocaml-stuff, which the user of the library does not
see).

OK, strings are not char-lists, and they are not char-arrays.
At least not to the user.


But it would help, to have such powerful functions like

<Module>.map
<Module>.iter
<Module>.fold_left
<Module>.fold_right
<Module>.filter

Where Module here would be one of:  Array, List, String.

If this is not very senseful, because the functions
are only applied to char#s and not to any type ('a)
(like in Array- or List-module), and this powerful
functions are bored, when used only at one type (char),
then it would make sense to have at least these two
functions in the Array.module:

Array.to_string
Array.of_string

If you think, this is not necessary in the stdlib,
because it is easy to convert strings to arrays
(very similar notation/syntax), then I can answer:
Well, it is also easy to implement functions like
Array.to_list
Array.of_list

So why having them in the stdlib?

If there are conversion-functions between the
fundamental data-types (Array.to_list, Array.of_list,
string_of_int, string_of_float, int_of_string, int_of_float)
why are there no conversions between (at least) string and Array?



Ciao,
   Oliver

P.S.: Another thing, where I think about, is:
      Shouldn't it be possible to handle
      strings as Lists for the user, even if it is implemented
      array-based somewhere deep in the basement of the code-base?
      So, that it would be possible to handle strings like
      [char], even if they are implemented array-based (and therefore
      perfromant)?
      Isn't one of the major goals of Languages like Ocaml,
      to have a clear distinction between implementation and interface?

      (Or does your "abstraction inversion" here says "No!" to such
      a thing?)


P.P.S.: The reason, why I asked for R-Tree/R+-Tree/Quad-Tree-
        Implementation in Ocaml: They are very good tools for
        *very* highlevel textprocessing.

        So maybe some Tree-libraries would be a good thing for
        Ocaml, but IMHO such stuff is better suited on a COAN,
        and should not be part of the Ocaml-language/-standard-
        libraries itself.
        But it's good to have such libraries too, even if it
        should be relatively easy to implement it in Ocaml.
        I think, when some OCaml-gurus would implement them, they would
        be more performant and easy to use, than if any other
        Ocaml-programmer would write his/her own solution.
        And such basic (often called) stuff should be performant...


----- End forwarded message -----

-- 
  Why Ocaml is programmer's heaven?
     http://www.win.tue.nl/~lhol/projects/pargen/ocaml.html

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