Re: (cached) named return values?



Joost Diepenmaat wrote:
On Sun, 04 Nov 2007 21:03:36 -0500, Ken Tilton wrote:


There's nothing more there to be found except something that newcomers
to Lisp often need to hear: the magic of Lisp is not in any particular
mechanism, feature, or style. We often get folks obsessed with doing
things The Magical Lisp Way, it's just the Unbearable Powerfulness of a
lot of things engineered really well. Well, OK, the monkeys* over here
just suggested the parentheses are magical, I can see that...


Ok then. It's just that I would like to have my code be easily be understood by whoever does Lisp currently. Which is basically what I meant originally with "idiomatic".

As I stated in my originial post, I've done quite a lot of Perl programming. In perl, idiom is pretty important, since the language is flexible enough to drive people crazy. From what I understand of Lisp right now, it's even more flexible than Perl *and* it's been around a lot longer, so my assumption was that there was were "normal ways" of doing what I wanted to do.

Probably, but then this is where I would fall back on "I think we need a fuller specification". I am a little fuzzy on how plug-ins get to define their own language (as in their own names for variables) such that some form of data structure would be unworkable.


In other words, I wasn't exactly looking for "the most efficient" way, I was looking for the "clearest way" of expressing my strategy in Lisp.

I might start a new thread/write a blog post about this topic in general seperately, since it's interesting but getting *really* off-topic.


My concern with named variables is that we end up with some function
that can be named no better than do-something-useful taking one
argument, this-stuff. Pascal agonized over a struct being maintained as
well as a caller and a callee. No. A function should take a couple of
specific arguments (not an equally obscurant struct) and return a
specific result. Functions that are just huge pipes, anything in
anything out, just hide the meat of a program, and to find that meat I
am now looking at lines and lines of code. Granularity of function lets
us look no further -- oh, this call obviously does that.


Yeah, well, but most languages - including Lisp - that I know do not allow for multiple return values.

<cough> See VALUES. :)

Sure you can return a struct, or a list or a multidimensional array, but if you compare that to the multitude of options you can get when you're specifying a functions's (input) arguments, it all seems pretty low-level and sparse.

Well then you'd love PC's suggestion whereby the return result can be, well, destructured with destructuring-bind, but then I am definitely having visions of this one big pipe called do-something-useful-and-say-something-back. I have dealt with functions like that, and they are a curse upon productivity, intractably opaque.

In this case, I am a bit frightened by the idea of a function consing up a plist just to return its result to its caller, but now I hear you lusting for the same power in the "return" direction as you have with parameter lists, so yes PC has given you the syntax you need but no this is not something anyone has ever done before. :)

Sure, functions can build plists and return those, but then that is in the spirit of "make", not "return". If you know the idioms. :)

kt

--
http://www.theoryyalgebra.com/

"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
.

Relevant Pages

  • Re: Why I never got into Lisp
    ... solutions in languages like Perl. ... and what you tried in Lisp, and how Lisp mapped better, for you. ... While this can be done to some extent in any language, ... liked the fact that Ruby, like lisp, seems to have sensible defaults ...
    (comp.lang.lisp)
  • Re: Decreasing the "standard deviation" of lisp
    ... Are you saying that the entire concept of language "standard deviation" ... I would also argue the Perl benefited from having traits similar enough ... Having spent a little time looking at the syntax and style of Dylan, ... The Lisp family of languages has certainly been around for a long time, ...
    (comp.lang.lisp)
  • Re: Accessibility of the Higher-Order Perl E-book in Amazon (Was: Emulating Generators)
    ... returned, also called a generator, in Perl? ... not just in the context of Perl alone. ... to give lisp a try to see how it's like. ... But, man, the language is older than Fortran! ...
    (comp.lang.perl.misc)
  • Re: "Higher Order Perl" book and Lisp
    ... >> perl some time ago, I had code running in about 30 minutes, since I ... >> could grab a dozen packages off of CPAN, ... >> of thinking that made single user Lisp Machines (whereas even Windows ... maligned language. ...
    (comp.lang.lisp)
  • Re: My Perl is starting to look like Lisp
    ... In perl, its not so simple - some users exploit hidden ... > the fact that there can be as many programming styles as there are ... Paul Graham writes his code one way in ACL and On Lisp. ... very easy to make mistakes because the 'behavior' of the language can ...
    (comp.lang.lisp)