Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Dynamically evaluating OCaml code
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Kenneth Knowles <kknowles@b...>
Subject: Re: [Caml-list] Dynamically evaluating OCaml code
On Thu, Apr 08, 2004 at 01:39:57PM -0500, John Goerzen wrote:
> However, while perhaps someone could design a more advanced String.sub
> that can count backwards from the end of the string (I posted one such
> example) in one line of the code, it may still have merit being in the
> library.  Otherwise, everyone will probably end up writing a function
> anyway (since it's too ugly to use inline with any frequency) and this
> reduces the efficiency of programming with OCaml.

I agree that String.sub is not the exhaustive solution; a variety of ways to
select substrings is nice, and not provided in the standard library.  A huge
standard String module is still bad, so I wonder if anyone has submitted a
coherent patch with 2 or 3 fundamentally different string functions and strong
rationale?  Probably most people whine about how their 2000 line string library
isn't accepted into the standard, when the addition of less than 100 lines is
what String might need to be gracefully augmented.

Getting deep into the "what should go in the standard library" isn't what I want
to do - I just want to express general approval of small standard libraries with
functions that combine well.  I think a very beautiful solution to complaints
would be to have one fully independent library per module in the standard
library - one could easily make a complete String, List, Array, or Set library,
with useful, but non-orthogonal helper functions.

In particular, a comprehensive Date library would be very useful, since it is
not in the standard libs at all.  I think ocamli18n intended to solve this, but
I haven't tracked the project.

I haven't checked the Cstr library that was linked, so maybe it has some nice
stuff.

> My simplified example does not necessary represent all possible ones.
> Some people may be dealing with 500MB structures where going back and
> forth between lists and arrays is not even an executable option.

True, but let's not be silly.  A 500 MB structure is probably going to be its
own animal, not simply an array or list... and I've seen a lot of talk about
Persil on the mailing list for mixing on-disk and in-memory storage, which might
be appropriate.

Kenn

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