From: =?ISO-8859-15?Q?Andr=E9_Thieme?=
Subject: creating and assigning keys in a hashtable
Date:
Message-ID: <d5q78f$7j4$1@ulric.tng.de>
Ron Garret explains in one of his papers:
"Note that there is a difference between creating a variable for the
first time, and changing the value stored in a variable that already
exists. Some languages (like Python) hide this distinction, using the
same syntax for both operations. While this may seem convenient at
first glance, it is generally considered a bad idea because it makes
it impossible to tell the difference between the creation of a new
variable and an assignment to an existing variable that contains a
typographical error. This in turn often leads to hard-to-find bugs."
( http://www.flownet.com/gat/specials.pdf )
I agree to that and see that CLs solution is better.
However, what about this problem regarding hashtables? When I have a
hashtable I can simply say:
(setf (gethash 'geier ht) "Hi")
This way I create a key for the first time and change a value stored
with this specific key. In the context of Rons paper this does not look
so good. What do you think about it?
Andr�
--
[Ron Garret wants creation and assignment to be different
>operations in order to avoid hard-to-find bugs]
>I agree to that and see that CLs solution is better.
>However, what about this problem regarding hashtables? When I >have a
>hashtable I can simply say:
>(setf (gethash 'geier ht) "Hi")
I don't think the creators of Common Lisp agreed with Ron Garret at
all. In what way is CL's solution "better" in this respect? Try typing
the following lines into your favorite Lisp:
(print a) --> error, A does not exist
(setf a 3)
(print a) --> 3
(setf a 5)
(print a) --> 5
The creation (of variable A equal to 3) and assignment (of 5 to the
variable A) look rather similar to me ^^
On the other hand, if I do this inside of a function, I will get
warning messages about "A assumed special" so I guess as a bug it
wouldn't be so hard to find.
The real key, though, is that functions should be debugged one at a
time. Write a short function. Test it immediately. If it doesn't work
right because of a typo... and you know which three line block of code
has the mistake... how hard to find can it be?
From: Pascal Costanza
Subject: Re: creating and assigning keys in a hashtable
Date:
Message-ID: <3ec098F26cn7U2@individual.net>
Eric Lavigne wrote:
> [Ron Garret wants creation and assignment to be different
>
>>operations in order to avoid hard-to-find bugs]
>
>>I agree to that and see that CLs solution is better.
>>However, what about this problem regarding hashtables? When I >have a
>>hashtable I can simply say:
>
>>(setf (gethash 'geier ht) "Hi")
>
> I don't think the creators of Common Lisp agreed with Ron Garret at
> all. In what way is CL's solution "better" in this respect? Try typing
> the following lines into your favorite Lisp:
> (print a) --> error, A does not exist
> (setf a 3)
> (print a) --> 3
> (setf a 5)
> (print a) --> 5
>
> The creation (of variable A equal to 3) and assignment (of 5 to the
> variable A) look rather similar to me ^^
This is outside of the scope of ANSI Common Lisp. This is only provided
by CL implementations for convenience in the listener.
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
Pascal Costanza <··@p-cos.net> writes:
> Eric Lavigne wrote:
>
> > [Ron Garret wants creation and assignment to be different
> >
> >>operations in order to avoid hard-to-find bugs]
> >
> >>I agree to that and see that CLs solution is better.
> >>However, what about this problem regarding hashtables? When I >have a
> >>hashtable I can simply say:
> >
> >>(setf (gethash 'geier ht) "Hi")
> > I don't think the creators of Common Lisp agreed with Ron Garret at
> > all. In what way is CL's solution "better" in this respect? Try typing
> > the following lines into your favorite Lisp:
> > (print a) --> error, A does not exist
> > (setf a 3)
> > (print a) --> 3
> > (setf a 5)
> > (print a) --> 5
> > The creation (of variable A equal to 3) and assignment (of 5 to the
> > variable A) look rather similar to me ^^
>
> This is outside of the scope of ANSI Common Lisp. This is only
> provided by CL implementations for convenience in the listener.
>
I have never and would never write anything like this. As you said
you will receive a warning or note that the variable is assumed special.
The special could be defvar'd in another file so this is acceptable.
However the code will not run if the variable isn't actually a special.
That it may work in the listener is, as Pascal pointed out, simply
provided by the implementor as a convenience.
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: creating and assigning keys in a hashtable
Date:
Message-ID: <87y8an1d31.fsf@qrnik.zagroda>
Andr� Thieme <······························@justmail.de> writes:
> "[...] While this may seem convenient at first glance, it is
> generally considered a bad idea because it makes it impossible to
> tell the difference between the creation of a new variable and an
> assignment to an existing variable that contains a typographical
> error. [...]"
> However, what about this problem regarding hashtables?
1. Hashtables are generally used when keys are not literals in the
program but are computed dynamically.
If keys were literals, you would probably use a structure.
2. IMHO a far bigger problem with implicit variable declarations is
that it's impossible to determine the scope of a variable, i.e.
which accesses should share the same location.
This problem doesn't apply to hash tables because a hash table is
a single scope. You use separate hash tables for separate scopes.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Andr� Thieme wrote:
> "Note that there is a difference between creating a variable for the
> first time, and changing the value stored in a variable that already
> exists.
I fear this thread will quickly devolve into nonsense because it is
based on semantic assumptions that are quite different from those
required in CL. In ANSI CL, all possible variables always exist,
at least providing that the symbol naming the variable exists.
It is a good thing, of course, for an implementation to warn the
programmer when he mentions an otherwise-unknown variable, because
that is likely a spelling error. In most implementations this
warning is the responsibility of the compiler, and in most
implementations, convenience forms such as a (setf q ...) entered
at top level to a lisp listener are not seen by the compiler.
Even in implementations in which the top-level repl loop is
processed by the compiler, it is reasonable for the repl to
suppress warnings about undeclared variables because the utility
of a repl so typically exploits free variables.
I think the fundamental confusion behind this thread is conflating
a free variable in _code_ with a free variable used for convenience
in the repl. I don't think of them as the same thing at all...