Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Unix.file_descr -> int ???
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Max Kirillov <max630@m...>
Subject: Re: [Caml-list] Unix.file_descr -> int ???
On Wed, Jun 12, 2002 at 10:21:02AM +0200, Xavier Leroy wrote:
<...>
> WARNING!  Stereotype alert!  So, let's see, according to you, the
> virtues of type abstraction should be reserved to academia, while the
> "real world" (whatever the #$@%@ this means) is concerned about dirty hacks
> and nothing else?  What are you going to tell us next?  Women can't
> drive and men can't raise children? :-)
> 
> I can assure you that in an "industrial" programming setting,
> guaranteeing (some amount of) Unix-Windows source-code portability is
> a *lot* more important than the marginal Unix hacks you describe.

Why so strong? Unix is Unix, Win32 is Win32. That's
different system, and they both have specific things. Nobody
calls ACL or multi-threaded file storage (or how they
called), or DDE, "marginal Windows hacks". So why do you
call some things "marginal hacks" just because MS didn't
bother to implement them? If you want throw away all of Unix
weirdness, you better should throw away Unix itself, or your
come into risk of turning it into DOS. That's not good to
use under-system just because it's "right way".

I think that there is a lot of things which are not
portable. And there are a lot of progs not intended to be
portable. Btw, Unix module contains tc* functions, with all
their non-potrability. Why did you included them?

If asked, I would say that there should be module IO,
presenting the higher abstraction level for interaction with
the system, and the lower-level modules Unix, Win32, and so
on... The first requires some design, but is better than be
sticked to castrated unix.

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