From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 13698BC6B for ; Mon, 10 Dec 2007 17:33:23 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAEf5XEfAbSoIh2dsb2JhbACPZAEBAQgKKYEU X-IronPort-AV: E=Sophos;i="4.23,277,1194217200"; d="scan'208";a="5077395" Received: from einhorn.in-berlin.de ([192.109.42.8]) by mail2-smtp-roc.national.inria.fr with ESMTP; 10 Dec 2007 17:33:22 +0100 X-Envelope-From: oliver@first.in-berlin.de X-Envelope-To: Received: from einhorn.in-berlin.de (localhost [127.0.0.1]) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id lBAGXMUw014328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 10 Dec 2007 17:33:22 +0100 Received: (from www-data@localhost) by einhorn.in-berlin.de (8.13.6/8.13.6/Submit) id lBAGXLjs014326 for caml-list@yquem.inria.fr; Mon, 10 Dec 2007 17:33:21 +0100 X-Authentication-Warning: einhorn.in-berlin.de: www-data set sender to oliver@first.in-berlin.de using -f Received: from dslb-088-073-105-066.pools.arcor-ip.net (dslb-088-073-105-066.pools.arcor-ip.net [88.73.105.66]) by webmail.in-berlin.de (IMP) with HTTP for ; Mon, 10 Dec 2007 17:33:21 +0100 Message-ID: <1197304401.475d6a51d9c06@webmail.in-berlin.de> Date: Mon, 10 Dec 2007 17:33:21 +0100 From: Oliver Bandel To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Ask for a more efficient way to deallocate memory (full version) References: <39980.81.57.198.61.1197236388.squirrel@webmail.lpn.cnrs.fr> <95513600712091355j35c4fa65g40bbfce02303796a@mail.gmail.com> <475D2210.70708@Lpn.cnrs.fr> In-Reply-To: <475D2210.70708@Lpn.cnrs.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 X-Spam: no; 0.00; bandel:01 in-berlin:01 ocaml:01 unix-module:01 ocaml:01 opendir:01 readdir:01 high-level:01 allocating:01 opendir:01 unix-module:01 higher-level:01 coe:01 libs:01 imho:01 Zitat von Fabrice Pardo : [...] > 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!