Re: [Caml-list] Ask for a more efficient way to deallocate memory (full version)

[Oliver Bandel <oliver@first.in-berlin.de>]

Zitat von Fabrice Pardo <Fabrice.Pardo@Lpn.cnrs.fr>:

[...]
> When using these kind of external C functions,
> OCaml seems then less comfortable to the programmer
> than reference counted languages.

I doubt that reference-count is the reason here.
perl also uses reference count, but Filehandles
and Dirhandles have to be closed with close / closedir.

So, a language that uses reference counting does not necessarily
handle file-/dir-handles.

There are different things you mix up.

BTW: The Unix-module it's name is "Unix"-module,
and it is not part of the so-called OCaml standard-lib.

And because it is used to access the Unix-API (hence it's name),
it should behave like a OCaml-binding to the Unix-API.
And this means: you have a opendir, a ´readdir and a closedir
function. And they behave like the Unix-API, as mentioned above.

When you come from C, use Unix-functions, and then go to
OCaml, you have the aequivalents there too.

If you want "safer" functions, write them (or use already existing
wrapper-libs, if they are there). But the need to have access to the
Unix-API is there, because it's system-near programming, and too much
High-level programmign around it, is not what one needs, when using
the system's API.

The discussion I mentioned in one of my ealrier mails
has brought in some arguments to the reason, why it is good,
not to make all the deallocation-things automatically.
I think one reason is overhead. But one reason more was
to have a separation of system-level and non-system level, but on that
point I'm quite unsure to get the arguments right from my memory.

If I have some time, I can look for the thread.
Possibly someone else has the link at hand.



[...]
>
> I have a new question now:
> What is the drawback if we keep hidden
> unsecure external functions

Unsecure?
No coredump, so it's secure.

If you need more and more and more RAM in your application and your
applications ays to you: "Sorry, all memory ehausted!",
is this an unsecure application?

Unsecure for me would be if the program throws an exception
that can't be caught ans is from a different level of programming.
If OCaml gives you a Unix-exception, when you wasted all your
filedescriptors, this IMHO is not unsecure. Unsecure in this case would
be, if you get a segmentation fault/ coredump, instead a clean
OCaml exception.



> (allocating out of the heap
> resources, as Unix.opendir),
> only publishing secure functions as "with_dir" ?

The Unix-module has the reason, that it gives you access to the system's
API. And the systems API is the systems API is the systems API.
If you need access to it, use Unix-module. If you use a higher-level
library, and do not have access to the system itself, you get more and
more bloat. I would think, this is one of the problems,
Java-programmers have... at least I remember people who had problems
with their super-super highleve network-API (including automatically
encrypted network connections) and nothing worked because of that
bloat.

What a good cure would it have been, to open a socket. ;-)


Ciao,
   Oliver

P.S.: Imagine a programming language that handles all the things you
want to have in the way you look for it... then people would say: Well,
what a bad language, that does not give me clear access to the system!
=> Then one possibly would have a problem to write system-near drivers,
where you need direct, clear access to the system, without many layers
between your language and the system!

Each thing has two (or more) sides. For me the things that OCaml offers
are the right things. OCaml is not perfect, but very very good.
And as I have done some Unix-programming, I find it not only ok, I find
it necessary to have clear access to the system, as I have also in C.
And I don't want to switch back to C, only because I want to have access
to the Unix-API! (And there is no limitation in writing coe around that
unix-module.

So: one can add wrapping code around, but you can't scratch code off, if
it is always there and bloats your libs!

It's not like in color-systems: you can use additive and subtractive
ways of mixing colors, but normally you only can add code, not throw it
away if it's built-in!