stupid iper newbie question

On Oct 16, 6:15*pm, carlo.ambro...@gmail.com wrote:
> thanks everybody for you answers
> Now i'm reading capter 3 of "pratical common lisp": i really hope
> chapter 2 is only a "whirlwind tour" as the author calls it, because
> if things are going to get even more complicated it's not my kind of
> book!!!!!!!!!

I'm not sure that PCL is the best place to start. I've bought five or
six Lisp book so far, and I think that Wilensky's 'Common LISPcraft'
is the best for a beginner. It can be had for very little on half.com
or amazon.com.

Graham's 'ANSI Lisp' is good as well, but it's a second or third book.
It's too dense to be of much use to a beginner, but meaty for someone
with some Lisp experience.

I like PCL, but I think that you miss a lot by seeing only one view of
the language. I would encourage you to get several books and compare
their views of the language. Lisp is sufficiently malleable to allow
you to blend whatever approach you find most to your liking.

CC

cartercc <cartercc@gmail.com> wrote:
+---------------
| On Oct 16, 6:15*pm, carlo.ambro...@gmail.com wrote:
| > Now i'm reading capter 3 of "pratical common lisp": i really hope
| > chapter 2 is only a "whirlwind tour" as the author calls it, because
| > if things are going to get even more complicated it's not my kind of
| > book!!!!!!!!!
|
| I'm not sure that PCL is the best place to start.
....
| I like PCL, but I think that you miss a lot by seeing only one view of
| the language. I would encourage you to get several books and compare
| their views of the language. Lisp is sufficiently malleable to allow
| you to blend whatever approach you find most to your liking.
+---------------

I already knew Scheme at the time, so I'm sure that biases things a
bit, but I found Peter Norvig's "Paradigms of Artificial Intelligence
Programming: Case Studies in Common Lisp" <http://www.norvig.com/paip.html>
to be a *great* intro to CL, much more so than as in intro to AI per se.
*Quite* worth the $80-90 price, IMHO.

Norvig wrote a retrospective <http://norvig.com/Lisp-retro.html>
in October 1997 (six years after the book was published), updated
again in April 2002, which near the end contains a section titled
"What Lessons are in PAIP?", giving his own personal "list of the
52 most important lessons in PAIP" [each is indexed to the page(s)
in the book where that particular lesson comes up].

It definitely gives one a different (not necessarily "better"
or "worse" -- just different) view of the language than "PCL"
or "ANSI Common Lisp" [or "On Lisp", for that matter, since
Norvig & Graham have slightly different approaches to the use
of macros].


-Rob

-----
Rob Warnock <rpw3@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607

> From: Kenny <kentil...@gmail.com>
> (defun where (&key title artist rating (ripped nil ripped-p))
> #'(lambda (cd)
> (and
> (if title (equal (getf cd :title) title) t)
> (if artist (equal (getf cd :artist) artist) t)
> (if rating (equal (getf cd :rating) rating) t)
> (if ripped-p (equal (getf cd :ripped) ripped) t))))

That's clearly written, an example of how in Lisp you can "just do
it" in the obvious way instead of going through contortions like
you need to do in other languages such as Java. But most of that
function definition is repeated boilerplate that would be the same
for defining similar functions nevermind duplicated within this
single definition. So after that way of coding it, if you plan to
write several similar functions, you should consider writing a
macro where you specify just the name of the macro and the parts
that vary from one such definition to another. Then each time you
want to write a specific type of WHERE function you code something
like this: (meta-where title artist rating (ripped-p ripped))
which expands to something like the above code. There are at least
three directions to go:
- If you call each specialized function just once in your code, you
would generate an anonymous function on the fly at the one point
of use, instead of defining a named function then calling it just
once.
- If you plan to call such a function lots of times and are willing
to deal with giving a different name to each distinct version of
the function, generate the DEFUN as above once, then call it by
name each place you need it.
- If you might call each such function more than once, but there
are many variants of such a function and it would be a hassle to
make up distinct names for each such function, have the macro
generate code to maintain a hash table of variants, defining
such a function the first time it's called then re-using that
function again whenever another instance of it occurs.
The nice thing about Lisp is that it's relatively easy to do it
*any* of those ways, and to change your mind and re-implement it a
different way without needing to re-write any of the calls
(although you will need to recompile any call to the macro after
the macro has changed, minor nuisance). You aren't constrained to
do it just one way, or prohibited from using macros at all.

<aside>If the Seed7 guy is reading this thread, I'm curious how
easy it would be in Seed7 for an ordinary programmer to
enhance the syntax to support all three ways.</aside>


<box/> my thinking

