Alright, so I've got this function (well one like it)
(defun somefunc (a &rest args)
(if (null (car args))
a
(somefunc (* a 4) (cdr args))))
This is a function similar to * but for a type. Unfortunately, what happens
is that every time somefunc is recursive, it adds another level of list to
it, so it works for 2 items, but 3 fails because of a type mismatch (cause
it's a list instead of each item.) How do I fix this?
From: Ari Johnson
Subject: Re: Problem with recursive function and &rest
Date:
Message-ID: <Qtxtc.206$zN5.54@fed1read01>
Paul Betts wrote:
> Alright, so I've got this function (well one like it)
>
> (defun somefunc (a &rest args)
> (if (null (car args))
> a
> (somefunc (* a 4) (cdr args))))
>
> This is a function similar to * but for a type. Unfortunately, what happens
> is that every time somefunc is recursive, it adds another level of list to
> it, so it works for 2 items, but 3 fails because of a type mismatch (cause
> it's a list instead of each item.) How do I fix this?
I'll take a stab:
(apply #'somefunc (cons (* a 4) (cdr args)))
That worked like gangbusters guys, thanks!
Paul
"Ari Johnson" <·····@hotmail.com> wrote in message
·····················@fed1read01...
> Paul Betts wrote:
> > Alright, so I've got this function (well one like it)
> >
> > (defun somefunc (a &rest args)
> > (if (null (car args))
> > a
> > (somefunc (* a 4) (cdr args))))
> >
> > This is a function similar to * but for a type. Unfortunately, what
happens
> > is that every time somefunc is recursive, it adds another level of list
to
> > it, so it works for 2 items, but 3 fails because of a type mismatch
(cause
> > it's a list instead of each item.) How do I fix this?
>
> I'll take a stab:
> (apply #'somefunc (cons (* a 4) (cdr args)))
In article <················@fed1read01>,
Ari Johnson <·····@hotmail.com> wrote:
> Paul Betts wrote:
> > Alright, so I've got this function (well one like it)
> >
> > (defun somefunc (a &rest args)
> > (if (null (car args))
> > a
> > (somefunc (* a 4) (cdr args))))
> >
> > This is a function similar to * but for a type. Unfortunately, what happens
> > is that every time somefunc is recursive, it adds another level of list to
> > it, so it works for 2 items, but 3 fails because of a type mismatch (cause
> > it's a list instead of each item.) How do I fix this?
>
> I'll take a stab:
> (apply #'somefunc (cons (* a 4) (cdr args)))
Or more simply: (apply #'somefunc (* a 4) (cdr args))
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Barry Margolin wrote:
> In article <················@fed1read01>,
> Ari Johnson <·····@hotmail.com> wrote:
>
>
>>Paul Betts wrote:
>>
>>>Alright, so I've got this function (well one like it)
>>>
>>>(defun somefunc (a &rest args)
>>> (if (null (car args))
>>> a
>>> (somefunc (* a 4) (cdr args))))
>>>
>>>This is a function similar to * but for a type. Unfortunately, what happens
>>>is that every time somefunc is recursive, it adds another level of list to
>>>it, so it works for 2 items, but 3 fails because of a type mismatch (cause
>>>it's a list instead of each item.) How do I fix this?
>>
>>I'll take a stab:
>> (apply #'somefunc (cons (* a 4) (cdr args)))
>
>
> Or more simply: (apply #'somefunc (* a 4) (cdr args))
yes, and this is one of the things about CL (a) it took me a while to
discover, and (b) really screams out the maturity and useability and
practicality of CL. OK, funcall does its thing with spelled-out args,
and apply does its thing expanding a list into args, but apply also
takes that little extra trouble to permit as-funcally-as-you know
specification where known arguments are simply specified before dropping
into a final list of args, I guess just so you do not have to (list*
....) the args.
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
>
>
> Barry Margolin wrote:
>
>> In article <················@fed1read01>,
>> Ari Johnson <·····@hotmail.com> wrote:
>>
>>
>>> Paul Betts wrote:
>>>
>>>> Alright, so I've got this function (well one like it)
>>>>
>>>> (defun somefunc (a &rest args)
>>>> (if (null (car args))
>>>> a
>>>> (somefunc (* a 4) (cdr args))))
>>>>
>>>> This is a function similar to * but for a type. Unfortunately, what
>>>> happens
>>>> is that every time somefunc is recursive, it adds another level of
>>>> list to
>>>> it, so it works for 2 items, but 3 fails because of a type mismatch
>>>> (cause
>>>> it's a list instead of each item.) How do I fix this?
>>>
>>>
>>> I'll take a stab:
>>> (apply #'somefunc (cons (* a 4) (cdr args)))
>>
>>
>>
>> Or more simply: (apply #'somefunc (* a 4) (cdr args))
>
>
> yes, and this is one of the things about CL (a) it took me a while to
> discover, and (b) really screams out the maturity and useability and
> practicality of CL. OK, funcall does its thing with spelled-out args,
> and apply does its thing expanding a list into args, but apply also
> takes that little extra trouble to permit as-funcally-as-you know
> specification where known arguments are simply specified before dropping
> into a final list of args, I guess just so you do not have to (list*
> ....) the args.
And I learned its use just now. Thanks to both Barry and Kenny. :)
From: Rahul Jain
Subject: Re: Problem with recursive function and &rest
Date:
Message-ID: <87u0xuo5lt.fsf@nyct.net>
Kenny Tilton <·······@nyc.rr.com> writes:
> yes, and this is one of the things about CL (a) it took me a while to
> discover, and (b) really screams out the maturity and useability and
> practicality of CL. OK, funcall does its thing with spelled-out args,
> and apply does its thing expanding a list into args, but apply also
> takes that little extra trouble to permit as-funcally-as-you know
> specification where known arguments are simply specified before dropping
> into a final list of args, I guess just so you do not have to (list*
> ....) the args.
In Commoner's Lisp, we should rename APPLY to FUNCALL*. All this talk of
APPLYing oneself takes the FUN(CALL) out of programming.
:)
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain <·····@nyct.net> wrote:
+---------------
| In Commoner's Lisp, we should rename APPLY to FUNCALL*.
+---------------
Good idea! Except that a suffix "*" doesn't always imply "final arg
is list" (or "consed with") -- it just means "different than without *".
[E.g., for DO/DO*, PROG/PROG*, LET/LET* the "*" means "sequential
binding" as opposed to parallel.] Still, the LIST/LIST* :: FUNCALL/FUNCALL*
analogy is appealing...
+---------------
| All this talk of APPLYing oneself takes the FUN(CALL) out of programming.
+---------------
(*GROAN!!*)
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> Rahul Jain <·····@nyct.net> wrote:
> +---------------
> | In Commoner's Lisp, we should rename APPLY to FUNCALL*.
> +---------------
>
> Good idea! Except that a suffix "*" doesn't always imply "final arg
> is list" (or "consed with") -- it just means "different than without *".
> [E.g., for DO/DO*, PROG/PROG*, LET/LET* the "*" means "sequential
> binding" as opposed to parallel.] Still, the LIST/LIST* :: FUNCALL/FUNCALL*
> analogy is appealing...
What about APPLY/APPLYN, as in PROG/PROGN?
Pascal
--
ECOOP 2004 Workshops - Oslo, Norway
*1st European Lisp and Scheme Workshop, June 13*
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
*2nd Post-Java Workshop, June 14*
http://prog.vub.ac.be/~wdmeuter/PostJava04/
From: Rahul Jain
Subject: Re: Problem with recursive function and &rest
Date:
Message-ID: <87hdttbe65.fsf@nyct.net>
Pascal Costanza <········@web.de> writes:
> What about APPLY/APPLYN, as in PROG/PROGN?
PROGN is PROG missing a bindings list (and a tagbody and a block nil).
What is FUNCALL missing from APPLY? And what would APPLY1 and APPLY2 and
MULTIPLE-VALUE-APPLY do? And you'd still need an APPLY* that did
parallel instead of sequential binding of the arguments. :P
Am I wrong in my impression that PROGN is named by analogy to PROG1 and
PROG2 in that it returns the result of the Nth form in the body?
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain wrote:
> Pascal Costanza <········@web.de> writes:
>
>>What about APPLY/APPLYN, as in PROG/PROGN?
>
> PROGN is PROG missing a bindings list (and a tagbody and a block nil).
> What is FUNCALL missing from APPLY? And what would APPLY1 and APPLY2 and
> MULTIPLE-VALUE-APPLY do? And you'd still need an APPLY* that did
> parallel instead of sequential binding of the arguments. :P
>
> Am I wrong in my impression that PROGN is named by analogy to PROG1 and
> PROG2 in that it returns the result of the Nth form in the body?
Yes. I recall reading somewhere that it is just shorthand for (PROG Nil ...)
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
Pascal Costanza <········@web.de> wrote:
+---------------
| Rob Warnock wrote:
| > Rahul Jain <·····@nyct.net> wrote:
| > +---------------
| > | In Commoner's Lisp, we should rename APPLY to FUNCALL*.
| > +---------------
| >
| > Good idea! Except ... "*" doesn't always imply "final arg is list"...
| > Still, the LIST/LIST* :: FUNCALL/FUNCALL* analogy is appealing...
|
| What about APPLY/APPLYN, as in PROG/PROGN?
+---------------
The problem is that APPLY already means "many". That is, PROG/PROGN
doesn't feel like the proper axis; PROG1/PROG2/PROGN seems a better
set to look at. And then back up from APPLY (which is closer to PROGN)
to something "smaller" as the FUNCALL equivalent. I might suggest APPLY0,
or APPLY1, except that FUNCALL isn't limited to a small number of args.
Hmmm... Too bad APPLY is so deeply embedded in the history of Lisp;
otherwise we could rename *it* into FUNCALLN. ;-}
But to bring this back to Common Lisp today: We have the names we
have in CL, and yes, some of them are perhaps a bit funky when viewed
without the historical/evolutionary context, but that shouldn't stop
us from showing newcomers useful structural parallels, even if the
names themselves aren't very parallel. That is, even without renaming
(which, at this point, would be a mistake, IMHO), it is useful to
point out the parallels between LIST/LIST* and FUNCALL/APPLY.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> Pascal Costanza <········@web.de> wrote:
> +---------------
> | Rob Warnock wrote:
> | > Rahul Jain <·····@nyct.net> wrote:
> | > +---------------
> | > | In Commoner's Lisp, we should rename APPLY to FUNCALL*.
> | > +---------------
> | >
> | > Good idea! Except ... "*" doesn't always imply "final arg is list"...
> | > Still, the LIST/LIST* :: FUNCALL/FUNCALL* analogy is appealing...
> |
> | What about APPLY/APPLYN, as in PROG/PROGN?
> +---------------
>
> The problem is that APPLY already means "many". That is, PROG/PROGN
> doesn't feel like the proper axis; PROG1/PROG2/PROGN seems a better
> set to look at.
The "N" in PROGN doesn't mean "many", it means "nil".
But I agree that the FUNCALL* analogy could be illuminating.
Pascal
--
ECOOP 2004 Workshops - Oslo, Norway
*1st European Lisp and Scheme Workshop, June 13*
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
*2nd Post-Java Workshop, June 14*
http://prog.vub.ac.be/~wdmeuter/PostJava04/
On Thu, 3 Jun 2004, Pascal Costanza wrote:
> The "N" in PROGN doesn't mean "many", it means "nil".
I might be wrong, but I recall reading that the name comes from the fact
that it returns the value of the Nth form.
PROG1 -- 1st form's value
PROG2 -- 2nd form's value
PROGN -- Nth form's value, where N is the number of sub-forms
In article
<····································@unix45.andrew.cmu.edu>,
Matthew Danish <·······@andrew.cmu.edu> wrote:
> On Thu, 3 Jun 2004, Pascal Costanza wrote:
> > The "N" in PROGN doesn't mean "many", it means "nil".
>
> I might be wrong, but I recall reading that the name comes from the fact
> that it returns the value of the Nth form.
>
> PROG1 -- 1st form's value
> PROG2 -- 2nd form's value
> PROGN -- Nth form's value, where N is the number of sub-forms
That might make sense if there had been a PROG1 when PROGN was named (in
Maclisp), but there wasn't. At that time there were just PROG, PROG2,
and PROGN. I think PROG1 was added either for the Lisp Machine or when
Common Lisp was being designed -- users had noticed that many uses of
PROG2 didn't have a useful first form, i.e. they were (prog2 nil
<expression-to-return> <more expressions>), so PROG1 was added for
convenience.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Matthew Danish wrote:
> On Thu, 3 Jun 2004, Pascal Costanza wrote:
>
>>The "N" in PROGN doesn't mean "many", it means "nil".
>
> I might be wrong, but I recall reading that the name comes from the fact
> that it returns the value of the Nth form.
>
> PROG1 -- 1st form's value
> PROG2 -- 2nd form's value
> PROGN -- Nth form's value, where N is the number of sub-forms
Both interpretations make sense. I haven't found a reference for (PROGN
...) = (PROG NIL ...), though.
It wouldn't be the only case for which multiple interpretations exist.
For example, I have seen interpretations of SETF both as "set field" and
"set form".
Pascal
--
ECOOP 2004 Workshops - Oslo, Norway
*1st European Lisp and Scheme Workshop, June 13*
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
*2nd Post-Java Workshop, June 14*
http://prog.vub.ac.be/~wdmeuter/PostJava04/
From: Rahul Jain
Subject: Re: Problem with recursive function and &rest
Date:
Message-ID: <87llj5befz.fsf@nyct.net>
····@rpw3.org (Rob Warnock) writes:
> Good idea! Except that a suffix "*" doesn't always imply "final arg
> is list" (or "consed with") -- it just means "different than without *".
> [E.g., for DO/DO*, PROG/PROG*, LET/LET* the "*" means "sequential
> binding" as opposed to parallel.] Still, the LIST/LIST* :: FUNCALL/FUNCALL*
> analogy is appealing...
Yeah, I know. It's the LIST/LIST* analogy, since that's exactly what
you're doing as far as the parameter list is concerned. The
binding-form-sequentiality set is an orthogonal set of starrifiable
operators.
BTW:
(funcall 'list* ...) = (funcall* 'list ...)
:)
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Ari Johnson <·····@hotmail.com> wrote in message news:<················@fed1read01>...
> Paul Betts wrote:
> > Alright, so I've got this function (well one like it)
> >
> > (defun somefunc (a &rest args)
> > (if (null (car args))
> > a
> > (somefunc (* a 4) (cdr args))))
> >
> > This is a function similar to * but for a type. Unfortunately, what happens
> > is that every time somefunc is recursive, it adds another level of list to
> > it, so it works for 2 items, but 3 fails because of a type mismatch (cause
> > it's a list instead of each item.) How do I fix this?
>
> I'll take a stab:
> (apply #'somefunc (cons (* a 4) (cdr args)))
No need to cons here as #'apply takes a &rest parameter also:
(apply #'somefunc (* a 4) (cdr args))
See: http://www.lisp.org/HyperSpec/Body/fun_apply.html
Justin Dubs
In article <····························@posting.google.com>,
······@eos.ncsu.edu (Justin Dubs) wrote:
> No need to cons here as #'apply takes a &rest parameter also:
I said that last week....
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Barry Margolin <······@alum.mit.edu> wrote in message news:<····························@comcast.dca.giganews.com>...
> In article <····························@posting.google.com>,
> ······@eos.ncsu.edu (Justin Dubs) wrote:
>
> > No need to cons here as #'apply takes a &rest parameter also:
>
> I said that last week....
Yeah, sorry. My newsreader (Google Groups) was woefully out of sync.
A little after I posted everything refreshed and I saw your post from
last week. :-)
It's been acting wierd for a while now... claiming it can't find
threads and even giving me internal server errors on occasion...
Anyway, sorry about that.
Justin Dubs
"Paul Betts" <···············@cis.ohio-state.edu> writes:
> Unfortunately, what happens is that every time somefunc is
> recursive, it adds another level of list to it, so it works for 2
> items, but 3 fails because of a type mismatch (cause it's a list
> instead of each item.) How do I fix this?
This particular example would best be implemented with a required
parameter that is the list of items that you want to work against.
e.g., instead of:
(defun somefunc (a &rest args)
(if (null (car args))
a
(somefunc (* a 4) (cdr args))))
try:
(defun somefunc (a args)
(if (null (car args))
a
(somefunc (* a 4) (cdr args))))
and observe how it runs:
[63]> (somefunc 4 '(5 6 7))
256
[64]> (trace somefunc)
;; Tracing function SOMEFUNC.
(SOMEFUNC)
[65]> (somefunc 4 '(5 6 7))
1. Trace: (SOMEFUNC '4 '(5 6 7))
2. Trace: (SOMEFUNC '16 '(6 7))
3. Trace: (SOMEFUNC '64 '(7))
4. Trace: (SOMEFUNC '256 'NIL)
4. Trace: SOMEFUNC ==> 256
3. Trace: SOMEFUNC ==> 256
2. Trace: SOMEFUNC ==> 256
1. Trace: SOMEFUNC ==> 256
256
--
Matt Curtin, CISSP, IAM, INTP. Keywords: Lisp, Unix, Internet, INFOSEC.
Founder, Interhack Corporation +1 614 545 HACK http://web.interhack.com/
Author of /Developing Trust: Online Privacy and Security/ (Apress, 2001)
Paul Betts wrote:
> Alright, so I've got this function (well one like it)
>
> (defun somefunc (a &rest args)
> (if (null (car args))
> a
> (somefunc (* a 4) (cdr args))))
>
> This is a function similar to * but for a type. Unfortunately, what happens
> is that every time somefunc is recursive, it adds another level of list to
> it, so it works for 2 items, but 3 fails because of a type mismatch (cause
> it's a list instead of each item.) How do I fix this?
As Ari said, you need to use APPLY. The signature of somefunc says that
it wants all arguments after the first, eg:
(somefunc 'hi-mom 1 2 3)
...gathered into a list bound to ARGS, the &rest variable.
In the case of a call like: (somefunc 'hi-mom), ARGS gets bound to a
list of nothing, or nil.
In the case of a call like: (somefunc 'hi-mom 1), ARGS gets bound to a
list of just 1, or (1).
In the case of a call like: (somefunc 'hi-mom (1 2 3)), there is still
only one form following the required arg, and it still gets collected
into a list to fulfill the &rest: ARGS gets bound to ((1 2 3)). And this
is what you are doing in the recursive call:
(somefunc (* a 4) (cdr args))
As Ari implied, APPLY <fn> expands its last argument (a list) into
separate arguments to <fn>. Just the ticket here. Your alternative is to
replace the "&rest args" with "args" and require the caller to collect
things into a list before calling somefunc.
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
"Paul Betts" <···············@cis.ohio-state.edu> wrote in message news:<···········@news.cis.ohio-state.edu>...
> Alright, so I've got this function (well one like it)
>
> (defun somefunc (a &rest args)
> (if (null (car args))
> a
> (somefunc (* a 4) (cdr args))))
>
> This is a function similar to * but for a type. Unfortunately, what happens
> is that every time somefunc is recursive, it adds another level of list to
> it, so it works for 2 items, but 3 fails because of a type mismatch (cause
> it's a list instead of each item.) How do I fix this?
You probably don't mean that function to do what it does even if it
worked - don't you want to *use* the elements of ARGS rather than just
counting them?
To make it work (stull not using ARGS), either use APPLY or something
like this:
(defun somefunc (a &rest args)
(labels ((sf (f r)
(if (null r) f (sf (* f 4) (cdr r)))))
(sf a args)))
--tim
From: Joe Marshall
Subject: Re: Problem with recursive function and &rest
Date:
Message-ID: <d64jbd71.fsf@ccs.neu.edu>
"Paul Betts" <···············@cis.ohio-state.edu> writes:
> Alright, so I've got this function (well one like it)
>
> (defun somefunc (a &rest args)
> (if (null (car args))
> a
> (somefunc (* a 4) (cdr args))))
>
> This is a function similar to * but for a type. Unfortunately, what happens
> is that every time somefunc is recursive, it adds another level of list to
> it, so it works for 2 items, but 3 fails because of a type mismatch (cause
> it's a list instead of each item.) How do I fix this?
(defun binary-somefunc (left right)
....)
(defun somefunc (a &rest args)
(reduce #'binary-somefunc args :initial-value a))
Or, if you want it to be right-associative,
(defun somefunc (a &rest args)
(reduce #'binary-somefunc args :initial-value a :from-end t))