Tomasz Wegrzanowski
7/25/2006 4:17:00 AM
On 7/25/06, William James <w_a_x_man@yahoo.com> wrote:
[...]
I have to say that I come more from Objective Caml/Ruby than
from Scheme/Common Lisp, so I don't know much how Lisps
are doing different things. I want is an operator "rebind in loca
lexical environment" (global or the current lambda/defsyntax's),
more or less like Ruby's = or Python's =.
So the simple question I have is - what names does it have
in existing Lisps, and what should it be called in RLisp ?
Now why I called it let:
In Objective Caml the most similar construct is called let:
let veclen x y = (* this let changes global veclen *)
let x2 = x *. x in (* this let operates is local, but is too lexical *)
let y2 = y *. y in
let z2 = x2 +. y2 in
sqrt z2
;;
Now everybody hates its syntax and some people would much rather have it be:
let veclen x y = (* this let changes global veclen *)
let x2 = x *. x
let y2 = y *. y
let z2 = x2 +. y2
sqrt z2
;;
That was the main reason why I used let.
In Nemerle (which is ML inside, it just throw away ML syntax that nobody really
likes):
def veclen (x,y) {
def x2 = x * x; // This is immutable binding, not a variable
def y2 = y * y;
def z2 = x2 + y2;
sqrt(z2)
}
That's even more similar to RLisp's let, but def would confuse
Ruby programmers too much (much more than let),
as def is never used for local binding.
setq in Common Lisp seems to have completely different semantics -
it changes variable, not just rebinds it locally.
> (setq a 2)
2
> (funcall (lambda () (setq a 3) a))
3
> a
3
> (funcall (lambda () (setq b 3) b))
3
> b
3
In RLisp a would be 2 and b would be undefined after the functions return.
So calling it setq would be about as confusing.
> With your 'let' you are doing something different than
> all other Lisps are doing with 'let', so you should give
> it a different name. By using the same name, you are
> creating confusion and making it more difficult to port
> code between other Lisps and yours. You are making
> it more certain that the only people who will use your
> Lisp are people who know no other Lisp. Is that
> what you want? Do you think that your Lisp is so
> magnificent that people will abandon all others and
> use only yours?
RLisp is just-for-fun kind of Lisp, what lets me break all the rules.
I did not want just another Scheme.
And let means different things in different Lisps.
Scheme's let is different from Arc's. So it's not that radical.
> If you would keep the semantics
> of your Lisp as similar as possible to the semantics
> of other Lisps, you would make it easier for others
> to learn it and, having learned it, to remember it.
> When Matz added features to Ruby from other
> languages, he tried to keep the original names.
> Consider Ruby's inject; it does the same thing
> as Smalltalk's inject. If it didn't, a Smalltalk programmer
> using Ruby would continually have to remember that
> he is dealing with a peculiar, nonstandard inject and
> not with the widely known, original inject.
> Changing the meaning of existing words may satisfy
> your inner urges, but it helps nobody else.
I agree with the sentiment, but I don't see it as changing
the meaning of existing word. I simply needed to name
an important operation somehow. And please notice that
in Ruby many things that are called the same as in different
languages are completely different way, just in the
most common cases happen to work like expected.
Like Perl's scalar variables $<whatever> become global variables,
what incidentally lets $_, $1 etc. work, and what was just brilliant.
[about letn/let*]
I know about let*, letrec and all the Scheme magic, but I find
it very inelegant for a language to have multiple binding operators,
so I tried to do with just one :-)