Re: Redefinition doesn't work

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.]

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

[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]

> 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

[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]

> >>>>> "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

[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 ;-)

Good programming languages (Was: Redefinition doesn't work)

[Mattias Waldau]

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

>> Pierre Weis

Sorry, I don't buy your arguments. The most important aspects of a
programming language for me is:

1. typed (to find typo-like bugs, or when changing the program)
2. interactive environment (to be able to test hard part of the program
without have to write elaborate function just for testing)
3. easy to use and understand libraries.
4. good syntax, which makes it easy to write the correct code
5. fast
6. portable, works on windows and linux
7. good support or good open source team
8. cheap

On a scale from 1 to 5, where 5 is the best,
Ocaml would get 5 for typed,
3 for interactive environment (better than C, Java, SML, but much worse than
Lisp, Prolog, Scheme, examples of problem: #relet, not very good
emacs-modes, no object-browser),
2 for easy to use libraries (it is so hard to find the right function, I
have to search thru the PDF-file all the time),
2 for good syntax (it is very easy to spend a lot of time trying to get the
program to compile, for example I called a attribute in a record 'value',
and that works sometimes I have noticed :-),
5 for fast,
5 for portable (when ocamldebug works on windows)
4 for good support (I tried to understand the source code of ocaml, but my
French is to bad.)
5 for cheap


Very good scores for ocaml, but there are places for improvements.

/mattias

Re: Good programming languages (Was: Redefinition doesn't work)

[bcpierce]

> 2 for easy to use libraries (it is so hard to find the right function, I
> have to search thru the PDF-file all the time),

I find that Emacs is an excellent tool for searching for functions in the
OCaml library.  The developers have helpfully provided a pure-ascii
version of the documentation, and a couple of incremental searches
usually gets me to what I want in a few second.

Occasionally I even do searches based on types.  For example, I can never
remember the convention for naming conversion functions.  Is it
int_to_string or string_to_int or string_of_int or...?  A simple search
for "int -> string" settles the question in moments.  :-)

    B

Re: Good programming languages (Was: Redefinition doesn't work)

[Jacques Garrigue]

From: bcpierce@cis.upenn.edu

> > 2 for easy to use libraries (it is so hard to find the right function, I
> > have to search thru the PDF-file all the time),
> 
> I find that Emacs is an excellent tool for searching for functions in the
> OCaml library.  The developers have helpfully provided a pure-ascii
> version of the documentation, and a couple of incremental searches
> usually gets me to what I want in a few second.
> 
> Occasionally I even do searches based on types.  For example, I can never
> remember the convention for naming conversion functions.  Is it
> int_to_string or string_to_int or string_of_int or...?  A simple search
> for "int -> string" settles the question in moments.  :-)

Just a plug: ocamlbrowser is really good at all that.
You can visit modules through navigation, read comments in the .mli's...
You can even search by types, with a few built-in isomorphisms.
Maybe for experienced users full text search is just enough, but
beginners should at least give a try to it.
And it works even if there is no documentation :-) as for labltk :-(

        Jacques

Re: Good programming languages (Was: Redefinition doesn't work)

[Markus Mottl]

On Fri, 03 Nov 2000, bcpierce@cis.upenn.edu wrote:
> I find that Emacs is an excellent tool for searching for functions in
> the OCaml library.  The developers have helpfully provided a pure-ascii
> version of the documentation, and a couple of incremental searches
> usually gets me to what I want in a few second.

VIM-users might want to put the following function definition into their
.bashrc-file:

  function ocdoc () { command vim -R $OCAMLLIBPATH/$1; }

where $OCAMLLIBPATH is set to the location of the library directory. A
simple e.g. "ocdoc list.mli" (or also "ocdoc list.ml") on the command
line will display the nicely highlighted code in a shell window (starting
up Emacs in a similar way is just too slow :-)

Best regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl

Re: Good programming languages (Was: Redefinition doesn't work)

[Juan J. Quintela]

>>>>> "markus" == Markus Mottl <mottl@miss.wu-wien.ac.at> writes:

markus> On Fri, 03 Nov 2000, bcpierce@cis.upenn.edu wrote:
>> I find that Emacs is an excellent tool for searching for functions in
>> the OCaml library.  The developers have helpfully provided a pure-ascii
>> version of the documentation, and a couple of incremental searches
>> usually gets me to what I want in a few second.

markus> VIM-users might want to put the following function definition into their
markus> .bashrc-file:

markus>   function ocdoc () { command vim -R $OCAMLLIBPATH/$1; }

markus> where $OCAMLLIBPATH is set to the location of the library directory. A
markus> simple e.g. "ocdoc list.mli" (or also "ocdoc list.ml") on the command
markus> line will display the nicely highlighted code in a shell window (starting
markus> up Emacs in a similar way is just too slow :-)

Have you ever heard of emacsclient????

/me hides under the _holy_ war emacs/vi.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

Re: Good programming languages (Was: Redefinition doesn't work)

[Markus Mottl]

On Thu, 09 Nov 2000, Juan J. Quintela wrote:
> Have you ever heard of emacsclient????

Yes - I had used emacs for over two years. That was a mistake...

The emacs server needs too much memory ;)

I generally hold it with this saying:

  "Emacs is a good operating system, but Unix has a nicer editor."

Programming OCaml is even more fun with Vim! :-)

Best regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl

Re: Good programming languages (Was: Redefinition doesn't work)

[Stephan Houben]

On Fri, 10 Nov 2000, Markus Mottl wrote:

> Programming OCaml is even more fun with Vim! :-)

Especially with the ocaml.vim mode!
Keep up the good work!

Stephan

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

Re: Good programming languages (Was: Redefinition doesn't work)

[Remi VANICAT]

"Juan J. Quintela" <quintela@fi.udc.es> writes:

> >>>>> "markus" == Markus Mottl <mottl@miss.wu-wien.ac.at> writes:
> 
> markus> On Fri, 03 Nov 2000, bcpierce@cis.upenn.edu wrote:
> >> I find that Emacs is an excellent tool for searching for functions in
> >> the OCaml library.  The developers have helpfully provided a pure-ascii
> >> version of the documentation, and a couple of incremental searches
> >> usually gets me to what I want in a few second.
> 
> markus> VIM-users might want to put the following function definition into their
> markus> .bashrc-file:
> 
> markus>   function ocdoc () { command vim -R $OCAMLLIBPATH/$1; }
> 
> markus> where $OCAMLLIBPATH is set to the location of the library directory. A
> markus> simple e.g. "ocdoc list.mli" (or also "ocdoc list.ml") on the command
> markus> line will display the nicely highlighted code in a shell window (starting
> markus> up Emacs in a similar way is just too slow :-)
> 
> Have you ever heard of emacsclient????

why use emacsclient ? if you use emacs, you can do an Emacs command to
do the work, after all, are'nt you making your job in Emacs ?

say :
(defun ocdoc (lib) (interactive "sThe library file: ")
        (view-file (concat ocaml-library-path lib)))
(suposed that the emacs variable ocaml-lib-path is already set.)

and the M-x ocdoc will do the job...

Tuareg already have a similar binding
-- 
Rémi Vanicat
vanicat@labri.u-bordeaux.fr
http://dept-info.labri.u-bordeaux.fr/~vanicat

Re: Good programming languages (Was: Redefinition doesn't work)

[Francisco Reyes]

On Fri, 3 Nov 2000 09:44:11 +0100, Mattias Waldau wrote:

>1. typed (to find typo-like bugs, or when changing the program)
>2. interactive environment (to be able to test hard part of the program
>without have to write elaborate function just for testing)
>3. easy to use and understand libraries.
>4. good syntax, which makes it easy to write the correct code
>5. fast
>6. portable, works on windows and linux
>7. good support or good open source team
>8. cheap
>
>3 for interactive environment (better than C, Java, SML, but much worse than
>Lisp, Prolog, Scheme, examples of problem: #relet, not very good
>emacs-modes, no object-browser),

2 for interactive.
In my case at least Ocaml still shows too much of it's research
background. It is taking me some time to get used to or even
understand the output of the interactive environment.

>2 for easy to use libraries (it is so hard to find the right function, I
>have to search thru the PDF-file all the time),

So far from the little I have seen it is not the libraries that
it is a problem. It is the docs and the examples. I asked once
if it was possible to contribute to the documentation and got no
answer. For instance there is no samples with the libraries so
for beginners it is difficult at the beginning to understand how
to use a library because there are no examples. To make things
worse I bought a book to try and learn Caml and the
examples/exercises are highly math driven. I find this too be a
horrible thing to have done. When I look at the exercises I 
spend more time trying to thing how the math is going to work
out than how I am going to program the thing. Example: the first
exercise is to prove that Ax^2 + bx + c = 0 is solvable given
three parameters a,b,c. For someone who is contantly doing math
this is probably trivial, but I have not taken any math clases
on years and I don't see the point on linking the exercises so
much to math. This perhaps is linked to the previous(current?)
set of intended users. If Ocaml is to ever become a general
purpose language then the docs/examples need to be less
theorical and more practical.




>2 for good syntax (it is very easy to spend a lot of time trying to get the
>program to compile, for example I called a attribute in a record 'value',
>and that works sometimes I have noticed :-),

I agree with the 2. I don't know if it is my lack of having
worked with other functional languages, but I find the Ocaml
syntax strange.


francisco
Moderator of the Corporate BSD list
http://www.egroups.com/group/BSD_Corporate

Re: Good programming languages (Was: Redefinition doesn't work)

[Brian Rogoff]

On Mon, 6 Nov 2000, Francisco Reyes wrote:
> 2 for interactive.
> In my case at least Ocaml still shows too much of it's research
> background. It is taking me some time to get used to or even
> understand the output of the interactive environment.

Well, it will only get better with specific comments for improvements. 
Saying "interactive mode sucks" sucks. If you have problems understanding 
the output (inferred types?) from the top level then post a question here
or on comp.lang.functional.

> So far from the little I have seen it is not the libraries that
> it is a problem. It is the docs and the examples. I asked once
> if it was possible to contribute to the documentation and got no
> answer. 

How about just writing some docs that you'd like to see and putting them
on a web page? No need to ask the team at INRIA for permission, and
anyways, I'd rather that they were busy adding recursive modules and 
overloading to Ocaml than adding more instructional docs ;-).

> For instance there is no samples with the libraries so
> for beginners it is difficult at the beginning to understand how
> to use a library because there are no examples. 

If you ask a specific question like "Can someone show me how to use the 
Format module to do ..." then someone, maybe even me, will happily cobble 
together an example, but vague comments like the above are tough to help
with. Hopefully when we have an English version of the OReilly book you'll 
find more satisfactory examples.

> To make things worse I bought a book to try and learn Caml and the
> examples/exercises are highly math driven. I find this too be a
> horrible thing to have done. 

Most people who learn Ocaml are strong in maths so this is natural. If you
stick with Caml you'll find lots of compiler oriented examples too. Sorry 
to be a broken record here but why not ask for examples of the kind that 
specifically interest you? If you want to understand Unison then maybe you 
are more of a systems programming kind of guy and you want to understand
how the Unix module can be used? 

> When I look at the exercises I 
> spend more time trying to thing how the math is going to work
> out than how I am going to program the thing. Example: the first
> exercise is to prove that Ax^2 + bx + c = 0 is solvable given
> three parameters a,b,c. 

Well, the translator must have been inaccurate because it is *always*
solvable, so you have to infer that they mean "has real roots" :-). 

> For someone who is contantly doing math
> this is probably trivial, but I have not taken any math clases
> on years and I don't see the point on linking the exercises so
> much to math. This perhaps is linked to the previous(current?)
> set of intended users.

Unfortunately, we run into the problem that a large number of potential 
users probably couldn't care less about the examples that interest you
either. If you come up with some examples that you find illuminating and
would like to share them then by all means do so.

> If Ocaml is to ever become a general purpose language then the
> docs/examples need to be less theorical and more practical.

Ocaml already is a general purpose language, thanks. I agree that we need 
more documents in order to spread the knowledge. However, I like the 
examples that you find too theoretical. I work in software for VLSI
design, so examples from maths, compilers, computational geometry,
graph theory, etc. all seem very practical to me. 

> >2 for good syntax (it is very easy to spend a lot of time trying to get the
> >program to compile, for example I called a attribute in a record 'value',
> >and that works sometimes I have noticed :-),
> 
> I agree with the 2. I don't know if it is my lack of having
> worked with other functional languages, but I find the Ocaml
> syntax strange.

I'm not terribly thrilled by the syntax either, but I hardly see how it
gets a 2 from you after you showed such deference to Perl. Perl and C++ 
are syntactic abominations.

-- Brian

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

[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/

LINUX MANDRAKE -> CAMLTK?

[mlf]

i need help because i can't compile camltk library and i need this library .
i got linux mandrake 7.1 version
i use tk8 and tcl8.
the compilation stop because it can't find tk_createmainwindow
what can i do ?

Re: LINUX MANDRAKE -> CAMLTK?

[Pierre Weis]

> i need help because i can't compile camltk library and i need this library .
> i got linux mandrake 7.1 version
> i use tk8 and tcl8.
> the compilation stop because it can't find tk_createmainwindow
> what can i do ?

Right, this function desappeared from recent versions of Tk. I
corrected this interface in the current source files of Caml Light
(the 0.75 next version of Caml Light). You can pick up the new version
of the CamlTk library for Caml Light as:

http://pauillac.inria.fr/~weis/camltk4.tar.gz

You should install the file in the contrib directory in place of the
old version, and run make as usual.

Hope this helps,

Pierre Weis

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

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

[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

[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]

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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/