chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Chicken-users] redefinitions


From: Michele Simionato
Subject: [Chicken-users] redefinitions
Date: Fri, 23 Jul 2004 08:19:30 +0200

Hi Felix and folks! and happy birthday to Chicken!

Chicken made a lot of progress in these four years and I am
sure more will follow in the near feature :)

I take the occasion to ask for a feature request.

Suppose I am writing a script using an external 
library written by somebody else and that i) the library is badly
documented or ii) I have not read the documentation carefully
or iii) I didn't look at the source code.  Suppose that by chance
the external library define a top-level name which clashes
with a top-level name used by my script. Then disasters may
happens and it may be not easy  to debug them.

Here is a trivial example:

(define TAB-WIDTH 4)
  
(define (print-tab-width)
  (print TAB-WIDTH))      

(do-something)

(if condition (load "text-processing-library")
              (load "another-text-processing-library"))

(print-tab-width)

I would expect (print-tab-width) to return 4, but if the
external library redefine  TAB-WIDTH  to be 8 for instance,
I would get unexpected results.

Of course experienced programmer are aware of this
and they just do not use globals, they enclose their
library in a safe lexical scope. But this is NOT a solution,
it is a workaround. 

Moreover sometimes you want to redefine global names,
even builtins, in order to do magic things, but doing so will
propagate the surprising behavior to the unlucky users of your library
:-( This is a problem of Scheme, not of
Chicken, but maybe Chicken could improve on it.

There are various options that may or may not conflict with 
R5RS.

One option is to make globals available only in the module
where they are defined, i.e. not exported unless explicitely
declared. But this means a module system and use some
import mechanism different from "load", so let me not
pursue that. 

A (apparently) simpler solution would be to warn the user
if a name is redefined. I mean 

(define TAB-WIDTH 4)
(define TAB-WIDTH 8) ; error

should raise a redefinition error (that would be my preferred
behavior) or at least print a redefinition warning (if raising
the error would be too radical). The right way to
redefine things should be via set! :

(define TAB-WIDTH 4)
(set! TAB-WIDTH 8) ; ok

I was told on comp.lang.scheme months ago that the reason
why 

(define TAB-WIDTH 4)
(define TAB-WIDTH 8) 

raises no error in current Scheme is just convenience at
the REPL but I don't buy that argument.  It is just stupid,
i.e. for a very questionable "convenience" in the REPL 
you open the door for lots of potentially serious bugs.

So I want to know if there is some hope to get this
"fixed", at least having a warning when things are
redefined in the same lexical scoping using define
instead of set! (of course shadowing a name with internal 
defines or let is fine and should not raise any warning).

What do you think?

                                    Michele Simionato




reply via email to

[Prev in Thread] Current Thread [Next in Thread]