Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Re: Re: C# reinvents @_

by hding (Chaplain)
on Sep 19, 2001 at 19:35 UTC ( [id://113370]=note: print w/replies, xml ) Need Help??


in reply to Re: C# reinvents @_
in thread C# reinvents @_

I had the same thought about Lisp when I first saw this post, but after looking around a bit, I wasn't able to find any way to do this properly in Common Lisp. (This isn't to say that there's not one; just that it's not immediately obvious to me.) With macros one can specify a &whole parameter to grab the argument list, but that's not valid for functions. And for functions one can start off the argument list with a &rest parameter which will grab the entire list of arguments, but then you can only use &key and &aux parameters afterward, no normal or &optional ones.

Of course, this may be a limitation of Common Lisp only (or, as I said, maybe not; I may just be ignorant); I don't really know any other Lisps well enough to speculate.

Replies are listed 'Best First'.
Re: C# reinvents @_
by Dominus (Parson) on Sep 21, 2001 at 10:52 UTC
    Says hding:
    I had the same thought about Lisp when I first saw this post, but after looking around a bit, I wasn't able to find any way to do this properly in Common Lisp.

    It seems to me that this is exactly what you want:

    (defun myfunction (&rest args) ...)

    In the body of myfunction, the parameter args is bound to the entire argument list, which is analogous to @_ in Perl.

    I don't understand your point about &optional. I thought we were looking for a way to simulate Perl's parameter-passing mechanism in Common Lisp; this is it. Perl doesn't have &optional; instead, you're supposed to examine the contents of @_ and make a decision depending on how many elements it contains. With the args parameter above, you are free to do the same thing in the same way.

    --
    Mark Dominus
    Perl Paraphernalia

      Yes, I mentioned this in another node somewhere in this discussion. I know that we can do that (which does suffice to address the original point). I was wondering about the extended question: is there a way to get the entire argument list while at the same time preserving the rest of Lisp's argument handling facilities? I may not have made that clear in this entry.

Re: Re: Re: C# reinvents @_
by John M. Dlugosz (Monsignor) on Sep 19, 2001 at 19:47 UTC
    Hmm, I thought you could have unnamed parameters collected into a list. My Lisp-dialects are 10 years rusty, and Common Lisp is just a manual to me. Maybe it was dropped from the standard, or has some more obsucre way to set it up. Or, maybe it's just so simple to throw another set of ()'s around the data that nobody cares.

    (foo one two (three four five))
    is similar to
    sub foo ($$$); foo ($one, $two, [$three, $four, $five]);
    with exactly three parameters according to the function, but the caller does the "collecting".

      I agree, it's the kind of thing that screams out "Lisp!", but I just couldn't think of how to do it. Guess we'll have to leave it to the Lisp historians.

      Update: Just in case anybody actually reads this and I'm not being clear, one can simulate the Perlish behavior simply by having a function like (defun fred (&rest args) (do-stuff-with args)). In fact, by treating args as a plist, one can simulate the Perl trick of passing a hash. What I can't see is how to get all the arguments as a list while still using Lisp's other facilities for handling them.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://113370]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others having a coffee break in the Monastery: (3)
As of 2025-07-08 23:05 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?
    erzuuliAnonymous Monks are no longer allowed to use Super Search, due to an excessive use of this resource by robots.