From: Jeff M.
Subject: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <1096910466.233668.29000@k26g2000oda.googlegroups.com>
Every once in a while, when I have a lack of projects to keep me busy,
I will glance through the book again and try to solve another of the
problems at the end of a chapter. Yesterday I flipped through and just
picked one at random. The problem is very simple:

Paraphrased: Given a list of numbers (7 1 4 9), write a function called
pos+ that will return a new list that is the original list plus the
index of each element in the new list, (7 2 6 12).

The first two parts are simple, write one function recursively and the
other iteratively. However, then Mr. Graham threw me for a loop and
asked to do the same just using a MAPCAR. For the life of me I can't
figure out how to do this. The function to MAPCAR just takes a single
item (in this case).

To use some C terminology, I would normally make some kind of static
variable that kept the index in it and just incremented itself each
call. This would work if I knew how to do this in Lisp. &aux doesn't
seem to help (not static). I'm really interested now in seeing this
solved. Any suggestions or hints? ;)

Jeff

From: Dan Muller
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <2Mf8d.13749$g_.10438@newssvr31.news.prodigy.com>
"Jeff M." <·······@gmail.com> writes:

> Every once in a while, when I have a lack of projects to keep me busy,
> I will glance through the book again and try to solve another of the
> problems at the end of a chapter. Yesterday I flipped through and just
> picked one at random. The problem is very simple:
>
> Paraphrased: Given a list of numbers (7 1 4 9), write a function called
> pos+ that will return a new list that is the original list plus the
> index of each element in the new list, (7 2 6 12).
>
> The first two parts are simple, write one function recursively and the
> other iteratively. However, then Mr. Graham threw me for a loop and
> asked to do the same just using a MAPCAR. For the life of me I can't
> figure out how to do this. The function to MAPCAR just takes a single
> item (in this case).
>
> To use some C terminology, I would normally make some kind of static
> variable that kept the index in it and just incremented itself each
> call. This would work if I knew how to do this in Lisp. &aux doesn't
> seem to help (not static). I'm really interested now in seeing this
> solved. Any suggestions or hints? ;)
>

Ooh! Ooh! I know how to do that one!

(let ((index 0))
  (mapcar #'(lambda (n) (prog1 (+ n index) (incf index)))
	  '(7 1 4 9)))

=> (7 2 6 12)

Your "static variable" is "index", which is in the closure associated
with the the LAMBDA form.
From: Jeff M.
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <1096911179.133154.56820@k17g2000odb.googlegroups.com>
God I feel stupid. Should have seen that right away... ugh! Thanks for
making me feel so good about myself ;)

Jeff
From: John Thingstad
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <opsfcww8c7pqzri1@mjolner.upc.no>
On Mon, 04 Oct 2004 17:29:34 GMT, Dan Muller <·········@sneakemail.com>  
wrote:


> Ooh! Ooh! I know how to do that one!
>
> (let ((index 0))
>   (mapcar #'(lambda (n) (prog1 (+ n index) (incf index)))
> 	  '(7 1 4 9)))
>
> => (7 2 6 12)
>
> Your "static variable" is "index", which is in the closure associated
> with the the LAMBDA form.

remember.. master Paul reads this newsgroup.. (from time to time) ;)

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
From: Dan Muller
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <%Bg8d.13764$g_.12567@newssvr31.news.prodigy.com>
"John Thingstad" <··············@chello.no> writes:
> remember.. master Paul reads this newsgroup.. (from time to time) ;)

Err, did I do a bad thing by giving the answer to one of his problems
online? (Forgive me, Master!) And I made Jeff feel bad, too.  :-(
From: Steven M. Haflich
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <41624AFB.8030408@alum.mit.edu>
Dan Muller wrote:

> Ooh! Ooh! I know how to do that one!
> 
> (let ((index 0))
>   (mapcar #'(lambda (n) (prog1 (+ n index) (incf index)))
> 	  '(7 1 4 9)))

I find this wordy and verbose.  Try instead:

(let ((x -1))
   (mapcar (lambda (n) (+ n (incf x)))
            '(7 1 4 9)))

:-)
From: Mario S. Mommer
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <fzr7oee6f8.fsf@germany.igpm.rwth-aachen.de>
"Jeff M." <·······@gmail.com> writes:
> To use some C terminology, I would normally make some kind of static
> variable that kept the index in it and just incremented itself each
> call. This would work if I knew how to do this in Lisp. &aux doesn't
> seem to help (not static). I'm really interested now in seeing this
> solved. Any suggestions or hints? ;)

(let ((index 0))
  (mapcar ...<your code here>))

Now all you have to do is to slip an (incf index) at the right place,
+- some additional balancing.

I hope I did not tell you too much :)
From: paul graham
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <4fba79f2.0410042041.1ab75345@posting.google.com>
Or you could write

(defun pos+ (lst)
  (let ((i -1))
    (mapcar #'(lambda (x) (+ x (incf i))) 
            lst)))

Btw, in Arc that would be

(def pos+ (lst)
  (let i -1
    (map [+ _ (++ i)] lst)))
From: Kenny Tilton
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <Wdq8d.154835$4h7.27365590@twister.nyc.rr.com>
paul graham wrote:

> Or you could write
> 
> (defun pos+ (lst)
>   (let ((i -1))
>     (mapcar #'(lambda (x) (+ x (incf i))) 
>             lst)))
> 
> Btw, in Arc that would be
> 
> (def pos+ (lst)
>   (let i -1
>     (map [+ _ (++ i)] lst)))

Great. First you turn everyone on to Lisp, then just as we are 
developing some momentum you release Arc and god help anyone standing in 
front of the exits.

:)

kenny


-- 
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Stefan Scholl
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <j21e8bjhr8b4.dlg@parsec.no-spoon.de>
On 2004-10-05 07:24:06, Kenny Tilton wrote:
> paul graham wrote:
>> Btw, in Arc that would be
>> 
>> (def pos+ (lst)
>>   (let i -1
>>     (map [+ _ (++ i)] lst)))
> 
> Great. First you turn everyone on to Lisp, then just as we are 
> developing some momentum you release Arc and god help anyone standing in 
> front of the exits.

No problem. As long as Arc is released before Perl 6 ...
From: Justin Dubs
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <2e262238.0410050628.374a1e85@posting.google.com>
··@bugbear.com (paul graham) wrote in message news:<····························@posting.google.com>...
> Btw, in Arc that would be
> 
> (def pos+ (lst)
>   (let i -1
>     (map [+ _ (++ i)] lst)))

I like the [] syntax.  In fact, I have a reader macro to add oddly
similar syntax to Common Lisp.  (Thief!  ;-))

Example expansions would be:

[+ 1] -> (lambda (&rest r) (apply #'+ 1 r))
[+ _ 1] -> (lambda (a) (+ a 1))
[cons _ _] -> (lambda (a b) (cons a b))

I also added positional parameters, which may be more confusing than
they are worth.

[/ $2 $1] -> (lambda (a b) (/ b a))

In the real reader macro they are all gensyms, of course.  I don't
have anywhere to host it right now, but I'd be happy to send it to
anyone who wants it.

Justin Dubs
From: Randall Randall
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <4162f383$1_5@alt.athenanews.com>
Justin Dubs wrote:

> [cons _ _] -> (lambda (a b) (cons a b))

Um...how does this one work? :)

--
Randall Randall <·······@randallsquared.com>
"And no practical definition of freedom would be complete
  without the freedom to take the consequences. Indeed, it
  is the freedom upon which all the others are based."
  - Terry Pratchett, _Going Postal_
From: Justin Dubs
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <2e262238.0410071549.655d0b4a@posting.google.com>
Randall Randall <·······@randallsquared.com> wrote in message news:<············@alt.athenanews.com>...
> Justin Dubs wrote:
> 
> > [cons _ _] -> (lambda (a b) (cons a b))
> 
> Um...how does this one work? :)

Think "fill in the blanks."

Each underscore in left-to-right order (actually, depth-first order)
is replaced by a new gensym which is in turn appended to the argument
list of the resulting lamba expression.  This replacement with gensyms
allows one to nest []'ed expressions.

[list _ (+ _ 1) (- _ 1)] => (lambda (a b c) (list a (+ b 1) (- c 1))) 
with a, b and c replaced by gensyms

I also support positional parameters of the form $n where $n
represents the nth argument to the function.

So, $1 is the first arg, $2 is the second, ... $n is the nth.

[+ $1 $2] => (lambda (a b) (+ a b))
[+ $2 $1] => (lambda (a b) (+ b a))
[+ $1 $1] => (lambda (a) (+ a a))
[+ $3 $4] => (lambda (a b c d) (+ c d))

Although neat, I find all but trivial uses of my reader macro take
more effort to parse mentally than they are worth.  Oh, well.  :-)

