Rüdiger Sonderfeld <cplusplush...@gmx.net> writes: > Thomas F. Burdick wrote: > > You might also be interested in CHAR=, CHAR<, CHAR>, etc., depending > > on why you want this. Be sure to check:
> I wrote this function
> (defun isupper(x) > (if (and (char>= x #\A) (char<= x #\Z)) > t (return-from isupper)) > nil)
> but it always returns nil :(
Of course, it does exactly what you told it to:
(defun isupper (x) (if (and ...) t (return-from isupper) nil))
If the condition is true, the value of the IF form is T, which is then discarded, and NIL is returned. If the condition is not true, then you explicitly return NIL.
What you want is something like:
(defun isupper (x) (if (and ...) t nil))
Although, if you read the link in my previous message, you'll see that this isn't guaranteed to work. Besides, it's already built in: UPPER-CASE-P.
Dear lord, please use Emacs to format your code for you (M-q). This is the Lisp equivalent of the C:
if (foo) bar(f); else bar(f); baz(f);
That function should be indented as:
;; one form (defun isupper (x) (if (and (>= (char-code x) (char-code #\A)) (<= (char-code x) (char-code #\Z))) t (return-from isupper))) ;; end of defun, followed by another form nil ;; stray close paren )
-- /|_ .-----------------------. ,' .\ / | No to Imperialist war | ,--' _,' | Wage class war! | / / `-----------------------' ( -. | | ) | (`-. '--.) `. )----'
Rüdiger Sonderfeld <cplusplush...@gmx.net> writes: > Thomas F. Burdick wrote: > > You might also be interested in CHAR=, CHAR<, CHAR>, etc., depending > > on why you want this. Be sure to check:
> I wrote this function
> (defun isupper(x) > (if (and (char>= x #\A) (char<= x #\Z)) > t (return-from isupper)) > nil)
> but it always returns nil :(
That's because you told it to :-)
(defun isupper(x) (if (and (char>= x #\A) (char<= x #\Z)) (return-from isupper t)) nil)
would work, as would
(defun isupper (x) (if (and (char>= x #\A) (char<= x #\Z)) t nil))
In article <ahv31f$kvv$0...@news.t-online.com>, Rüdiger Sonderfeld wrote: > Thomas F. Burdick wrote: >> You might also be interested in CHAR=, CHAR<, CHAR>, etc., depending >> on why you want this. Be sure to check:
> I wrote this function
> (defun isupper(x) > (if (and (char>= x #\A) (char<= x #\Z))
You are assuming that the characters A through Z have consecutive values, which happens to be true in ASCII and character systems derived from it, like ISO-8859-<N> and UNICODE.
In any case, Lisp already has this predicate function, it is called upper-case-p. You should study the HyperSpec to discover what functions are available in Common Lisp.
> t (return-from isupper)) > nil)
> but it always returns nil :(
That's because you told it to. The last form in the function is nil, which is what is evaluated after the if form, unless the return-from is evaluated, which also returns nil.
> > > Thomas F. Burdick wrote: > > > > You might also be interested in CHAR=, CHAR<, CHAR>, etc., depending > > > > on why you want this. Be sure to check:
> > > I wrote this function
> > > (defun isupper(x) > > > (if (and (char>= x #\A) (char<= x #\Z)) > > > t (return-from isupper)) > > > nil)
> > > > Thomas F. Burdick wrote: > > > > > You might also be interested in CHAR=, CHAR<, CHAR>, etc., depending > > > > > on why you want this. Be sure to check:
> > > > I wrote this function
> > > > (defun isupper(x) > > > > (if (and (char>= x #\A) (char<= x #\Z)) > > > > t (return-from isupper)) > > > > nil)
Despite all the good intentions and efforts to help this lost newbie, I think it is a mistake to try to help people who ask such questions. (This reply is not directed specifically towards Nils.)
Defining your own because the standard function does not have the same name as in C is wrong. We already have upper-case-p, lower-case-p, alpha-char-p, etc, in Common Lisp. Reinventing wheels to look more like C will do nobody any good. Even asking for strlen and isupper is extremely counterproductive.
People who ask for help in Common Lisp but refuse to relinquish their past language remind that I want to learn French, but only to hear it and read it. The utter helplessness of most French-speakers' attempt to produce English is so grating on my ears that I not only would like to be relieved of listening to it, speaking their language to them would probably be just as atrocious (almost like pronouncing "fromage" like "fromidge").
The original poster has no problem with strings, he has a problem with his willingness to learn Common Lisp. Much could be said about this affliction of the mind that causes people to assume that what they do not understand does not matter, that they have reached such a level of omniscience that they no longer need to observe and listen and learn. Having learned enough, some people evidently stop learning altogether. What they learned first is the standard for everything that comes later. That the probably only _truly_ random element in anyone's life is the order in which they experience things, seems not even to be underststandable -- they somehow believe that the order they run into them is universalizable and important, that first impressions really tell you everything you need to know about something. I have seen people who have the mental capacity only for the transition from "have not experienced" to "have experienced", and who are unable to make a distinction between their observations and their conclusions, such that they are unable to change their conclusions about what they observed. They walk around like they had CD-Rs for brains.
What is the length of a string? C's string representation has no room for an allocated length vs an active length. C's string representation has no concept of substrings. C's strings cannot contain all possible characters. C's strlen is actually (position 0 <string> :key #'char-code) and is O(n).
Forget "strlen". For our immediate purposes, there is no "strlen". "strlen" does not _exist_.
Common Lisp has vectors with fill-points, and strings are vectors which are sequences and arrays. Numerous functions that in other languages only work on strings, work on sequences in Commo Lisp. Functions like search, match, find, position, etc, are much more general than string functions in other languages. A string with a fill-pointer has a total and an active length. Most sequence functions accept bounding indices, start and end indices that make it possible to use substrings without modifying the target strings. Common Lisp even has displaced arrays if you really need a substring without copying the string contents. Common Lisp has string-streams to read from and write to strings in memory. Common Lisp has real charcters, not just small integers. Common Lisp's characters are not bytes, so when Unicode came along, there was no need to make extensive library and language changes. Common Lisp supports base and extended characters and hence base-string in addition to the general string.
Common Lisp is a big-city language. Spit out the hayseed, pronounce "shit" with one syllable and "shotgun" with two. You're not in Kansas, anymore. C is the language of the poor farmer village where the allocation of every seed and livestock matters, where taxes are low and public service non-existent. Appreciating the value of a large language is evidently hard for many people, just like many people find themselves miserable in the big city and go to great lengths to create a small village for themselves in the city where everything is like it used to be where they came from. Common Lisp can accomodate people who want to program in any old language and re-create what they are used to, but if they want to get the most ouf ot it, the only way to do it is to adapt to the language and accept that somebody else may be better than you are at designing languages.
-- Erik Naggum, Oslo, Norway ***** One manslaughter is another man's laughter.
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
Erik Naggum <e...@naggum.net> writes: > * Nils Goesche > | (defun isupper (char) > | (char<= #\A char #\Z))
> Despite all the good intentions and efforts to help this lost > newbie, I think it is a mistake to try to help people who ask such > questions. (This reply is not directed specifically towards > Nils.)
> Defining your own because the standard function does not have the > same name as in C is wrong. We already have upper-case-p, > lower-case-p, alpha-char-p, etc, in Common Lisp. Reinventing > wheels to look more like C will do nobody any good. Even asking > for strlen and isupper is extremely counterproductive.
I understand what you're saying and actually agree with you, as far as newbies are concerned. That's precisely why I so strongly oppose using the word ``pointer'' when explaining anything about Lisp. If you tell a newbie ``When you pass a cons cell to a function, what really gets passed is a pointer to the cell, not the cell itself'' or some such, you are only encouraging him to continue to think in C terms like pointers and memory locations, instead of Lisp terms like bindings and objects with identity. The result will be yet another one who thinks Lisp is call-by-reference. So, when a newbie asks a question thereby revealing that he is still thinking in wrong terms, it is not right to tell him how to achieve whatever stupid thing he is trying to do, but one should rather set him straight about his terms and desires.
However, in this case, the OP wasn't even able to use IF and RETURN-FROM correctly, something he should be capable of doing, had he only read the first few pages of an introductory Lisp text. My conclusion was that he hasn't even started learning Lisp yet but is still only playing around with it, so I wouldn't even call him a newbie :-) Often when we encounter something new, we want to play around with it immediately. Of course, we could start learning how to use it properly right away, but playing around with something new is a natural human desire, I think. Sometimes I give in, sometimes not. When I buy something new like a DVD player, I sometimes read the manual right away, or first play around with it and read the manual then. Sometimes, when I learn a new programming language, I read its definition right away, as I did with SML or Java, for instance, and sometimes I first play around with it, as I did with Lisp or OCaml.
As long as you are only playing around with something, you don't want to hear long explanations about your misconceptions because listening and thinking much would mean that you've stopped playing and have started learning. Some people think this ``playing phase'' should be omitted altogether because all it does is forming bad habits. Well, maybe. But it's also fun :-) And it might make somebody curious enough that he really starts learning. How dangerous it is depends strongly on whether he is willing to give up old beliefs and misconceptions, then. When we see that somebody isn't willing to drop his old beliefs, we should scold him until he does, but only after he has actually started learning, I think.
Regards, -- Nils Goesche "Don't ask for whom the <CTRL-G> tolls."
Erik> Despite all the good intentions and efforts to help this Erik> lost newbie, I think it is a mistake to try to help people Erik> who ask such questions. (This reply is not directed Erik> specifically towards Nils.)
Erik> Defining your own because the standard function does not Erik> have the same name as in C is wrong. We already have Erik> upper-case-p, lower-case-p, alpha-char-p, etc, in Common Erik> Lisp. Reinventing wheels to look more like C will do nobody Erik> any good. Even asking for strlen and isupper is extremely Erik> counterproductive.
Where did you pick up the idea that anyone is defining functions "because the standard function does not have the same name as in C"? Another reason could be: let's take a function whose semantics I know, try to implement it in lisp and see what the differences there are. Immanuel
Erik Naggum wrote: > Despite all the good intentions and efforts to help this lost newbie, I > think > it is a mistake to try to help people who ask such questions. (This > reply is not directed specifically towards Nils.)
> Defining your own because the standard function does not have the same > name > as in C is wrong.
I don't want to write my own upper-case-p function because they use different names in C! I only want to test the language. My first poor steps. And the string part in the tutorial I read is very short (I read the LISP-tutorial.txt that I found in the clisp release documentation).
So I thought it is no problem to ask here and I asked for the C functions because I hoped that everybody will understand me!
> Reinventing wheels to look more like C will do nobody > any good.
you are right. But I only want to test the language (play with it a little bit) and so I wrote some uninteressting functions! I didn't want to write a big program looking like C!
> People who ask for help in Common Lisp but refuse to relinquish their > past language
I don't want to relinquish my past language! I want to learn lisp for additional use!
And I thought it isn't a problem to use the name of the C functions so that it is easier to understand what I mean!
> The original poster has no problem with strings, he has a problem with > his > willingness to learn Common Lisp.
No! I read a tutorial! And I only want to play with Common Lisp because I want to know if common lisp is the language I need.
> Much could be said about this > affliction of the mind that causes people to assume that what they do > not understand does not matter, that they have reached such a level of > omniscience that they > no longer need to observe and listen and learn. Having learned enough, > some > people evidently stop learning altogether. What they learned first is > the > standard for everything that comes later. That the probably only > _truly_ random element in anyone's life is the order in which they > experience things, seems not even to be underststandable -- they somehow > believe that the order they run into them is universalizable and > important, that first impressions > really tell you everything you need to know about something. I have > seen people who have the mental capacity only for the transition from > "have not experienced" to "have experienced", and who are unable to make > a distinction between their observations and their conclusions, such > that they are unable > to change their conclusions about what they observed. They walk around > like they had CD-Rs for brains.
> What is the length of a string? C's string representation has no room > for an allocated length vs an active length. > C's string representation has no > concept of substrings. C's strings cannot contain all possible > characters. C's strlen is actually (position 0 <string> :key > #'char-code) and is O(n).
> Forget "strlen". For our immediate purposes, there is no "strlen". > "strlen" does not _exist_.
> Common Lisp has vectors with fill-points, and strings are vectors which > are > sequences and arrays. Numerous functions that in other languages only > work > on strings, work on sequences in Commo Lisp. Functions like search, > match, find, position, etc, are much more general than string functions > in other > languages. A string with a fill-pointer has a total and an active > length. Most sequence functions accept bounding indices, start and end > indices that make it possible to use substrings without modifying the > target strings. Common Lisp even has displaced arrays if you really need > a substring without > copying the string contents. Common Lisp has string-streams to read > from and > write to strings in memory. Common Lisp has real charcters, not just > small > integers. Common Lisp's characters are not bytes, so when Unicode came > along, there was no need to make extensive library and language changes. > Common Lisp supports base and extended characters and hence base-string > in addition to the general string.
> Common Lisp is a big-city language. Spit out the hayseed, pronounce > "shit" > with one syllable and "shotgun" with two. You're not in Kansas, > anymore. C is the language of the poor farmer village where the > allocation of every seed and livestock matters, where taxes are low and > public service non-existent. Appreciating the value of a large language > is evidently hard for many people, just like many people find themselves > miserable in the big city and go to great lengths to create a small > village for themselves in the city where > everything is like it used to be where they came from. Common Lisp can > accomodate people who want to program in any old language and re-create > what they are used to, but if they want to get the most ouf ot it, the > only way to do it is to adapt to the language and accept that somebody > else may be better than you are at designing languages.
Oh C is so bad that you're OS and Common Lisp Interpreter is written in it.
Nils Goesche wrote: > However, in this case, the OP wasn't even able to use IF and > RETURN-FROM correctly, something he should be capable of doing, had he > only read the first few pages of an introductory Lisp text.
I read a tutorial.
> My conclusion was that he hasn't even started learning Lisp yet but is > still only playing around with it, so I wouldn't even call him a > newbie :-)
I want to test Common Lisp. If Common Lisp is what I need I will learn it really.
> As long as you are only playing around with something, you don't want > to hear long explanations about your misconceptions because listening > and thinking much would mean that you've stopped playing and have > started learning.
I want to hear long explanations because so I can see if Common Lisp is what I want.
Immanuel Litzroth wrote: > Where did you pick up the idea that anyone is defining functions > "because the standard function does not have the same name as in C"? > Another reason could be: let's take a function whose semantics I > know, try to implement it in lisp and see what the differences there > are.
Rüdiger Sonderfeld <cplusplush...@gmx.net> writes: > > As long as you are only playing around with something, you don't want > > to hear long explanations about your misconceptions because listening > > and thinking much would mean that you've stopped playing and have > > started learning.
> I want to hear long explanations because so I can see if Common Lisp is > what I want.
This is unfair to us who are not so newby as you are. You obviously want us to write an own tutorial for you who are too idle to find and understand one. I consider this as a form of trolling. Please study
Nicolas Neuss wrote: > Rüdiger Sonderfeld <cplusplush...@gmx.net> writes: > This is unfair to us who are not so newby as you are. You obviously > want us to write an own tutorial for you who are too idle to find and > understand one.
I don't want you to write a tutorial for me! I only said that i want to hear long explanations because you wrote that I don't wont to hear them.
> I consider this as a form of trolling. [...] > before you write in that impertinent way here.
I didn't knew that asking a question about to simple Common Lisp functions and a code problem (okay it was a easy problem) is impertinence.
Ruediger Sonderfeld <cplusplush...@gmx.net> writes: > Nicolas Neuss wrote:
> > Rüdiger Sonderfeld <cplusplush...@gmx.net> writes: > > This is unfair to us who are not so newby as you are. You obviously > > want us to write an own tutorial for you who are too idle to find and > > understand one.
> I don't want you to write a tutorial for me! I only said that i want to > hear long explanations because you wrote that I don't wont to hear them.
> > I consider this as a form of trolling. > [...] > > before you write in that impertinent way here.
> I didn't knew that asking a question about to simple Common Lisp functions > and a code problem (okay it was a easy problem) is impertinence.
It is also not far from impertinence to cite only what fits to ones response. The sentence to which I objected and which I find impertinent is:
Rüdiger Sonderfeld <cplusplush...@gmx.net> writes: > I want to hear long explanations because so I can see if Common Lisp is > what I want.
Again, and the last time: we all have other jobs to do than writing you your own tutorial.
Rüdiger Sonderfeld <cplusplush...@gmx.net> writes: > Oh C is so bad that you're OS and Common Lisp Interpreter is written in it.
Speak for yourself, but most of _my_ Common Lisp compiler (note: `compiler', `not interpreter') is written in Common Lisp. And the OS is written in a variety of languages including C, Python, Perl and several other Lisp and Lisp-like languages (rep, elisp, guile etc).
Rüdiger Sonderfeld <cplusplush...@gmx.net> writes: > Erik Naggum wrote: > > Defining your own because the standard function does not have > > the same name as in C is wrong. > I don't want to write my own upper-case-p function because they use > different names in C! I only want to test the language. My first > poor steps. And the string part in the tutorial I read is very short > (I read the LISP-tutorial.txt that I found in the clisp release > documentation).
Nicolas gave you a URL of another one.
> So I thought it is no problem to ask here and I asked for the C > functions because I hoped that everybody will understand me!
> > Reinventing wheels to look more like C will do nobody any good.
> you are right. But I only want to test the language (play with it a > little bit) and so I wrote some uninteressting functions! I didn't > want to write a big program looking like C!
> > People who ask for help in Common Lisp but refuse to relinquish > > their past language
> I don't want to relinquish my past language! I want to learn lisp > for additional use!
Please make up your mind: Sometimes you say you want to learn it, sometimes you say you only want to play around with it, then you say you want to ``test'' it in order to find out if it is what you need. Well, at least I can assure you that you won't find out that without actually learning it. Tutorials tell you how to play around with it, they won't teach you much, if anything. That's what they're for, I think. If you want to start learning, tutorials aren't good enough anymore; get a book. Which one is right for you is hard to say; maybe Paul Graham's ANSI Common Lisp, or Stephen Slade's Object-Oriented Common Lisp, or, if you find those too hard, try
> And I thought it isn't a problem to use the name of the C functions > so that it is easier to understand what I mean!
The point is another one, namely that in order to learn Lisp, you have to stop thinking in C terms. Learn Lisp in its own terms. There are people who try to map any new thing they learn about Lisp onto something they already know from C, like ``Ah, in C, I would do that in such-and-such way''. That way doesn't work here, you won't learn a thing as long as you try to do that. /That's/ what Erik was concerned about, and rightly so.
> > The original poster has no problem with strings, he has a > > problem with his willingness to learn Common Lisp.
> No! I read a tutorial! And I only want to play with Common Lisp > because I want to know if common lisp is the language I need.
See above.
> > I have seen people who have the mental capacity only for the > > transition from "have not experienced" to "have experienced", > > and who are unable to make a distinction between their > > observations and their conclusions, such that they are unable to > > change their conclusions about what they observed. They walk > > around like they had CD-Rs for brains.
> I don't think I have learned enough!
That's nice to hear. So start learning and stop being so defensive :-)
> > Common Lisp is a big-city language. Spit out the hayseed, > > pronounce "shit" with one syllable and "shotgun" with two. > > You're not in Kansas, anymore. C is the language of the poor > > farmer village where the allocation of every seed and livestock > > matters, where taxes are low and public service > > non-existent. Appreciating the value of a large language is > > evidently hard for many people, just like many people find > > themselves miserable in the big city and go to great lengths to > > create a small village for themselves in the city where > > everything is like it used to be where they came from. Common > > Lisp can accomodate people who want to program in any old > > language and re-create what they are used to, but if they want > > to get the most ouf ot it, the only way to do it is to adapt to > > the language and accept that somebody else may be better than > > you are at designing languages.
> Oh C is so bad that you're OS and Common Lisp Interpreter is written > in it.
Erik Naggum is not exactly known as a CLISP user. Most Common Lisp systems compile into native machine code, and are not properly described as ``Interpreters''. And yes, C and C++ /are/ bad, that's why many of us have come here. Why don't you start learning and find out for yourself? :-)
You'd better listen to him, rather than being sarcastic, and get on with it.
Regards, -- Nils Goesche "Don't ask for whom the <CTRL-G> tolls."
> Please make up your mind: Sometimes you say you want to learn it, > sometimes you say you only want to play around with it, then you say > you want to ``test'' it in order to find out if it is what you need. > Well, at least I can assure you that you won't find out that without > actually learning it. Tutorials tell you how to play around with it, > they won't teach you much, if anything. That's what they're for, I > think. If you want to start learning, tutorials aren't good enough > anymore; get a book. Which one is right for you is hard to say; maybe > Paul Graham's ANSI Common Lisp, or Stephen Slade's Object-Oriented > Common Lisp, or, if you find those too hard, try
>> And I thought it isn't a problem to use the name of the C functions >> so that it is easier to understand what I mean!
> The point is another one, namely that in order to learn Lisp, you have > to stop thinking in C terms. Learn Lisp in its own terms. There are > people who try to map any new thing they learn about Lisp onto > something they already know from C, like ``Ah, in C, I would do that > in such-and-such way''. That way doesn't work here, you won't learn a > thing as long as you try to do that. /That's/ what Erik was concerned > about, and rightly so.
okay he is right
>> Oh C is so bad that you're OS and Common Lisp Interpreter is written >> in it.
> Erik Naggum is not exactly known as a CLISP user. Most Common Lisp > systems compile into native machine code, and are not properly > described as ``Interpreters''. And yes, C and C++ /are/ bad, that's > why many of us have come here. Why don't you start learning and find > out for yourself? :-)
I only know clisp and clisp is mostly written in C. I thought that is common to other implementations.
And I don't think you can compare C(++) and Common Lisp. But we shouldn't discuss this!
> You'd better listen to him, rather than being sarcastic, and get on > with it.
okay, you are right. I'm sorry. I think he's right that it is important to forget C(++) and other languages I know.
