Redefinition doesn't work

Redefinition doesn't work

[Mattias Waldau]

One of the reason of me liking OCaml is the interactive top level. However,
it is a bit messy always remember to redefine all functions that depend of
the function you just corrected.

For example below, f2 doesn't notice the redefinition of f1, even if the
types of the new and old definition of f1 are the same.

The last language I used that had this feature was Forth, and that was 20
years ago, we used 8Kb of memory and a 6502. These 8 Kb contained both the
interactive compiler, the program, and the data.

What is the reason for this misfeature?


# let f1 () = 10;;
  val f1 : unit -> int = <fun>
# let f2 () = (f1 ()) * 10;;
val f2 : unit -> int = <fun>
# f2 ();;
- : int = 100
# let f1 () = 20;;
val f1 : unit -> int = <fun>
# f2 ();;
- : int = 100
#

----
Mattias Waldau

Re: Redefinition doesn't work

[Pierre Weis]

> One of the reason of me liking OCaml is the interactive top level. However,
> it is a bit messy always remember to redefine all functions that depend of
> the function you just corrected.

You just have to use a very simple rule: reload your source file after
each correction (use #use "filename.ml";;).

> For example below, f2 doesn't notice the redefinition of f1, even if the
> types of the new and old definition of f1 are the same.

Yes, as you know this is static binding.

> The last language I used that had this feature was Forth, and that was 20
> years ago, we used 8Kb of memory and a 6502. These 8 Kb contained both the
> interactive compiler, the program, and the data.

So what the point with the memory and the processor ?

> What is the reason for this misfeature?

This is not a misfeature, but an extremely desirable property: a sound
theoretical fundation for the binding rule of identifiers in the
language. This rule means that every identifier in a program is bound
before the point of use. This is simple to explain and clear to
understand. Furthermore it allows the static verification of type
correctness.

Best regards,

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://cristal.inria.fr/~weis/

Re: Redefinition doesn't work

[Bruce Hoult]

At 12:15 PM +0100 5/11/00, sperber@informatik.uni-tuebingen.de (Michael Sperber
>Traditionally, dynamic binding means something like this:
>
>(define x 1)
>(define (f)
>   x)
>(let ((x 2))
>   (f))
>
>Under dynamic binding (and, in fact, in languages like Common Lisp),
>the last expression returns 2.

No!  This is true for older lisps (and Emacs lisp, too), but Common 
Lisp is lexically bound.

-- Bruce

Re: Redefinition doesn't work

[Stephan Houben]

On Fri, 03 Nov 2000, Pierpaolo BERNARDI wrote:

> For example, in Common Lisp it is forbidden to redefine system functions.
> In Scheme, you can define functions with the same name of a system one,
> but this redefinition cannot change the behaviour of other system
> functions.

And this is not very nice, since this forbids the "obvious" way to 
implement various Scheme functions in terms of more primitive
ones. I.e. one would expect that Scheme implementations load
a preamble file which defines things like cadr as:

(define (cadr x) (car (cdr x)))

But this is incorrect, since redefining car would change the behavior of
cadr, which is explicitely forbidden. Correct way to do this:

(define cadr
    (let ((my-car car)
           (my-cdr cdr))
        (lambda (x) (my-car (my-cdr)))))

Of course, even more problematic is that user code needs to do similar
hacks if it wants to be stable against redefinitions of standard procedures.
Moreover, it complicates compiler optimisation an awful lot (it becomes
basically impossible at the toplevel; it can be done in a batch compiler
where the whole source can be inspected to rule out (set! car ...) things).

> > I just tried to
> > compile my Scheme files as usual, calling some primitive function
> > named compile-file (or so), that unfortunately happened to use a
> > global function also named compile.
> 
> This is not a property of Scheme, is a bug in the implementation you
> were using!

Since compile-file is not a R5RS standard procedure, 
there is no guarantee that redefinition of *any* procedure might not change
the behavior of it.  This makes use of any 3d party library in your Scheme
program very problematic, unless the Scheme implementation provides
a (non-standard) module system that fixes this madness.

Of course, I probably don't have to tell all this to the O'Caml developers,
who wisely chose *not* to follow Scheme in this regard...

Stephan
-- 
ir. Stephan H.M.J. Houben
tel. +31-40-2474358 / +31-40-2743497
e-mail: stephanh@win.tue.nl

Re: Redefinition doesn't work

[Michael Sperber [Mr. Preprocessor]]

>>>>> "Stefan" == Stefan Monnier <monnier+lists.caml/news/@RUM.cs.yale.edu> writes:

>>>>> "Pierre" == Pierre Weis <Pierre.Weis@inria.fr> writes:
>> I remember my surprise when I was porting to Scheme some fancy
Stefan> [...example of bad things happening with redefinition...]

Stefan> Don't get me wrong.  The "always redefine" approach is just as wrong
Stefan> as the "never redefine" used by Caml.  It's just that sometimes you want
Stefan> one and sometimes you want the other.

Stefan> I remember a proposition for Scheme (maybe from Matthias Blume) to use
Stefan> `set!' for redefinition and `define' to create a whole new binding.

Stefan> I'm not sure if Scheme ended up providing such a facility, but it
Stefan> does sound right to me.

Most Schemes which address the issue use a module system to resolve it.

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla

Re: Redefinition doesn't work

[Michael Sperber [Mr. Preprocessor]]

>>>>> "Pierre" == Pierre Weis <Pierre.Weis@inria.fr> writes:

Pierre> Mike Friede wrote:

Pierre> Scheme has lexical scoping <EM>locally</EM>. It has dynamic binding
Pierre> globally,
>> 
>> No.

Pierre> I'm very surprised, since I find in the R5RS, a clear distinction
Pierre> between top level definitions that are said to be equivalent to
Pierre> assigments

Exactly.

Pierre> (i.e. top level definitions are treated dynamically):

This is a different issue.  I probably misunderstood you.
Traditionally, dynamic binding means something like this:

(define x 1)
(define (f)
  x)
(let ((x 2))
  (f))

Under dynamic binding (and, in fact, in languages like Common Lisp),
the last expression returns 2.

Binding is not the same thing as assignment.

Pierre> Good! So for built-in procedures we also get static binding at toplevel!

I don't understand what this means: R5RS merely says, that, by
redefining, say, CAR, you won't break MAP.

Pierre> May be it is a bug of the Scheme I used, or may be your Section 6 is
Pierre> new with respect to the Scheme I used (the report on Scheme was known
Pierre> as R3 at the time).

Right.  I believe this was introduced in R4RS or R5RS.

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla

Re: Redefinition doesn't work

[Michel Mauny]

I don't want to spray gasoline on what looks like the beginning of a
flame war, but the `dynamic' behavior of Scheme variables shouldn't be
confused with dynamic scoping.

Pierre Weis wrote/écrivait (Nov 03 2000, 05:56PM +0100):
> Scheme has lexical scoping <EM>locally</EM>. It has dynamic binding
> globally,

> I find in the R5RS, a clear distinction between top level
> definitions that are said to be equivalent to assigments

That's because undefined identifiers are considered to be bound to
global locations. Therefore, a global definition is considered as an
assignment to such a location. This is where the difference comes
from.

To be sure that Scheme uses lexical binding for both global and local
identifiers, consider this simple example:

; -----------
(define (f x) (+ (g x) 1))

(f 1)   ; => Error: g is undefined

(let ((g (lambda (z) z)))
  (f 1)) ; => Error: g is still undefined, although it's avaliable
         ;           from the dynamic env

(define (g x) x)

(f 1)    ; => 2
; -----------

Under dynamic scoping, the second call (f 1) would succeed, since g is
available in the dynamic context. This is how ynamic Lisp would
behave.

In Scheme, when f is defined, g is lexically bound to a location. That
location is assigned when g gets defined (or redefined).

-- Michel

No, I'm not here.

Re: Redefinition doesn't work

[Stefan Monnier]

>>>>> "Pierre" == Pierre Weis <Pierre.Weis@inria.fr> writes:
> I remember my surprise when I was porting to Scheme some fancy
[...example of bad things happening with redefinition...]

Don't get me wrong.  The "always redefine" approach is just as wrong
as the "never redefine" used by Caml.  It's just that sometimes you want
one and sometimes you want the other.

I remember a proposition for Scheme (maybe from Matthias Blume) to use
`set!' for redefinition and `define' to create a whole new binding.

I'm not sure if Scheme ended up providing such a facility, but it
does sound right to me.


        Stefan

Re: Redefinition doesn't work

[Pierpaolo BERNARDI]

On Fri, 3 Nov 2000, Pierre Weis wrote:

> > Stefan Monnier wrote:
> > >>>>>> "Pierre" == Pierre Weis <Pierre.Weis@inria.fr> writes:
> > >> It is not only a question of type. As I mentioned in my previous
> > >> message, if you allow the user to ``rebind'' some basic functions,
> > >> such as map or iter, the behaviour of the compiler can be
> > >> unpredictable.
> > >
> > >It never seems to bother Lisp users.

It does bother Lisp users, and they solve the problem (partially) in
different ways.

For example, in Common Lisp it is forbidden to redefine system functions.
In Scheme, you can define functions with the same name of a system one,
but this redefinition cannot change the behaviour of other system
functions.

> Scheme has lexical scoping <EM>locally</EM>. It has dynamic binding
> globally, just to address this redefinition problem (as far as I can
> imagine a clever justification to this extremely strange behaviour). I
> remember my surprise when I was porting to Scheme some fancy
> metacompilation stuff written in Caml: unfortunately the Caml code
> ended by redefining (globally) the functions load and compile; how
> strange errors messages when the internals of the Scheme compiler
> tried to use those functions in place of its original versions! I
> needed a long time to figure out what was happening, since I did not
> use directly any Scheme function named compile: I just tried to
> compile my Scheme files as usual, calling some primitive function
> named compile-file (or so), that unfortunately happened to use a
> global function also named compile.

This is not a property of Scheme, is a bug in the implementation you
were using!

P.

Re: Redefinition doesn't work

[Pierre Weis]

Mike Friede wrote:

> Pierre> Scheme has lexical scoping <EM>locally</EM>. It has dynamic binding
> Pierre> globally,
> 
> No.

I'm very surprised, since I find in the R5RS, a clear distinction
between top level definitions that are said to be equivalent to
assigments (i.e. top level definitions are treated dynamically):

``Top level definitions

  At the top level of a program, a definition 
  (define <variable> <expression>)

  has essentially the same effect as the assignment expression 
  (set! <variable> <expression>)

  if <variable> is bound. If <variable> is not bound, however, then the
  definition will bind <variable> to a new location before performing
  the assignment, whereas it would be an error to perform a `set!' on
  an unbound variable.''

In contrast, local definitions that are not treated as an assigment,
but as conventional static bindings:

``Internal definitions

  Definitions may occur at the beginning of a <body> (that is, the body
  of a lambda, let, let*, letrec, let-syntax, or letrec-syntax
  expression or that of a definition of an appropriate form). Such
  definitions are known as internal definitions as opposed to the top
  level definitions described above. The variable defined by an internal
  definition is local to the <body>. That is, <variable> is bound rather
  than assigned, and the region of the binding is the entire <body>.''

In my mind these two definitons can be summerized as this crude
statement: ``Scheme has lexical scoping <EM>locally</EM>. It has
dynamic binding globally''.

> Pierre> just to address this redefinition problem (as far as I can
> Pierre> imagine a clever justification to this extremely strange behaviour). I
[...]
> 
> What you're describing is not a binding issue, but an assignment
> issue.  (Look in R5RS, 5.2.1 for an explanation.)  Moreover, what
> you're describing is (at least not in spirit) not conformant with
> R5RS.

As quoted above, the R5RS essentially says : Top level definitions are
assignments. The dynamic behaviour of Scheme global definitions is
just a consequence of this design choice. So, you are right, it is an
assignment issue: once you decided that global definitions are
assignments, then you automatically get dynamic top level definitions.

May be, what I call ``dynamic global binding'', is what you call an
assignment issue ? Or is it the same old semantics discussion with
schemers that pretended that Scheme global binding was indeed static
since a global identifier was always bound to the same memory location
(obtained once and for all at the first definition of the global),
even if the contents of this memory location can be changed
dynamically and dereferencement was transparent in Scheme ?

>  Section 6 has this:
> 
>   [Global binding alterations] do not modify the behavior of Scheme's
>   built-in procedures.

Good! So for built-in procedures we also get static binding at toplevel!

However, this is clearly a hack for built-in procedures! Useful, but
it is difficult to understand why I cannot benefit from this feature
for my own programs.

Note also the direct consequences of this cautious statement: now you
have a lot of identifiers that you cannot use any more in your
programs, since, if you dedefine these names, you would probably
``modify the behavior of Scheme's built-in procedures''. Also, if the
Scheme implementors add a new built-in procedure then your programs
have to be changed if you ever used the new name !

> Pierre> That's an example of a user that does not want the functions to be
> Pierre> redefined everywhere, since he cannot understand the consequences of
> Pierre> the redefinition since he does not even know where the rebound
> Pierre> function was used!
> 
> Sounds like an implementation bug to me.
> 
> -- 
> Cheers =8-} Mike
> Friede, Völkerverständigung und überhaupt blabla

May be it is a bug of the Scheme I used, or may be your Section 6 is
new with respect to the Scheme I used (the report on Scheme was known
as R3 at the time).

However, this behaviour was a consequence of the choice of the
semantics of global definitions. In 2000, this definition is still
valid, as written in the R5RS. Hence, you will have the problem of
global dynamic binding for any big program for which global
definitions cannot be protected against ``Global binding
alterations''.

In Caml, we do not treat global definitions as assigments. Hence we
have not to add a Section 6 special case in the manual to prevent
users from breaking the compiler. Hence you can redefine any built-in
you want, since you can never ``alterate'' the bindings. Hence, you
cannot modify the semantics of already defined functions (this is also
true for basic operators such as +, *, ...), and this property is
universal, either locally or globally. This a strong property (and a
good one in my mind, since it allows the programmer to be sure that
nobody can alterate the code that will be executed at run time). A
#relet feature would geopardize this invaluable property.

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://cristal.inria.fr/~weis/

Re: Redefinition doesn't work

[Michael Sperber [Mr. Preprocessor]]

>>>>> "Pierre" == Pierre Weis <Pierre.Weis@inria.fr> writes:

>> Stefan Monnier wrote:
>> >>>>>> "Pierre" == Pierre Weis <Pierre.Weis@inria.fr> writes:
>> >> It is not only a question of type. As I mentioned in my previous
>> >> message, if you allow the user to ``rebind'' some basic functions,
>> >> such as map or iter, the behaviour of the compiler can be
>> >> unpredictable.
>> >
>> >It never seems to bother Lisp users.
>> 
>> It must have bothered some Lisp users, otherwise why does Scheme have
>> lexical scoping?
>> 
>> Ruchira Datta
>> datta@math.berkeley.edu

Pierre> Scheme has lexical scoping <EM>locally</EM>. It has dynamic binding
Pierre> globally,

No.

Pierre> just to address this redefinition problem (as far as I can
Pierre> imagine a clever justification to this extremely strange behaviour). I
Pierre> remember my surprise when I was porting to Scheme some fancy
Pierre> metacompilation stuff written in Caml: unfortunately the Caml code
Pierre> ended by redefining (globally) the functions load and compile; how
Pierre> strange errors messages when the internals of the Scheme compiler
Pierre> tried to use those functions in place of its original versions! I
Pierre> needed a long time to figure out what was happening, since I did not
Pierre> use directly any Scheme function named compile: I just tried to
Pierre> compile my Scheme files as usual, calling some primitive function
Pierre> named compile-file (or so), that unfortunately happened to use a
Pierre> global function also named compile.

What you're describing is not a binding issue, but an assignment
issue.  (Look in R5RS, 5.2.1 for an explanation.)  Moreover, what
you're describing is (at least not in spirit) not conformant with
R5RS.  Section 6 has this:

  [Global binding alterations] do not modify the behavior of Scheme's
  built-in procedures.

Pierre> That's an example of a user that does not want the functions to be
Pierre> redefined everywhere, since he cannot understand the consequences of
Pierre> the redefinition since he does not even know where the rebound
Pierre> function was used!

Sounds like an implementation bug to me.

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla

Re: Redefinition doesn't work

[Pierre Weis]

> Stefan Monnier wrote:
> >>>>>> "Pierre" == Pierre Weis <Pierre.Weis@inria.fr> writes:
> >> It is not only a question of type. As I mentioned in my previous
> >> message, if you allow the user to ``rebind'' some basic functions,
> >> such as map or iter, the behaviour of the compiler can be
> >> unpredictable.
> >
> >It never seems to bother Lisp users.
> 
> It must have bothered some Lisp users, otherwise why does Scheme have
> lexical scoping?
> 
> Ruchira Datta
> datta@math.berkeley.edu

Scheme has lexical scoping <EM>locally</EM>. It has dynamic binding
globally, just to address this redefinition problem (as far as I can
imagine a clever justification to this extremely strange behaviour). I
remember my surprise when I was porting to Scheme some fancy
metacompilation stuff written in Caml: unfortunately the Caml code
ended by redefining (globally) the functions load and compile; how
strange errors messages when the internals of the Scheme compiler
tried to use those functions in place of its original versions! I
needed a long time to figure out what was happening, since I did not
use directly any Scheme function named compile: I just tried to
compile my Scheme files as usual, calling some primitive function
named compile-file (or so), that unfortunately happened to use a
global function also named compile.

That's an example of a user that does not want the functions to be
redefined everywhere, since he cannot understand the consequences of
the redefinition since he does not even know where the rebound
function was used!

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://cristal.inria.fr/~weis/

Re: Redefinition doesn't work

[Stefan Monnier]

>>>>> "Pierre" == Pierre Weis <Pierre.Weis@inria.fr> writes:
> Absolutely right. In the same vein we have: the absence of static
> type-checking ``never seems to bother Lisp users'', the absence of GC
> ``never seems to bother C users'', the absence of dynamically
> allocated arrays ``never seems to bother Pascal users'', the absence
> of pattern matching ``never seems to bother Pascal users''...
....
...., the absence of rebinding in the interactive loop ``never seems
to bother OCaml users''....


        Stefan ;-)

Re: Redefinition doesn't work

[Ruchira Datta]

Stefan Monnier wrote:
>>>>>> "Pierre" == Pierre Weis <Pierre.Weis@inria.fr> writes:
>> It is not only a question of type. As I mentioned in my previous
>> message, if you allow the user to ``rebind'' some basic functions,
>> such as map or iter, the behaviour of the compiler can be
>> unpredictable.
>
>It never seems to bother Lisp users.

It must have bothered some Lisp users, otherwise why does Scheme have
lexical scoping?

Ruchira Datta
datta@math.berkeley.edu

Re: Redefinition doesn't work

[Trevor Jim]

If anyone is interested in static, incremental type inference (which
allows type safe redefinitions without #use), I worked out how to do
this for core ML in a paper in POPL '96.  As someone noted earlier, of
course this does not address the semantic issues (of changing
List.map, for example).

-Trevor

Re: Redefinition doesn't work

[Pierre Weis]

> >>>>> "Pierre" == Pierre Weis <Pierre.Weis@inria.fr> writes:
> > It is not only a question of type. As I mentioned in my previous
> > message, if you allow the user to ``rebind'' some basic functions,
> > such as map or iter, the behaviour of the compiler can be
> > unpredictable.
> 
> It never seems to bother Lisp users.
> 
> 
>         Stefan

Absolutely right. In the same vein we have: the absence of static
type-checking ``never seems to bother Lisp users'', the absence of GC
``never seems to bother C users'', the absence of dynamically
allocated arrays ``never seems to bother Pascal users'', the absence
of pattern matching ``never seems to bother Pascal users''...

So what ? Users of these languages have very often to fight against
the absence of these features. In Caml, we chose to provide them to
the user in a simple and rigorous way.

Conversely, we try to avoid the addition of features that can confuse
the users in some situations (and in my mind the rebinding of
identifiers belongs to this category). To be precise, I implemented
this feature long time ago in Caml: it was named the #relet directive
of the toplevel. It had the type-checking constraints I mentioned. So
it was safe. But it was confusing, since people quickly started to
imagine that it meant : everything that mentioned the old function
should now behave as if the old function were the new one. So they
asked this relet feature to be applied recursively everywhere in their
programs, including partially applied functions or even totally
applied functions such as constants expressed as a call to a rebound
function (something like: I relet fib, but my x, defined as let x =
fib 20, has not changed, it still uses the old value of fib!). We
ended up by saying: if you want to obtain this effect, you just have
to reload the entire program ...

So better start by saying ``if you want to obtain this effect, you
just have to reload the entire program''!

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://cristal.inria.fr/~weis/

Re: Redefinition doesn't work

[Ruchira Datta]

Pierre Weis wrote:
>Mattias Waldau wrote:
>> One of the reason of me liking OCaml is the interactive top level. However,
>> it is a bit messy always remember to redefine all functions that depend of
>> the function you just corrected.
>
>You just have to use a very simple rule: reload your source file after
>each correction (use #use "filename.ml";;).

Well, part of the point of the interactive top level is that you can try
out commands at the prompt, rather than having to put them in a separate
file.  However, you can have the best of both worlds with ledit
(see http://cristal.inria.fr/~ddr).  Just keep a running history of
your interactive session by starting it up as follows:

ledit -h "./ocaml_history" -x ocaml

Then to reload the functions that depend on the function you just corrected,
you have two options (which is more convenient depends on how many 
redefinitions have to be made): 

- if there are only a few redefinitions:
  just use the up arrow to go back to the original definitions and
  reenter them

- if there are many redefinitions:
  go into a text editor in a separate window, paste their definitions from 
  the file ocaml_history into some other file, e.g., temp.ml, and finally 
  go back to your ocaml interactive session and load the file with 
  #use "temp.ml" as above.

Ruchira Datta
datta@math.berkeley.edu

Re: Redefinition doesn't work

[Stefan Monnier]

>>>>> "Pierre" == Pierre Weis <Pierre.Weis@inria.fr> writes:
> It is not only a question of type. As I mentioned in my previous
> message, if you allow the user to ``rebind'' some basic functions,
> such as map or iter, the behaviour of the compiler can be
> unpredictable.

It never seems to bother Lisp users.


        Stefan

Re: Redefinition doesn't work

[Pierre Weis]

> Maybe I missed it, but one relevant thing I did not see mentioned in this
> discussion is the fact that if a value x is rebound, and the type of the
> new x differs from that of the old, then some values whose implementation
> (definition) depend on x may become ill-typed.
> 
> -- 
> Frank Atanassow, Dept. of Computer Science, Utrecht University
> Padualaan 14, PO Box 80.089, 3508 TB Utrecht, Netherlands
> Tel +31 (030) 253-1012, Fax +31 (030) 251-3791

Thank you for the precision, but I took it for ganted that the type
(scheme) assigned by the type-checker to the new identifier was
compatible with the (rebound) identifier's type scheme (more precisely
if x has type scheme sigma and you redefine x with type scheme sigma',
then sigma' must be more general than sigma). Otherwise the idea of
redefinition is pointless since any thing can occur after a
redefinition and the language becomes unsafe.

Best regards,

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://cristal.inria.fr/~weis/

Re: Redefinition doesn't work

[Pierre Weis]

> Isn't it possible to have a rebind or something such keyboard, that would test
> that the type of the newly binded value is the same as the old value, or maybe
> even something larger than that ?
> 
> Friendly,
> 
> Sven LUTHER

It is not only a question of type. As I mentioned in my previous
message, if you allow the user to ``rebind'' some basic functions,
such as map or iter, the behaviour of the compiler can be
unpredictable.

Friendly,

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://cristal.inria.fr/~weis/

Re: Redefinition doesn't work

[Frank Atanassow]

Pierre Weis writes:
 > >  when user redefines some function, isn't it exactly the user's intention
 > >  to redefine all the bindings already defined not only those following that
 > >  redefinition?
 > 
 > No, I guess it is not the intention of the user, since he does not
 > know the set of bindings that uses the function he is redefining.

Maybe I missed it, but one relevant thing I did not see mentioned in this
discussion is the fact that if a value x is rebound, and the type of the
new x differs from that of the old, then some values whose implementation
(definition) depend on x may become ill-typed.

-- 
Frank Atanassow, Dept. of Computer Science, Utrecht University
Padualaan 14, PO Box 80.089, 3508 TB Utrecht, Netherlands
Tel +31 (030) 253-1012, Fax +31 (030) 251-3791

Re: Redefinition doesn't work

[Sven LUTHER]

On Tue, Oct 31, 2000 at 12:06:13PM +0100, Pierre Weis wrote:
> Jaeyoun Chung (mailto:jay@kldp.org) wrote:
> 
> >  this is quite true but the above feature for the toplevel is quite useful
> >  during the development phase. if each time we should redefine everything
> >  dependent on one function, toplevel isn't quite that useful -- to find out
> >  the dependencies or just reload everything dependent on the file
> >  containing the function is what should have be done automatically. what
> >  about having an option or directive so that user can control the behavior?
> 
> We already have one: #use "filename.ml";;
> 
> For instance, you can use a loadall.ml file that contains the list of
> #use directives that load the files that made your program.
> 
> >  when user redefines some function, isn't it exactly the user's intention
> >  to redefine all the bindings already defined not only those following that
> >  redefinition?
> 
> No, I guess it is not the intention of the user, since he does not
> know the set of bindings that uses the function he is redefining.

Isn't it possible to have a rebind or something such keyboard, that would test
that the type of the newly binded value is the same as the old value, or maybe
even something larger than that ?

Friendly,

Sven LUTHER

Re: Redefinition doesn't work

[Pierre Weis]

Jaeyoun Chung (mailto:jay@kldp.org) wrote:

>  this is quite true but the above feature for the toplevel is quite useful
>  during the development phase. if each time we should redefine everything
>  dependent on one function, toplevel isn't quite that useful -- to find out
>  the dependencies or just reload everything dependent on the file
>  containing the function is what should have be done automatically. what
>  about having an option or directive so that user can control the behavior?

We already have one: #use "filename.ml";;

For instance, you can use a loadall.ml file that contains the list of
#use directives that load the files that made your program.

>  when user redefines some function, isn't it exactly the user's intention
>  to redefine all the bindings already defined not only those following that
>  redefinition?

No, I guess it is not the intention of the user, since he does not
know the set of bindings that uses the function he is redefining.

If you want to test, you can use the Ocaml feature that effectively
redefines functions the way you suggest they should be, namely the
#trace directive. For instance:

# #trace List.iter;;
List.iter is now traced.
# 1;;

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://cristal.inria.fr/~weis/

Re: Redefinition doesn't work

[Jaeyoun Chung]

[hm. this is quite strange anyway, here's the message that i've posted to
the caml list.]

* "Mattias Waldau" <mattias.waldau@abc.se> at 2000-10-28 09:32+0200
| # let f1 () = 10;;
|   val f1 : unit -> int = <fun>
| # let f2 () = (f1 ()) * 10;;
| val f2 : unit -> int = <fun>
| # f2 ();;
| - : int = 100
| # let f1 () = 20;;
| val f1 : unit -> int = <fun>
| # f2 ();;
| - : int = 100
| #

* Pierre Weis <Pierre.Weis@inria.fr> at 2000-10-28 18:37+0200
| This is not a misfeature, but an extremely desirable property: a sound
| theoretical fundation for the binding rule of identifiers in the
| language. This rule means that every identifier in a program is bound
| before the point of use. This is simple to explain and clear to
| understand. Furthermore it allows the static verification of type
| correctness.

 this is quite true but the above feature for the toplevel is quite useful
 during the development phase. if each time we should redefine everything
 dependent on one function, toplevel isn't quite that useful -- to find out
 the dependencies or just reload everything dependent on the file
 containing the function is what should have be done automatically. what
 about having an option or directive so that user can control the behavior?

 when user redefines some function, isn't it exactly the user's intention
 to redefine all the bindings already defined not only those following that
 redefinition?

-- 
Jaeyoun Chung                       mailto:jay@kldp.org
[see http://emacs.kldp.org for emacs-KR homepage.]