Justin Dubs
From: Randall Randall
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <4165dd7b$1_4@alt.athenanews.com>
Justin Dubs wrote:
> Randall Randall <·······@randallsquared.com> wrote in message news:<············@alt.athenanews.com>...
> 
>>Justin Dubs wrote:
>>
>>
>>>[cons _ _] -> (lambda (a b) (cons a b))
>>
>>Um...how does this one work? :)
> 
> 
> Think "fill in the blanks."

Yeah, I had that.  What I meant was really, "In what
way, of several possible, does the macro that does the
work here parse '_' variables?  The explanation made
it clear that it does so positionally, which make the
whole thing less useful, in my opinion, than the
situation where '_' means the same thing every time
one encounters it in the same function.  I do think
the idea of doing this only for single argument functions
is a good one, since anonymous functions are extremely
common (in my code, at least) as arguments to mapcar
and map.

So, I was commenting, rather than actually asking a
question.  Sorry. :)
From: Justin Dubs
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <2e262238.0410080558.10348cdc@posting.google.com>
Randall Randall <·······@randallsquared.com> wrote in message news:<············@alt.athenanews.com>...
> Justin Dubs wrote:
> > Randall Randall <·······@randallsquared.com> wrote in message news:<············@alt.athenanews.com>...
> > 
> >>Justin Dubs wrote:
> >>
> >>
> >>>[cons _ _] -> (lambda (a b) (cons a b))
> >>
> >>Um...how does this one work? :)
> > 
> > 
> > Think "fill in the blanks."
> 
> [snip]
> I do think the idea of doing this only for single argument functions
> is a good one, since anonymous functions are extremely common
> (in my code, at least) as arguments to mapcar and map.

I agree completely.  I mainly wrote this for uses with map and mapcar.
 The first time I wrote it I had each _ mean the same argument
everytime, like you are saying.  So [+ _ _] would be (lambda (a) (+ a
a)).  Unfortunately, I found this unintuitive.  I think the "fill in
the blanks" method is the more natural way to read the underscores.  I
showed code like (mapcar [cons _ _] '(1 2 3)) to friends and they were
all bewildered.  They assumed the two underscores were different
places to be filled in.  So, then I changed it to this depth-first
parsing system.  Now I needed to add the positional parameters ($1 ...
$n) so that I could use a value more than once in the expansion.

So, what you want to do for single-argument functions can be done
with:

(mapcar [cons $1 $1] '(1 2 3))

I think this is closer to intuitive but unfortunately less pretty.  Of
course, I also have:

[+ 1] => (lambda (&rest r) (apply '+ 1 r))

If no underscores or positional parameters are found I expand into one
of these apply's that takes any number of arguments.  I find this
really readable.

(mapcar [+ 1] '(1 2 3)) => (2 3 4)

> So, I was commenting, rather than actually asking a
> question.  Sorry. :)

:-)

Justin Dubs
From: Pascal Bourguignon
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <87u0t5xpj6.fsf@thalassa.informatimago.com>
······@eos.ncsu.edu (Justin Dubs) writes:
> a)).  Unfortunately, I found this unintuitive.  I think the "fill in
> the blanks" method is the more natural way to read the underscores.  I
> showed code like (mapcar [cons _ _] '(1 2 3)) to friends and they were
> all bewildered.  They assumed the two underscores were different
> places to be filled in. 

Which should be proof enough that's a plain bad idea!


> So, then I changed it to this depth-first
> parsing system. 

Wrong reaction, IMHO, you should have binned it.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

Voting Democrat or Republican is like choosing a cabin in the Titanic.
From: Justin Dubs
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <2e262238.0410081157.7ba2fbc6@posting.google.com>
Pascal Bourguignon <····@mouse-potato.com> wrote in message news:<··············@thalassa.informatimago.com>...
> ······@eos.ncsu.edu (Justin Dubs) writes:
> > a)).  Unfortunately, I found this unintuitive.  I think the "fill in
> > the blanks" method is the more natural way to read the underscores.  I
> > showed code like (mapcar [cons _ _] '(1 2 3)) to friends and they were
> > all bewildered.  They assumed the two underscores were different
> > places to be filled in. 
> 
> Which should be proof enough that's a plain bad idea!

Agreed.  That was why I changed it to the "fill in the blanks"
approach...

> > So, then I changed it to this depth-first
> > parsing system. 
> 
> Wrong reaction, IMHO, you should have binned it.

I don't know about that.  It's still useful for simple cases.  The
whole idea doesn't scale, so no reason to worry about that.  I use
things like [+ 1] and simple one-variable versions with relative
frequency.

Either way, it was a fun way for a college student to learn how
readtables and reader macros work.  :-)

Justin Dubs
From: Jeff M.
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <1096991798.023479.264370@k26g2000oda.googlegroups.com>
Interesting. I always visit your web site in hopes of catching some
more information on the status of Arc.  Just some quick observations
that I'm sure might be wrong:

* Are you taking a Scheme (Lisp-1) approach with Arc? Just noticing DEF
as apposed to DEFUN, etc.

* Are () optional where applicable (the LET)? How does the compiler
know when the definitions end and code begins? Or is it just the last,
non-paired item the code?

* I'm assuming that [ ... ] defines an unnamed lambda. And that _ is
the single argument to that lambda. Is there equal shorthand for named
lambdas (like FLET or LABELS) and how does the [ ... ] syntax look with
arguments in the mix?

Thanks for the replies everyone. Lisp's greatest strength, IMO, is its
ability to solve any problem 101+1 ways. 

Jeff
From: paul graham
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <4fba79f2.0410051540.714aee3@posting.google.com>
"Jeff M." <·······@gmail.com> wrote in message news:<························@k26g2000oda.googlegroups.com>...

> 
> * Are you taking a Scheme (Lisp-1) approach with Arc? Just noticing DEF
> as apposed to DEFUN, etc.
> 

Yes, though the fact that the main function defining macro is called
def is no evidence of that.

> * Are () optional where applicable (the LET)? How does the compiler
> know when the definitions end and code begins? Or is it just the last,
> non-paired item the code?

I noticed that most lets in my code were for 1 var, so Arc let is 
for just that case.  There's another macro for n vars.

> 
> * I'm assuming that [ ... ] defines an unnamed lambda. And that _ is
> the single argument to that lambda. Is there equal shorthand for named
> lambdas (like FLET or LABELS) and how does the [ ... ] syntax look with
> arguments in the mix?
> 

[...] is a read-macro for (fn (_) ...)

> Thanks for the replies everyone. Lisp's greatest strength, IMO, is its
> ability to solve any problem 101+1 ways. 
> 

Hmm.  I think its greatest strength is that Lisp source is lists.
And all that implies.
From: Jeff
Subject: Arc questions (was: Simple problem in PG's ANSI Common Lisp)
Date: 
Message-ID: <E9L8d.187689$MQ5.79959@attbi_s52>
paul graham wrote:

> "Jeff M." <·······@gmail.com> wrote in message
> news:<························@k26g2000oda.googlegroups.com>...
> 
> > 
> > * Are you taking a Scheme (Lisp-1) approach with Arc? Just noticing
> > DEF as apposed to DEFUN, etc.
> > 
> 
> Yes, though the fact that the main function defining macro is called
> def is no evidence of that.

It was just an assumption. Just instantly thought of DEFINE from
Scheme, but trying to be more terse. ;)

