The immediate stimulus for this post is that I had some examples on my
FSet page on CLiki that looked like:
* (setq some-var (some-value))
... value of some-var ...
Someone changed them to use `defconstant'. Probably that change was
inspired by the 20-or-so lines of warnings SBCL prints in response to
an interactive `setq' of a new (i.e. previously undeclared) variable
-- said warnings also being part of the stimulus for this post -- and
by considerations such as those in this discussion:
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/44a782d680926bc9/7074027eb1ca6522
I want to express my dismay at this turn of events. It's simply
ridiculous, IMO, that one can't use `setq' in this way. None of the
`def-' forms (`defvar', `defparameter', etc.) is an adequate
replacement, either, because:
() Their names are too long for interactive use.
() None of them evaluate to the value being set; they all return the
name of the variable being declared. So interactively, one must first
write the `def-' form, then evaluate the variable again to see its
value. This, again, is too much typing.
() None of them has the right semantics anyway. As explained in
detail in the above-linked discussion, one really doesn't want a
variable used this way to be declared globally special; this rules out
`defvar' and `defparameter'. But `defconstant' carries an additional
semantic weight that is also undesirable.
I am, of course, perfectly capable of defining a macro that does what
I want for my own use. However, this doesn't solve my problem. I
want to be able to publish examples of interaction with a Lisp REPL
using existing CL primitives, so that potential users of my software
could try them out.
I also can't believe that it was the considered intent of the ANSI
committee to render `setq' unusable for this purpose. This usage was
routine on the Lisp Machines and in Allegro at the time the standard
was being finalized. It's only quite recently that this issue has
emerged.
So what I want -- and I'm well aware of the limitations of what I'm
asking for, but nonetheless -- is the sense of the newsgroup
concerning the following resolution:
() The appropriate primitive for interactive setting of new variables
is `setq'.
() When evaluating such a `setq' form, an implementation should not
declare the variable globally special.
() When evaluating such a `setq' form, an implementation should not
emit more than one line of warning to the effect that the variable is
unknown.
I understand that we can't claim to annotate the ANSI standard; we've
just been over that. All I'm asking for is your opinion. (Surely no
one here will mind providing that :) Do you agree that it would be a
good thing if implementations followed the above guidelines? If not,
why not?
-- Scott
Scott Burson <········@gmail.com> writes:
> The immediate stimulus for this post is that I had some examples on my
> FSet page on CLiki that looked like:
>
> * (setq some-var (some-value))
> ... value of some-var ...
>
> Someone changed them to use `defconstant'. Probably that change was
> inspired by the 20-or-so lines of warnings SBCL prints in response to
> an interactive `setq' of a new (i.e. previously undeclared) variable
> -- said warnings also being part of the stimulus for this post -- and
> by considerations such as those in this discussion:
>
> http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/44a782d680926bc9/7074027eb1ca6522
>
> I want to express my dismay at this turn of events.
You shouldn't be so emotional about these matters.
> It's simply
> ridiculous, IMO, that one can't use `setq' in this way. None of the
> `def-' forms (`defvar', `defparameter', etc.) is an adequate
> replacement, either, because:
>
> () Their names are too long for interactive use.
This is not a valid objection, because for interactive use you can
write your own interactive tools.
For example, I've got a LSPACK "command" that uses LIST-ALL-PACKAGES
and prints a nicely formated report of the available packages. It's
in my com.informatimago.common-lisp.INTERACTIVE package.
You can easily write an interactive shortcut:
(defmacro s (var val &rest others)
`(progn (defparameter ,var ,val "interactive global variable")
,@(if others
`((s ,@others))
`(,var))))
(s *a* 1 *b* 2)
You can put it in your own interactive package, and put
(use-package "MY-OWN-INTERACTIVE-STUFF")
in your ~/.clisprc or ~/.sbclrc or whatever your implementation uses.
> () None of them evaluate to the value being set; they all return the
> name of the variable being declared. So interactively, one must first
> write the `def-' form, then evaluate the variable again to see its
> value. This, again, is too much typing.
See above.
> () None of them has the right semantics anyway. As explained in
> detail in the above-linked discussion, one really doesn't want a
> variable used this way to be declared globally special; this rules out
> `defvar' and `defparameter'. But `defconstant' carries an additional
> semantic weight that is also undesirable.
This have been discussed at length at least recently here. Use google
groups. The good thing is that your interactive shortcut S can define
a "pseudo-lexical" global variable as described in this recent thread
instead of DEFPARAMETER.
> I am, of course, perfectly capable of defining a macro that does what
> I want for my own use. However, this doesn't solve my problem. I
> want to be able to publish examples of interaction with a Lisp REPL
> using existing CL primitives, so that potential users of my software
> could try them out.
Well, Common Lisp is a meta programming language...
> I also can't believe that it was the considered intent of the ANSI
> committee to render `setq' unusable for this purpose. This usage was
> routine on the Lisp Machines and in Allegro at the time the standard
> was being finalized. It's only quite recently that this issue has
> emerged.
It's not so much that the intend was to render it unusuable, than to
allow for implementation doing something else.
If your implementation implements a top-level SETQ without declaring
special the assigned variables, the be happy and use it. But your
tutorial will be specific to this kind of implementations.
> So what I want -- and I'm well aware of the limitations of what I'm
> asking for, but nonetheless -- is the sense of the newsgroup
> concerning the following resolution:
>
> () The appropriate primitive for interactive setting of new variables
> is `setq'.
>
> () When evaluating such a `setq' form, an implementation should not
> declare the variable globally special.
>
> () When evaluating such a `setq' form, an implementation should not
> emit more than one line of warning to the effect that the variable is
> unknown.
>
> I understand that we can't claim to annotate the ANSI standard; we've
> just been over that. All I'm asking for is your opinion. (Surely no
> one here will mind providing that :) Do you agree that it would be a
> good thing if implementations followed the above guidelines? If not,
> why not?
As a user, I don't mind writting DEFPARAMETER. I don't know if it
would be a good thing to what you want. I guess it's the implementors
who would have to answer.
Since the standard doesn't impose anything here, the implementors are
free to do as you want, given the right incentives...
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
Pascal Bourguignon <···@informatimago.com> writes:
> Scott Burson <········@gmail.com> writes:
>
>> It's simply
>> ridiculous, IMO, that one can't use `setq' in this way. None of the
>> `def-' forms (`defvar', `defparameter', etc.) is an adequate
>> replacement, either, because:
>>
>> () Their names are too long for interactive use.
>
> This is not a valid objection, because for interactive use you can
> write your own interactive tools.
Moreover, any decent environment (like SLIME, commercial lisps, etc)
will have some mechanism to save typing. Eg in SLIME, defpar[TAB]
will expand into defparameter, defv[TAB] to defvar, etc. The OP could
mention this at the start of his tutorial for newbies.
Tamas
[Ah its been more than a month since this was last discussed on CLL!
I see this thread: <····························@news-europe.giganews.com>
( joswig-3A9400.21413106062007 ! news-europe.giganews.com ) ]
* Scott Burson <·······················@i38g2000prf.XXX> :
| I want to express my dismay at this turn of events. It's simply
| ridiculous, IMO, that one can't use `setq' in this way. None of the
| `def-' forms (`defvar', `defparameter', etc.) is an adequate
| replacement, either, because:
[...]
| I also can't believe that it was the considered intent of the ANSI
| committee to render `setq' unusable for this purpose. This usage was
| routine on the Lisp Machines and in Allegro at the time the standard
| was being finalized. It's only quite recently that this issue has
| emerged.
|
| () The appropriate primitive for interactive setting of new variables
| is `setq'.
Yes
| () When evaluating such a `setq' form, an implementation should not
| declare the variable globally special.
Only if *TOP-LEVEL-AUTO-DECLARE* is non-NIL.
The rationale for proposing this behaviour rather than what you said is
that there is no mention in the standard of top level lexical variables.
Therefore it is an acceptable worldview that setting a symbol value
would make a variable special, unless explicitly documented otherwise.
| () When evaluating such a `setq' form, an implementation should not
| emit more than one line of warning to the effect that the variable is
| unknown.
If *TOP-LEVEL-AUTO-DECLARE* is NIL, emit one line of warning when
evaluating the SETQ form, and one line of warning when using the
variable.
In interpreted use, there should, in general be no "unknown variable"
warnings, but if a form is compiled the semantics of your variable are
not clear: You can't take symbol-values of lexical variables. Variables
either are lexical or special. This variable is not declared special.
(With the ANSI spec, the compiler can go legally mad.) But the compiler
will have to put out code that looks up symbol-value. So an "unknown
variable" warning would be in order?
If *TOP-LEVEL-AUTO-DECLARE* is [not NIL but] :WARN, print a single
warning, but declare the variable special, along the lines of: "Warning:
Declaring $A special"
*TOP-LEVEL-AUTODECLARE* is CMUCL specific, It is documented. I can
understand it's behaviour, and set the value in my INIT file to suit my
preference. I find this an acceptable thing to do, and the mechanism
provided by CMUCL to be sound and sensible.
However *TOP-LEVEL-AUTODECLARE* comes up for periodic bashing with
complaints about "unintuitive behaviour" and "surprises".
The debate seems to center around the "newbie experience". This being
based on assumptions on a new user *might have*, makes it more of a
political debate. And I suspect that only reason for taking up such a
debate is that championing the cause and winning *might imply* that the
newbie population that have been convinced that they want some behaviour
and now have it, are now your followers, by some weird social logic.
| I understand that we can't claim to annotate the ANSI standard; we've
| just been over that. All I'm asking for is your opinion. (Surely no
| one here will mind providing that :) Do you agree that it would be a
| good thing if implementations followed the above guidelines? If not,
| why not?
There you have my opinion :)
My vote is for the *TOP-LEVEL-AUTODECLARE* mechanism which can be set in
an init file, available in all lisps.
--
Madhu
On Jul 16, 5:23 am, Madhu <·······@meer.net> wrote:
> The debate seems to center around the "newbie experience".
Yes, exactly, and thank you for putting it more clearly than I did.
It's about the newbie experience, and about how we write tutorial
material.
> This being
> based on assumptions on a new user *might have*, makes it more of a
> political debate. And I suspect that only reason for taking up such a
> debate is that championing the cause and winning *might imply* that the
> newbie population that have been convinced that they want some behaviour
> and now have it, are now your followers, by some weird social logic.
Yes, it is a political debate, not a technical one. I don't care
about followers, but I do care about growing the Lisp community.
Telling people not to use `setq' this way strikes me as unnecessarily
legalistic and somewhat forbidding, particularly when many
implementations accept it without a hiccup.
> My vote is for the *TOP-LEVEL-AUTODECLARE* mechanism which can be set in
> an init file, available in all lisps.
Okay, thanks.
-- Scott