Robert Maas, http://tinyurl.com/uh3t wrote:
>>From: Kenny <kentil...@gmail.com>
>>(defun where (&key title artist rating (ripped nil ripped-p))
>> #'(lambda (cd)
>> (and
>> (if title (equal (getf cd :title) title) t)
>> (if artist (equal (getf cd :artist) artist) t)
>> (if rating (equal (getf cd :rating) rating) t)
>> (if ripped-p (equal (getf cd :ripped) ripped) t))))
>
>
> That's clearly written, an example of how in Lisp you can "just do
> it" in the obvious way instead of going through contortions like
> you need to do in other languages such as Java. But most of that
> function definition is repeated boilerplatel...

That was my thinking. About Peter Seibel's code. Not mine. Hint.

Drop the keywords and straghtway one can code (JTIOTOMH):

(macrolet ((match (x v)
`(or (null ,x) (equal (getf cd ',x) ,v))))
(and (match title)
(match artist)...))

...with an obvious next step to follow if one plans a lot of these.

kxo

On Sat, 18 Oct 2008 03:35:13 -0400, Kenny wrote:

> Robert Maas, http://tinyurl.com/uh3t wrote:
>>>From: Kenny <kentil...@gmail.com>
>>>(defun where (&key title artist rating (ripped nil ripped-p))
>>> #'(lambda (cd)
>>> (and
>>> (if title (equal (getf cd :title) title) t) (if artist
>>> (equal (getf cd :artist) artist) t) (if rating (equal (getf
>>> cd :rating) rating) t) (if ripped-p (equal (getf cd :ripped)
>>> ripped) t))))
>>
>>
>> That's clearly written, an example of how in Lisp you can "just do it"
>> in the obvious way instead of going through contortions like you need
>> to do in other languages such as Java. But most of that function
>> definition is repeated boilerplatel...
>
> That was my thinking. About Peter Seibel's code. Not mine. Hint.
>
> Drop the keywords and straghtway one can code (JTIOTOMH):
>
> (macrolet ((match (x v)
> `(or (null ,x) (equal (getf cd ',x) ,v))))
> (and (match title)
> (match artist)...))
>
> ..with an obvious next step to follow if one plans a lot of these.

Indeed. But keep in mind that the example is in the third chapter of the
book, just after the user was introduced to the REPL in chapter 2.
Macros come later (chapters 7 & 8). Dumping the "best" solution on
people who just got started with CL would not make much sense in this
context.

Tamas

Thanks everybody for all the help you are giving me here...

Today i read the book up to the end of chapter 5...the only problem
with this book is the missing of guided exercises...maybe i'll try
reading also "gently introduction..." and ""COMMON LISP: An
Interactive Approach" with PCL...

> (JTIOTOMH) * *
> kxo

...I'm still working on that one. Google didn't help much.


ez

e_0r wrote:
>>(JTIOTOMH)
>>kxo
>
>
> ..I'm still working on that one. Google didn't help much.

sorry, just kidding around, and I left out a T to make it worse. Problem
is a lot of times I cannot be bothered to type into a lisp IDE and even
balance parens, and "untested" does not quite cover it. But my fan base
knows I do that, so I figgered anyone would realize the code was just
typed in off [the] top of my head.

kt

> From: Tamas K Papp <tkp...@gmail.com>
> ... keep in mind that the example is in the third chapter of the
> book, just after the user was introduced to the REPL in chapter 2.
> Macros come later (chapters 7 & 8). Dumping the "best" solution on
> people who just got started with CL would not make much sense in
> this context.

I agree completely. In fact I would go further into the process of
R&D from initial concept to first working algorithm to better and
better in various ways. Before even the first complete algorithm is
presented, the reader should be shown how to devise such an
algorithm in the first place by line-at-a-time testing of
data-processing steps and then finally collecting all those lines
of code into a PROG and then showing how to refactor the code in a
more "lispy" way, up to the main technique being presented in that
chapter. But then there should be a teaser forward reference
telling how this generic code can be encapsulated into a "macro"
whereby instead of writing such-and-such function call that
includes mostly repeated "boilerplate" with just a few things
changed from call to call we can write this much more compact and
to-the-point expression of the instance of this generic task where
all the boilerplate is hidden inside the "macro" and only the name
of the macro plus the *NEW* data that varies from instance need be
explicitly written for each new instance of this generic algorithm.
Then in the chapter on macros, there should be a reference to this
algorithm from earlier chapter, and explanation of how to actually
define and use that macro. Then another forward reference, this
time to a later chapter where we go beyond macros to reader-macros
or domain-specific languages with their own individual parsers.