hi.. sorry if this question is silly.
i just can't figure out why my case statement doesn't work properly
(well i used it in another program and it worked exactly what i expected)
here is the example
(defun case-testing (test)
(case test
(NN (princ "inside NN"))
(otherwise (princ "in otherwise"))))
(setf test "NN")
so in this case when i call
(case-testing test)
I'm expecting that it will print "inside NN"
on the other hand, it prints "in otherwise"
am I missing something??
thanks for the help...
--
***********************************
{} Irma Sumera
/^\ ·······@cs.rmit.edu.au
/ 3rd year Computer Science
/
\..
***********************************
Irma wrote:
>
> hi.. sorry if this question is silly.
> i just can't figure out why my case statement doesn't work properly
> (well i used it in another program and it worked exactly what i expected)
>
> here is the example
>
> (defun case-testing (test)
> (case test
> (NN (princ "inside NN"))
> (otherwise (princ "in otherwise"))))
>
> (setf test "NN")
>
> so in this case when i call
> (case-testing test)
> I'm expecting that it will print "inside NN"
>
> on the other hand, it prints "in otherwise"
>
> am I missing something??
> thanks for the help...
Hello,
I know just enough lisp to tell you that if you do instead:
(setf test 'NN)
(case-testing test)
==> "inside NN"
Others can explain to you many further subtleties of various forms of
"equals"....
Cheers,
John
·······@cs.rmit.edu.au (Irma) writes:
> hi.. sorry if this question is silly.
> i just can't figure out why my case statement doesn't work properly
Because you're confusing symbols and strings.
But it's good you provided and example so we can fix you up easily.
> (well i used it in another program and it worked exactly what i expected)
>
> here is the example
>
> (defun case-testing (test)
> (case test
> (NN (princ "inside NN"))
Test is being checked for being the symbol NN.
> (otherwise (princ "in otherwise"))))
>
> (setf test "NN")
Test is bound to the string "NN".
The string "NN" is not the symbol NN.
> so in this case when i call
> (case-testing test)
> I'm expecting that it will print "inside NN"
Hopefully you now understand why your expectations were wrong.
Kent M Pitman <······@world.std.com> writes:
> ·······@cs.rmit.edu.au (Irma) writes:
>
> > hi.. sorry if this question is silly.
> > i just can't figure out why my case statement doesn't work properly
>
> Because you're confusing symbols and strings.
> But it's good you provided and example so we can fix you up easily.
Btw, I think CASE is not too well defined in the standard: You have to
read the description of CASE several times before you understand that
it actually indirectly says that the underlying test is EQL. As far as
I can tell this is only indirectly said through the use of the word
'same' and the example, which shows, through the use of numbers, that
the test must be 'at least' EQL. (I guess a lot of people have an
EQUAL version in their macro libraries?)
--
(espen)
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > ·······@cs.rmit.edu.au (Irma) writes:
> >
> > > hi.. sorry if this question is silly.
> > > i just can't figure out why my case statement doesn't work properly
> >
> > Because you're confusing symbols and strings.
> > But it's good you provided and example so we can fix you up easily.
>
> Btw, I think CASE is not too well defined in the standard:
Oh, it's well defined. There's no ambiguity of what's written.
You mean to say it's not necessarily easy for the casual reader
(not the standard's target audience) to find.
> You have to
> read the description of CASE several times before you understand that
> it actually indirectly says that the underlying test is EQL. As far as
> I can tell this is only indirectly said through the use of the word
> 'same' and the example, which shows, through the use of numbers, that
> the test must be 'at least' EQL. (I guess a lot of people have an
> EQUAL version in their macro libraries?)
There is no one of EQ, EQL, EQUAL, nor EQUALP that compares "NN" and
NN as being equivalent. Only STRING-EQUAL or STRING= would compare NN
and "NN" the same, and only because it has as its contract to *first*
coerce both arguments to strings; there is no "test" parameter or
implied predicate that I can think of anywhere in the language that
uses STRING-EQUAL or STRING= as its default test. So this should not
be a popular confusion.
The standard is intended to be readable by a mere mortal, but there is a
limit to its usefulness as an introductory text to an outsider. For
brevity (relatively speaking, that is), it necessarily doesn't re-explain
itself at every point. In particular, this use of the word "same" is
italicized in order to emphasize its precise meaning as a glossary term,
and is used heavily throughout the standard in preference to direct
reference to EQL. It would be appropriate for a teaching text to explain
this, but I think it's fine and appropriate for the standard to not.
In the HyperSpec form, which is surely how any ordinary person would read
the standard, it's easy to click on that word "same" and find out its
meaning.
A string/symbol example would have been a good one to include in the
examples. "Maybe next time."
The examples throughout the spec, by the way, heavily rely on people
understanding the read/print syntax of datatypes and not assuming that
one kind of object is or can be confused by another. I could have been
more explicit throughout, but it would have again only destroyed the
spec's much-lauded "crisp brevity". ;-)
That's what I get for writing a mostly-readable standard, I suppose.
It's not perfect, surely, but compared to some other language
stnadrds, it is approachable. Had I made it less readable by casual
readers, they wouldn't have tried and would, as happens with all other
languages, be resorting to secondary references instead...
Kent M Pitman <······@world.std.com> writes:
> Oh, it's well defined. There's no ambiguity of what's written.
> You mean to say it's not necessarily easy for the casual reader
> (not the standard's target audience) to find.
Yes, sorry for the misuse of 'well definined'.
That's what I meant. It's difficult for the casual reader of the
Hyperspec to observe the essential use of the word _same_ here.
> There is no one of EQ, EQL, EQUAL, nor EQUALP that compares "NN" and
> NN as being equivalent.
I know, I should have made it clear that I wasn't actually commenting
on the specific misunderstanding that you clarified in your post,
but on the general understandability of the definition of CASE.
> In the HyperSpec form, which is surely how any ordinary person would read
> the standard, it's easy to click on that word "same" and find out its
> meaning.
Yes, it isn't all that difficult - but in the case of 'case' (;-)),
'same' is the same as EQL (since there is no alternative predicate
allowed).
Never mind, I think the standard is just great, and I might as well
be assuming wrong things about casual readers! (And maybe the whole
thing boils down to the fact that CASE itself could have been defined
slightly different (with an optional predicate parameter))
--
(espen)
* Kent M Pitman <······@world.std.com>
| That's what I get for writing a mostly-readable standard, I suppose.
| It's not perfect, surely, but compared to some other language
| stnadrds, it is approachable. Had I made it less readable by casual
| readers, they wouldn't have tried and would, as happens with all other
| languages, be resorting to secondary references instead...
Since I argued that Scheme has the best standard I know about, and I
know that didn't match your views all that well, there are at least
two metrics by which you can judge a standard: (1) How easy is it to
arrive at a conforming implementation according to the standard?
(2) How easy is it to understand and use a conforming implementation
with the aid of the standard? Scheme rules supreme on the first
count, and that has been the traditional use for a standard. In
computer science, however, standards are more than that, and the
last point you make above is that the standard is very useful as a
reference for users of conforming implementations of Common Lisp. I
quite agree that secondary references are not the way to go, and I'm
quite annoyed by the lack of official references for other languages
that I'd like to use or understand, so let me put it this way: ANSI
Common Lisp was the first standards document that was targeted to
the user community (just like its predecessors), to be _the_ source
of information on the language, not just for implementors. I could
say it's the best reference document for a language I know.
With my Scheme comment, I also wanted to honor the goal of Scheme,
which is to have an excellent standard, which implies that they
could revel in its excellence without any implementations. Common
Lisp didn't have that goal: It's goal was to unite user communities,
and later to provide implementors and users with a useful contract
document. The result is a remarkably good standards document, but
for an implementor, there are still a lot to figure out that isn't
explicitly stated in the standard. (I believe Kyoto Common Lisp was
the first Common Lisp to have been written without access to the
rich oral tradition surrounding CLtL1, but I know of no Common Lisp
implementation according to the ANSI specification that was not
developed by people who didn't know the standards folks, too.)
#:Erik
--
If this is not what you expected, please alter your expectations.
Erik Naggum <····@naggum.net> writes:
> Since I argued that Scheme has the best standard I know about, and I
> know that didn't match your views all that well, there are at least
> two metrics by which you can judge a standard:
>
> (1) How easy is it to arrive at a conforming implementation
> according to the standard?
So a standard which says
"You can do whatever you want and call your implementation conforming."
gets points for being a good standard? I'm skeptical, unless the amount of
goodness this can provide is properly only part of the whole.
> (2) How easy is it to understand and use a conforming implementation
> with the aid of the standard?
This seems on track to being a better criterion, but I would say instead:
(2a) How likely is it that a typical conforming program will run in a
typical conforming implementation?
or
(2b) Using just the standard, can one take a conforming implementation
and get work done without appealing to implementation-specific stuff.
> With my Scheme comment, I also wanted to honor the goal of Scheme,
> which is to have an excellent standard, which implies that they
> could revel in its excellence without any implementations. Common
> Lisp didn't have that goal: It's goal was to unite user communities,
> and later to provide implementors and users with a useful contract
> document.
The Scheme goal was not much different--to unite a community of textbook
writers. I think both languages showed equal disregard for the broad
community they sought to unite in that they each provided major gaps in
portability and guidance for how to predict or recover from implementation
variation. The difference is that CLTL corrected that problem (by going
to the ANSI format) while Scheme really never did (IMO).
Note that I'm not being intentionally particularly defensive about CL's
standard. I don't mind if people say it's not up to par or what they
expect in a standard. I just absolutely don't believe the Scheme standard
is fairly cited as a model of a "better" standard. It is enormously
vague on numerous matters of consequence. It omits really esential
functionaliy that would be neede dto write any seriously portable programs.
It was stagnant for years on quibbles over some of the silliest syntax
details. In my opinion, it's a toy language. There are real commercial
Scheme implementations, but only by the sheer will of those implementors
who've gone beyond the so-called stnadard and written in the things that the
stndard ought to have said in order to make the language finally useful.
It achieves its "prettiness" and its "smallness" on the back of just plain
leaving stuff out where it would appear to "clutter", and whatever you
think of CL, I personally reject any claim that the Scheme is a model of
improvement.
> The result is a remarkably good standards document, but
> for an implementor, there are still a lot to figure out that isn't
> explicitly stated in the standard. (I believe Kyoto Common Lisp was
> the first Common Lisp to have been written without access to the
> rich oral tradition surrounding CLtL1, ...)
Perhaps. I believe Robertson Common Lisp (which later became Symbolics
CLOE) was developed in relative isolation, too. It had some very odd
interpretations of some passages of CLTL. Most particularly the one that
I recall is that DEFVAR arranged for a variable to take on a value on
first access to the variable, because of some phrase about the variable
getting a value "if used" and they didn't realize that meant "if the
initial value form was used" rather than "if the symbol's value is
ultimately used".
* Kent M Pitman <······@world.std.com>
| So a standard which says
| "You can do whatever you want and call your implementation conforming."
| gets points for being a good standard?
Well, that's certainly _one_ implication. I had other implications
in mind, though... Like, determining whether an implementation is
or is not conforming is sometimes extremely hard because of a number
of important issues that are reduced to fuzziness where you don't
know how much you can do or how much you can't do. Of course, the
relative tightness of specification is just assumed to be reasonable.
| (2b) Using just the standard, can one take a conforming implementation
| and get work done without appealing to implementation-specific stuff.
I'd label this "completeness", which is a different metric again.
| The Scheme goal was not much different--to unite a community of textbook
| writers.
Heh.
| Note that I'm not being intentionally particularly defensive about
| CL's standard. I don't mind if people say it's not up to par or
| what they expect in a standard.
... and here I was trying to argue that ANSI CL is more useful than
the Scheme standard.
| I just absolutely don't believe the Scheme standard is fairly cited
| as a model of a "better" standard.
Well, on that I argued that the model of better computer science
standards have changed from the industrial standards of the past.
| In my opinion, it's a toy language.
But there are many good standards for toys. E.g., OSI (or "ISO
reference model for Open Systems Interconnection" for completeness).
Nobody in their right mind would even propose to use the whole set
of OSI protocols (those who did weren't :), but the standards define
a universe of their own that is fairly complete. Pity it doesn't
and can't apply to this universe.
| It achieves its "prettiness" and its "smallness" on the back of just plain
| leaving stuff out where it would appear to "clutter", and whatever you
| think of CL, I personally reject any claim that the Scheme is a model of
| improvement.
I see that the point of my message failed to get through. I have
argued that Scheme is a better standard in that world of standards
that isn't hampered by the requirement to fit the real world, and
that, when hampered by the real world, ANSI CL is as good as you can
get. The real world is incredibly messy and a model of the real
world that tries to brush the messiness under the rug can look nice,
but not work nice. What works nice is usually not very pretty.
I'm not trying to hold Scheme up as a model. I'm trying to explain
that they have succeeded along _one_ metric. Obviously, I don't
like the result at all, or I would actually have used Scheme, and
not Common Lisp. There's a reason I wrote hyperspec.el for Emacs so
I could jump right to the reference page, too. Please don't forget
that.
#:Erik
--
If this is not what you expected, please alter your expectations.
Kent M Pitman <······@world.std.com> writes:
> Erik Naggum <····@naggum.net> writes:
>
> > Since I argued that Scheme has the best standard I know about, and I
> > know that didn't match your views all that well, there are at least
> > two metrics by which you can judge a standard:
> >
> > (1) How easy is it to arrive at a conforming implementation
> > according to the standard?
>
> So a standard which says
> "You can do whatever you want and call your implementation conforming."
> gets points for being a good standard? I'm skeptical, unless the amount of
> goodness this can provide is properly only part of the whole.
You can off course go to far in this direction. On the other hand, in
the C standards community, there is a notion of "quality of
implementation issue", where some things are deliberately left open
for abuse if having the standard make hard guarantees is considered
too burdensome for the implementors. For instance, some of the minimal
implementation limits like depth of nested include files, depth of
nested control structures, size of array etc. are specified but an
implementation is conforming if at least one program hitting all these
limits compiles and runs correctly. So a standard conforming C
compiler can be a shell script accompanied by a "program.c" file that
basically does the following:
if program.c = program-to-compile
then print "Program successfully translated: The result=42"
else print "Error: implementation limits exceeded"
Off course, it's market share will be quite small ;-)
--
Lieven Marchand <···@bewoner.dma.be>
Lambda calculus - Call us a mad club
On Wed, 23 Aug 2000 14:58:49 GMT, Kent M Pitman <······@world.std.com>
wrote:
> That's what I get for writing a mostly-readable standard, I suppose.
> It's not perfect, surely, but compared to some other language
> stnadrds, it is approachable. Had I made it less readable by casual
As a beginner, when I first saw the HyperSpec I found it a bit
intimidating. But the more I used it, the more I found it useful and
approachable. Now I am studying it not only for learning about Lisp, but as
an example of good technical documentation.
To effectively use the HyperSpec it's better to start reading the
introductory material, especially sections on notation, and becoming
familiar with the overall structure of the document and its possible
reading paths (e.g. symbol entries, introductory sections to specific
topics, table of contents, etc.).
Then it's possible to check it on demand. The many links to terms defined
in the glossary are an invaluable resource for setting the appropriate
context for understanding the material in symbol entries.
Here's a tip. When not using Emacs, I prefer to browse the HyperSpec with
Lynx. This way I can control browsing entirely with the keyboard, and I get
very fast response times compared to Netscape.
What are your favorite HyperSpec tips and tricks?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: Rudolf Schlatte
Subject: Re: HyperSpec tips & tricks [was: Re: case confusion]
Date:
Message-ID: <lxr977sy5g.fsf@ist.tu-graz.ac.at>
Paolo Amoroso <·······@mclink.it> writes:
> What are your favorite HyperSpec tips and tricks?
Reading it on the Palm Pilot with iSilo. Bought another 4MB just for
this purpose.
From: Xenophon Fenderson the Carbon(d)ated
Subject: Re: HyperSpec tips & tricks [was: Re: case confusion]
Date:
Message-ID: <w4oaedvdkzd.fsf@lovecraft.irtnog.org>
>>>>> "Rudolf" == Rudolf Schlatte <········@ist.tu-graz.ac.at> writes:
Rudolf> Reading it on the Palm Pilot with iSilo. Bought another
Rudolf> 4MB just for this purpose.
I would love to have a copy. Is it in DOC format or do I have to buy
a copy of Isilo to read it? And where can I download it?
--
UN-altered reproduction and DISSEMINATION of this IMPORTANT information is
ENCOURAGED
From: Rudolf Schlatte
Subject: Re: HyperSpec tips & tricks [was: Re: case confusion]
Date:
Message-ID: <lx4s423i69.fsf@ist.tu-graz.ac.at>
[non-lisp content ahead]
········@irtnog.org (Xenophon Fenderson the Carbon(d)ated) writes:
> >>>>> "Rudolf" == Rudolf Schlatte <········@ist.tu-graz.ac.at> writes:
>
> Rudolf> Reading it on the Palm Pilot with iSilo. Bought another
> Rudolf> 4MB just for this purpose.
>
> I would love to have a copy. Is it in DOC format or do I have to buy
> a copy of Isilo to read it? And where can I download it?
The license of the HyperSpec explicitly forbids redistribution of
altered versions (and with good reasons; inadvertent alteration by
human or tool error would be a Bad Thing). I figured that as long as
the converted version never leaves my Pilot, it's okay.
That being said, there are free (as in beer) HTML conversion tools at
<http://www.isilo.com/>. Re Doc format: the great thing about iSilo
is that it groks Hyperlinks and displays images (Doc does not). The
Hyperspec is not much fun without links. There's a demo version of
iSilo too, but it doesn't do Hyperlinks, so I bought a full version.
Have fun,
Rudi