> (mapcar #'my-eql my-list) > ; probobly we can use a lambda-function but I'm not sure how
> this will give us (NIL T NIL) whereas I just want a 2 or NIL
> NIL if we can not find any 'toto in my-list or > 2 because it's the element number 2 of my-list which is 'toto
I get (NIL NIL NIL), which is quite understandable because 'toto is not the same as '(toto).
Try something like
(position '(toto) *my-list* :test #'equal)
or
(position 'toto *my-list* :key #'car :test #'eql)
or even
(position t (mapcar #'my-test *my-list*))
--- but the last is somewhat inelegant :-)
All of these "solutions" require you to sort of what you're actually trying to do - are you looking for '(toto), or 'toto as the first element in a sublist?
> > (mapcar #'my-eql my-list) > > ; probobly we can use a lambda-function but I'm not sure how
> > this will give us (NIL T NIL) whereas I just want a 2 or NIL
> > NIL if we can not find any 'toto in my-list or > > 2 because it's the element number 2 of my-list which is 'toto
> How about
> (1+ (position 'toto my-list :key #'car))
That doesn't take into account that position might return nil. Use something like this instead: (let ((pos (position 'toto my-list :key #'car))) (and pos (1+ pos)))
> Regards, > -- > Nils Goesche > Ask not for whom the <CONTROL-G> tolls.
----- Oprindelig meddelelse ----- Fra: "ab talebi" <ab_talebi...@yahoo.com> Nyhedsgrupper: comp.lang.lisp Sendt: 3. februar 2002 18:22 Emne: one small function
----- Guess that's all right. and then I made setf into setq and pastet to an Lisp evaluator , like this ;
Yield error function undefined, after expecting an enter with the line (mapcar #'my-eql my-list), I simply don't understand why you write (list) in parentets in ; (defun my-eql (list) (eql 'toto list)) Then beside the function undefined, must be the "eql" in last line.
I don't understand the last line ; you call mapcar with a function you define ; (defun my-eql (list) (eql 'toto list)) Now this is not a function, so what I don't understand, is how you have two parameters to mapcar, and what the _if_ you pass on a function you described yourself, maby the trouble is, that the function you define for that, need a parameter list with one member ; the element the function will work on down the list. Please clearify, as Im'e very confused, how you first define the function that will work with mapcar. Have a nice day. P.C.
> Yield error function undefined, after expecting an enter with the line (mapcar > #'my-eql my-list), > I simply don't understand why you write (list) in parentets in ; > (defun my-eql (list) > (eql 'toto list)) > Then beside the function undefined, must be the "eql" in last line.
>> > (mapcar #'my-eql my-list) >> > ; probobly we can use a lambda-function but I'm not sure how
>> > this will give us (NIL T NIL) whereas I just want a 2 or NIL
>> > NIL if we can not find any 'toto in my-list or >> > 2 because it's the element number 2 of my-list which is 'toto
>> How about
>> (1+ (position 'toto my-list :key #'car))
>That doesn't take into account that position might return nil. Use something >like this instead: >(let ((pos (position 'toto my-list :key #'car))) > (and pos (1+ pos)))
ok, lets say that we impliment that into a function like this:
(defun find-position (word list) (let ((pos (position word list :key #'car))) (and pos (1+ pos))))
> to contain several '(toto)s it will still return only the position of > the first one > 2 > whereas it should give us > 2 4
> any idea?
(defun find-positions (item list &key (test #'eql) (key #'identity)) (loop for position from 1 and element in list when (funcall test item (funcall key element)) collect position))
> In Common Lisp, DEFUN is used to define functions and the syntax of the > definition form is rather a bit different than for DEFINE in Scheme.
Now I agrea that I don't know Sceme ; so in Sceme you can have a list representing the symbol . What I mean is, that this differ from Lisp, where an evaluator automaticly will look at car list, as if that's a symbol there will be a defined function to be evaluatet, and the remaining part of the list, will then be the parameters described in the function description , ---- guess you se why I simply didn't understand this ;
>(setf my-list '((titi tata) (toto) (tada))) ;
;------ isn't there a missing right parentets here ?------- so the defun my-list continue with
> (defun my-eql (list) > (eql 'toto list))
> (mapcar #'my-eql my-list)
While using "(list)" ; a predefined function, as parameter, and then Mapcar a function "#" onto a function defined, and then making Mapcar work a function "#" on two lists ,first a function defination list and then an unballanced list with 3 lists with each one symbol ; hope you understand how I find this very confusing ; don't sceem have same rules about ballancing parentets as Lisp ? P.C.
Guess the difference Sceme/Lisp are very small but important, ------- still the doubt I had, made me think, that you was mapping within a function allready defined, changing the function defination, I can now se, after you explained the #'foo being _one_ symbol, that Mapcar is not working on two but one list, and that make sense, as Im'e used to define my own one parameter functions working recursive with mapcar , mapping down a list. P.C.
> Now I agrea that I don't know Sceme ; so in Sceme you can have a list > representing the symbol . > What I mean is, that this differ from Lisp, where an evaluator automaticly will > look at car list, as if that's a symbol there will be a defined function to be > evaluatet, and the remaining part of the list, will then be the parameters > described in the function description , ---- guess you se why I simply didn't > understand this ;
> >(setf my-list '((titi tata) (toto) (tada))) ; > ;------ isn't there a missing right parentets here ?------- so the defun
No, look again. A BC C D D E EBA 1 > (setq my-list '((titi tata) (toto) (tada))) ((TITI TATA) (TOTO) (TADA))
> While using "(list)" ; a predefined function, as parameter, and then Mapcar a > function "#" onto a function defined, and then making Mapcar work a function "#" > on two lists ,first a function defination list and then an unballanced list with > 3 lists with each one symbol ; hope you understand how I find this very > confusing ; don't sceem have same rules about ballancing parentets as Lisp ? > P.C.
In Lisp, a symbol may be a function name and still be a variable AT THE SAME TIME, which gets used depends on context.
5 > (setf list 4) 4
6 > list ;; context: "list" treated as variable 4
7 > (function list) ;; function says: No, treat "list" as a function name #<function LIST 200DCA7A>
8 > (function not-a-function) Error: Undefined function NOT-A-FUNCTION...
#' is shorthand for (function ...) just like ' is shorthand for (quote ...)
9 > #'list #<function LIST 200DCA7A>
10 > (list 1 2 3 4) ;; context: "list" treates as function name (1 2 3 4)
MAPCAR's entry in the hyperspec looks like this: mapcar function &rest lists+ => result-list In other words, MAPCAR takes as arguments a function and 0 or more lists and returns a list.
"Geoff Summerhayes" <sNuOmSrPnA...@hNoOtSmPaAiMl.com> writes: > MAPCAR's entry in the hyperspec looks like this: > mapcar function &rest lists+ => result-list > In other words, MAPCAR takes as arguments a function and 0 or more lists > and returns a list.
> 11 > (mapcar #'my-eql my-list) > (NIL NIL NIL)
Actually, it's a small point, but the use of "lists+" in the ANSI CL (and hence CLHS) notation indicates that at least one of these lists is required. For better or worse, you aren't allowed to do (mapcar #'(lambda ())).
> > MAPCAR's entry in the hyperspec looks like this: > > mapcar function &rest lists+ => result-list > > In other words, MAPCAR takes as arguments a function and 0 or more lists > > and returns a list.
> Actually, it's a small point, but the use of "lists+" in the ANSI CL > (and hence CLHS) notation indicates that at least one of these lists > is required. For better or worse, you aren't allowed to do > (mapcar #'(lambda ())).
* "P.C." <per.cor...@privat.dk> | Guess the difference Sceme/Lisp are very small but important
They are so large that someone who has been trained in Scheme has no hope of ever learning Common Lisp, because they _think_ the differences are very small despite strong evidence to the contrary, and because it is possible to write Scheme in Common Lisp, they will never be "offered" the necessary negative feedback necessary to "get it".
I think the problem is that most people who have not been made aware of this fallacy at a young age have an unnerving tendency to think that they know something if it looks like something they know, and the less they _actually_ know what they think they know, the more they think something that looks the same to them, also _is_ the same. In a world of physical objects, this is probably not such a bad idea. The number of things you need to examine to determine that something is a duck is quite limited. This changes with man-made objects, and even more with purely man-made constructs like the infrastructure of a society or programming languages, where you have to be able to distinguish differences between _versions_ of what is actually _marketed_ as the same, For instance, if you plan according to the tax law or the Java version of a year ago, you are in trouble. This leads to a reversal of an important relationship between identity and details: In the physical world, if you find large similar properties between something new and something you know, you are quite justified in concluding that you know what it is, but in the man-made world, especially that of ideas, it is more important to look carefully after you have discovered large-scale similarities than before.
For man-made things and ideas in particular, the belief that what looks the same is the same is an anti-intellectual attitude towards one's knowledge and actually betrays a lack of understanding of that which is believeed known. Also, since this belief is most probably not restricted to one particular area of knowledge, but is a result of methodological errors in reasoning and learning, there is no chance at all to make such a believer realize that he does not actually know what he believes he knows until he runs into a very serious problem that he cannot resolve well enough for comfort. Only when programming is made into a "team" effort which exposes newbies to the critical review that only gurus can provide, and gurus themselves acknowledge that new gurus may arise worth listening to, can the necessary feedback loops work well enough that good knowledge drives out bad. Today, we have a lot of people who are quite convinced of their own competence mainly because they have never been challenged beyond what they already know.
The tragedy is that "looks the same, is the same" is not commutative. If you learned Common Lisp well and then found Scheme, it would be nothing more than some old home-made toy discovered in your parent's basement -- cute and all that, but not worth playing with for long, because all of the stuff you think a real programming language should have are simply not there. If you learned Scheme first and then found Common Lisp, it would seem just like Scheme, because what you have come to think of as a "programming language" is basically so little that you would not even comprehend all the stuff in Common Lisp that is not like Scheme at all.
/// -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief.
Erik Naggum <e...@naggum.net> writes: > * "P.C." <per.cor...@privat.dk> > | Guess the difference Sceme/Lisp are very small but important
... > The tragedy is that "looks the same, is the same" is not commutative. If > you learned Common Lisp well and then found Scheme, it would be nothing > more than some old home-made toy discovered in your parent's basement -- > cute and all that, but not worth playing with for long, because all of > the stuff you think a real programming language should have are simply > not there. If you learned Scheme first and then found Common Lisp, it > would seem just like Scheme, because what you have come to think of as a > "programming language" is basically so little that you would not even > comprehend all the stuff in Common Lisp that is not like Scheme at all.
This kind of reminds me of when I was in high school and had taken high school algebra and a little analysis and someone handed me a calculus textbook to give me an idea of what I would learn the next year. I flipped through it quickly, taking an inventory of the notation--lots of x's and y's and exponents and sigmas and stuff. I shrugged and handed it back. "Yeah, I can do all this. Looks pretty much like what I already know except maybe for that little squiggle [integral sign]," I remarked to the person showing me the book. "I guess I won't learn anything much new next year," I continued with a sigh.
Superficial similarity and overlap of notation can be quite deceiving sometimes.
Erik Naggum <e...@naggum.net> writes: > * "P.C." <per.cor...@privat.dk> > | Guess the difference Sceme/Lisp are very small but important
> They are so large that someone who has been trained in Scheme has no hope > of ever learning Common Lisp, because they _think_ the differences are > very small despite strong evidence to the contrary, and because it is > possible to write Scheme in Common Lisp, they will never be "offered" the > necessary negative feedback necessary to "get it".
At my uni, taking the SICP course is a recommended preparation for those who wish to take the CL course. Therefore I choose, despite your warnings, to assimilate what Scheme has to offer as a teaching language. Any advice on how to get through unharmed? (OVS phrasing optional...) -- chr
Here we have the Nagging Naggum, detailing his fantasy of Scheme hatred, through cunning theories and fastidious remarks, on the philosophies of same and not the same, the tragedies of commutative or non-commutative phrase inventions.
> Guess the difference Sceme/Lisp are very small but important
The different is trivial, the distinction trifle. In the history of computer languages, they are identical.
What's different languages? Logical languages and functional languages are different. Pure OOP languages and traditional imperative languages are different. Lisp family languages and purely functional languages makes a huge difference. Purely functional languages and denotational languages have importantly distinct concepts.
My readers, set your eyes afar, your views afield. Don't fret about the trifling particularities of Scheme and common lisps that so bugs the Nag'm & Pit-man scheming haters. If you are concerned about learning something, master a *different* language as i outlined above. Broaden your mind.
Btw, i think i'm the first person who coined Nagging Naggum. (is that right, Erik?) If so, i should get some credit.
From: Erik Naggum (e...@naggum.net) Subject: Re: one small function Newsgroups: comp.lang.lisp Date: 2002-02-07 00:01:37 PST
* "P.C." <per.cor...@privat.dk> | Guess the difference Sceme/Lisp are very small but important
They are so large that someone who has been trained in Scheme has no hope of ever learning Common Lisp, because they _think_ the differences are very small despite strong evidence to the contrary, and because it is possible to write Scheme in Common Lisp, they will never be "offered" the necessary negative feedback necessary to "get it".
I think the problem is that most people who have not been made aware of this fallacy at a young age have an unnerving tendency to think that they know something if it looks like something they know, and the less they _actually_ know what they think they know, the more they think something that looks the same to them, also _is_ the same. In a world of physical objects, this is probably not such a bad idea. The number of things you need to examine to determine that something is a duck is quite limited. This changes with man-made objects, and even more with purely man-made constructs like the infrastructure of a society or programming languages, where you have to be able to distinguish differences between _versions_ of what is actually _marketed_ as the same, For instance, if you plan according to the tax law or the Java version of a year ago, you are in trouble. This leads to a reversal of an important relationship between identity and details: In the physical world, if you find large similar properties between something new and something you know, you are quite justified in concluding that you know what it is, but in the man-made world, especially that of ideas, it is more important to look carefully after you have discovered large-scale similarities than before.
For man-made things and ideas in particular, the belief that what looks the same is the same is an anti-intellectual attitude towards one's knowledge and actually betrays a lack of understanding of that which is believeed known. Also, since this belief is most probably not restricted to one particular area of knowledge, but is a result of methodological errors in reasoning and learning, there is no chance at all to make such a believer realize that he does not actually know what he believes he knows until he runs into a very serious problem that he cannot resolve well enough for comfort. Only when programming is made into a "team" effort which exposes newbies to the critical review that only gurus can provide, and gurus themselves acknowledge that new gurus may arise worth listening to, can the necessary feedback loops work well enough that good knowledge drives out bad. Today, we have a lot of people who are quite convinced of their own competence mainly because they have never been challenged beyond what they already know.
The tragedy is that "looks the same, is the same" is not commutative. If you learned Common Lisp well and then found Scheme, it would be nothing more than some old home-made toy discovered in your parent's basement -- cute and all that, but not worth playing with for long, because all of the stuff you think a real programming language should have are simply not there. If you learned Scheme first and then found Common Lisp, it would seem just like Scheme, because what you have come to think of as a "programming language" is basically so little that you would not even comprehend all the stuff in Common Lisp that is not like Scheme at all.
/// -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief
x...@xahlee.org (Xah Lee) writes: > My readers, set your eyes afar, your views afield. Don't fret about > the trifling particularities of Scheme and common lisps that so bugs > the Nag'm & Pit-man scheming haters. If you are concerned about > learning something, master a *different* language as i outlined above. > Broaden your mind.
I'll pass on responding to the first sentence here, but (notwithstanding the fact that Xah wants to position himself as disagreeing with me) I'll agree with the second sentence here.
To the extent that there are things presented in a Scheme course which introduce new ideas and broaden the mind, take them in, learn, and enjoy.
The place where we differ is in the belief that every Scheme course is, in point of fact, an exercise in mind-broadening. I have no problem with Scheme per se, and I have used it myself for various work-related tasks. However, I do have considerable problem with Scheme qua religion, and I have routinely seen people come out of a Scheme course not thinking they have learned a new thing, but that they have UNlearned an old thing, and, more to the point, have often specifically learned to hate CL. It is routine to find that people taking Scheme courses have learned that "iteration is Bad and tail recursion is Good", which I believe is itself limiting and therefore bad; I have no problem if they have gotten instead the lesson that "iteration can take on multiple syntactic forms", "there are equivalences between conventional loops and tail recursions", "sometimes seeing things in a different syntactic form, whether conventional or recursive, reveals through that form truths that are not as perspicuous in the other form". To the extent that people instead believe that grand truths only leap out of tail recursive form and do not leap out of the other form, they have been misled.
Broadening the mind, that is, learning new ways to see and use things is good. Revamping the mind according to propaganda is not, however, broadening the mind.
> Btw, i think i'm the first person who coined Nagging Naggum. (is that > right, Erik?) If so, i should get some credit.
If you are able to make your own coinage, I'm not sure why you need to operate on credit.
c...@sli.uio.no (Christian Nybų) writes: > At my uni, taking the SICP course is a recommended preparation for > those who wish to take the CL course. Therefore I choose, despite > your warnings, to assimilate what Scheme has to offer as a teaching > language. Any advice on how to get through unharmed? (OVS phrasing > optional...)
You should forget that Scheme exists when you learn Lisp. Essentially, approach Lisp with no preconcieved notions, and beware of specific biases towards specific programming styles that your professor may have. Lisp is designed to allow for all styles of programming, which also means that it allows for exclusively one style if the programmer so desires. I find it much more freeing to allow oneself to mix all styles of programming in the same code. Object oriented, applicative, logic, symbolic; whatever combination fits the needs of the algorithm.
-- -> -/- - Rahul Jain - -\- <- -> -\- http://linux.rice.edu/~rahul -=- mailto:rj...@techie.com -/- <- -> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <- |--|--------|--------------|----|-------------|------|---------|-----|-| Version 11.423.999.221020101.23.50110101.042 (c)1996-2002, All rights reserved. Disclaimer available upon request.
>At my uni, taking the SICP course is a recommended preparation for >those who wish to take the CL course. Therefore I choose, despite >your warnings, to assimilate what Scheme has to offer as a teaching >language. Any advice on how to get through unharmed? (OVS phrasing >optional...)
I would say that (in general) it is fairly difficult for Scheme learners to learn Common Lisp. You can kind of get by, but you have to be resigned to that fact. Common Lisp is the archetypal jealous-god type of programming language. Scheme tends to be a lot more freewheeling, and its programs suffer less crosstalk from their writer's acquaintance with other languages (including CL). From the CL point of view, crosstalk from Scheme can be immobilizing.
