Hi all.
When I create an instance (lets call it "inst") of a class and use it in the
expression: (type-of inst) the type is correctly returned.
However, when I use it in the expression: (type-of (car '(inst))) I find
that the type returned is SYMBOL.
Can anyone explain why this happens and how to obtain the correct type
information?
Thanks in advance from a frustrated newbie.
From: Sam Steingold
Subject: Re: Puzzled over loss of type information
Date:
Message-ID: <uoef95p7n.fsf@gnu.org>
> * Tony <··········@rznvy.pbz> [2005-01-29 06:19:29 +1100]:
>
> When I create an instance (lets call it "inst") of a class and use it in the
> expression: (type-of inst) the type is correctly returned.
>
> However, when I use it in the expression: (type-of (car '(inst))) I find
> that the type returned is SYMBOL.
(car '(inst))
returns the symbol INST, not its value.
try
(cat (list inst))
instead.
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
Incorrect time syncronization.
On Fri, 28 Jan 2005 14:27:24 -0500, Sam Steingold wrote:
>> * Tony <··········@rznvy.pbz> [2005-01-29 06:19:29 +1100]:
>>
>> When I create an instance (lets call it "inst") of a class and use it in the
>> expression: (type-of inst) the type is correctly returned.
>>
>> However, when I use it in the expression: (type-of (car '(inst))) I find
>> that the type returned is SYMBOL.
>
> (car '(inst))
> returns the symbol INST, not its value.
> try
> (cat (list inst))
> instead.
... and if you make that into (car (list inst)) it'll work ;-)
RalfD
Thanks very much for your help guys.
I try not to bother the newsgroup with my learning difficulties (this was my
first question) but it was just getting so frustrating.
"Tony" <··········@email.com> wrote in message
·················@nnrp.waia.asn.au...
> Hi all.
>
> When I create an instance (lets call it "inst") of a class and use it in
the
> expression: (type-of inst) the type is correctly returned.
>
> However, when I use it in the expression: (type-of (car '(inst))) I find
> that the type returned is SYMBOL.
>
> Can anyone explain why this happens and how to obtain the correct type
> information?
>
> Thanks in advance from a frustrated newbie.
>
>
Tony wrote:
> Thanks very much for your help guys.
>
> I try not to bother the newsgroup with my learning difficulties (this was my
> first question) but it was just getting so frustrating.
Don't feel bad. You have been poorly served by those who write Lisp
tutorials and by this NG, who by now should know (because I have made
this point a thousand times) that the Real Problem is bad tutorials.
Every intro text creates lists using quote ('). So you things like '(1 2
3) and '(dog cat parakeet) everywhere you turn. Quote (') then gets
understood to be "a way to make a list". Nope.
Quote is a way to avoid evaluation:
(let ((a 42)) 'a) -> 'a
(let ((a 42)) A) -> 42 ;; no quote, evaluated
(let ((a 42)) (list a)) -> (42) ;; likewise
(let ((a 42)) (list 'a) -> (a)
(let ((a 42)) '(a) -> (a)
(let ((a 42)) (car '(a)) -> 'a
Quote /does/ accept a list, but then it quotes everything in the list;
(let ((a 42)) '(A 42)) -> (A 42)
(let ((a 42)) (list a 42)) -> (42 42)
The problem is that tutorial examples often just need lists of number or
symbols, so the authors cheat and use ' when they should use LIST,
leading to misinformation and the frustration you expereinced.
kt
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Kenny Tilton <·······@nyc.rr.com> writes:
> The problem is that tutorial examples often just need lists of number
> or symbols, so the authors cheat and use ' when they should use LIST,
> leading to misinformation and the frustration you expereinced.
That's a bit exaggregated, I think. You don't really want to use LIST
to construct complex nested lists which are not going to be
destructively modified anyway.
A possible problem with tutorials may be that they may fail to stress
what QUOTE /really/ does. Is that really a common problem with
tutorials?
--
(espen)
Espen Vestre wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>The problem is that tutorial examples often just need lists of number
>>or symbols, so the authors cheat and use ' when they should use LIST,
>>leading to misinformation and the frustration you expereinced.
>
>
> That's a bit exaggregated, I think. You don't really want to use LIST
> to construct complex nested lists which are not going to be
> destructively modified anyway.
I think that just reiterates the problem: quote is indeed quite handy,
which is how it ends up in the first few examples a newby ever sees,
which is how they end up thinking quote is LIST.
Not sure how I would handle this if I were writing a tutorial, but with
the admitted advantage of hindsight, I would do something to fend off
this FAM (Frequently acquired misconception).
>
> A possible problem with tutorials may be that they may fail to stress
> what QUOTE /really/ does.
Could be. Maybe the way to go is to start with (list 1 2 3) until a
hairy, nested list is reached. Then introduce '<nested list> with the
convenience motivation at hand, at the same time emphasizing the
gotchas. Give them a fighting chance, anyway.
> Is that really a common problem with
> tutorials?
Based on the traffic here, I would say so.
kt
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Kenny Tilton <·······@nyc.rr.com> wrote:
+---------------
| Espen Vestre wrote:
| > A possible problem with tutorials may be that they may fail to stress
| > what QUOTE /really/ does.
|
| Could be. Maybe the way to go is to start with (list 1 2 3) until a
| hairy, nested list is reached. Then introduce '<nested list> with the
| convenience motivation at hand, at the same time emphasizing the gotchas.
+---------------
Another approach that seems to work (the couple of time I've tried it)
is to go ahead and introduce QUOTE, but *not* the <quotation-mark>
reader macro for it [at least not initially]. That way, one can present
QUOTE and LIST as looking more alike, yet focus on QUOTE's "specialness"
in not evaluating, compared to LIST. Only when the person really seems
to grok it do you then say, "Oh, and since it's used a lot there's this
really short abbreviation..."
> (let ((a 42)
(b 53))
(print (quote a))
(print a)
(print (quote 42))
(print 42)
(print (list (quote a)))
(print (list a))
(print (list 42))
(print (list (quote a) (quote b)))
(print (list a b))
(print (list 42 53))
nil) ; just to get the value out of the way
A
42
42
42
(A)
(42)
(42)
(A B)
(42 53)
(42 53)
>
And then maybe they're ready for:
> (let ((a 42)
(b 53))
(print (list a b 42 53))
(print (list (quote a) (quote b) 42 53))
(print (quote (a b 42 53)))
(print '(a b 42 53))
nil)
(42 53 42 53)
(A B 42 53)
(A B 42 53)
(A B 42 53)
>
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> Kenny Tilton <·······@nyc.rr.com> wrote:
> +---------------
> | Espen Vestre wrote:
> | > A possible problem with tutorials may be that they may fail to stress
> | > what QUOTE /really/ does.
> |
> | Could be. Maybe the way to go is to start with (list 1 2 3) until a
> | hairy, nested list is reached. Then introduce '<nested list> with the
> | convenience motivation at hand, at the same time emphasizing the gotchas.
> +---------------
>
> Another approach that seems to work (the couple of time I've tried it)
> is to go ahead and introduce QUOTE, but *not* the <quotation-mark>
Brilliant. Keeps the convenience, but forces them to confront QUOTE as
opposed to LIST. Should work. Ping Peter...
kt
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Kenny Tilton <·······@nyc.rr.com> writes:
> Rob Warnock wrote:
>> Kenny Tilton <·······@nyc.rr.com> wrote:
>> +---------------
>> | Espen Vestre wrote:
>> | > A possible problem with tutorials may be that they may fail to
>> stress | > what QUOTE /really/ does.
>> | | Could be. Maybe the way to go is to start with (list 1 2 3)
>> until a | hairy, nested list is reached. Then introduce '<nested
>> list> with the | convenience motivation at hand, at the same time
>> emphasizing the gotchas.
>> +---------------
>> Another approach that seems to work (the couple of time I've tried
>> it)
>> is to go ahead and introduce QUOTE, but *not* the <quotation-mark>
>
> Brilliant. Keeps the convenience, but forces them to confront QUOTE as
> opposed to LIST. Should work. Ping Peter...
It's waaay too late for that feedback--those chapters are off to the
printers as far as I know. However I did go out of my way to try to
avoid installing this confusion in my readers minds by using LIST to
make lists and explaining QUOTE and ' in a different context. It also
helps that I don't really talk about lists until chapter 12. ;-)
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Kenny Tilton <·······@nyc.rr.com> writes:
> Espen Vestre wrote:
> > Kenny Tilton <·······@nyc.rr.com> writes:
> >
> >>The problem is that tutorial examples often just need lists of number
> >>or symbols, so the authors cheat and use ' when they should use LIST,
> >>leading to misinformation and the frustration you expereinced.
> > That's a bit exaggregated, I think. You don't really want to use LIST
> > to construct complex nested lists which are not going to be
> > destructively modified anyway.
>
> I think that just reiterates the problem: quote is indeed quite handy,
> which is how it ends up in the first few examples a newby ever sees,
> which is how they end up thinking quote is LIST.
>
> Not sure how I would handle this if I were writing a tutorial, but
> with the admitted advantage of hindsight, I would do something to fend
> off this FAM (Frequently acquired misconception).
IMO, ' should not be used in tutorials. Only QUOTE.
Then only at the end of the tutorial could it be mentionned, once the
reader macros have been treated, that there's a reader macro #\' that
substitute (quote x) for 'x.
Of course, the same should be done with #' and FUNCTION.
> [...]
> > Is that really a common problem with
> > tutorials?
>
> Based on the traffic here, I would say so.
--
__Pascal Bourguignon__ http://www.informatimago.com/
In deep sleep hear sound,
Cat vomit hairball somewhere.
Will find in morning.
From: Damien Kick
Subject: Re: Puzzled over loss of type information
Date:
Message-ID: <k6ptti0f.fsf@email.mot.com>
Pascal Bourguignon <····@mouse-potato.com> writes:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > I think that just reiterates the problem: quote is indeed quite handy,
> > which is how it ends up in the first few examples a newby ever sees,
> > which is how they end up thinking quote is LIST.
> >
> > Not sure how I would handle this if I were writing a tutorial, but
> > with the admitted advantage of hindsight, I would do something to fend
> > off this FAM (Frequently acquired misconception).
>
> IMO, ' should not be used in tutorials. Only QUOTE.
I'm still a n00b myself but I've been half-wondering if Lisp tutorials
shouldn't start with backquote, just the backquote itself without any
mention of the comma or splice operators, because it would mean that
one wouldn't run into the problem with modifying literals so quickly.
PG-USER> (let ((x `(a b c d e f)))
(setf (nth 2 x)
`x)
x)
(A B X D E F)
The above code is perfectly safe. Sure, for the average case,
backquote is going to CONS more than it needs but for tutorial users,
this would not be a concern. After the reader has grasped the basics
of evaluation rules, a tutorial could delve into the difference
between things like #\`, #\', QUOTE, literals, destructive operations,
structure sharing, etc.
Damien Kick <······@email.mot.com> writes:
> Pascal Bourguignon <····@mouse-potato.com> writes:
>
>> Kenny Tilton <·······@nyc.rr.com> writes:
>>
>> > I think that just reiterates the problem: quote is indeed quite handy,
>> > which is how it ends up in the first few examples a newby ever sees,
>> > which is how they end up thinking quote is LIST.
>> >
>> > Not sure how I would handle this if I were writing a tutorial, but
>> > with the admitted advantage of hindsight, I would do something to fend
>> > off this FAM (Frequently acquired misconception).
>>
>> IMO, ' should not be used in tutorials. Only QUOTE.
>
> I'm still a n00b myself but I've been half-wondering if Lisp tutorials
> shouldn't start with backquote, just the backquote itself without any
> mention of the comma or splice operators, because it would mean that
> one wouldn't run into the problem with modifying literals so quickly.
>
> PG-USER> (let ((x `(a b c d e f)))
> (setf (nth 2 x)
> `x)
> x)
> (A B X D E F)
>
> The above code is perfectly safe.
I'm not sure that's true. I think the compiler would be within its
rights to translate `(a b c) into '(a b c). At least, I can't find
anything in the standard that requires much of anything out of the
implementation of backquote except that it generate a correctly
"shaped" list (or vector) structure. And when I asked about it some
months back, wiser folks that me told me that you couldn't rely on
backquote to generate fresh conses at runtime if it didn't have to.
Which is, I think, sort of a pity, but there it is.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: Damien Kick
Subject: Re: Puzzled over loss of type information
Date:
Message-ID: <fz0ht1nk.fsf@email.mot.com>
Peter Seibel <·····@javamonkey.com> writes:
> Damien Kick <······@email.mot.com> writes:
>
> > [...] The above code is perfectly safe.
>
> I'm not sure that's true. [...]
And this is why I'm not writing tutorials <smile>.
Damien Kick <······@email.mot.com> writes:
[...]
> I'm still a n00b myself but I've been half-wondering if Lisp
> tutorials shouldn't start with backquote, just the backquote itself
> without any mention of the comma or splice operators, because it
> would mean that one wouldn't run into the problem with modifying
> literals so quickly.
Even if it were sure to be safe (and apparently it's not) I still
think that would be a bad idea. I guess it depends on what your goals
are: if you're teaching a lisp language as part of a university class,
then it might make sense to teach a subset that nobody in fact uses,
if that's easier to understand.
But I presume most tutorials (and Peter's book) are trying to teach
Common Lisp as it's actually used, or (even better) Common Lisp as (in
the author's opinion) it ought to be used (presuming that there's
Common Lisp that's regarded as in poor style). In that case I think
it's best to show (as soon as possible) the kind of things that are
actually in (well-written) Common Lisp programs.
Similarly in a C++ tutorial: it's worth knowing that struct and class
are essentially the same, but it's even more useful to know how and
why they're typically used quite differently. Similarly the
relatively recent trend of using the C++ standard library early on
rather than starting with C and adding C++ stuff seems like a positive
trend to me.
[...]
Damien Kick <······@email.mot.com> writes:
> I'm still a n00b myself but I've been half-wondering if Lisp tutorials
> shouldn't start with backquote, just the backquote itself without any
> mention of the comma or splice operators, because it would mean that
> one wouldn't run into the problem with modifying literals so quickly.
It would actually be worse, because now _parts_ of a structure may be
static instead of the whole with QUOTE or none with LIST.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Cats meow out of angst
"Thumbs! If only we had thumbs!
We could break so much!"
From: Svein Ove Aas
Subject: Re: Puzzled over loss of type information
Date:
Message-ID: <ctmhde$5oe$1@services.kq.no>
Pascal Bourguignon wrote:
> Damien Kick <······@email.mot.com> writes:
>> I'm still a n00b myself but I've been half-wondering if Lisp tutorials
>> shouldn't start with backquote, just the backquote itself without any
>> mention of the comma or splice operators, because it would mean that
>> one wouldn't run into the problem with modifying literals so quickly.
>
> It would actually be worse, because now _parts_ of a structure may be
> static instead of the whole with QUOTE or none with LIST.
>
I'm wondering about adding a "~" syntax macro to my utilities, and have ~(a
b (c)) expand to (list a b (list c)).
Anyone else done this? Is it actually useful?
Svein Ove Aas <·········@aas.no> writes:
> Pascal Bourguignon wrote:
>
> > Damien Kick <······@email.mot.com> writes:
> >> I'm still a n00b myself but I've been half-wondering if Lisp tutorials
> >> shouldn't start with backquote, just the backquote itself without any
> >> mention of the comma or splice operators, because it would mean that
> >> one wouldn't run into the problem with modifying literals so quickly.
> >
> > It would actually be worse, because now _parts_ of a structure may be
> > static instead of the whole with QUOTE or none with LIST.
> >
> I'm wondering about adding a "~" syntax macro to my utilities, and have ~(a
> b (c)) expand to (list a b (list c)).
>
> Anyone else done this?
Yes (*)
> Is it actually useful?
Of course. Three good things:
- it get rid of the (f x) notation for the better f(x) one.
- it's less key to type.
- ultimately it removes the need for parentheses.
Most COMMON-LISP functions will need a combination of two special
characters, and the rarest ones three special characters, so you can
get quite a compact notation. Note that now that unicode spreads, you
can even reduce every COMMON-LISP function to one symbol^W special
character.
(*) It's called: APL
--
__Pascal Bourguignon__ http://www.informatimago.com/
PS: I swear, we should forbid ' and #' to all newbies up to 4 years of
experience in lisp programming...
Pascal Bourguignon <····@mouse-potato.com> writes:
> IMO, ' should not be used in tutorials. Only QUOTE.
>
> Then only at the end of the tutorial could it be mentionned, once the
> reader macros have been treated, that there's a reader macro #\' that
> substitute (quote x) for 'x.
>
> Of course, the same should be done with #' and FUNCTION.
I don't agree. Before you reach the level where introducing the
concept of reader macros is anything but annoying, you would have
to go through hours and hours of lisp lectures and programming
exercises, and pretending that ' and #' didn't exist through all
that time would do more harm than good.
--
(espen)
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> Pascal Bourguignon <····@mouse-potato.com> writes:
>
> > IMO, ' should not be used in tutorials. Only QUOTE.
> >
> > Then only at the end of the tutorial could it be mentionned, once the
> > reader macros have been treated, that there's a reader macro #\' that
> > substitute (quote x) for 'x.
> >
> > Of course, the same should be done with #' and FUNCTION.
>
> I don't agree. Before you reach the level where introducing the
> concept of reader macros is anything but annoying, you would have
> to go through hours and hours of lisp lectures and programming
> exercises, and pretending that ' and #' didn't exist through all
> that time would do more harm than good.
What harm could that do?
I'm no professionnal pedagogue, but it looks like it's a perfectly
valid pedagogical trick if I can judge from DrScheme.
--
__Pascal Bourguignon__ http://www.informatimago.com/
In a World without Walls and Fences,
who needs Windows and Gates?
From: Duane Rettig
Subject: Re: Puzzled over loss of type information
Date:
Message-ID: <47jltmt1u.fsf@franz.com>
Pascal Bourguignon <····@mouse-potato.com> writes:
> Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
>
> > Pascal Bourguignon <····@mouse-potato.com> writes:
> >
> > > IMO, ' should not be used in tutorials. Only QUOTE.
> > >
> > > Then only at the end of the tutorial could it be mentionned, once the
> > > reader macros have been treated, that there's a reader macro #\' that
> > > substitute (quote x) for 'x.
> > >
> > > Of course, the same should be done with #' and FUNCTION.
> >
> > I don't agree. Before you reach the level where introducing the
> > concept of reader macros is anything but annoying, you would have
> > to go through hours and hours of lisp lectures and programming
> > exercises, and pretending that ' and #' didn't exist through all
> > that time would do more harm than good.
>
> What harm could that do?
Two problems, that I can see after ten seconds of thinking about it
(maybe there are more):
1. In forms, (QUOTE ...) and (FUNCTION ...) tend to be printed as
'... and #'... respectively, so a follower of a tutorial will become
confused as to why what was typed doesn't appear to be what it is.
An explanation must at least cover why this is being seen:
CL-USER(1): '(a b (quote c))
(A B 'C)
CL-USER(2):
2. ', `, and #' are constructs that make the underlying structure
of the data fit closer to what it _looks_ like, rather than how
it is constructed. Now, it is important to know how a list-based
structure is constructed, and I think the pendulum has swung a little
too far in the opposite direction (i.e. I agree that the acctual
construction of these character macros should be explained early),
but the spell-it-out-always philosophy will force us back to the days
when I was learning Lisp and looking at macro constructions, when
(nconc (cadadr form) ... was the norm, and impossible to read. I'd
like the pendulum to stop somewhere in the middle, where the equivalence
of the macro characters is emphasized (and perhaps an exercise is done
in spell-it-out style, to show the reader what a great benefit these
reader macros are), and then the rest is done using the easier to
understand style.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> writes:
> Two problems, that I can see after ten seconds of thinking about it
> (maybe there are more):
>
> 1. In forms, (QUOTE ...) and (FUNCTION ...) tend to be printed as
> '... and #'... respectively, so a follower of a tutorial will become
But even if you managed to circumvent that, the students would and
should be exposed to other literature than your tutorial, where
they would most certainly see ' and #' anyway.
> 2. ', `, and #' are constructs that make the underlying structure
> of the data fit closer to what it _looks_ like, rather than how
> it is constructed.
That's a good point too. I don't think the student can fully appreciate
the beuaty of the data/program dichotomy in lisp if they have to
do without the quotes.
(I gave my daughters (12 and 11) a taste of what you could do with lisp
the other day, and even presented backquote as one of the first
constructs (without hoping for a deep understanding of it, of cousre),
just because it made it very easy to smear together a few functions
that do things that children find really amusing, e.g.:
(defun greeting ()
`(,(name) you ,(adjective) ,(noun)))
)
--
(espen)