I'm really starting to get the feel of functional programming, in the
sense that I try to use setf as infrequently as possible. I'm using
'let' with functions rather than 'setf'.
But does correct Lisp mean using macros everywhere possible? And the
same with CLOS?
jonathon wrote:
> I'm really starting to get the feel of functional programming, in the
> sense that I try to use setf as infrequently as possible. I'm using
> 'let' with functions rather than 'setf'.
>
> But does correct Lisp mean using macros everywhere possible?
No. In general, you should only use macros when what you want to do
cannot be done with a function. Normally, this means that you are
writing something in which you need to control which arguments are
evaluated and in what order.
> And the same with CLOS?
No. CLOS is available for your use, but you should feel no obligation
to make use of it. Some problems fit more naturally into an OO
representation than others. Some people avoid using OO at all. In
general, I would say that OO programs tend to be imperitive rather than
functional, so this would be at odds with your earlier goal of
functional programming.
Really, the key is that there is no "right" way to use Common Lisp. It
provides you with so many programming constructs that you can fit
together in any way that you want. How you use them depends entirely
on your particular programming style.
Atleast, that's my opinion.
Justin Dubs
······@gmail.com wrote:
> jonathon wrote:
>
>>I'm really starting to get the feel of functional programming, in the
>>sense that I try to use setf as infrequently as possible.
Good attitude.
>> I'm using
>>'let' with functions rather than 'setf'.
Ooops. (let ((answer 42) ...) => (let (answer) (setf answer 42)...)
The rule is, only bind variables to computations you mean to use more
than once.
>>
>>But does correct Lisp mean using macros everywhere possible?
exactly the opposite: only when necessary,
>
>
> No. In general, you should only use macros when what you want to do
> cannot be done with a function. Normally, this means that you are
> writing something in which you need to control which arguments are
> evaluated and in what order.
It goes beyond that. Macros rule where you just want to hide
boilerplate. They can also be hellasweet in re variable capture.
Probably other ways I am too woozy to think of.
>
>
>>And the same with CLOS?
>
>
> No. CLOS is available for your use, but you should feel no obligation
> to make use of it. Some problems fit more naturally into an OO
> representation than others. Some people avoid using OO at all. In
> general, I would say that OO programs tend to be imperitive rather than
> functional, so this would be at odds with your earlier goal of
> functional programming.
Ahem. Cells (see sig) derive a declarative, functional programming model
from CLOS.
>
> Really, the key is that there is no "right" way to use Common Lisp. It
> provides you with so many programming constructs that you can fit
> together in any way that you want. How you use them depends entirely
> on your particular programming style.
Ugh, moral relativism rears its ugly head. Tilton's Law: There is one
right way to skin a cat. Never give up searching for that one way. This
because I agree with Justin: Lisp will give you a kazillion ways to
solve a problem. But (1- kazillion) are wrong.
kt
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Kenny Tilton wrote:
> ······@gmail.com wrote:
> > jonathon wrote:
> >
> >>I'm really starting to get the feel of functional programming, in
the
> >>sense that I try to use setf as infrequently as possible.
>
> Good attitude.
>
> >> I'm using
> >>'let' with functions rather than 'setf'.
>
> Ooops. (let ((answer 42) ...) => (let (answer) (setf answer 42)...)
>
> The rule is, only bind variables to computations you mean to use more
> than once.
Oh, really? I was doing this first:
(let ((answer 0))
(setf answer 42)
Then I changed to:
(let ((answer (get-answer)))
(ask-question answer)
In both cases, the value of answer never changes.
> Ugh, moral relativism rears its ugly head. Tilton's Law: There is one
> right way to skin a cat. Never give up searching for that one way.
This
> because I agree with Justin: Lisp will give you a kazillion ways to
> solve a problem. But (1- kazillion) are wrong.
Hmm. How can this be, if Lisp supports all these styles? I mean, it's
not like Perl, where 'there's more than one to do it' is the slogan,
right?
jonathon <···········@bigfoot.com> wrote:
> Kenny Tilton wrote:
> > Ugh, moral relativism rears its ugly head. Tilton's Law: There is one
> > right way to skin a cat. Never give up searching for that one way.
> > This because I agree with Justin: Lisp will give you a kazillion ways to
> > solve a problem. But (1- kazillion) are wrong.
> Hmm. How can this be, if Lisp supports all these styles? I mean, it's
> not like Perl, where 'there's more than one to do it' is the slogan,
> right?
For any given programming problem there is one optimal solution, a large
number of suboptimal solutions, and kazillions of bad or wrong
"solutions".
By supporting so many styles, Lisp is more likely to support the optimal
solution. But it will also support a lot more wrong ones.
Some languages leave you very few ways to go wrong, but no way to go
right.
Michael
jonathon wrote:
> Kenny Tilton wrote:
>
>>>> I'm using
>>>>'let' with functions rather than 'setf'.
>>
>>Ooops. (let ((answer 42) ...) => (let (answer) (setf answer 42)...)
>>
>>The rule is, only bind variables to computations you mean to use more
>
>
>>than once.
>
>
> Oh, really? I was doing this first:
>
> (let ((answer 0))
> (setf answer 42)
>
> Then I changed to:
>
> (let ((answer (get-answer)))
> (ask-question answer)
How about (ask-question (get-answer))?
kt
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Kenny Tilton <·······@nyc.rr.com> writes:
> How about (ask-question (get-answer))?
What is: "Playing Jeopardy"?
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>How about (ask-question (get-answer))?
>
>
> What is: "Playing Jeopardy"?
>
Brilliant! I was wondering how to parse that code.
kenny
Kenny Tilton wrote:
> jonathon wrote:
> > Kenny Tilton wrote:
> > Oh, really? I was doing this first:
> >
> > (let ((answer 0))
> > (setf answer 42)
> >
> > Then I changed to:
> >
> > (let ((answer (get-answer)))
> > (ask-question answer)
>
> How about (ask-question (get-answer))?
Okay, that's an oversimplified example. It's actually more like this:
(let ((a-value (get-a-value)))
(format t "Result of calculation 1: ~a~%" (calc-1 a-value))
(format t "Result of calculation 2: ~a~%" (calc-2 a-value)))
Is that better?
>
> kt
>
> --
> Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
> Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
>
> "Doctor, I wrestled with reality for forty years, and I am happy to
> state that I finally won out over it." -- Elwood P. Dowd
jonathon wrote:
> Kenny Tilton wrote:
>
>>jonathon wrote:
>>
>>>Kenny Tilton wrote:
>>>Oh, really? I was doing this first:
>>>
>>>(let ((answer 0))
>>> (setf answer 42)
>>>
>>>Then I changed to:
>>>
>>>(let ((answer (get-answer)))
>>> (ask-question answer)
>>
>>How about (ask-question (get-answer))?
>
>
> Okay, that's an oversimplified example. It's actually more like this:
>
> (let ((a-value (get-a-value)))
> (format t "Result of calculation 1: ~a~%" (calc-1 a-value))
> (format t "Result of calculation 2: ~a~%" (calc-2 a-value)))
>
> Is that better?
Sure. Now you are using the value more than once, which is when I said
(a few articles back) LET was justified.
kenny
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Kenny Tilton wrote:
> ······@gmail.com wrote:
> > jonathon wrote:
> >
> >>I'm really starting to get the feel of functional programming, in
the
> >>sense that I try to use setf as infrequently as possible.
>
> Good attitude.
>
> >> I'm using
> >>'let' with functions rather than 'setf'.
>
> Ooops. (let ((answer 42) ...) => (let (answer) (setf answer 42)...)
>
> The rule is, only bind variables to computations you mean to use more
> than once.
>
> >>
> >>But does correct Lisp mean using macros everywhere possible?
>
> exactly the opposite: only when necessary,
>
> >
> >
> > No. In general, you should only use macros when what you want to
do
> > cannot be done with a function. Normally, this means that you are
> > writing something in which you need to control which arguments are
> > evaluated and in what order.
>
> It goes beyond that. Macros rule where you just want to hide
> boilerplate. They can also be hellasweet in re variable capture.
> Probably other ways I am too woozy to think of.
Agreed. I would argue that technically these fit into the mold I set
in my previous response. I thought about breaking it out into a few
broad categories of macros, such as the ones you mentioned...
> >
> >
> >>And the same with CLOS?
> >
> >
> > No. CLOS is available for your use, but you should feel no
obligation
> > to make use of it. Some problems fit more naturally into an OO
> > representation than others. Some people avoid using OO at all. In
> > general, I would say that OO programs tend to be imperitive rather
than
> > functional, so this would be at odds with your earlier goal of
> > functional programming.
>
> Ahem. Cells (see sig) derive a declarative, functional programming
model
> from CLOS.
Very true. I suppose this is a telling contrast between your
"dataflow" OO and more traditional OO.
> > Really, the key is that there is no "right" way to use Common Lisp.
It
> > provides you with so many programming constructs that you can fit
> > together in any way that you want. How you use them depends
entirely
> > on your particular programming style.
>
> Ugh, moral relativism rears its ugly head. Tilton's Law: There is one
> right way to skin a cat. Never give up searching for that one way.
This
> because I agree with Justin: Lisp will give you a kazillion ways to
> solve a problem. But (1- kazillion) are wrong.
Hrm. I would say that there are nearly infinite ways to skin a cat,
and the best way to do it would depend on your particular skill set and
goals for the problem. I thought about running with your metaphor, but
things got messy, fast. ;-)
Solving a problem with maintainability as paramount is likely different
than attempting to solve it in the shortest amount of time, is likely
different than solving it in the most elegant funtional way possible,
is likely different than solving it in the least resource intensive way
possible.
Someone with a smalltalk background will probably (hopefully) solve a
problem differently than someone with a fortran background. I'm not
convinced that it makes either of those solutions inately superior.
However, I agree with your basic premise that one should always keep
searching for the best possible solution. While I doubt anyone will
ever get to it for any complicated problem, the search itself should
improve all parties involved.
Of course, I could just mention Hilter and end this whole debate right
now... :-)
Justin Dubs
Kenny Tilton wrote:
>
>
> ······@gmail.com wrote:
>
>> jonathon wrote:
>>
>>> I'm really starting to get the feel of functional programming, in the
>>> sense that I try to use setf as infrequently as possible.
>
>
> Good attitude.
>
>>> I'm using
>>> 'let' with functions rather than 'setf'.
>
>
> Ooops. (let ((answer 42) ...) => (let (answer) (setf answer 42)...)
I thought (let ((answer 24) ...) would expand to
(funcall (lambda (answer) ...) 24)
On Tue, 03 May 2005 09:57:37 +0200, Knut Olav Bøhmer wrote:
> Kenny Tilton wrote:
>>
>>
>> ······@gmail.com wrote:
>>
>>> jonathon wrote:
>>>
>>>> I'm really starting to get the feel of functional programming, in the
>>>> sense that I try to use setf as infrequently as possible.
>>
>>
>> Good attitude.
>>
>>>> I'm using
>>>> 'let' with functions rather than 'setf'.
>>
>>
>> Ooops. (let ((answer 42) ...) => (let (answer) (setf answer 42)...)
>
> I thought (let ((answer 24) ...) would expand to
> (funcall (lambda (answer) ...) 24)
i guess it's the same, but the point is/was that the required external
contexts when doing (calling) stuff should be as small as possible -
so one can debug things without having to set up an environment for these
things
orsomethinglikethat
--
mvh,
Lars Rune Nøstdal
http://lars.nostdal.org/
Lars Rune Nøstdal wrote:
> On Tue, 03 May 2005 09:57:37 +0200, Knut Olav Bøhmer wrote:
>>>
>>>>> I'm using
>>>>>'let' with functions rather than 'setf'.
>>>
>>>
>>>Ooops. (let ((answer 42) ...) => (let (answer) (setf answer 42)...)
>>
>>I thought (let ((answer 24) ...) would expand to
>>(funcall (lambda (answer) ...) 24)
>
>
> i guess it's the same, but the point is/was that the required external
> contexts when doing (calling) stuff should be as small as possible -
> so one can debug things without having to set up an environment for these
> things
That's not the an answer to the question. He is talking about functional
programming, and there is nothing wrong with using let in functional
programming (as far as I know).
If the expansion I suggested above is correct, it expands to a function,
and functions must be allowed in functional programming.
--
Knut Olav Bøhmer
FreeCode AS
On Tue, 03 May 2005 17:51:53 +0200, Knut Olav Bøhmer wrote:
> Lars Rune Nøstdal wrote:
>> On Tue, 03 May 2005 09:57:37 +0200, Knut Olav Bøhmer wrote:
>>>>
>>>>>> I'm using
>>>>>>'let' with functions rather than 'setf'.
>>>>
>>>>
>>>>Ooops. (let ((answer 42) ...) => (let (answer) (setf answer 42)...)
>>>
>>>I thought (let ((answer 24) ...) would expand to
>>>(funcall (lambda (answer) ...) 24)
>>
>>
>> i guess it's the same, but the point is/was that the required external
>> contexts when doing (calling) stuff should be as small as possible -
>> so one can debug things without having to set up an environment for these
>> things
>
> That's not the an answer to the question. He is talking about functional
> programming, and there is nothing wrong with using let in functional
> programming (as far as I know).
>
> If the expansion I suggested above is correct, it expands to a function,
> and functions must be allowed in functional programming.
i guess i'm saying that let and setf does the same thing if they are
(mis)used(?) to set up environments only for enabling one to use something
that depends on a lot of external context
one should set up these environments only to save time (use computations
more than once), the stuff one creates (calls) should not depend on a lot
of external context
i guess i'm trying to avoid creating stuff that depends on a lot of
external context, and that by not using let or setf - i more easly avoid
this
"functional programming"; i might be wrong about these words/concepts ..
or i might be mixing them
(but i don't care)
--
mvh,
Lars Rune Nøstdal
http://lars.nostdal.org/
Lars Rune Nøstdal wrote:
>
> i guess i'm saying that let and setf does the same thing if they are
> (mis)used(?) to set up environments only for enabling one to use
something
> that depends on a lot of external context
>
> one should set up these environments only to save time (use
computations
> more than once), the stuff one creates (calls) should not depend on a
lot
> of external context
>
> i guess i'm trying to avoid creating stuff that depends on a lot of
> external context, and that by not using let or setf - i more easly
avoid
> this
>
> "functional programming"; i might be wrong about these words/concepts
..
> or i might be mixing them
>
You're talking more about general design issues than about functional
or non-functional programming. If a function that I'm developing is
ballooning WRT the number of arguments it requires (or, gods forbid,
depending on and/or modifying global data), that's a sign that my
design has problems and needs to be re-thought, whether I'm writing
functional code, or imperative code, or whatever.
'setf' is imperative in style, basically because it depends on side
effects. 'let' allows assignment to variables in a purely functional
style.
--David
"wildwood" <············@gmail.com> writes:
> You're talking more about general design issues than about functional
> or non-functional programming. If a function that I'm developing is
> ballooning WRT the number of arguments it requires (or, gods forbid,
> depending on and/or modifying global data), that's a sign that my
> design has problems and needs to be re-thought, whether I'm writing
> functional code, or imperative code, or whatever.
>
> 'setf' is imperative in style, basically because it depends on side
> effects. 'let' allows assignment to variables in a purely functional
> style.
If you want to be precise, LET doesn't assign anything, it _binds_.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we. -- Georges W. Bush
On Tue, 03 May 2005 20:25:43 +0200, Lars Rune Nøstdal wrote:
> i guess i'm trying to avoid creating stuff that depends on a lot of
> external context, and that by not using let or setf - i more easly avoid
> this
>
> "functional programming"; i might be wrong about these words/concepts ..
> or i might be mixing them
or i might be talking about something that makes functional programming
easier
--
mvh,
Lars Rune Nøstdal
http://lars.nostdal.org/
In article <·······················@twister.nyc.rr.com>,
Kenny Tilton <·······@nyc.rr.com> wrote:
> ······@gmail.com wrote:
> > jonathon wrote:
> >
> >>I'm really starting to get the feel of functional programming, in the
> >>sense that I try to use setf as infrequently as possible.
>
> Good attitude.
>
> >> I'm using
> >>'let' with functions rather than 'setf'.
>
> Ooops. (let ((answer 42) ...) => (let (answer) (setf answer 42)...)
>
I think what the OP meant was that he's learned to use local variables
rather than doing everything with global variables. This is a good
thing.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
In article <·······················@g14g2000cwa.googlegroups.com>,
"jonathon" <···········@bigfoot.com> wrote:
> But does correct Lisp mean using macros everywhere possible? And the
> same with CLOS?
No. Macros are very useful for some applications, but many have little
need of them (the standard macros provide the most commonly-needed
features). And CLOS is a whole programming style that is not often
necessary for simple applications.
Take a look at Practical CL. His applications have a few macros, and
occasional use of CLOS where appropriate.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
From: Kent M Pitman
Subject: Re: Lispy without macros and/or CLOS?
Date:
Message-ID: <ufyx417ba.fsf@nhplace.com>
"jonathon" <···········@bigfoot.com> writes:
> I'm really starting to get the feel of functional programming, in the
> sense that I try to use setf as infrequently as possible. I'm using
> 'let' with functions rather than 'setf'.
Hmmm. This statement sounds a great deal like "I'm trying to get the
feel of Judaism in the sense that I've been trying to prefer turkey
bacon instead of pork bacon." Are you sure this will give you the kind
of overarching insight you seem to seek?
> But does correct Lisp mean using macros everywhere possible?
Correct Lisp means solving your domain problem to the necessary degree.
I'm not sure it can be measured otherwise.
Lisp permits functional programming, but does not require it at all.
True functional programming has no side-effects at all. No changes to
data structures, no I/O, etc. There may be some interesting insights
you can get from studying functional programming, but I hope that one of
them you'll get is "this sure makes some simple things cumbersome".
Most modern Lisp programmers understand and use functional programming
when it's appropriate to a computation they need, but they also don't
go overboard and deny themselves a valuable tool.
> And the same with CLOS?
You're trying to program with or without CLOS?
Same answers, though: It depends on your need. It's a useful tool.
Whatever language you program in, a good programmer understands the
value of many programming paradigms, and flexibly shifts among them to
solve what needs solving. Some languages better support paradigm
shifts than others; Lisp is extremely flexible that way. Sometimes I
write programs with CLOS heavily and sometimes ignoring it entirely.
It's not like Java where you can't conceive of a program without
thinking of the object system. For me, it depends on whether I'm
trying to model objects that are best represented as opaque objects
with slots, methods, etc. Usually you'll get to CLOS at some point if
your program gets at all big, but even then it may not be the central
focus of what you're doing. And there are large Lisp programs that
don't use CLOS ever.