Re: [Caml-list] String.unescaped and some other little pitiful laments

[Xavier Leroy <Xavier.Leroy@inria.fr>]

> 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