stuck on binding problem:
this is what code should do:
>>(setf s '(())) ;initialization to empty
(NIL)
>>s ; can see that s is bound here
(NIL)
>>(setf (car s) 'a) ; replace head of list s with a
A
>>s ; check it, and it's there
(A)
-------------------------------------
in code, i have little more;
(defun stack-init (name)
( setf name '(()) ) ) ;; want to initialize to empty list.
(defun pushS (name elem)
( setf (car name) elem ) ) ;; this type of thing in text.
-------------------------------------
get (NIL) as list after stack-init, but somehow elem not bound to
name:
>(stack-init 's)
(NIL) ;; so far so good
>s ;; try to check s ..
Error: The variable S is unbound.
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by EVAL.
Broken at EVAL. Type :H for Help.
using gcl lisp version. help no good. can't progress unless get this
bound.
thnx if any knowledgeable person can supply divination ..
In article <·······················@news2.jacksonville.net> , "Bjorn Goldis"
<·······@MediaOne.Net> wrote:
> stuck on binding problem:
> this is what code should do:
>
>>>(setf s '(())) ;initialization to empty
> (NIL)
>>>s ; can see that s is bound here
> (NIL)
>>>(setf (car s) 'a) ; replace head of list s with a
> A
>>>s ; check it, and it's there
> (A)
> -------------------------------------
> in code, i have little more;
>
> (defun stack-init (name)
> ( setf name '(()) ) ) ;; want to initialize to empty list.
>
This is setting the local variable NAME to '(()). Not what you want. If
you're planning to pass a name, you need a form that will evaluate NAME to
get the name. One way to do this is to use SET instead of SETF (see further
below).
If you're willing to say (STACK-INIT S) rather than (STACK-INIT 'S), then
you can define
(defmacro stack-init (name)
`(setq ,name (list '())))
Note that it's generally a bad idea to use constants to initialize mutable
values (that is, composite values whose components will be changed by the
program).
> (defun pushS (name elem)
> ( setf (car name) elem ) ) ;; this type of thing in text.
If you must call this as (PUSHS 's value), then see further below.
If you're willing to call it without the extra quote, define
(defmacro pushS (name elem)
`(setf (car ,name) ,elem)) ;; this type of thing in text.
You would invoke these as
(stack-init s)
(pushS s 'foo)
If you're really trying to implement the functions suggested by your choice
of names, you should take a look at CL:PUSH (the PUSH symbol in the Common
Lisp package).
You'll find online help for Common Lisp at
<http://www.harlequin.com/books/HyperSpec/>. Note that your environment
(GCL) will probably have quite a few differences from Common Lisp.
>
> -------------------------------------
> get (NIL) as list after stack-init, but somehow elem not bound to
> name:
>
>>(stack-init 's)
> (NIL) ;; so far so good
>
>>s ;; try to check s ..
>
> Error: The variable S is unbound.
Try this:
(defun stack-init (name)
(set name (list '()))) ;; want to initialize to empty list.
(defun pushS (name elem)
(set name (cons elem (rest (symbol-value name)))))
(stack-init 's)
(pushS 's 'foo)
s
--
David B. Lamkins <http://www.teleport.com/~dlamkins/>
((lambda (x) (list x (list 'quote x)))
'(lambda (x) (list x (list 'quote x))))
In article <·······················@news1.teleport.com>,
"David B. Lamkins" <········@teleport.com> wrote:
(...)
> (defmacro stack-init (name)
> `(setq ,name (list '())))
(...)
> (defmacro pushS (name elem)
> `(setf (car ,name) ,elem)) ;; this type of thing in text.
It should be noted that while this approach is not wrong per se,^1
it takes some expertise to be able to see when it is acceptable
and when it is not (I'd say that the latter is more likely).
____________________________________________________________
^1 except that pushS should involve some consing too if it is to
behave as a stack push operation, as below
Personally, I believe that macros should not be used for this
kind of thing unless there is really serious justification.
(...)
> (defun stack-init (name)
> (set name (list '()))) ;; want to initialize to empty list.
>
> (defun pushS (name elem)
> (set name (cons elem (rest (symbol-value name)))))
First, the minor issue: SET is not recommended to be used any more,
use SETF of SYMBOL-FUNCTION instead, e.g.
(setf (symbol-function name) (list '()))
in the body of STACK-INIT above.
Second, the typically proper way to do this---which I'd like to
see as the only way suggested in a Lisp textbook---would be to:
* define a class, say SIMPLE-STACK, with a single slot with an
initform of '();
* define MAKE-STACK as calling MAKE-INSTANCE of SIMPLE-STACK;
* define (a method) STACK-PUSH for instances of class SIMPLE-STACK
which does PUSH on the slot.
Then use this like:
(let ((s1 (make-stack)))
...
(stack-push 'thing s1)
...)
If, for some strange reason, this exercise must be done without CLOS,
which I'd argue is the Wrong Thing, then this could be the abstractions
under that unnatural restriction:
(defun make-stack () (make-array nil :initial-value '()))
(defun stack-push (thing stack) (push thing (aref stack))
One final note: a name that contains `init' implies that the
object has been already allocated elsewhere; usually the interface
to a set of abstractions provides `making' as a single operation,
which internally combines allocation and initialisation. Sometimes
access to each of these components of `making' is provided in the
interface too---the quintessential example is MAKE-INSTANCE.
Good luck,
Vassil.
Vassil Nikolov <········@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
LEGEMANVALEMFVTVTVM (Ancient Roman programmers' adage.)
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Vassil Nikolov <········@poboxes.com> writes:
> First, the minor issue: SET is not recommended to be used any more,
> use SETF of SYMBOL-FUNCTION instead, e.g.
>
> (setf (symbol-function name) (list '()))
>
> in the body of STACK-INIT above.
Hmmm, shouldn't that be (setf (symbol-value name) (list '())) ?
Storing list's into the function-slot of a symbol will result in
undefined behaviour IIRC, and isn't the intended thing anyways... ;)
> If, for some strange reason, this exercise must be done without CLOS,
> which I'd argue is the Wrong Thing, then this could be the abstractions
> under that unnatural restriction:
>
> (defun make-stack () (make-array nil :initial-value '()))
> (defun stack-push (thing stack) (push thing (aref stack))
Before resorting to using 0-dimensional arrays, I'd think that using
defstruct to define a structure would be a better way, especially
since defstruct gives you many of the benefits of defining a
full-blown CLOS standard-class, without actually "having to" use
CLOS. Of course, since any ANSI CL conforming implementation has CLOS
built-in, using defstruct&co. _is_ actually using CLOS ;)
Just my 2 cents[1]...
Footnotes:
[1] Isn't it great that since the introduction of the Euro, people
in the Euro member countries can share this idiom from the US? ;)
--
Pierre Mai <····@acm.org> http://home.pages.de/~trillian/
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
In article <··············@orion.dent.isdn.cs.tu-berlin.de>,
····@acm.org (Pierre R. Mai) wrote:
> Vassil Nikolov <········@poboxes.com> writes:
>
> > First, the minor issue: SET is not recommended to be used any more,
> > use SETF of SYMBOL-FUNCTION instead, e.g.
> >
> > (setf (symbol-function name) (list '()))
> >
> > in the body of STACK-INIT above.
>
> Hmmm, shouldn't that be (setf (symbol-value name) (list '())) ?
Yes. My mistake. Thanks for noticing.
(set s v) <=> (setf (symbol-value s) v)
but SET is deprecated.
> Storing list's into the function-slot of a symbol will result in
> undefined behaviour IIRC, and isn't the intended thing anyways... ;)
Correct on both counts.
> > If, for some strange reason, this exercise must be done without CLOS,
> > which I'd argue is the Wrong Thing, then this could be the abstractions
> > under that unnatural restriction:
> >
> > (defun make-stack () (make-array nil :initial-value '()))
> > (defun stack-push (thing stack) (push thing (aref stack))
>
> Before resorting to using 0-dimensional arrays, I'd think that using
> defstruct to define a structure would be a better way, especially
> since defstruct gives you many of the benefits of defining a
> full-blown CLOS standard-class, without actually "having to" use
Do you mean `structure-class'?
> CLOS. Of course, since any ANSI CL conforming implementation has CLOS
> built-in, using defstruct&co. _is_ actually using CLOS ;)
(...)
Well, I said without CLOS... I did not mention structures mainly
because I did not want to start a debate whether one should use
structures at all, or only instances.
Besides, using a structure or an instance implies that there could
be other slots as well by a relatively minor change of the design,
while a 0-dimensional array clearly says, just a single component.
In other words, my idiom for a singleton reference (`half a cons')
is a 0-dimensional array, not a structure with a single slot. But
that is a minor style issue anyway.
Vassil Nikolov <········@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
LEGEMANVALEMFVTVTVM (Ancient Roman programmers' adage.)
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
* Vassil Nikolov <········@poboxes.com>
| but SET is deprecated.
I'm curious how people react to this "deprecated" thing. the other day,
I saw some code that did LOAD at the top of a file because the author was
scared of REQUIRE and PROVIDE, although he was in fact producing modules.
the reason was no better than that they were "deprecated". I don't think
it's a good idea to avoid things just because they are deprecated when no
better solution exists.
e.g., if the accessor is (symbol-value symbol), then clearly setf of same
is the best solution. if, however, the accessor is EVAL, I think SET is
a better solution because the fact that we access a symbol's value slot
is incidental to that usage.
other deprecated features have similar rationales, but not all. e.g., I
can fully accept the deprecation of the :TEST-NOT argument to predicates,
but not because I believe in COMPLEMENT (which I don't), but because it
has clear and present problems when combined with :TEST. the same
problem does not exist with the -IF-NOT functions, which I have posted
about previously.
BTW, I think REQUIRE and PROVIDE _can_ be removed from the standard only
after a DEFSYSTEM has been included.
#:Erik
Erik Naggum <····@naggum.no> writes:
> * Vassil Nikolov <········@poboxes.com>
> | but SET is deprecated.
>
> I'm curious how people react to this "deprecated" thing. the other day,
> I saw some code that did LOAD at the top of a file because the author was
> scared of REQUIRE and PROVIDE, although he was in fact producing modules.
> the reason was no better than that they were "deprecated". I don't think
> it's a good idea to avoid things just because they are deprecated when no
> better solution exists.
>
I tend to look up the reasons why these things were deprecated and see
whether I agree and whether there exists alternatives.
> e.g., if the accessor is (symbol-value symbol), then clearly setf of same
> is the best solution. if, however, the accessor is EVAL, I think SET is
> a better solution because the fact that we access a symbol's value slot
> is incidental to that usage.
>
I haven't used either EVAL or SET much but you've got a point.
> other deprecated features have similar rationales, but not all. e.g., I
> can fully accept the deprecation of the :TEST-NOT argument to predicates,
> but not because I believe in COMPLEMENT (which I don't), but because it
> has clear and present problems when combined with :TEST. the same
> problem does not exist with the -IF-NOT functions, which I have posted
> about previously.
>
I continue to use the -IF-NOT versions since they seem to indicate
most clearly what is meant. Most of the time I want to filter out the
stuff that doesn't satisfy a certain condition and I find
(REMOVE-IF-NOT #'predicate sequence) far clearer than (REMOVE-IF
(COMPLEMENT #'predicate) sequence). I also fail to see what removal
(no pun intended) of these forms would buy. Yes, they're logically
redundant but CL is not in the small language camp anyway. IF, WHEN,
UNLESS and COND are also redundant but they allow clear expression of
the programmer's intention which I find more important than keeping
the language small.
> BTW, I think REQUIRE and PROVIDE _can_ be removed from the standard only
> after a DEFSYSTEM has been included.
Likewise. If I understand the Issues the Hyperspec refers to
correctly, the main argument against them was that they were
inherently unportable because of the implementation-defined search
path. I think that - combined with logical pathname support - they
would allow fairly simple installation instruction for large packages
without having to change the source code. Emacs Lisp seems to do ok
with them.
--
Lieven Marchand <···@bewoner.dma.be>
If there are aliens, they play Go. -- Lasker
In article <················@naggum.no>,
Erik Naggum <····@naggum.no> wrote:
> * Vassil Nikolov <········@poboxes.com>
> | but SET is deprecated.
>
> I'm curious how people react to this "deprecated" thing.
I dont' know about people, but here's my attitude.
(...)
> I don't think
> it's a good idea to avoid things just because they are deprecated when
> no better solution exists.
Something may be deprecated when:
* there is no other construct that does the same (as with REQUIRE/PROVIDE);
* or there is another means to achieve the same.
Avoiding the first means depriving oneself of functionality, and I
wouldn't want to do this to myself, or reimplementing the functionality
(perhaps in the Right Way) which may be a waste of time or complicate a
program too much.
Avoiding the second should be considered on a case per case basis.
I.e. the case SET vs. SETF of SYMBOL-VALUE should get its own
treatment different from e.g. xxx-IF-NOT vs. xxx-IF of COMPLEMENT.
> e.g., if the accessor is (symbol-value symbol), then clearly setf of same
> is the best solution. if, however, the accessor is EVAL, I think SET is
> a better solution because the fact that we access a symbol's value slot
> is incidental to that usage.
I agree that for the case of SET the issue is really, do we use EVAL.
My view is that EVAL should be used only when absolutely necessary
and that there would rarely be justification for EVAL if all we want
is the dynamic value of a symbol. (To me EVAL implies the argument
could be any form, i.e. (EVAL (THE SYMBOL S)) looks unnatural. If
EVAL took a second (environment) argument, this would be another matter.)
In particular, the example that started this thread did not call for
EVAL in my opinion. Also, I was worried that the original poster
may learn that SET is the only solution and then get hurt if one
day SET disappears (if my opinion matters, that would be a loss).
But I would like to hear other arguments which may be stronger than
mine.
> other deprecated features have similar rationales, but not all. e.g., I
> can fully accept the deprecation of the :TEST-NOT argument to predicates,
> but not because I believe in COMPLEMENT (which I don't), but because it
> has clear and present problems when combined with :TEST. the same
> problem does not exist with the -IF-NOT functions, which I have posted
> about previously.
I'd like to add that _if_ any of these have to be deprecated, this should
be done again case per case. For example, even if we agree that
COUNT-IF is more useful than COUNT-IF-NOT, I'd still argue that
REMOVE-IF-NOT, being effectively KEEP-IF, is more useful than REMOVE-IF.
As to COMPLEMENT, me neither... Apart from performance issues,
(COUNT-IF (COMPLEMENT #'NUMBERP) ...), for example, invokes an idea
of infinity (the infinite set which is the complement to the set of
numbers) which is too explicit for me to be comfortable. On the other
hand, I don't have the same problem with (COUNT-IF-NOT #'NUMBERP ...)
even though I know that as far as formal logic is concerned the two
are equivalent. But maybe it's just me.
> BTW, I think REQUIRE and PROVIDE _can_ be removed from the standard only
> after a DEFSYSTEM has been included.
Or at least some simple facility which provides the functionality
of REQUIRE and PROVIDE and which can be extended to a full-fledged
DEFSYSTEM by the user or vendor. (Simple in order to avoid making
the standard too heavy.)
Vassil Nikolov <········@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
LEGEMANVALEMFVTVTVM (Ancient Roman programmers' adage.)
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Vassil Nikolov <········@poboxes.com> writes:
The situation with SET is the following:
First, (SETF (SYMBOL-VALUE x) y) is computationally sufficient.
It's syntactically cumbersome if you need to do mapping but that's
rare, and I usually prefer to write
#'(lambda (x y) (setf (symbol-value x) y))
rather than
#'set
in that case, just because it's clearer.
Second, underlying this, there is a longstanding confusion about
SETQ that it just means SET + QUOTE. That is, it used to be that
(SETQ X 3) was identical in meaning to (SET' X 3). That was when
Lisp was dynamically scoped. A lot of people find stale references
to this equivalence and it confuses them no end, which is why I and
others try to move people away from using SET--so they won't get into
that confusion.
SETQ is a primitive linguistic thing, and setting the symbol value
is a (meta)data structure access and to the extent that there is any
relation between these two, it's fairly incidental. The SET/SETQ
thing makes them look more related than they are.
That's why it's good style to avoid SET.
(Also, as a minor aside, because of SET-DIFFERENCE and friends, the
morpheme SET has a confusing double-meaning. It's unfortunate that
the term SETF also uses set, but at least it's harder to see there.
Even so, because the isolated word SET is in between these two
naming conventions, it makes for serious visual ambiguity when you're
caught out of context and again that argues for not using SET.)
On 30 Mar 1999 11:20:04 +0000, Erik Naggum <····@naggum.no> wrote:
> I'm curious how people react to this "deprecated" thing. the other day,
Since I don't have enough experience yet, I'm perplexed about deprecated
things. So, I try to gather further opinions and experience.
> I saw some code that did LOAD at the top of a file because the author was
> scared of REQUIRE and PROVIDE, although he was in fact producing modules.
> the reason was no better than that they were "deprecated". I don't think
> it's a good idea to avoid things just because they are deprecated when no
> better solution exists.
I found a few comments at Chris Riesbeck's Web site
http://www.cs.nwu.edu/~riesbeck/. He notes that those functions were
deprecated in CLtL2 because there were some unspecified aspects of their
behavior in CLtL1(?). Anyway, he uses and recommends them to his students
because he says that REQUIRE and PROVIDE are simple, flexible and handle
individual modules as well as whole systems.
Paolo
--
Paolo Amoroso <·······@mclink.it>
In article <·······················@news1.teleport.com>,
"David B. Lamkins" <········@teleport.com> writes:
> In article <·······················@news2.jacksonville.net> , "Bjorn Goldis"
> <·······@MediaOne.Net> wrote:
> > (defun pushS (name elem)
> > ( setf (car name) elem ) ) ;; this type of thing in text.
<snip explanation of why this doesn't do what Bjorn expected, and why it
isn't the right thing anyway>
> (defmacro pushS (name elem)
> `(setf (car ,name) ,elem)) ;; this type of thing in text.
>
> (defun pushS (name elem)
> (set name (cons elem (rest (symbol-value name)))))
Of course, this isn't really the same as Bjorn's pushS -- it creates an
extra cons, and leaves one behind as garbage,
(defun pushS (name elem)
(rplaca (symbol-value name) elem))
--
Aaron Crane <···········@pobox.com> <URL:http://pobox.com/~aaronc/>
** Please send on-topic followups by Usenet, not email **
"Bjorn Goldis" <·······@MediaOne.Net> writes:
> stuck on binding problem:
> this is what code should do:
>
> >>(setf s '(())) ;initialization to empty
> (NIL)
> >>s ; can see that s is bound here
> (NIL)
> >>(setf (car s) 'a) ; replace head of list s with a
> A
> >>s ; check it, and it's there
> (A)
> -------------------------------------
> in code, i have little more;
>
> (defun stack-init (name)
> ( setf name '(()) ) ) ;; want to initialize to empty list.
>
> (defun pushS (name elem)
> ( setf (car name) elem ) ) ;; this type of thing in text.
>
> -------------------------------------
> get (NIL) as list after stack-init, but somehow elem not bound to
> name:
>
> >(stack-init 's)
> (NIL) ;; so far so good
>
> >s ;; try to check s ..
>
> Error: The variable S is unbound.
> Fast links are on: do (si::use-fast-links nil) for debugging
> Error signalled by EVAL.
> Broken at EVAL. Type :H for Help.
>
> using gcl lisp version. help no good. can't progress unless get this
> bound.
Using GCL is already a bad sign :}
Trying to re-implement what is already there is a sign that you should
read more about CL first.
This is how things should be done! (Does anybod know of any other way?
:) )
Note that this is just a wrapping around functionality that is already
there.
(in-package "STACK")
(export '(emptyp top))
(defun emptyp (s)
(null s))
(defun top (s)
(if (emptyp s)
(error "stack empty.")
(first s)))
;;; PUSH, PUSHNEW and POP are already there. No need to reimplement
;;; them.
Of course, you do not get the & reference * pointer mess typical of
C/C++, but this is (Common) Lisp ! :)
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa