RE: [Caml-list] Examples where let rec is undesirable

[David Allsopp <dra-news@metastack.com>]

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