From: John G. <jgo...@co...> - 2004-04-26 13:22:42
|
On Mon, Apr 26, 2004 at 09:34:42AM +0200, Nicolas Cannasse wrote: > Some comments : > - the ConfigParser is nice, but lacks some persitency and typing. I would By this I assume you mean something akin to Marshal, where you can throw an OCaml object at it and always get back the same one (as opposed to the getint(), getbool(), etc. that are in ConfigParser). One problem with that approach is that is goes against the easily user-editable goal, where users should be able to just put values in the config file and not worry too much about the app. Note, though, that ConfigParser does define functions to write out the in-memory structure to a file or string. > IMHO, it would be nice to have some persistant storage for configuration > data which would be stored in a single user database file and made > accessible for all ocaml programs ( a little like a portable windows > registry ) Perhaps some would like this, and perhaps ConfigParser could be modified to serve that purpose. I, OTOH, would not like that. In general, I think that users do not care what language a program is written in if it does what they want. Users are more likely to think "Where do I go to configure app foo?" than "What language is app foo written in, and where does it store config data?" Moreover, a shared file like that brings in locking-related issues that are not necessarily present with individual app-specific configuration files. It also goes against the grain of what people expect on a *nix system and makes it more difficult for people to write tools to generate config files for a given app in an automated fashion. > - Hashtbloper are pure syntactic sugar and each user should be free to > define its own bindings. That's true, and nobody has to open Hashtbloper. In fact, the reason I defined the *oper modules is so that people can get the functionality without the operators if they wish. > - you will be happy to know that most of the functions in Hashtblutil are > already in ExtLib extHashtbl module I took a look... one thing that is unclear to me is the relationship between ExtHashtbl.Hashtbl and the standard Hashtbl. On the surface, from the API docs, they look incompatible. Is that true? The other thing is that those functions return Enums. While it looks easy enough to convert those to lists, I'd probably wind up defining my own functions to do that anyway. > - current Ocaml Lexer is providing (at last) support for line numbers in > error messages (see Lexing.position) Yes, but it does not work. The line number information in position is never updated by the ocamllex code. To be more specific, pos_lnum is never updated. And, when you think about it, that makes sense; a line may be defined differently in different lexers. Thus the countline function that updates a Lexing.position. The raise_syntax_error function does indeed use Lexing.position itself. > - splices should be interfaced with Enums in order to scale well with the > increasing number of types to support (string, list, array, bigarray, > dynarray, hashtbl..... ) Interesting approach there. Will have to think on that one a bit more. > If you think I forgot something that should definitly be added to the > ExtLib, please send back an email. The main ones that occur to me are: Listutil.sub Listutil.replace Strutil.strip, lstrip, rstrip (These are *not* the same as the chop functions in ExtString) Strutil.split (It is defined in terms of Str.split_delim in MissingLib but could probably be implemented without it for Extlib) > > * Client-side IMAP library > > * Asynchronous I/O system (patterned after www.twistedmatrix.com for > > Python) > > Theses both are nice. > Async IO might be tricky to implement correctly in pure caml. I have not yet looked into that much. I guess it will depend on how powerful the Unix module is. Sigh; my hopes are not high for that one. Which is a pity, given the poor state of threading in OCaml at the moment, too. -- John |