> I noticed that most lets in my code were for 1 var, so Arc let is 
> for just that case.  There's another macro for n vars.

Interesting. I honestly can't wait to see what other "shortcuts" have
been thrown into Arc.

Out of curiosity, are most of those currently in there ones that you
have personally used quite often and found the most useful, or are
there several from past Lisp implementations and suggestions from
others? Are there any that make the leap beyond simple read macros?

> Hmm.  I think its greatest strength is that Lisp source is lists.
> And all that implies.

I bow to the great one. ;)

Mr. Graham, I thoroughly enjoy reading all of your writings. And with
regards to Arc, there has been a single question gnawing at me.

In your essay "What Made Lisp Different", you make the observation that
as time goes on, all other languages are slowly adding components that
Lisp has had the entire time[1]. In your FAQ on Arc, "Why do you need
to design a new language?" you state that programming languages aren't
a solved problem.

While these two different statements are not opposing, since Arc is a
language derived from Lisp, it does beg the question: what does Arc do
(or what do you hope it will do) especially better than Lisp? or
perhaps, what do you hope to discover with Arc?

Jeff
From: Pascal Bourguignon
Subject: Re: Arc questions (was: Simple problem in PG's ANSI Common Lisp)
Date: 
Message-ID: <87brfgmdyo.fsf@thalassa.informatimago.com>
"Jeff" <···@nospam.insightbb.com> writes:

> paul graham wrote:
> > I noticed that most lets in my code were for 1 var, so Arc let is 
> > for just that case.  There's another macro for n vars.
> 
> Interesting. I honestly can't wait to see what other "shortcuts" have
> been thrown into Arc.

On 452 of my LETs, 246 have more than one variable.  
Does it means that Arc is not for me?

Over 76190 LET in the various free lisp sources I've got in my
/usr/local/shared/lisp, 35581 have more than one variable.
Right, there's (slightly) more 1-var lets. Must be worthwhile to
introduce a new special operator for them...


> Out of curiosity, are most of those currently in there ones that you
> have personally used quite often and found the most useful, or are
> there several from past Lisp implementations and suggestions from
> others? Are there any that make the leap beyond simple read macros?

I guess it would be better to wait for the completed language,
otherwise we only can get a partial view.  After all, the advantage of
Common-Lisp is in its integration of several mechanisms.


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

To vote Democrat or Republican, it's like changing of cabin in the Titanic.
From: Edi Weitz
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <87k6u56175.fsf@miles.agharta.de>
On 4 Oct 2004 21:41:28 -0700, ··@bugbear.com (paul graham) wrote:

> Btw, in Arc that would be
>
> (def pos+ (lst)
>   (let i -1
>     (map [+ _ (++ i)] lst)))

Would this be the right moment to ask how far you've gotten with Arc?
I know, we're not supposed to ask. But while we're at it... :)

Thanks,
Edi.

-- 

"Lisp doesn't look any deader than usual to me."
(David Thornley, reply to a question older than most languages)

Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Kenny Tilton
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <_4A8d.63227$Ot3.101@twister.nyc.rr.com>
Edi Weitz wrote:
> On 4 Oct 2004 21:41:28 -0700, ··@bugbear.com (paul graham) wrote:
> 
> 
>>Btw, in Arc that would be
>>
>>(def pos+ (lst)
>>  (let i -1
>>    (map [+ _ (++ i)] lst)))
> 
> 
> Would this be the right moment to ask how far you've gotten with Arc?
> I know, we're not supposed to ask. But while we're at it... :)

Great. Now you have scared him off. I was going to trick him into 
answering by flaming him inaccurately for releasing Arc.

"What do mean released? That won't be for another three months...doh!"

Anyway, Paul Graham would not risk stirring the hornets by mentioning 
Arc hear on c.l.l unless its release were imminent, so I think it is 
high time we signed up for the notification list.

Can't wait to port Cells to Arc. Someone want to head over to Slashdot 
and mention that Arc is about to be released?[*]

kenny

* For the sublety-impaired, yes, this is a second, deliberate attempt to 
flush our quarry. Please don't spoil this one. k

-- 
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Edi Weitz
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <87r7oclxxp.fsf@miles.agharta.de>
On Tue, 05 Oct 2004 16:37:14 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:

> Great. Now you have scared him off.

If /that/ already scared him off then even the mention of your name
will turn him into a nervous wreck no longer able to work on Arc or
anything else. So be glad I did it... :)

-- 

"Lisp doesn't look any deader than usual to me."
(David Thornley, reply to a question older than most languages)

Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: paul graham
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <4fba79f2.0410060618.2146ac5b@posting.google.com>
Edi Weitz <········@agharta.de> wrote in message news:<··············@miles.agharta.de>...
> On 4 Oct 2004 21:41:28 -0700, ··@bugbear.com (paul graham) wrote:
> 
> 
> Would this be the right moment to ask how far you've gotten with Arc?
> I know, we're not supposed to ask. But while we're at it... :)
> 

I just put the talk from ILC 2003 online.  I didn't do this at
the time because I expected to write something more organized
shortly.  Instead I started working on Hackers & Painters.

It's at http://www.paulgraham.com/ilc03.html
From: Pascal Costanza
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <ck12qe$10e2$1@f1node01.rhrz.uni-bonn.de>
paul graham wrote:

> Edi Weitz <········@agharta.de> wrote in message news:<··············@miles.agharta.de>...
> 
>>Would this be the right moment to ask how far you've gotten with Arc?
>>I know, we're not supposed to ask. But while we're at it... :)
> 
> I just put the talk from ILC 2003 online.  I didn't do this at
> the time because I expected to write something more organized
> shortly.  Instead I started working on Hackers & Painters.
> 
> It's at http://www.paulgraham.com/ilc03.html

Nice overview. I like the idea of being able to manipulate types inside 
the language in the same way that usually only language implementors 
can. However, it seems to me that you are missing one important aspect 
of object orientation, especially of class-based inheritance.

Assume you have the following hierarchy:

(defclass a () ())

(defclass b (a) ())

And the following method already defined:

(defmethod m ((obj b))
   ...)

Now you want to add a method for class a. In a system with class-based 
inheritance, you can just add another method.

(defmehod m ((obj a))
   ...)

For example in CLOS, the generic function takes care of ordering the 
methods correctly for you (as do other OOP languages with other dispatch 
mechanisms).

In a wrapper-based (or delegation-based) approach, you would have to 
define the first method/function as follows:

(defun f (obj)
   (when (typep obj 'b)
     ...))

And now you can't define the other function. Consider the following form.

(flet ((f (obj)
          (cond ((typep obj 'a) ...)
                (t (f obj)))))
   ...)

This doesn't work because the first function will never be executed. All 
instances of b are already instances of a, so they will be covered by 
the first test in the cond form. The value of class-based inheritance is 
that you can always inject new behavior in the middle of an existing 
hierarchy - right below the first function in the example above - not 
only from the outside.

One might argue that this is just a matter of ordering the function 
definitions in the right way, but that makes programming harder than 
necessary IMHO. Think about refactoring class hierarchies which would 
imply the need to reorder all corresponding function definitions, etc.

Of course, it's always possible to implement a CLOS-style library on top 
of Arc. ;)


Pascal

-- 
Pascal Costanza               University of Bonn
···············@web.de        Institute of Computer Science III
http://www.pascalcostanza.de  R�merstr. 164, D-53117 Bonn (Germany)
From: Lars Brinkhoff
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <85d5zvc7p9.fsf@junk.nocrew.org>
Pascal Costanza <········@web.de> writes:
> Of course, it's always possible to implement a CLOS-style library on
> top of Arc. ;)

"CLOSed Arc"

-- 
Lars Brinkhoff,         Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting    http://www.brinkhoff.se/
From: John Thingstad
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <opsfhuebmqpqzri1@mjolner.upc.no>
On Wed, 06 Oct 2004 17:26:04 +0200, Pascal Costanza <········@web.de>  
wrote:


> Of course, it's always possible to implement a CLOS-style library on top  
> of Arc. ;)
>
>
> Pascal
>

