On Thu, 23 Aug 2001, Gerd Stolpmann wrote:
> On Thu, 23 Aug 2001, Brian Rogoff wrote:
> >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).

Right, and our advantage is that the language is something without CCAN
(COAN? KOAN? :) but will be much more with it. 

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

Maybe the Consortium should just get you a few Windows machines? I'm
totally serious about that; once this hole is filled we can seriously talk 
about world domination. Err, benevolent world domination, of course. 

> 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".)
> 
[...snip...]

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

Really that API is "Posix", right? Yeah, I know, a small matter of spelling.

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

My memory is that NT's Posix mode was not truely Posix compliant, but it's
been a while and I could be wrong. 

> Being more abstract has also disadvantages because you don't know which system
> calls are done for one abstract call. 

I was thinking of "OS" as providing a high level view of a fairly generic
OS with a hierarchical file system. I agree that a Posix module with Posix 
semantics is also required, as is a WindowsNT/2000/XP or whatever they
decide to call it. Or to sound hip, a thick binding to generic OS features
and numerous thin bindings which are mostly just stubs for the system  
calls. 

-- Brian


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