Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Str.string_match raising Invalid_argument "String.sub" in gc
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Gerd Stolpmann <info@g...>
Subject: Re: [Caml-list] standard regex package
On Thu, 23 Aug 2001, Brian Rogoff wrote:
>On Thu, 23 Aug 2001, Miles Egan wrote:
>[... snip ...]
>> These would all be very nice, I agree, but I also think we need something better
>> than str and sooner than all these things could be implemented.  Maybe some kind
>> of transitional scheme would work?
>
>I agree, from a pragmatic point of view a better regexp matcher would make OCaml 
>significantly sexier to all of those poor deluded Python and Perl programmers. 

Agreed, too.

>The other stuff can come later. I think Markus has a very good point about 
>some distutils (Python) like facility being even more important. Once such
>a framework is in place we can have an OCaml CPAN. Last time I looked findlib 
>ran only on Unix, which is a big problem. 

When I developed findlib I had something like CPAN in mind. I started it when I
downloaded several 3rd party packages, and all had a different installation
routines I had to modify for my purposes. For those who don't know: You can
install almost every 3rd party Perl package by simply doing

perl Makefile.pl
make
make test
make install

It is simple to do, and that's an important aspect of the success of Perl (a
language which is nothing without CPAN).

I hope we will have CCAN. Of course, one precondition is a standard package
structure, and I can imagine the findlib tool could be an important part of it
(for a description see 
http://test.ocaml-programming.de/packages/documentation/findlib/).

Currently, findlib runs only on Unix (including cygwin), but this is mainly
because I have no native Windows installation on which I could test it.
Especially, I have removed all shell scripts (it is now purely programmed in
OCaml), and it is only a question of fixing details. (And of writing a
replacement for "configure".)

>On the subject of "social tools", the program Neel is looking for is this one 
>
>http://www.lri.fr/~filliatr/ocamlweb/index.en.html
>
>and Hevea of course. There is also OCamlDoc, which seems quite nice too,
>but ocamlweb is used in a few more libraries I think. 
>
>> While were on the subject of beginner usability, it seems to me that if dynamic
>> loading of c-libraries is still a ways off, it might be nice to build the unix
>> module into the toplevel at install time.
>
>A better apporach might be to ape Python and the SML Basis Library by providing a 
>generic "OS" module which abstracts at least Unix/Win/Mac away. I would
>prefer this, since I feel silly using Unix.<blah> on a Windows box :-).

"Unix" is only a name for an API (and not for a technology or a familiy of OSs),
and it is clearly MS's fault not to be Unix-compliant (other operating systems
originating in different worlds are, e.g. MVS includes a Unix API). But that's
politics... (MS had some times ago a Posix mode in NT but nobody used it, so I
think there are no real technical reasons.)

Being more abstract has also disadvantages because you don't know which system
calls are done for one abstract call. (Ironically, Perl tried to abstract from
the system calls, i.e. _the_ language used by system hackers. And Perl shows
clearly that this way is wrong. For example, Perl's flock is one of flock,
fcntl, or lockf, resulting in total confusion which semantics the program can
expect.)

So I think having a Unix module with Unix semantics is right.

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 45             
64293 Darmstadt     EMail:   gerd@gerd-stolpmann.de
Germany                     
----------------------------------------------------------------------------
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr