From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id VAA20330; Wed, 11 Jul 2001 21:30:31 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id VAA20400 for ; Wed, 11 Jul 2001 21:30:30 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f6BJUT903684; Wed, 11 Jul 2001 21:30:29 +0200 (MET DST) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id VAA20399; Wed, 11 Jul 2001 21:30:29 +0200 (MET DST) Date: Wed, 11 Jul 2001 21:30:29 +0200 From: Xavier Leroy To: Berke Durak Cc: caml-list@inria.fr Subject: Re: [Caml-list] String.unescaped and some other little pitiful laments Message-ID: <20010711213029.B20109@pauillac.inria.fr> References: <20010710200734.B10265@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20010710200734.B10265@localhost.localdomain>; from berke@altern.org on Tue, Jul 10, 2001 at 08:07:34PM +0200 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > Also I'd like to see those horrible functions returning parameters in > global variables be eradicated, such as those that can be found in the Str > (regular expression) module. Yes, the Str module is a thorn in my side: not only the API is bad (too much reliance on global state), but the underlying implementation (the GNU regexp library) is awful -- on moderately complex regular expressions, it can get really slow, or just abort on an exception. (Stallman et al usually write better code than this!) I'd really love to get rid of it, but as usual I'm obsessed with backward compatibility, and couldn't find an existing regexp library that recognizes the same regexp language as Str -- so that we could easily keep the old Str interface as a wrapper around the new interface. So, this is a question to the developers of alternate regexp libraries: how hard would it be to implement an Str emulation on top of your libraries? If you're interested, we can pursue this discussion by private e-mail. > Many people on this list are talking lighthearted about functions such > as Obj.magic. These functions are pure evil. It makes me sorry to see > that my favorite language has an unsafe and ugly type casting > function. Modules using such features should be flagged as > ``evil'', and the use of these functions should not be publicly > advocated. But they are not! Not by us, at least. You'd be hard-pressed to find any mention of the Obj module in the OCaml docs. There are a couple of legitimate uses of Obj.magic in the toplevel loop, and a few other uses (e.g. in ocamlyacc-generated parsers) that could be removed with a little more work. But, yes, I'd advise all OCaml programmers to never, never use Obj.magic. In particular, this can lead to incorrect code being generated by the ocamlopt compiler (because it fools its type-dependent optimizations). A few years ago, I spent a couple of hours tracking an obscure GC bug in a program sent by an user as part of a bug report. It turned out to be an incorrect use of Obj.magic in the source code... Since then, I first grep for Obj.magic in every bug report sent to us! > PS. What is the purpose of the "uses unsafe features" flag in .cmo > files ? (it can be seen in the output of the "objinfo" program in the > tools/ directory of the compiler). I've made a test program using > unsafe features such as Obj and Array.unsafe_get but the flag wasn't > set. It's poorly named. Actually, it tracks whether the module declares external primitives (using the "external" syntax). It's used for type-safe dynamic loading of compiled bytecode: the Dynlink loader lets you check that the bytecode was compiled against a set of known interfaces (presumably not including unsafe operations such as Obj.magic or Array.unsafe_get), but there is also the risk that the bytecode simply declares these operations itself using well-chosen "external" declarations. So, Dynlink can also track "external" declarations and prohibit them. - Xavier Leroy ------------------- 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