You may note that Paul Graham never much cared of object oriented  
programming.
I very much doubt it will be a part of his library.
(check his web site.)

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
From: Pascal Costanza
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <ck3q0p$rue$1@f1node01.rhrz.uni-bonn.de>
John Thingstad wrote:

> You may note that Paul Graham never much cared of object oriented  
> programming.
> I very much doubt it will be a part of his library.
> (check his web site.)

Yes, I know. I have read both http://www.paulgraham.com/noop.html and 
Jonathan Bachrach's "Why Goo is especially object-oriented" (which 
doesn't seem to be online at the moment).

I know that OOP is basically a belief system that you either subscribe 
to or not. However, I have tried to point out the one feature of OOP 
that I think is very hard to get with purely functional / imperative 
means without reinventing OO. (Another one would be object identity, but 
you already have that in Lisp from day one.)


Pascal

-- 
Pascal Costanza               University of Bonn
···············@web.de        Institute of Computer Science III
http://www.pascalcostanza.de  R�merstr. 164, D-53117 Bonn (Germany)
From: Lars Brinkhoff
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <85hdp7c820.fsf@junk.nocrew.org>
··@bugbear.com (paul graham) writes:
> It's at http://www.paulgraham.com/ilc03.html

    What happens when a Common Lisp macro returns a list whose car is
    a function?  (Not the name of a function, mind you, but an actual
    function.)  What happens is what you'd expect, in every
    implementation I've used.  But the spec doesn't say anything about
    this.

I believe "3.1.2.1.2 Conses as Forms" covers this.

-- 
Lars Brinkhoff,         Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting    http://www.brinkhoff.se/
From: Kalle Olavi Niemitalo
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <87brfcyh8m.fsf@Astalo.kon.iki.fi>
Lars Brinkhoff <·········@nocrew.org> writes:

> I believe "3.1.2.1.2 Conses as Forms" covers this.

Not really.  "If the car of the compound form is not a symbol,
then that car must be a lambda expression, in which case [...]."
A function is neither a symbol nor a lambda expression.  The spec
does not require an error though; implementations can define
their own behavior.  Although CLISP 2.33.2 and SBCL 0.8.14.9
choose to signal an error for e.g. (#.#'+ 2 2), CLISP allows
((SETF foo)) as equivalent to (FUNCALL #'(SETF foo)).
From: Peter Seibel
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <m3llegr0ot.fsf@javamonkey.com>
Kalle Olavi Niemitalo <···@iki.fi> writes:

> Lars Brinkhoff <·········@nocrew.org> writes:
>
>> I believe "3.1.2.1.2 Conses as Forms" covers this.
>
> Not really.  "If the car of the compound form is not a symbol,
> then that car must be a lambda expression, in which case [...]."
> A function is neither a symbol nor a lambda expression.  The spec
> does not require an error though; implementations can define
> their own behavior.  Although CLISP 2.33.2 and SBCL 0.8.14.9
> choose to signal an error for e.g. (#.#'+ 2 2), CLISP allows
> ((SETF foo)) as equivalent to (FUNCALL #'(SETF foo)).

There's also the issue that functions are not "externalizable objects"
so if a macro expansion involves literal function objects it's not
portable to COMPILE-FILE functions that use that macro. At least
that's my understanding.

-Peter

-- 
Peter Seibel                                      ·····@javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: Laurence Kramer
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <ck18h6$ptq$1@wolfberry.srv.cs.cmu.edu>
paul graham wrote:
> Or you could write
> 
> (defun pos+ (lst)
>   (let ((i -1))
>     (mapcar #'(lambda (x) (+ x (incf i))) 
>             lst)))
> 
> Btw, in Arc that would be
> 
> (def pos+ (lst)
>   (let i -1
>     (map [+ _ (++ i)] lst)))

Which would be more concise, but less readable.

Larry
From: Marco Antoniotti
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <_n%8d.7$u5.2483@typhoon.nyu.edu>
Laurence Kramer wrote:
> paul graham wrote:
> 
>> Or you could write
>>
>> (defun pos+ (lst)
>>   (let ((i -1))
>>     (mapcar #'(lambda (x) (+ x (incf i)))             lst)))
>>
>> Btw, in Arc that would be
>>
>> (def pos+ (lst)
>>   (let i -1
>>     (map [+ _ (++ i)] lst)))
> 
> 
> Which would be more concise, but less readable.

Agreed.  Apart from that it is also trivial to define ++ and a

	[operator . args]

reader macro that expanded in

	(lambda (_) (operator . args))

Cheers
--
Marco
From: paul graham
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <4fba79f2.0410070514.9108ff1@posting.google.com>
Laurence Kramer <·······@cs.cmu.edu> wrote in message news:<············@wolfberry.srv.cs.cmu.edu>...
> paul graham wrote:
> > Or you could write
> > 
> > (defun pos+ (lst)
> >   (let ((i -1))
> >     (mapcar #'(lambda (x) (+ x (incf i))) 
> >             lst)))
> > 
> > Btw, in Arc that would be
> > 
> > (def pos+ (lst)
> >   (let i -1
> >     (map [+ _ (++ i)] lst)))
> 
> Which would be more concise, but less readable.
> 

You're just not used to it.  I speak from experience, because
I've been using Arc and CL simultaneously for years.  You get
used to [] notation.  The fact that the parameter is _ is 
helpful because if you see other vars, it's a closure, and they're
the vars the fn is closed over.  And the shorter names really
help with readability, because you don't have to break expressions
up over multiple lines so often.
From: Laurence Kramer
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <ck3jh2$piu$1@wolfberry.srv.cs.cmu.edu>
paul graham wrote:

> Laurence Kramer <·······@cs.cmu.edu> wrote in message news:<············@wolfberry.srv.cs.cmu.edu>...
> 
>>paul graham wrote:
>>
>>>Or you could write
>>>
>>>(defun pos+ (lst)
>>>  (let ((i -1))
>>>    (mapcar #'(lambda (x) (+ x (incf i))) 
>>>            lst)))
>>>
>>>Btw, in Arc that would be
>>>
>>>(def pos+ (lst)
>>>  (let i -1
>>>    (map [+ _ (++ i)] lst)))
>>
>>Which would be more concise, but less readable.
>>
> 
> 
> You're just not used to it.  I speak from experience, because
> I've been using Arc and CL simultaneously for years.  You get
> used to [] notation.  The fact that the parameter is _ is 
> helpful because if you see other vars, it's a closure, and they're
> the vars the fn is closed over.  And the shorter names really
> help with readability, because you don't have to break expressions
> up over multiple lines so often.

I'm sure that after using Arc for a while, I'd get used to it,
too.  I just think having "_" as a variable name is not a good
idea.  Even a novice to Common Lisp can see that x is taking
on values in lst as mapcar is evaluated, however what the hell
is _ ?  It denotes nothing to me.  Good Lisp code should read
like English as much as possible.  It makes it easier to read
two months after you've written it.  I realize that mapcar
#'(lambda ..) isn't English, but it's a lot closer than
(map [+ _ ...].  How do I say that out loud (in my mind's ear)?

Larry
From: Paul Dietz
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <41655F09.44C5617D@motorola.com>
Laurence Kramer wrote:

> I'm sure that after using Arc for a while, I'd get used to it,
> too.  I just think having "_" as a variable name is not a good
> idea.  Even a novice to Common Lisp can see that x is taking
> on values in lst as mapcar is evaluated, however what the hell
> is _ ?  It denotes nothing to me.  Good Lisp code should read
> like English as much as possible.  It makes it easier to read
> two months after you've written it.  I realize that mapcar
> #'(lambda ..) isn't English, but it's a lot closer than
> (map [+ _ ...].  How do I say that out loud (in my mind's ear)?


To me, _ reads like 'fill in the blank'.  It seems fairly natural
to me.

The 'unreadable' argument seems ironic to me, since it's just
the argument that's used by mainstream programmers against 'lots
of silly parentheses'.

	Paul
From: Reini Urban
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <4165ba87$1@e-post.inode.at>
Paul Dietz schrieb:
> Laurence Kramer wrote:
>>I'm sure that after using Arc for a while, I'd get used to it,
>>too.  I just think having "_" as a variable name is not a good
>>idea.  Even a novice to Common Lisp can see that x is taking
>>on values in lst as mapcar is evaluated, however what the hell
>>is _ ?  It denotes nothing to me.  Good Lisp code should read
>>like English as much as possible.  It makes it easier to read
>>two months after you've written it.  I realize that mapcar
>>#'(lambda ..) isn't English, but it's a lot closer than
>>(map [+ _ ...].  How do I say that out loud (in my mind's ear)?
> 
> To me, _ reads like 'fill in the blank'.  It seems fairly natural
> to me.
> 
> The 'unreadable' argument seems ironic to me, since it's just
> the argument that's used by mainstream programmers against 'lots
> of silly parentheses'.

I also have to agree.
_ is natural for AI lispers to be detected as internal variable.

And lispers always tried to use [] readermacros for special lists.
Using it for functions makes perfect sense to me.
Looks much better then #'( ). And there's no superficial lambda needed. 
lambda should be expressed in syntax, not written down.

 > (defun pos+ (lst)
 >   (let ((i -1))
 >     (mapcar #'(lambda (x) (+ x (incf i)))             lst)))
 >
 > Btw, in Arc that would be
 >
 > (def pos+ (lst)
 >   (let i -1
 >     (map [+ _ (++ i)] lst)))


/Jon:
 >I think the deeper problem is, as Marco Antoniotti
 >pointed out, it's not an interesting idea.  Actually, I think that is
 >the main problem I have with Arc so far: its basically the same ol'
 >same ol' with a thin new veneer.  Shrug.

Come on! Everybody wants to invent his own language or lisp-based 
implementation. What's wrong with that? It is very interesting indeed.
Happens here all the time.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
From: jayessay
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <m3y8ii2kx6.fsf@rigel.goldenthreadtech.com>
Reini Urban <······@x-ray.at> writes:

> /Jon:
>  >I think the deeper problem is, as Marco Antoniotti
>  >pointed out, it's not an interesting idea.  Actually, I think that is
>  >the main problem I have with Arc so far: its basically the same ol'
>  >same ol' with a thin new veneer.  Shrug.
> 
> Come on! Everybody wants to invent his own language or lisp-based
> implementation. What's wrong with that?

Who said there was anything wrong with it?  I just said that so far
Arc is pretty boring.


> It is very interesting indeed.

In what way?


> Happens here all the time.

So?  Note: creating DSLs is emphatically not boring or uninteresting.
Creating a new programming language could indeed be _not_ boring or
uninteresting, but I don't see that yet in Arc.

The kind of thing that would be interesting and impressive is to
discover (fall over, see/create in a flash of brilliance or whatever)
something as interesting and important as lisp macros, or
unification/logic style programming or even OO and have that melded
into the language.  Hmmm, to put that IOW, maybe this is "simply": a
new and interesting paradigm that looks at "general" problems in a
unique way with a potent means of expressing solutinos to them using
that perspective and encompassing that in a natural, transparent
syntax as well.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com
From: Reini Urban
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <4165cb72$1@e-post.inode.at>
jayessay schrieb:
> Reini Urban <······@x-ray.at> writes:
>>/Jon:
>> >I think the deeper problem is, as Marco Antoniotti
>> >pointed out, it's not an interesting idea.  Actually, I think that is
>> >the main problem I have with Arc so far: its basically the same ol'
>> >same ol' with a thin new veneer.  Shrug.
>>
>>Come on! Everybody wants to invent his own language or lisp-based
>>implementation. What's wrong with that?
> 
> Who said there was anything wrong with it?  I just said that so far
> Arc is pretty boring.

For you, but not for him.

  >>It is very interesting indeed.
> In what way?

Having fun creating something new.

>>Happens here all the time.
> 
> So?  Note: creating DSLs is emphatically not boring or uninteresting.
> Creating a new programming language could indeed be _not_ boring or
> uninteresting, but I don't see that yet in Arc.

Because you don't that. You might get excited by expecting new features, 
not by looking at new design.
I'm also not excited, and I wouldn't use it personally.
But academically it is interesting, as haskell, dylan or every new 
scheme dialect. Using completely different names doesn't help us 
lispers, but the syntax looks ok so far.

> The kind of thing that would be interesting and impressive is to
> discover (fall over, see/create in a flash of brilliance or whatever)
> something as interesting and important as lisp macros, or
> unification/logic style programming or even OO and have that melded
> into the language.  Hmmm, to put that IOW, maybe this is "simply": a
> new and interesting paradigm that looks at "general" problems in a
> unique way with a potent means of expressing solutinos to them using
> that perspective and encompassing that in a natural, transparent
> syntax as well.

screamer as builtin? na.
Or a backtracking expert system shell is also not that exiting.
You want to get down to the traditional lisp level very soon.
And convert to procedural forward tracking.

lisp offers all that.
I get excited about new libraries. Or libraries and features ported to 
my platform. arc is just a language.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
From: jayessay
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <m3u0t52x3m.fsf@rigel.goldenthreadtech.com>
Reini Urban <······@x-ray.at> writes:

> jayessay schrieb:
> > Reini Urban <······@x-ray.at> writes:
> >>/Jon:
> >> >I think the deeper problem is, as Marco Antoniotti
> >> >pointed out, it's not an interesting idea.  Actually, I think that is
> >> >the main problem I have with Arc so far: its basically the same ol'
> >> >same ol' with a thin new veneer.  Shrug.
> >>
> >>Come on! Everybody wants to invent his own language or lisp-based
> >>implementation. What's wrong with that?
> > Who said there was anything wrong with it?  I just said that so far
> > Arc is pretty boring.
> 
> For you, but not for him.

I would hope it would be at least interesting to him!


>   >>It is very interesting indeed.
> > In what way?
> 
> Having fun creating something new.

That's part of my point: it isn't anything new in any interesting sense.


> Because you don't that. You might get excited by expecting new
> features, not by looking at new design.

This makes no sense to me.


> I'm also not excited, and I wouldn't use it personally.  But
> academically it is interesting, as haskell, dylan or every new
> scheme dialect. Using completely different names doesn't help us
> lispers, but the syntax looks ok so far.

I guess it doesn't take much to get you excited.  Hey, whatever floats
your boat.


> > The kind of thing that would be interesting and impressive is to
> > discover (fall over, see/create in a flash of brilliance or whatever)
> > something as interesting and important as lisp macros, or
> > unification/logic style programming or even OO and have that melded
> > into the language.  Hmmm, to put that IOW, maybe this is "simply": a
> > new and interesting paradigm that looks at "general" problems in a
> > unique way with a potent means of expressing solutinos to them using
> > that perspective and encompassing that in a natural, transparent
> > syntax as well.
> 
> screamer as builtin? na.

Who said anything about that?  Those examples were for illustration of
things that _were_ interesting and innovative and have proven
important as well.


> Or a backtracking expert system shell is also not that exiting.

Of course it's not exciting _now_.  Just like Arc is not exciting
_now_; if it had come into existence, say 30 or so years ago (at least
b4 scheme), it may have been interesting and exciting.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com
From: jayessay
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <m33c0q4jh7.fsf@rigel.goldenthreadtech.com>
Laurence Kramer <·······@cs.cmu.edu> writes:

> paul graham wrote:
> 
> > Laurence Kramer <·······@cs.cmu.edu> wrote in message news:
> >
> >>paul graham wrote:
> >>
> >>>Or you could write
> >>>
> >>>(defun pos+ (lst)
> >>>  (let ((i -1))
> >>>    (mapcar #'(lambda (x) (+ x (incf i)))            lst)))
> >>>
> >>>Btw, in Arc that would be
> >>>
> >>>(def pos+ (lst)
> >>>  (let i -1
> >>>    (map [+ _ (++ i)] lst)))
> >>
> >>Which would be more concise, but less readable.
> >>
> > You're just not used to it.  I speak from experience, because
> > I've been using Arc and CL simultaneously for years.  You get
> > used to [] notation.  The fact that the parameter is _ is helpful
> > because if you see other vars, it's a closure, and they're
> > the vars the fn is closed over.  And the shorter names really
> > help with readability, because you don't have to break expressions
> > up over multiple lines so often.
> 
> I'm sure that after using Arc for a while, I'd get used to it,
> too.  I just think having "_" as a variable name is not a good
> idea.

Maybe its a good idea; maybe its not.  '_' seems to be used a fair
amount in "unification style code" for similar things so it isn't
particularly odd.  I think the deeper problem is, as Marco Antoniotti
pointed out, it's not an interesting idea.  Actually, I think that is
the main problem I have with Arc so far: its basically the same ol'
same ol' with a thin new veneer.  Shrug.


/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com
From: Christophe Turle
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <41659501$0$4508$636a15ce@news.free.fr>
"jayessay" <······@foo.com> a �crit dans le message de
···················@rigel.goldenthreadtech.com...
> Laurence Kramer <·······@cs.cmu.edu> writes:
>
> > paul graham wrote:
> >
> > > Laurence Kramer <·······@cs.cmu.edu> wrote in message news:
> > >
> > >>paul graham wrote:
> > >>
> > >>>Or you could write
> > >>>
> > >>>(defun pos+ (lst)
> > >>>  (let ((i -1))
> > >>>    (mapcar #'(lambda (x) (+ x (incf i)))            lst)))
> > >>>
> > >>>Btw, in Arc that would be
> > >>>
> > >>>(def pos+ (lst)
> > >>>  (let i -1
> > >>>    (map [+ _ (++ i)] lst)))
> > >>
> > >>Which would be more concise, but less readable.
> > >>
> > > You're just not used to it.  I speak from experience, because
> > > I've been using Arc and CL simultaneously for years.  You get
> > > used to [] notation.  The fact that the parameter is _ is helpful
> > > because if you see other vars, it's a closure, and they're
> > > the vars the fn is closed over.  And the shorter names really
> > > help with readability, because you don't have to break expressions
> > > up over multiple lines so often.
> >
> > I'm sure that after using Arc for a while, I'd get used to it,
> > too.  I just think having "_" as a variable name is not a good
> > idea.
>
> Maybe its a good idea; maybe its not.  '_' seems to be used a fair
> amount in "unification style code" for similar things so it isn't
> particularly odd.  I think the deeper problem is, as Marco Antoniotti
> pointed out, it's not an interesting idea.  Actually, I think that is
> the main problem I have with Arc so far: its basically the same ol'
> same ol' with a thin new veneer.  Shrug.


I have the same feeling.

Why Arc is needed ? What can do Arc, CL can't easily ?

Is it really needed to start over from scratch ? A layer on CL won't
suffice, why ?

What are these CL limitations ? what is the true gain if removed ?


Christophe Turle.
From: Kenny Tilton
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <tVi9d.64523$Ot3.30402@twister.nyc.rr.com>
Christophe Turle wrote:
> "jayessay" <······@foo.com> a �crit dans le message de
> ···················@rigel.goldenthreadtech.com...
> 
>>Laurence Kramer <·······@cs.cmu.edu> writes:
>>
>>
>>>paul graham wrote:
>>>
>>>
>>>>Laurence Kramer <·······@cs.cmu.edu> wrote in message news:
>>>>
>>>>
>>>>>paul graham wrote:
>>>>>
>>>>>
>>>>>>Or you could write
>>>>>>
>>>>>>(defun pos+ (lst)
>>>>>> (let ((i -1))
>>>>>>   (mapcar #'(lambda (x) (+ x (incf i)))            lst)))
>>>>>>
>>>>>>Btw, in Arc that would be
>>>>>>
>>>>>>(def pos+ (lst)
>>>>>> (let i -1
>>>>>>   (map [+ _ (++ i)] lst)))
>>>>>
>>>>>Which would be more concise, but less readable.
>>>>>
>>>>
>>>>You're just not used to it.  I speak from experience, because
>>>>I've been using Arc and CL simultaneously for years.  You get
>>>>used to [] notation.  The fact that the parameter is _ is helpful
>>>>because if you see other vars, it's a closure, and they're
>>>>the vars the fn is closed over.  And the shorter names really
>>>>help with readability, because you don't have to break expressions
>>>>up over multiple lines so often.
>>>
>>>I'm sure that after using Arc for a while, I'd get used to it,
>>>too.  I just think having "_" as a variable name is not a good
>>>idea.
>>
>>Maybe its a good idea; maybe its not.  '_' seems to be used a fair
>>amount in "unification style code" for similar things so it isn't
>>particularly odd.  I think the deeper problem is, as Marco Antoniotti
>>pointed out, it's not an interesting idea.  Actually, I think that is
>>the main problem I have with Arc so far: its basically the same ol'
>>same ol' with a thin new veneer.  Shrug.
> 
> 
> 
> I have the same feeling.
> 
> Why Arc is needed ? What can do Arc, CL can't easily ?
> 
> Is it really needed to start over from scratch ? A layer on CL won't
> suffice, why ?
> 
> What are these CL limitations ? what is the true gain if removed ?

Have you and/or Laurence read the stuff here?:

   http://www.paulgraham.com/arc.html

I ask because it seems not. eg, form the FAQ:

"Why do you need to design a new language?

It would be surprising if we didn't still need to design more languages. 
That would amount to saying that programming language design is now a 
solved problem, and that the final, perfect language has now been 
designed. It does not seem that way to me-- not by a long shot. The 
number of still open questions makes my head spin."

For an example more salient toLaurence's concerns about readability, 
somewhere on the site you will discover the Great One Himself at first 
disliked his own subsitution of FN for LAMBDA, but then grew to love it. 
As he said, give it time.

And even if you end up not liking it, it does not matter; a design goal 
of Arc is brevity:

"Another thing good programmers like is brevity, and that is Arc's other 
main goal...[snip]

"By brevity I don't mean that programs should require fewer characters. 
That counts for something, but it is more important to require fewer tokens.

"Perl is an inspiring example of brevity. Larry Wall broke all the 
rules, and in the process discovered some good ideas. Perl may be a 
kludge, but it makes your programs short, and you have to respect that."

So it is fair enough to say you do not like it, but how much sense would 
it have made to complain, "Grace, c'mon. Much too wordy."[1]?

:)

kenny

Adm. Grace Hopper, designer of COBOL, a language designed to be readable 
by non-programmer auditors.



-- 
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Christophe Turle
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <41664fab$0$307$636a15ce@news.free.fr>
> > I have the same feeling.
> >
> > Why Arc is needed ? What can do Arc, CL can't easily ?
> >
> > Is it really needed to start over from scratch ? A layer on CL won't
> > suffice, why ?
> >
> > What are these CL limitations ? what is the true gain if removed ?
>
> Have you and/or Laurence read the stuff here?:
>
>    http://www.paulgraham.com/arc.html
>
> I ask because it seems not.

Yes i read it. what seems really interesting is the suggestions part (from
others !). Parts from PG seem "fuzzy". I have not seen clearly THE point.
And the problem is that PG is very clear when he expresses ideas which are
very clear in his head. I'm afraid that Arc is more an idea/feeling than a
clear path.

> eg, form the FAQ:
>
> "Why do you need to design a new language?
>
> It would be surprising if we didn't still need to design more languages.
> That would amount to saying that programming language design is now a
> solved problem, and that the final, perfect language has now been
> designed. It does not seem that way to me-- not by a long shot. The
> number of still open questions makes my head spin."

Is there something concrete here ? It's really theory : there must be
something better than what we possess today. And he may become surprised,
after all we are using lisp from 1960's !

Why not open all these opened questions in a forum. CLRFI seems a better way
to reach the programming language Graal.

> For an example more salient toLaurence's concerns about readability,
> somewhere on the site you will discover the Great One Himself at first
> disliked his own subsitution of FN for LAMBDA, but then grew to love it.
> As he said, give it time.

really impressive.

> And even if you end up not liking it, it does not matter; a design goal
> of Arc is brevity:
>
> "Another thing good programmers like is brevity, and that is Arc's other
> main goal...[snip]
>
> "By brevity I don't mean that programs should require fewer characters.
> That counts for something, but it is more important to require fewer
tokens.

Yes i agree. So why i don't see a striking example of brevity, CL can't
accomplish. I'm just asking for that striking examples. After having
concrete examples, we can discuss.

> "Perl is an inspiring example of brevity. Larry Wall broke all the
> rules, and in the process discovered some good ideas. Perl may be a
> kludge, but it makes your programs short, and you have to respect that."
>
> So it is fair enough to say you do not like it, but how much sense would
> it have made to complain, "Grace, c'mon. Much too wordy."[1]?

The point is not 'i like' / 'i don't like', it is i don't see.


Christophe Turle.
From: Lars Brinkhoff
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <85acuxbo0e.fsf@junk.nocrew.org>
"Christophe Turle" <······@nospam.com> writes:
> I'm afraid that Arc is more an idea/feeling than a clear path.

Perhaps Arc is a curved path?

-- 
Lars Brinkhoff,         Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting    http://www.brinkhoff.se/
From: Kenny Tilton
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <8qv9d.13207$4C.3059618@twister.nyc.rr.com>
Christophe Turle wrote:
>>>I have the same feeling.
>>>
>>>Why Arc is needed ? What can do Arc, CL can't easily ?
>>>
>>>Is it really needed to start over from scratch ? A layer on CL won't
>>>suffice, why ?
>>>
>>>What are these CL limitations ? what is the true gain if removed ?
>>
>>Have you and/or Laurence read the stuff here?:
>>
>>   http://www.paulgraham.com/arc.html
>>
>>I ask because it seems not.
> 
> 
> Yes i read it. what seems really interesting is the suggestions part (from
> others !). Parts from PG seem "fuzzy". I have not seen clearly THE point.
> And the problem is that PG is very clear when he expresses ideas which are
> very clear in his head. I'm afraid that Arc is more an idea/feeling than a
> clear path.

Oh. Sure. Good programmers always work that way. :)

kenny

-- 
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Harald Hanche-Olsen
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <pcovfdm8pjn.fsf@shuttle.math.ntnu.no>
+ Laurence Kramer <·······@cs.cmu.edu>:

| >>>    (map [+ _ (++ i)] lst)))
| 
| I just think having "_" as a variable name is not a good
| idea.  Even a novice to Common Lisp can see that x is taking
| on values in lst as mapcar is evaluated, however what the hell
| is _ ?

It's obviously what mathematicians commonly refer to as "dot", as in
"the function f(�-a)".  Such syntactic shortcuts for lambda are really
only useful for functions of a single variable though, so I am
unconvinced that this is a really big win.  But neither do I find it
offensive.  And it is often true that in extremely localized
situations, shorter is better.  I often use single letter variables if
their scope is not much more than a couple of lines, particularly for
things like array indices.

-- 
* Harald Hanche-Olsen     <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
  than thinking does: but it deprives us of whatever chance there is
  of getting closer to the truth.  -- C.P. Snow
From: Szymon
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <87655m17v5.fsf@eva.rplacd.net>
Harald Hanche-Olsen <······@math.ntnu.no> writes:

> + Laurence Kramer <·······@cs.cmu.edu>:
> 
> | >>>    (map [+ _ (++ i)] lst)))
> | 
> | I just think having "_" as a variable name is not a good
> | idea.  Even a novice to Common Lisp can see that x is taking
> | on values in lst as mapcar is evaluated, however what the hell
> | is _ ?
> 
> It's obviously what mathematicians commonly refer to as "dot", as in
> "the function f(�-a)".  Such syntactic shortcuts for lambda are really
> only useful for functions of a single variable though,

?? for lambda maybe not... please see my post:

((From: Szymon <···@bar.baz>)
 (Newsgroups: comp.lang.lisp)
 (Subject: Re: Simple problem in PG's ANSI Common Lisp)
 (Date: 07 Oct 2004 23:29:30 +0200)
 (Message-ID: <··············@eva.rplacd.net>))

"...

Btw, Do you like this (similar idea to '_')?

(defcurry-0.1.1 concat-3 (s1 s2 s3)
   (concatenate 'string s1 s2 s3)

(mapcar (concat-3 ~ "-foo-" ~)
        '(a b c)
        '(1 2 3))

===> ("a-foo-1" "b-foo-2" "c-foo-3")

_simple_ implementation:

..."

Regards, Szymon.
From: Douglas Philips
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <4165e136_2@news.nauticom.net>
On 2004-10-07 10:23:23 -0400, Laurence Kramer <·······@cs.cmu.edu> said:
> paul graham wrote:
>> You're just not used to it.  I speak from experience, because
>> I've been using Arc and CL simultaneously for years.  You get
>> used to [] notation.  The fact that the parameter is _ is helpful 
>> because if you see other vars, it's a closure, and they're
>> the vars the fn is closed over.  And the shorter names really
>> help with readability, because you don't have to break expressions
>> up over multiple lines so often.
> 
> I'm sure that after using Arc for a while, I'd get used to it,
> too.  I just think having "_" as a variable name is not a good
> idea.  Even a novice to Common Lisp can see that x is taking
> on values in lst as mapcar is evaluated, however what the hell
> is _ ?  It denotes nothing to me.  Good Lisp code should read
> like English as much as possible.  It makes it easier to read
> two months after you've written it.  I realize that mapcar
> #'(lambda ..) isn't English, but it's a lot closer than
> (map [+ _ ...].  How do I say that out loud (in my mind's ear)?

Underscore seems to have been a influence from Perl,
but that is just a guess. It is different enough looking to
stand out and be visible in the code where an x or z or
some other letter wouldn't be as obvious.

There just isn't a need for a 15 character variable for a
short function's formal parameter. Tiny closures shouldn't be
dwarfed by the red-tape paperwork needed to create them,
as that only obscures the code's clarity.

Arc might not be a "very big" change to Common Lisp
but like Yoda, you best not judge it by its size...
Esp. when you've not seen the whole thing.

I'm surprised too, since a language for the next 100 years
probably needs a lot more work yet...

<D\'gou
From: Wade Humeniuk
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <Fbe9d.25060$MV5.11778@clgrps13>
paul graham wrote:
> Laurence Kramer <·······@cs.cmu.edu> wrote in message news:<············@wolfberry.srv.cs.cmu.edu>...
> 
>>paul graham wrote:
>>
>>>Or you could write
>>>
>>>(defun pos+ (lst)
>>>  (let ((i -1))
>>>    (mapcar #'(lambda (x) (+ x (incf i))) 
>>>            lst)))
>>>
>>>Btw, in Arc that would be
>>>
>>>(def pos+ (lst)
>>>  (let i -1
>>>    (map [+ _ (++ i)] lst)))
>>
>>Which would be more concise, but less readable.
>>
> 
> 
> You're just not used to it.

As an alternative, how about something like

(def pos+ (lst) (inc lst (gen from 0)))
  or

(def pos+ (lst) (inc lst (gen ++ -1)))

??

Means increment (non destructively) each member of list, generating increment
as integer from 0

Expanding incf/inc functionality to lists and adding generator like
constructs (borrowing the concept from iterate).

Having a temporary var i just seems verbose.

Wade
From: Mario S. Mommer
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <fzekka35eg.fsf@germany.igpm.rwth-aachen.de>
··@bugbear.com (paul graham) writes:
> Laurence Kramer <·······@cs.cmu.edu> wrote in message news:<············@wolfberry.srv.cs.cmu.edu>...
>> paul graham wrote:
>> > Btw, in Arc that would be
>> > 
>> > (def pos+ (lst)
>> >   (let i -1
>> >     (map [+ _ (++ i)] lst)))
>> 
>> Which would be more concise, but less readable.
>
> You're just not used to it.  I speak from experience, because I've
> been using Arc and CL simultaneously for years.  You get used to []
> notation.

Well, excuse me, but you are hardly an impartial judge in this
matter. And besides, I got used to C notation too.

> The fact that the parameter is _ is helpful because if you see other
> vars, it's a closure, and they're the vars the fn is closed over.
> And the shorter names really help with readability, because you
> don't have to break expressions up over multiple lines so often.

Sorry, but IMO this is hairsplitting. This '_' thing only helps when
you have one var, so it is hardly a gain. And using descriptive names
helps more than having everything on a line, as so many perl
signatures show.
From: Szymon
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <871xga17s1.fsf@eva.rplacd.net>
Mario S. Mommer <········@yahoo.com> writes:

> [.....] This '_' thing only helps when you have one var, so it is hardly
> a gain. [.....]

I think this problem can be solved.

Regards, Szymon.
From: Szymon
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <87is9m1akl.fsf@eva.rplacd.net>
paul graham wrote:
> Or you could write
> 
> (defun pos+ (lst)
>   (let ((i -1))
>     (mapcar #'(lambda (x) (+ x (incf i))) 
>             lst)))

(defun pos+ (lst &aux (i -1))
   (mapcar .....
 
> Btw, in Arc that would be
> 
> (def pos+ (lst)
>   (let i -1
>     (map [+ _ (++ i)] lst)))

This code looks like graveyard: + ... ++ ;)

Is '_' "multilevel" ?

for example:

(def pos+ (lst)
  (let i -1
    (map [+ _ (incf i _)] lst-1 lst-2)))

Btw, I wish for: (map (+ _ (incf i _)) ...) ; no '[',']'/LAMBDA.

Regards, Szymon.

Btw, Do you like this (similar idea to '_')?

(defcurry-0.1.1 concat-3 (s1 s2 s3)
   (concatenate 'string s1 s2 s3)

(mapcar (concat-3 ~ "-foo-" ~)
        '(a b c)
        '(1 2 3))

===> ("a-foo-1" "b-foo-2" "c-foo-3")

_simple_ implementation:

(defconstant ~ (gensym))

(defmacro
  defcurry-0.1.1 (macro-name
		  (&rest args)
		  &body  body
		  &aux   (mirror-lambda (gensym))
                         (f (gensym))
                         gensym-list
			 (case-index 0))
  (flet
      ((genlist-generator (&optional arg)
         (if arg
	     (push (gensym) gensym-list)
	   gensym-list))
       (const-template ()
         (loop :for symb :in args
               :collect `(,symb (if (eq ,symb ~) (pop ,mirror-lambda) ,symb)))))
      `(flet
	   ((,f ,args ,@body))
	 (defun ,macro-name ,args
	   (unless (memq ~ (list ,@args))
	     (return-from ,macro-name (,f ,@args)))
	   (case (count ~ (list ,@args))
	     ,@(loop :repeat (length args)
		     :collect `(,(incf case-index)
			         #'(lambda (,@(genlist-generator :add-gensym)
					    &aux (,mirror-lambda (list ,@(genlist-generator)))
					         ,@(const-template))
				     (,f ,@args)))))))))
From: Vassil Nikolov
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <lz655p6a8s.fsf@janus.vassil.nikolov.names>
"Jeff M." <·······@gmail.com> writes:

> [...]
> Paraphrased: Given a list of numbers (7 1 4 9), write a function called
> pos+ that will return a new list that is the original list plus the
> index of each element in the new list, (7 2 6 12).
> [...]
> just using a MAPCAR. [...] The function to MAPCAR just takes a single
> item (in this case).

  Is it a hard requirement to have a one-argument function?  I'd do
  something along the following lines, at least for an exercise (not
  production code):

    (mapcar #'(lambda (n p) (+ n (incf (aref p))))
            '(7 1 4 9)
            (let ((pp (list (make-array nil :initial-element -1))))
              (rplacd pp pp)))

  (just typed in, untested).  A kind of a "poor man's inifinite list";
  avoids the free variable; replaces assignment by mutation.

  ---Vassil.

-- 
Vassil Nikolov <········@poboxes.com>

Hollerith's Law of Docstrings: Everything can be summarized in 72 bytes.
From: Steven M. Haflich
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <mbs8d.6663$nj.2578@newssvr13.news.prodigy.com>
Vassil Nikolov wrote:

>     (mapcar #'(lambda (n p) (+ n (incf (aref p))))
>             '(7 1 4 9)
>             (let ((pp (list (make-array nil :initial-element -1))))
>               (rplacd pp pp)))

I find this slightly verbose and storage inefficient.  Try instead:

(maplist (lambda (n p) (+ (car n) (incf (car p))))
	 '(7 1 4 9)
	 (let ((l (list -1)))
	   (rplacd l l)))

:-)
From: Vassil Nikolov
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <lz4ql7tdws.fsf@janus.vassil.nikolov.names>
"Steven M. Haflich" <·················@alum.mit.edu> writes:

> Vassil Nikolov wrote:
>
>>     (mapcar #'(lambda (n p) (+ n (incf (aref p))))
>>             '(7 1 4 9)
>>             (let ((pp (list (make-array nil :initial-element -1))))
>>               (rplacd pp pp)))
>
> I find this slightly verbose and storage inefficient.

  It is.  I wanted to emphasize that I just needed "half a cons" there
  (I guess I did that with a vengeance...).  But I don't really expect
  there would be an implementation especially optimized for
  zero-dimensional arrays (well, maybe an experimental one of a 64-bit
  Lisp with many tag bits to spare).

> Try instead:
>
> (maplist (lambda (n p) (+ (car n) (incf (car p))))
> 	 '(7 1 4 9)
> 	 (let ((l (list -1)))
> 	   (rplacd l l)))
>
> :-)

  Yes, MAPLIST is neater.  I had my mind too strongly set on MAPCAR...

  ---Vassil.

-- 
Vassil Nikolov <········@poboxes.com>

Hollerith's Law of Docstrings: Everything can be summarized in 72 bytes.
From: szymon
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <ck49ho$bhq$1@nemesis.news.tpi.pl>
Steven M. Haflich wrote:
> Vassil Nikolov wrote:
> 
>>     (mapcar #'(lambda (n p) (+ n (incf (aref p))))
>>             '(7 1 4 9)
>>             (let ((pp (list (make-array nil :initial-element -1))))
>>               (rplacd pp pp)))
> 
> 
> I find this slightly verbose and storage inefficient.  Try instead:
> 
> (maplist (lambda (n p) (+ (car n) (incf (car p))))
>      '(7 1 4 9)
>      (let ((l (list -1)))
>        (rplacd l l)))
> 
> :-)

btw, destructive wersion:

(mapl (lambda (n p) (rplaca n (+ (car n) (incf (car p)))))
       (list 7 1 4 9)
       ((lambda (l) (rplacd l l)) (list -1)))

Regards, Szymon.
From: Reini Urban
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <4165baf3$1@e-post.inode.at>
szymon schrieb:
> Steven M. Haflich wrote:
>> Vassil Nikolov wrote:
>>
>>>     (mapcar #'(lambda (n p) (+ n (incf (aref p))))
>>>             '(7 1 4 9)
>>>             (let ((pp (list (make-array nil :initial-element -1))))
>>>               (rplacd pp pp)))
>>
>> I find this slightly verbose and storage inefficient.  Try instead:
>> (maplist (lambda (n p) (+ (car n) (incf (car p))))
>>      '(7 1 4 9)
>>      (let ((l (list -1)))
>>        (rplacd l l)))
>>
>> :-)
> 
> btw, destructive wersion:
> (mapl (lambda (n p) (rplaca n (+ (car n) (incf (car p)))))
>       (list 7 1 4 9)
>       ((lambda (l) (rplacd l l)) (list -1)))

And you call all that readable?
side-effects over side-effects. Horrible.
Worse than loop syntax.
Worse than perl syntax.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
From: Szymon
Subject: Re: Simple problem in PG's ANSI Common Lisp
Date: 
Message-ID: <87acuy19a5.fsf@eva.rplacd.net>
Reini Urban <······@x-ray.at> writes:

> szymon schrieb:
> [.....]
> > (mapl (lambda (n p) (rplaca n (+ (car n) (incf (car p)))))
> >       (list 7 1 4 9)
> >       ((lambda (l) (rplacd l l)) (list -1)))
> 
> And you call all that readable?

No.

> side-effects over side-effects. Horrible.

:)

> Worse than loop syntax.

:))

> Worse than perl syntax.

:D

Regards, Szymon.

;)