I checked out hyperspec and found much to my liking though the piece on
setf did not deal with the differences between it and defvar and setf.
While i can see the uncond/cond difference between defvar and setf, is
the only noteable difference between defparameter and setf what it
returns: defparameter:dynamic variable
setf: form assigned to the dynamic variable.
Also faced with this question:
Q>Using MAPCAR define a function called add-two that take a list of
numvers of any arbitrary length and adds two to every element of that
list.
Is this the best answer:
A>(MAPCAR '1+ (mapcar '1+ (4 5 6))) where (4 5 6) are the list.
Thanks to both Chris' for their help:)
samwise gamgee <········@yahoo.com> writes:
> I checked out hyperspec and found much to my liking though the piece on
> setf did not deal with the differences between it and defvar and setf.
> While i can see the uncond/cond difference between defvar and setf, is
> the only noteable difference between defparameter and setf what it
> returns: defparameter:dynamic variable
> setf: form assigned to the dynamic variable.
The reason there is no mention of the "differences" is that the HyperSpec
is not a tutorial document. It is not its responsibility to make
comparisons. It is already a long document, and the number of things that
could be compared are endless.
I can't even understand what you've said well enough to comment but suspect
you're confused. So here goes...
SETQ assigns variables. It is the most primitive.
[By special exception, it expands symbol macros and calls SETF when it
needs to, but you should think of this feature of SETQ as a conceptually
layered feature.]
SETF assigns any macro form that is SETF'able.
When SETF's first argument is a symbol, it is the same as SETQ of that
symbol. Otherwise, the intent is that it assigns some structure using
methods defined in any of a variety of ways. See SETF's doc for details.
Some people use SETF exclusively and never SETQ. I find this confusing
myself but accept that others do not. I think SETF should only be used
for modifying structure, and SETQ only for language-level side-effects
(meta side-effects). I do not regard SETQ as a destructive operator, since
it mutates no piece of first-class data in the system; I do regard SETF
as a destructive operator since it mutates first class data.
DEFVAR, DEFPARAMETER, and DEFCONSTANT are built at a different abstraction
level than SETQ.
DEFVAR and DEFPARAMETER do the combined service of
- in some implementations, recording the "definitional home" of the variable
- declaring the indicated variable special in compiler and runtime
- assigning the variable (either conditionally, as in DEFVAR, which assigns
only in the case that the variable is unbound, or unconditionally, as in
DEFPARAMETER).
DEFCONSTANT does the combined service of
- in some implementations, recording the "definitional home" of the
constant variable
- declaring the indicated variable to be constant in compiler and runtime
- assigning the variable permanently, so that it is available both as a
variable at runtime and also potentially as a constant to be folded in
at compile time.
As to use:
- Use SETQ to assign a variable.
- Use SETF to mutate a structure.
- Use DEFVAR or DEFPARAMETER in exactly one place to declare a
variable special and give it an initial value.
- Use DEFCONSTANT in exactly one place to declare a constant variable
(i.e., a named constant)
The difference between DEFVAR and DEFPARAMETER is subtle. In general, use
DEFVAR when reloading the file would clobber valuable data that you don't
wnat clobbered. Two examples of this are:
- Use DEFVAR when initializing a user-assignable option variable.
e.g., (DEFVAR *PREFERRED-SCREEN-LINES* 24)
If the user has set this in an init file with
(SETQ *PREFERRED-SCREEN-LINES* 48)
you don't want to override his/her value by loading (or reloading)
your file.
- Use DEFVAR when initializing a data repository others will add to,
especially if not all in the same file. e.g.,
(DEFVAR *DECLARED-FROBS* '())
(DEFMACRO DEF-FROB (NAME) `(PUSH `',NAME *DECLARED-FROBS*))
If you do a lot of DEF-FROB forms in another file, they will change
the value of *DECLARED-FROBS*. If you reload only this file that
has the DEFVAR, you would clobber the value to () if you'd used
DEFPARAMETER, so you use DEFVAR to keep reinitialization from
happening. Make a
(DEFUN INIT-FROBS () (SETQ *DECLARED-FROBS* '()))
in case you need to re-init the frobs.
- Use DEFPARAMETER in other cases so that reloading the file will reset
the value of the variable to "factory settings".
Kent M Pitman <······@world.std.com> writes:
> SETQ assigns variables. It is the most primitive.
I would've named SET the most primitive, but I see it has been
deprecated. Why?
> Some people use SETF exclusively and never SETQ. I find this confusing
> myself but accept that others do not. I think SETF should only be used
> for modifying structure, and SETQ only for language-level side-effects
> (meta side-effects). I do not regard SETQ as a destructive operator, since
> it mutates no piece of first-class data in the system; I do regard SETF
> as a destructive operator since it mutates first class data.
I exclusively use SETF for a number of reasons.
One is that I'm also fond of the (setf place-1 value-1 place-2 value-2
...) form with multiple pairs so if I'd use SETQ I could note in the
middle that I needed to change (foo x) and so I'd need SETF anyways.
Another is that I see SETF as the inverse of the access operation. If
(foo x y z w) accesses a piece of information (setf (foo x y z w) a)
should make it that the next call to (foo x y z w) returns a. I don't
like to break this generality by singling out accessing the symbol
value as needing a special setter.
--
Lieven Marchand <···@wyrd.be>
Gla�r ok reifr skyli gumna hverr, unz sinn b��r bana.
Lieven Marchand <···@wyrd.be> writes:
>
> I would've named SET the most primitive, but I see it has been
> deprecated. Why?
Once SYMBOL-VALUE is an accessor, you don't really need SET I guess.
But SET is not more primitive than SETQ, it's different - it doesn't
do lexical bindings at all.
--tim
Kent M Pitman <······@world.std.com> writes:
> (DEFMACRO DEF-FROB (NAME) `(PUSH `',NAME *DECLARED-FROBS*))
Is it conventional in Common Lisp to have a hyphen in DEF-FROB?
In Emacs Lisp, such macros seem to be called deffrob or
define-frob; the only exception I could find is def-edebug-spec
which has another hyphen too (like window-live-p vs. windowp).
Kalle Olavi Niemitalo <···@iki.fi> writes:
>
> Kent M Pitman <······@world.std.com> writes:
>
> > (DEFMACRO DEF-FROB (NAME) `(PUSH `',NAME *DECLARED-FROBS*))
>
> Is it conventional in Common Lisp to have a hyphen in DEF-FROB?
> In Emacs Lisp, such macros seem to be called deffrob or
> define-frob; the only exception I could find is def-edebug-spec
> which has another hyphen too (like window-live-p vs. windowp).
I used a hyphen so that if you didn't know that frob was a made-up word
you'd have a better chance of parsing "frob" out of my example.
Mostly CL folks would use DEFFROB for such a small word, but it probably
varies some. Consider, for example, that in the most common example,
DEFUN, there is a contracted "F", suggesting DEFROB might also occur.
But that doesn't mean your overall observations aren't still good general
rules. Just expect general rules to get broken sometimes; as a general
rule, general rules are neither wholly general nor wholly rules.
Kent M Pitman <······@world.std.com> writes:
>
> Mostly CL folks would use DEFFROB for such a small word, but it probably
> varies some. Consider, for example, that in the most common example,
> DEFUN, there is a contracted "F", suggesting DEFROB might also occur.
> But that doesn't mean your overall observations aren't still good general
> rules. Just expect general rules to get broken sometimes; as a general
> rule, general rules are neither wholly general nor wholly rules.
Surely DEFROB is a function which removes all the frobs from
something? Some kind of optimiser I suppose. Worryingly, DEFUN
appears to be a function that removes all the fun from something:
after using it all your code is converted to C++.
--tim
In article <···············@tfeb.org>, Tim Bradshaw <···@tfeb.org> wrote:
>Kent M Pitman <······@world.std.com> writes:
>
>>
>> Mostly CL folks would use DEFFROB for such a small word, but it probably
>> varies some. Consider, for example, that in the most common example,
>> DEFUN, there is a contracted "F", suggesting DEFROB might also occur.
DEFUN should not be considered an archtetype. It comes to us from
prehistoric times, before there were any other defining forms so there
wasn't a need for a naming convention. It's similar to a feature of
natural languages, where the words that represent very basic concepts are
also the ones with nonstandard inflections and conjugations in almost all
languages. A related characteristic of terms like these is that they tend
to vary most between languages that are otherwise very similar (e.g. there
are Lisp dialects whose word for DEFUN are DE, DEFINE, and other variants).
On the other hand, when the Flavor system was developed, HIC did pattern
its main macro after DEFUN, calling it DEFLAVOR rather than DEFFLAVOR
(despite the potention that Tim might think that this is used to make
something less flavorful, not more so :-).
>> But that doesn't mean your overall observations aren't still good general
>> rules. Just expect general rules to get broken sometimes; as a general
>> rule, general rules are neither wholly general nor wholly rules.
>
>Surely DEFROB is a function which removes all the frobs from
>something?
Either that, or it defines Robs:
(defrob robert :formality :very-formal)
(defrob bob :formality :somewhat-formal)
(defrob rob :formality :informal)
(defrob roberto :language :spanish)
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
In article <·················@burlma1-snr2>, Barry Margolin
<······@genuity.net> wrote:
>DEFUN should not be considered an archtetype. It comes to us from
>prehistoric times, before there were any other defining forms so there
>wasn't a need for a naming convention. ... there
>are Lisp dialects whose word for DEFUN are DE, DEFINE, and other variants).
Those were the days. DE, DF and DM. Think of all the typing time
we saved back then!
On Thu, 26 Apr 2001 17:56:06 GMT, Kent M Pitman <······@world.std.com>
wrote:
> (DEFVAR *DECLARED-FROBS* '())
> (DEFMACRO DEF-FROB (NAME) `(PUSH `',NAME *DECLARED-FROBS*))
What is the purpose of the backquote in front of NAME in the PUSH form?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Paolo Amoroso <·······@mclink.it> writes:
> On Thu, 26 Apr 2001 17:56:06 GMT, Kent M Pitman <······@world.std.com>
> wrote:
>
> > (DEFVAR *DECLARED-FROBS* '())
> > (DEFMACRO DEF-FROB (NAME) `(PUSH `',NAME *DECLARED-FROBS*))
>
> What is the purpose of the backquote in front of NAME in the PUSH form?
It's there to see if you reading carefully, of course!
You're right. The outer backquote is "enough". The inner one makes a mess
of things.
(DEFMACRO DEF-FROB (NAME) `(PUSH ',NAME *DECLARED-FROBS*))
In old Teco-based Emacs, I had flashing backquotes (typing the comma flashed
the matching backquote) and I didn't make mistakes like that. Sigh.
samwise gamgee <········@yahoo.com> writes:
> Q>Using MAPCAR define a function called add-two that take a list of
> numvers of any arbitrary length and adds two to every element of that
> list.
> Is this the best answer:
> A>(MAPCAR '1+ (mapcar '1+ (4 5 6))) where (4 5 6) are the list.
When adding money to your bank account, do you do it a penny at a time or
do you just go ahead and deposit all the money at once? Can you see how
the penny at a time approach might take so long that you'd give up for any
seriously large operation?
You really want a 2+ function. Do you know how 1+ is defined? Maybe you
could make a 2+ and then use that.