Hi, All:
Greetings.
I am new to functional language and here is the problem, I was trying
to express
if (sth true)
{
statement
statement
.
statement
}
else
{
statement
statement
}
using the following lisp code, I thought "progn" will evaluate all the
expressions therefore execute my statements and return only the last
one
(if (equal last-move '(t t))
;; I play 'x
(progn (setq *player1* +player1+) (setq *player2*
+player2+) (setq myPos (list '(2 2))) (setq hisPos (list '(9 9)))
(setq retMove (second (minimax-rh2333 * player1* myPos hisPos board
time-left round #'simple-rh2333))) (iso-effect-move *player1* myPos
retMove board) (setq myPos (list retMove)) retMove)
;; I play 'o
(progn (setq *player1* +player2+) (setq *player2*
+player1+) (setq myPos (list '(9 9))) (setq hisPos (list '(2 2))) (iso-
legal? hisPos last-move board) (iso-effect-move *player2* hisPos last-
move board) (setq hisPos (list last-move)) (setq retMove (second
(minimax-rh2333 *player1* myPos hisPos board time-left round #'simple-
rh\
2333))) (iso-effect-move *player1* myPos retMove board) (setq myPos
(list retMove)) retMove)
)
when compile, the compiler complains about this whole thing not being
a lambda expression.
What is the problem? What is the correct way to express my original
meaning in LISP?
really appreciate your help.
--Ken
On Aug 2, 8:59 pm, ken <····················@gmail.com> wrote:
> (if (equal last-move '(t t))
> ;; I play 'x
[snip]
As Rainer suggested, it helps to format the code for everyone to be
able to read it. His other questions are also pertinent.
As a style point, I would recommend breaking the PROGN parts into
smaller functions. IF forms with long "then" and "else" parts are off-
putting.
+ ken <····················@gmail.com>:
| I am new to functional language
Actually, Lisp is not functional, though it has a large-ish functional
subset, and it is common enough to use a partly functional style in Lisp.
| and here is the problem, I was trying to express
|
| if (sth true)
| {
| statement
| statement
| .
| statement
| }
| else
| {
| statement
| statement
| }
which is definitely not functional: each statement but the last in
each branch influences the result only via side effects, and
functional languages by definition don't have side effects. (We'll
ignore monads for the sake of this discussion.) Also, in functional
languages you don't write statements, you write and call functions.
I realize of course that the above remarks don't help with your actual
problem, but thought it might be useful to correct the terminology.
(And others have already provided useful advice anyhow.)
As a matter of style, many people prefer to write such code using cond
rather than if, that is replace
(if (some test)
(progn
(blah)
(blah)
(blah))
(progn
(blah)
(blah)
(blah)))
by
(cond
((some test)
(blah)
(blah)
(blah))
(t
(blah)
(blah)
(blah)))
with the advantage that it is trivially transformed into a multibranch
version if the need should arise.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
Harald Hanche-Olsen schrieb:
> + ken <····················@gmail.com>:
>
> | I am new to functional language
>
> Actually, Lisp is not functional, though it has a large-ish functional
> subset, and it is common enough to use a partly functional style in Lisp.
A question regarding the wording:
what does it mean to say "Language L is functional"?
can a language only be functional if it does not support any other
paradigm of programming?
If it otherwise means that L supports functional style I can see a
contradiction in your above sentence. But maybe you had some other
meaning in mind when you wrote that?
I personally see Lisp as a functional programming language.
> each statement but the last in
> each branch influences the result only via side effects, and
> functional languages by definition don't have side effects.
Are you sure?
First of all it is hard for me to imagine how a *language* can have
side effects... can numbers or days also have side effects?
Besides that your statement would mean ML/OCaml are not functional
programming languages, no?
Andr�
--
Andr� Thieme <······························@justmail.de> writes:
> A question regarding the wording:
> what does it mean to say "Language L is functional"?
I think it's an overloaded term that sometimes is used in different ways.
If I point you to a chair and a tree stump and ask you which is the seat,
you're going to say it's the chair.
If I point you to a tree stump and a still-growing tree and ask which
is the seat, you're going to say it's the tree stump.
Meaning is often not absolute.
And this is why my paper "More Than Just Words: Lambda, the Ultimate
Political Party" ( http://www.nhplace.com/kent/PS/Lambda.html ) views
programming languages partly as political parties. Because it matters
the context in which you're asking. There are reasons for concluding
that Lisp is functional and/or supports functional programming and
reasons for concluding the opposite.
One could, of course, create an objective test. But that wouldn't
make it truth. I believe Stephen Colbert has created the term
"wikiality" to deal somewhat with that kind of definitional truth,
though it's been around for long before wikis. My article "What's in
a Name? Uses and Abuses of Lispy Terminology" (
http://www.nhplace.com/kent/PS/Name.html ) addresses this issue of
slippery terminology and how it affects Lisp.
> I personally see Lisp as a functional programming language.
One additional wrinkle is that Common Lisp is a language, but Lisp is
a language family, by request of John McCarthy, who created it. Even
if one is inclined to think CL is not functional, I think few (if any)
would say that Scheme is not functional. And yet most would say
Scheme is a Lisp. As for CL, I suspect fewer would say it is
functional than would say CL is, but I don't think the number is
vanishingly small. I personally think functionalness is a continuum,
and that CL is clearly toward the less-functional end of the axis than
Scheme... but others might say there is some bright line somewhere
such that you're either in or out based on some unambiguous and
objective stnadard. I don't know by what authority anyone's opinion
could be unambiguously judged "right" ... especially "in all
contexts", given that some contexts call for different definitions
than others.
> > each statement but the last in
> > each branch influences the result only via side effects, and
> > functional languages by definition don't have side effects.
>
> Are you sure?
> First of all it is hard for me to imagine how a *language* can have
> side effects... can numbers or days also have side effects?
I think Scheme, for example, is commonly regarded as functional and
yet has side-effects (which one can opt not to use). That creates a
pretty big piece of wiggle room in which many who consider themselves
to do functional programming in Lisp can comfortably resolve.
Moreover, although the CL programming language does not require tail
call elimination, it also does not forbid it. It's pretty much up to
implementations to decide how they will fall on this issue and the
community could shift over time. If one were to believe that
functional programming is "up and coming", then declaring CL to be
definitively not a functional language could, conceivably, negatively
affect whether Lisp would track that.
This issue comes up a lot in international diplomacy. You can cut ties
with a nation you think is not up to your standards, but when you do,
all trade ceases and that nation may focus on self-reliance rather
than interchange. That's a tricky line to walk sometimes, but it
comes back to the reasons I remarked about how languages are like
political parties--you can't just look at them statically--you have to
also look at the user bases they cater to and what those users want
and how the language changes over time to accommodate their needs.
+ Andr� Thieme <······························@justmail.de>:
| Harald Hanche-Olsen schrieb:
|> + ken <····················@gmail.com>:
|> | I am new to functional language
|> Actually, Lisp is not functional, though it has a large-ish
|> functional
|> subset, and it is common enough to use a partly functional style in Lisp.
|
| A question regarding the wording:
| what does it mean to say "Language L is functional"?
|
| can a language only be functional if it does not support any other
| paradigm of programming?
As Kent says in his followup, opinion seems to be divided. But see
also his anology with tree stumps, chairs and seats: Since we're
surrounded by languages that really are functional in the strict
sense, it doesn't seem right to me to call this particular tree stump
a seat. Sorry, to call this language (CL) functional.
| If it otherwise means that L supports functional style I can see a
| contradiction in your above sentence. But maybe you had some other
| meaning in mind when you wrote that?
Well, you skipped quoting the part where I said that Lisp has a
functional subset, and people often program in a partly functional
style. I think that might answer your question. 8-)
| I personally see Lisp as a functional programming language.
Okay. I won't quibble with that. But please note also that the OP
not only called Lisp a functional language, his own example was indeed
as far from the functional style as you can get. Perhaps I should
have said words to that effect, but then I am not always as careful
with my wording as Kent is.
|> each statement but the last in
|> each branch influences the result only via side effects, and
|> functional languages by definition don't have side effects.
|
| Are you sure?
| First of all it is hard for me to imagine how a *language* can have
| side effects... can numbers or days also have side effects?
Point well taken. Sloppy language.
| Besides that your statement would mean ML/OCaml are not functional
| programming languages, no?
I wouldn't know, have never looked at those. One can even question if
Haskell is, given the existence of the IO monad, but I feel
disinclined to split the finer philosophical hairs here.
All I really had wanted to say that someone who talks about Lisp as a
functional language, and then immediately comes up with a code snippet
in non-functional style, needs a little terminology adjustment.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
On 2007-08-04, Harald Hanche-Olsen <······@math.ntnu.no> wrote:
> + Andr� Thieme <······························@justmail.de>:
>| I personally see Lisp as a functional programming language.
>
> Okay. I won't quibble with that. But please note also that the OP
> not only called Lisp a functional language, his own example was
> indeed as far from the functional style as you can get.
I think the OP used "functional" in yet a third sense, that of
"something that returns a value (whether or not it has side effects)",
as opposed to "something that does not return a value (whether or not
it has side effects". See also "functions" (which must return a
value) and "procedures" (which can not) in Pascal (the language :).
I have the impression that many people hear about Lisp in the form of
"everything in Lisp is a function" -- by which they mean, "everything
returns a value". I think the OP used the word "functional" in that
extremely limited and trivial sense. I further think that lots of
other people use it that way, and that lots of discussions that start
off talking about whether Lisp (or any other language) is "functional"
immediately jump into the larger, more technical usage, and completely
miss the original posters' usage of the term as meaning "everything
returns a value".
This is not to disagree with
> All I really had wanted to say that someone who talks about Lisp
> as a functional language, and then immediately comes up with a
> code snippet in non-functional style, needs a little terminology
> adjustment.
but only to point out what I see as a(nother) common source of
misunderstanding.
-- L
+ Larry Clapp <·····@theclapp.org>:
| I have the impression that many people hear about Lisp in the form of
| "everything in Lisp is a function" -- by which they mean, "everything
| returns a value".
Except when it doesn't, of course. 8-)
But at least you are allowed to pretend it always does,
and then you get nil when it doesn't,
so in a sense you are absolutely correct.
So what am I quibbling at?
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
P� Sat, 04 Aug 2007 19:39:38 +0200, skrev Harald Hanche-Olsen
<······@math.ntnu.no>:
> + Larry Clapp <·····@theclapp.org>:
>
> | I have the impression that many people hear about Lisp in the form of
> | "everything in Lisp is a function" -- by which they mean, "everything
> | returns a value".
>
> Except when it doesn't, of course. 8-)
>
> But at least you are allowed to pretend it always does,
> and then you get nil when it doesn't,
> so in a sense you are absolutely correct.
>
> So what am I quibbling at?
>
(defun no-return () (values))
returns nothing.. never the less (null (no-return)) returns T..
Anyhow functional does not just mean all functions return values.
Treating it as if any definition goes is wrong.
I liked you original reply.
You could say the subset of CL supported by ACL2 is functional.
On Sat, 04 Aug 2007 02:51:43 +0200, Andr� Thieme
<······························@justmail.de> wrote:
>First of all it is hard for me to imagine how a *language* can have
>side effects... can numbers or days also have side effects?
Human languages are just noise - they have the side effect of
communicating ideas from one person to another.
George
--
for email reply remove "/" from address
P� Fri, 03 Aug 2007 02:59:48 +0200, skrev ken
<····················@gmail.com>:
There are quite a few thing here.. I suggest a read of
http://norvig.com/luv-sides.ps
for a taste of good vs. bad Lisp programming style.
"John Thingstad" <··············@chello.no> writes:
> P� Fri, 03 Aug 2007 02:59:48 +0200, skrev ken
> <····················@gmail.com>:
>
> There are quite a few thing here.. I suggest a read of
> http://norvig.com/luv-sides.ps
> for a taste of good vs. bad Lisp programming style.
Try instead:
<http://norvig.com/luv-slides.ps>
That is quite good. Indeed, I'm thinking of taking the first 11
pages, and bouncing it off some of our developers, as the early
material is pretty language-independent.
Page 4 {"What to Believe"} seems a particularly useful observation,
namely that what's important is *not* to know style rules, but rather
to know where they came from.
--
output = reverse("ofni.sesabatadxunil" ·@" "enworbbc")
http://linuxfinances.info/info/lsf.html
"The beginning of wisdom for a [software engineer] is to recognize the
difference between getting a program to work, and getting it right."
-- M A Jackson, 1975