* Re: Redefinition doesn't work
@ 2000-11-02 22:45 Ruchira Datta
2000-11-03 9:13 ` Pierre Weis
0 siblings, 1 reply; 24+ messages in thread
From: Ruchira Datta @ 2000-11-02 22:45 UTC (permalink / raw)
To: caml-list
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Redefinition doesn't work 2000-11-02 22:45 Redefinition doesn't work Ruchira Datta @ 2000-11-03 9:13 ` Pierre Weis 2000-11-03 10:09 ` Michael Sperber [Mr. Preprocessor] ` (2 more replies) 0 siblings, 3 replies; 24+ messages in thread From: Pierre Weis @ 2000-11-03 9:13 UTC (permalink / raw) To: 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 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/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Redefinition doesn't work 2000-11-03 9:13 ` Pierre Weis @ 2000-11-03 10:09 ` Michael Sperber [Mr. Preprocessor] 2000-11-03 16:56 ` Pierre Weis 2000-11-03 16:58 ` Pierpaolo BERNARDI 2000-11-03 17:30 ` Stefan Monnier 2 siblings, 1 reply; 24+ messages in thread From: Michael Sperber [Mr. Preprocessor] @ 2000-11-03 10:09 UTC (permalink / raw) To: caml-list; +Cc: Pierre Weis, datta >>>>> "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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Redefinition doesn't work 2000-11-03 10:09 ` Michael Sperber [Mr. Preprocessor] @ 2000-11-03 16:56 ` Pierre Weis 2000-11-03 17:36 ` Michel Mauny 2000-11-05 11:15 ` Michael Sperber [Mr. Preprocessor] 0 siblings, 2 replies; 24+ messages in thread From: Pierre Weis @ 2000-11-03 16:56 UTC (permalink / raw) To: Michael Sperber [Mr. Preprocessor]; +Cc: caml-list 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/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Redefinition doesn't work 2000-11-03 16:56 ` Pierre Weis @ 2000-11-03 17:36 ` Michel Mauny 2000-11-05 11:15 ` Michael Sperber [Mr. Preprocessor] 1 sibling, 0 replies; 24+ messages in thread From: Michel Mauny @ 2000-11-03 17:36 UTC (permalink / raw) To: Pierre Weis; +Cc: Michael Sperber [Mr. Preprocessor], caml-list 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Redefinition doesn't work 2000-11-03 16:56 ` Pierre Weis 2000-11-03 17:36 ` Michel Mauny @ 2000-11-05 11:15 ` Michael Sperber [Mr. Preprocessor] 2000-11-06 21:30 ` Bruce Hoult 1 sibling, 1 reply; 24+ messages in thread From: Michael Sperber [Mr. Preprocessor] @ 2000-11-05 11:15 UTC (permalink / raw) To: Pierre Weis; +Cc: caml-list >>>>> "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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Redefinition doesn't work 2000-11-05 11:15 ` Michael Sperber [Mr. Preprocessor] @ 2000-11-06 21:30 ` Bruce Hoult 0 siblings, 0 replies; 24+ messages in thread From: Bruce Hoult @ 2000-11-06 21:30 UTC (permalink / raw) To: Michael Sperber [Mr. Preprocessor], Pierre Weis; +Cc: caml-list 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Redefinition doesn't work 2000-11-03 9:13 ` Pierre Weis 2000-11-03 10:09 ` Michael Sperber [Mr. Preprocessor] @ 2000-11-03 16:58 ` Pierpaolo BERNARDI 2000-11-06 9:29 ` Stephan Houben 2000-11-03 17:30 ` Stefan Monnier 2 siblings, 1 reply; 24+ messages in thread From: Pierpaolo BERNARDI @ 2000-11-03 16:58 UTC (permalink / raw) To: Pierre Weis; +Cc: caml-list 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Redefinition doesn't work 2000-11-03 16:58 ` Pierpaolo BERNARDI @ 2000-11-06 9:29 ` Stephan Houben 0 siblings, 0 replies; 24+ messages in thread From: Stephan Houben @ 2000-11-06 9:29 UTC (permalink / raw) To: Pierpaolo BERNARDI, Pierre Weis; +Cc: caml-list 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Redefinition doesn't work 2000-11-03 9:13 ` Pierre Weis 2000-11-03 10:09 ` Michael Sperber [Mr. Preprocessor] 2000-11-03 16:58 ` Pierpaolo BERNARDI @ 2000-11-03 17:30 ` Stefan Monnier 2000-11-05 11:16 ` Michael Sperber [Mr. Preprocessor] 2 siblings, 1 reply; 24+ messages in thread From: Stefan Monnier @ 2000-11-03 17:30 UTC (permalink / raw) To: caml-list >>>>> "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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Redefinition doesn't work 2000-11-03 17:30 ` Stefan Monnier @ 2000-11-05 11:16 ` Michael Sperber [Mr. Preprocessor] 0 siblings, 0 replies; 24+ messages in thread From: Michael Sperber [Mr. Preprocessor] @ 2000-11-05 11:16 UTC (permalink / raw) To: caml-list >>>>> "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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Redefinition doesn't work
@ 2000-10-31 19:11 Ruchira Datta
2000-11-02 18:05 ` Trevor Jim
0 siblings, 1 reply; 24+ messages in thread
From: Ruchira Datta @ 2000-10-31 19:11 UTC (permalink / raw)
To: caml-list
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Redefinition doesn't work 2000-10-31 19:11 Ruchira Datta @ 2000-11-02 18:05 ` Trevor Jim 0 siblings, 0 replies; 24+ messages in thread From: Trevor Jim @ 2000-11-02 18:05 UTC (permalink / raw) To: caml-list 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <200010300739.IAA13016@pauillac.inria.fr>]
* Re: Redefinition doesn't work [not found] <200010300739.IAA13016@pauillac.inria.fr> @ 2000-10-30 23:38 ` Jaeyoun Chung 2000-10-31 11:06 ` Pierre Weis 0 siblings, 1 reply; 24+ messages in thread From: Jaeyoun Chung @ 2000-10-30 23:38 UTC (permalink / raw) To: Pierre Weis; +Cc: caml-list [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.] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Redefinition doesn't work 2000-10-30 23:38 ` Jaeyoun Chung @ 2000-10-31 11:06 ` Pierre Weis 2000-10-31 11:52 ` Sven LUTHER 2000-10-31 14:16 ` Frank Atanassow 0 siblings, 2 replies; 24+ messages in thread From: Pierre Weis @ 2000-10-31 11:06 UTC (permalink / raw) To: jay; +Cc: caml-list 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/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Redefinition doesn't work 2000-10-31 11:06 ` Pierre Weis @ 2000-10-31 11:52 ` Sven LUTHER 2000-10-31 16:47 ` Pierre Weis 2000-10-31 14:16 ` Frank Atanassow 1 sibling, 1 reply; 24+ messages in thread From: Sven LUTHER @ 2000-10-31 11:52 UTC (permalink / raw) To: Pierre Weis; +Cc: jay, caml-list 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Redefinition doesn't work 2000-10-31 11:52 ` Sven LUTHER @ 2000-10-31 16:47 ` Pierre Weis 2000-10-31 18:55 ` Stefan Monnier 0 siblings, 1 reply; 24+ messages in thread From: Pierre Weis @ 2000-10-31 16:47 UTC (permalink / raw) To: Sven LUTHER; +Cc: caml-list > 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/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Redefinition doesn't work 2000-10-31 16:47 ` Pierre Weis @ 2000-10-31 18:55 ` Stefan Monnier 2000-11-02 15:42 ` Pierre Weis 0 siblings, 1 reply; 24+ messages in thread From: Stefan Monnier @ 2000-10-31 18:55 UTC (permalink / raw) To: caml-list >>>>> "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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Redefinition doesn't work 2000-10-31 18:55 ` Stefan Monnier @ 2000-11-02 15:42 ` Pierre Weis 2000-11-03 3:10 ` Stefan Monnier 0 siblings, 1 reply; 24+ messages in thread From: Pierre Weis @ 2000-11-02 15:42 UTC (permalink / raw) To: Stefan Monnier; +Cc: caml-list > >>>>> "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/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Redefinition doesn't work 2000-11-02 15:42 ` Pierre Weis @ 2000-11-03 3:10 ` Stefan Monnier 0 siblings, 0 replies; 24+ messages in thread From: Stefan Monnier @ 2000-11-03 3:10 UTC (permalink / raw) To: caml-list >>>>> "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 ;-) ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Redefinition doesn't work 2000-10-31 11:06 ` Pierre Weis 2000-10-31 11:52 ` Sven LUTHER @ 2000-10-31 14:16 ` Frank Atanassow 2000-10-31 17:07 ` Pierre Weis 1 sibling, 1 reply; 24+ messages in thread From: Frank Atanassow @ 2000-10-31 14:16 UTC (permalink / raw) To: Pierre Weis; +Cc: jay, caml-list 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Redefinition doesn't work 2000-10-31 14:16 ` Frank Atanassow @ 2000-10-31 17:07 ` Pierre Weis 0 siblings, 0 replies; 24+ messages in thread From: Pierre Weis @ 2000-10-31 17:07 UTC (permalink / raw) To: Frank Atanassow; +Cc: caml-list > 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/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Redefinition doesn't work @ 2000-10-28 7:32 Mattias Waldau 2000-10-28 16:37 ` Pierre Weis 0 siblings, 1 reply; 24+ messages in thread From: Mattias Waldau @ 2000-10-28 7:32 UTC (permalink / raw) To: Caml-List 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Redefinition doesn't work 2000-10-28 7:32 Mattias Waldau @ 2000-10-28 16:37 ` Pierre Weis 0 siblings, 0 replies; 24+ messages in thread From: Pierre Weis @ 2000-10-28 16:37 UTC (permalink / raw) To: Mattias Waldau; +Cc: caml-list > 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/ ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2000-11-06 22:28 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-11-02 22:45 Redefinition doesn't work Ruchira Datta 2000-11-03 9:13 ` Pierre Weis 2000-11-03 10:09 ` Michael Sperber [Mr. Preprocessor] 2000-11-03 16:56 ` Pierre Weis 2000-11-03 17:36 ` Michel Mauny 2000-11-05 11:15 ` Michael Sperber [Mr. Preprocessor] 2000-11-06 21:30 ` Bruce Hoult 2000-11-03 16:58 ` Pierpaolo BERNARDI 2000-11-06 9:29 ` Stephan Houben 2000-11-03 17:30 ` Stefan Monnier 2000-11-05 11:16 ` Michael Sperber [Mr. Preprocessor] -- strict thread matches above, loose matches on Subject: below -- 2000-10-31 19:11 Ruchira Datta 2000-11-02 18:05 ` Trevor Jim [not found] <200010300739.IAA13016@pauillac.inria.fr> 2000-10-30 23:38 ` Jaeyoun Chung 2000-10-31 11:06 ` Pierre Weis 2000-10-31 11:52 ` Sven LUTHER 2000-10-31 16:47 ` Pierre Weis 2000-10-31 18:55 ` Stefan Monnier 2000-11-02 15:42 ` Pierre Weis 2000-11-03 3:10 ` Stefan Monnier 2000-10-31 14:16 ` Frank Atanassow 2000-10-31 17:07 ` Pierre Weis 2000-10-28 7:32 Mattias Waldau 2000-10-28 16:37 ` Pierre Weis
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).