ivan chollet wrote: > Sorry Richard I should have elaborated a bit more. > I guess there are a couple of examples in the literature, but one > of them comes to my mind, consider the following code snippet: > > let fd = Unix.open "myfile1" ... in > let fd = Unix.open "myfile2" ... in > ... (some code) > Unix.close fd
I got stung by this kind of thing a few years ago (no resource leaking, just referring to a variable which had been shadowed and wasn't the string/list I thought it was - I'm capable of being very dim). I posted about it in 2008 - http://caml.inria.fr/pub/ml-archives/caml-list/2008/08/41f896b99ecf9a84b3f2e977bbc4e232.fr.html My own determination was that variable shadowing is fine as long as the type changes - because in most cases I found that errors were then caught by the type checker and the number of cases where I had to make variable names differ where I hadn't before was low enough. I've quickly chucked the scripts at www.metastack.com/ocaml/checkshadow.tar.gz (the camlp4 filter is Gabriel's: http://bluestorm.info/camlp4/dev/pf_shadow/list.php). The only problem is that the camlp4 filter doesn't handle [if] expressions correctly, but it works by saying (for foo.ml): ocamlfind ocamlopt -c -annot -package pf_shadow -syntax standard foo.ml && checkShadow foo [pf_shadow.cmo is built with ocamlfind ocamlc -syntax camlp4o -package camlp4.lib,camlp4.quotations -c pf_shadow.ml and checkShadow with ocamlfind ocamlopt -c -package unix checkShadow.ml] and emits warnings if it detects variable shadowing of the same type. I hasten to add, this was all done to deal with a personal deficiency - IMHO the language itself should not enforce this behaviour. I too find the complete ban on variable shadowing in other languages intensely irritating (especially when it's even between separate scopes within the same function) David -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
