Good functional programming habbit?
Zadirion
I hope.
So from what I understand, side-effects are not desirable when writing
functional code. This means setq and variables in general should be
avoided.
But suppose I have a list and I need its length not once, but twice or
more inside my function. If i'm not supposed to use a variable to
store the length of the list, how am I supposed to reuse the result of
that computation (the length determining)?
(setq len (length mylist))
(concatenate 'list (subseq 0 (/ len 2)) (subseq (+ (/ len 2) 1) len))
How am i supposed to achieve this without using the len variable? Or
am I incorrectly understanding what functional programming is all
about? (I come from a c++ background so imperative programming is all
I know for now) I could call length each time where needed, but that
is obviously very inefficient and unnecessary.
Many thanks,
Gabriel
Pascal Costanza
(let* ((len (length mylist))
(half-len (/ len 2)))
(concatenate 'list (subseq 0 half-len) (subseq (+ half-len 1) len)))
...or something like that. Binding local variables is not considered as
using side effects.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Captain Obvious
Z> I hope.
I'm sorry to disappoint you, but Lisp is not really a functional programming
language.
But it supports functional programming to some extent, ok...
Z> So from what I understand, side-effects are not desirable when writing
Z> functional code. This means setq and variables in general should be
Z> avoided.
Those are recommendations for programmers coming from C-like languages, as
they tend to over-use setq and variables.
Variables are actually not different from function parameters. You might
want to use them when you want name some value.
C programmers often want to name every temporary value, as in C they usually
operate with shorter expressions. (As C doesn't allow to embed control
structure into the expression.)
So there is this recommendation -- write longer expressions without naming
temporaries.
But variables are not related to side-effects, as long as you do not assign
them via SETQ.
Making local variables via LET or LET* is fine. You can even name temporary
variables this way for no real reason, just because variable name might help
reading. (It is up to a personal taste.)
SETQ, indeed, has side-effects. But if you SETQ to a local variable
(introduced via LET), those side-effects are well-localized and are not a
big problem.
Sometimes using SETQ or, maybe, macros like PUSH or INCF makes code shorter.
It makes code "less functional", but if it has no effect on program in
general (if it affects only local variables) and you understand semantics
very well -- then why not?
But C programmers tend to over-use SETQ to initialize temporary variables
with it, so it is plain ugly.
Z> But suppose I have a list and I need its length not once, but twice or
Z> more inside my function.
That's a legit reason to introduce a variable.
Z> (setq len (length mylist))
Z> (concatenate 'list (subseq 0 (/ len 2)) (subseq (+ (/ len 2) 1) len))
Use LET, not SETQ. As a general rule, LET is much, much better than SETQ.
SETQ is for a last resort.
Z> I could call length each time where needed, but that
Z> is obviously very inefficient and unnecessary.
In theory, good compiler could optimize that away, but I would not bet on
it.
RG
<3a86d701-1dc2-4c48...@k33g2000yqc.googlegroups.com>,
Zadirion <zadi...@gmail.com> wrote:
> I'm new to functional programming, just barely getting the hang of it,
> I hope.
> So from what I understand, side-effects are not desirable when writing
> functional code. This means setq and variables in general should be
> avoided.
Not quite. It is the DEFINITION of functional programming that it is
done without side-effects. So it's not that SETQ "should" be avoided,
it's that by definition if you use SETQ you're not doing functional
programming. Also, using variables (created with LET or LAMBDA or other
binding forms) is perfectly fine. You just can't change the value of a
variable after it has been created.
> But suppose I have a list and I need its length not once, but twice or
> more inside my function. If i'm not supposed to use a variable to
> store the length of the list, how am I supposed to reuse the result of
> that computation (the length determining)?
>
> (setq len (length mylist))
> (concatenate 'list (subseq 0 (/ len 2)) (subseq (+ (/ len 2) 1) len))
>
> How am i supposed to achieve this without using the len variable? Or
> am I incorrectly understanding what functional programming is all
> about? (I come from a c++ background so imperative programming is all
> I know for now) I could call length each time where needed, but that
> is obviously very inefficient and unnecessary.
Exactly right. C++ has poisoned your mind to conflate binding and
assignment. (If you don't understand what that means, read
http://www.flownet.com/ron/specials.pdf) So it's perfectly fine to BIND
a variable to store an intermediate result, e.g.:
(let ((len (length mylist)))
...
)
You just can't reassign LEN with SETQ. You can do this though:
(let ((len ...))
...
(let ((len ...))
...
This may appear to be equivalent to:
(let ((len ...))
...
(setq len ...)
...
)
but it isn't. Figuring out why it isn't is left as an exercise. HINT:
consider what happens if you create closures as part of your
computations.
rg
His kennyness
> Z> I'm new to functional programming, just barely getting the hang of it,
> Z> I hope.
>
> I'm sorry to disappoint you, but Lisp is not really a functional
> programming language.
> But it supports functional programming to some extent, ok...
God, you are worse than I thought. Could you just go away or shut up for
ten years and learn something before speaking here again?
In Lisp, every form returns a value. Case closed. Thank you for playing.
kt
His kennyness
> On 28/04/2010 13:19, Zadirion wrote:
>> I'm new to functional programming, just barely getting the hang of it,
>> I hope.
>> So from what I understand, side-effects are not desirable when writing
>> functional code. This means setq and variables in general should be
>> avoided.
>>
>> But suppose I have a list and I need its length not once, but twice or
>> more inside my function. If i'm not supposed to use a variable to
>> store the length of the list, how am I supposed to reuse the result of
>> that computation (the length determining)?
>>
>> (setq len (length mylist))
>> (concatenate 'list (subseq 0 (/ len 2)) (subseq (+ (/ len 2) 1) len))
>>
>> How am i supposed to achieve this without using the len variable? Or
>> am I incorrectly understanding what functional programming is all
>> about? (I come from a c++ background so imperative programming is all
>> I know for now) I could call length each time where needed, but that
>> is obviously very inefficient and unnecessary.
>
> (let* ((len (length mylist))
> (half-len (/ len 2)))
> (concatenate 'list (subseq 0 half-len) (subseq (+ half-len 1) len)))
>
> ...or something like that. Binding local variables is not considered as
> using side effects.
No but it is considered evil and taxed heavily by Mr. Graham.
But to the OP: Lisp is a multi-paradigm language designed for real work,
damn the religious wars. Functional is a great productivity thing so use
it where you can, bind variables where that is faster.
If you are in fact curious about pure functional programming go check
out one of those, and their proponents will help you with needing the
length twice. i honestly do not know what they do about that.
kt
Mariano Montone
CL-USER> (defun foo ()
(values))
FOO
CL-USER> (foo)
; No value
CL-USER>
Norbert_Paul
> CL-USER> (defun foo ()
> (values))
> FOO
> CL-USER> (foo)
> ; No value
NIL
CL-USER> ;)
; No value
CL-USER>
grucidipo
In functional programming, for example in Haskell, if you bind l to be
a list then l can't change, also the functions are pure, that is
to the same input correspond the same output, so when you compute the
length of l the compiler can memorize the result and optimize the
code.
So functional programming take advantage of first you can't modify the
binding of a variable and only use pure functions (non pure require
a monad, a difficul concept to grasp for a C programmer.
His kennyness
I can always count on some newsgroup genius to point out the one
non-exception exception. It is a non-exception because there /is/ a
value if you are looking for one, namely nil. "; No value" is just a
choice of the author of your repl. My repl's author simply shows a new
prompt, which gets the edge for elegance in my book.
kt
Helmut Eller
(multiple-value-call (lambda (x) x) (values))
Is definitely an error.
Helmut
RG
Helmut Eller <eller....@gmail.com> wrote:
> * His kennyness [2010-04-28 21:12+0200] writes:
>
> > Mariano Montone wrote:
> >> His kennyness escribió:
Sigh. I hate it when smug lisp weenies get things wrong. Makes it hard
to clean up the mess.
Lisp is not considered functional because every form returns a value.
First, it is clearly not true that every form returns a value. You
don't even need to introduce the ambiguous case of (values). There are
many forms in CL that don't return anything, notably GO, THROW, and
ERROR.
The reason Lisp is considered a functional language is that it has
lexical closures as first-class data structures. That's really all you
need to do functional programming. It also has two additional features
that are generally considered part and parcel of functional programming:
linked lists and conditional expressions. But these don'y actually add
and real functionality since they can be built out of closures.
Everything else is a red herring.
rg
Scott L. Burson
>
> The reason Lisp is considered a functional language is that it has
> lexical closures as first-class data structures. That's really all you
> need to do functional programming.
That's strictly true, but a functional data structures library can
sure be handy!
http://common-lisp.net/project/fset/
-- Scott
Captain Obvious
What does GO return? And, importantly, WHERE does it return?
Hk> God, you are worse than I thought. Could you just go away or shut up
Hk> for ten years and learn something before speaking here again?
Aha, come back when you learn about non-local control transfers.
Captain Obvious
R> lexical closures as first-class data structures.
A bit of problem here is that most modern programming languages have them.
Python and JavaScript always had them.
They were added relatively recently into C#, PHP, Delphi.
There are proposals to add them into Java and C++.
Should we consider all these languages functional? I don't think so. That
would be totally meaningless.
R> That's really all you need to do functional programming.
Well, ok, you can do functional programming in all those languages I've
listed above.
But another question is -- do you want to? Is that a preferred style?
Xah Lee
using local variable is fine. In lisp, it's like this:
(let (var1 var2 ...)
(setq var1 val1)
(setq var2 val2)
...
body
)
the key to remember about functional programing, is that the behavior
of your function should only depends on input, and that usually means
just the argument it receives. Using local variable is still
functional programing, as long as those variables don't leak, such as
global variables, and they shouldn't keep a state (such as in OOP).
However, the quest to avoid using variables is of theoretical interest
as well as a interesting programing program of a given language.
there are, academic language that does not have variables at all.
(though, off hand i don't know any. Web search for the word
“cominator” and you'll find examples.)
without a pure functional lang such as Haskell, avoiding variable is
difficult or impossible.
Even Haskell, for practical reasons, have local variables, just that
you can't change a variable's value. (effectively, they are local
“constants”)
In a less strict functional lang OCaml/F#, you can have variables that
changes value.
Lisp, as a functional lang, is even less strict than the above ones.
Also, it is IMPOSSIBLE to write any non-trivial function without using
variables, mutable or not.
In Mathematica, which i've coded for over 10 years, am among the
world's say top 100 expert, i often avoid using ANY variables at all.
It is not difficult to do. Basically, any function is all just a
sequence of application of functions. Though, the code get complicated
for average programers to understand, but simple if you understand the
function application paradigm.
Mathematica can be considered as a lisp variant. However, lisps
(Common Lisp, Scheme Lisp, Emacs Lisp, Arc lisp, NewLisp, all can not
avoid variables. I'm pretty sure this includes Clojure lisp, Qi lisp,
or, that these two still would cost far more effort or un-natural code
to avoid vars than Mathematica)
Part of the reason why it is impossible to avoid using variables in
lisp,
i'v detailed in the past, in these essays:
• The Concepts and Confusions of Prefix, Infix, Postfix and Fully
Nested Notations
http://xahlee.org/UnixResource_dir/writ/notations.html
• Fundamental Problems of Lisp
http://xahlee.org/UnixResource_dir/writ/lisp_problems.html
In fact, trying code code in no-variable functional style is part of
the reason i discovered these lisp problems.
Look for the sections that discuss the nesting problem. The nesting
syntax is part of the problem, but there are other reasons that i
haven't discussed in the above essays. Maybe i'll write a detailed
essay about this topic in the future, but now just from the top of my
head ... (was going to write perhaps a one sentence description of
what i thought are the other reasons other than the nesting syntax,
because the problem cannot theoretically be just syntax... but am
tired, and i think the issue is more complex then i can think now...
will need to think about this another time)
Xah
∑ http://xahlee.org/
☄
Tim Bradshaw
> Lisp is not considered functional because every form returns a value.
> First, it is clearly not true that every form returns a value. You
> don't even need to introduce the ambiguous case of (values). There are
> many forms in CL that don't return anything, notably GO, THROW, and
> ERROR.
Even this is a red herring. The important thing (not about
being-a-functional-language but about being-a-Lisp) is that it's an
*expression language*: There are no statements in Lisp. What that
means is that if you can say x, you can say, for instance, (let ((y x)
...) freely (and this is true even for things like GO: Y will never
actually be bound to anything because control will have been
transferred, but it is syntactically a valid expression. What people
actually mean when they say "everything returns a value" (which is
false) is "everything is an expression".
This is quite distinct from C, say: I can say "if (x) then; else;", but
that's a *statement* not an expression, so I can't say "int foo = (if
(x) then; else;);" for instnace: indeed there is a whole construct in C
just for this: I have to say "int foo = (x? then : else);".
What this buys you is syntactic composabilty: you can freely compose
expressions with the result being another expression. In the above
case, I can take x and make (let ((y x)) ...), and I can quite happily
then have (let ((z (let ((y x)) ...))) ...), and so on.
And what *that* gets you turns out to be macros. People often wonder
if you could have a language "like C but with macros" and assume that
the thing that makes this difficult is syntax: it's not, it's the lack
of syntactic composability. It's not very difficult to write a front
end which has an s-expression syntax but the semantics of C:
(define-function (foo int) ((a int))
(if (bar a)
(return (+ a 1))
(return (- 1 a))))
and now you can use macros easily. Or you think you can until you find
that things like this are not valid:
(define-function (foo int) ((a int))
(return (+ a
(if (bar a) 1 -1))))
So you now need a whole bunch of idiosyncratic
this-is-a-statement/this-is-an-expression rules which are just endless
pain and make writing robust macros very hard.
Note in the above that I grounded everything on some undefined "x"
which was an expression. Expressions can have parts which are not
expressions: for instance in (let ((x 1)) ...) ((x 1)) is not an
expression, and neither is "FOR" in (loop for x from 1 below n ...).
RG
"Captain Obvious" <udod...@users.sourceforge.net> wrote:
> R> The reason Lisp is considered a functional language is that it has
> R> lexical closures as first-class data structures.
>
> A bit of problem here is that most modern programming languages have them.
> Python and JavaScript always had them.
Actually, Python didn't get them until version 2.2:
http://www.python.org/dev/peps/pep-0227/
> They were added relatively recently into C#, PHP, Delphi.
> There are proposals to add them into Java and C++.
>
> Should we consider all these languages functional? I don't think so. That
> would be totally meaningless.
I disagree. It depends on how you define functional language. There
are two reasonable definitions:
1. A functional language is one that supports programming in a
functional style. On this definition, being a functional language is
not a dichotomy, it's a continuum, and all of these languages are to
some extent functional.
2. A functional language is one that forces you to program in a
functional style. On this definition, none of these languages are
functional, including Lisp.
I personally prefer definition 1, though I don't really care to quibble
over terminology. But there is no reasonable way that you can say that
Lisp is definitively a functional language while Python and Javascript
are definitively not. The best you can do is argue that Lisp's support
for functional programming is better than the others.
> R> That's really all you need to do functional programming.
>
> Well, ok, you can do functional programming in all those languages I've
> listed above.
> But another question is -- do you want to? Is that a preferred style?
Sure. Why not? I write functional code in Python all the time. It's
annoying, but no more so than any of the zillion other annoyances that
coders have to face on a daily basis. And Python has some built-in
features (notably iterators and list comprehensions) that make
functional programming easier than in Lisp.
rg
Didier Verna
> I disagree. It depends on how you define functional language. There
> are two reasonable definitions:
>
> 1. A functional language is one that supports programming in a
> functional style. On this definition, being a functional language is
> not a dichotomy, it's a continuum, and all of these languages are to
> some extent functional.
>
> I personally prefer definition 1
Yup. The only definition that /should/ stand is: functional = supports
functions as first class citizens, as per Christopher Strachey's
definition. And support for any paradigm is indeed a continuum.
I also find particularly annoying when people assume that functional =
purely functional. That's the kind of vocabulary fuzziness that leads to
comments I've heard too often like:
<C guy>:
Lisp? Ah yeah, that's this weird functional language with lots of parens...
<Haskell guy>:
Lisp? Ah yeah, that's this weird imperative language with lots of parens...
--
Resistance is futile. You will be jazzimilated.
Scientific site: http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com
Tamas K Papp
> coders have to face on a daily basis. And Python has some built-in
> features (notably iterators and list comprehensions) that make
> functional programming easier than in Lisp.
I don't know Python that well. Could you please give an example? I
am curious whether those constructs give something extra, and if so,
whether one could implement them in CL.
Thanks,
Tamas
Zach Beane
Even if they're implementable, there's a lot of value in providing
things by default. For example, you can implement the condition system
with simpler features, but having a single, specified condition system
available with no extra effort is nicer.
Zach
RG
Tamas K Papp <tkp...@gmail.com> wrote:
> On Thu, 29 Apr 2010 06:55:24 -0700, RG wrote:
>
> > coders have to face on a daily basis. And Python has some built-in
> > features (notably iterators and list comprehensions) that make
> > functional programming easier than in Lisp.
>
> I don't know Python that well. Could you please give an example?
STFW.
> I am curious whether those constructs give something extra, and if so,
> whether one could implement them in CL.
Of course you can. And people have. STFW. Or you can start here:
http://rondam.blogspot.com/2008/02/joy-of-iterators.html
rg
Tamas K Papp
I don't disagree with you, but my question was not about establishing
which language is nicer. I just want to see if I can learn something
useful from another language, and possibly adapt it to CL and play around
with it.
Cheers,
Tamas
His kennyness
Cool, nice exception to the exception to the exclusion. But it is a
compiler-macro that complains, so it is not that (values) does not
return nil if asked (it better, it's in the spec) it's that
multiple-value-call knows how to count.
kt
RG
His kennyness <kent...@gmail.com> wrote:
> Helmut Eller wrote:
> > * His kennyness [2010-04-28 21:12+0200] writes:
> >
> >> Mariano Montone wrote:
> >>> His kennyness escribió:
You know, Kenny, the arrogant Lisp weenie act would go over a lot better
if you actually knew what you're talking about.
? (defun foo () (values))
FOO
? (defun baz () (multiple-value-call (lambda (x) x) (foo)))
BAZ
? (baz)
> Error: Too few arguments in call to #<Compiled-function (:INTERNAL BAZ) (Non-Global) #x302000D4D68F>:
rg
o.ja...@gmail.com
It is functional in the sense that you can write functionally with it
if you want, it isn't functional in the sense that it doesn't force
you, and perhaps it misses some features of functional languages.
(Though i suspect most of them are library-addable)
Andreas Eder
>>>>> "Xah" == Xah Lee <xah...@gmail.com> writes:
Xah> using local variable is fine. In lisp, it's like this:
Xah> (let (var1 var2 ...)
Xah> (setq var1 val1)
Xah> (setq var2 val2)
Xah> ...
Xah> body
Xah> )
You can do this easier and more succintly in the following way:
(let ((var1 val1) (var2 val2) ...)
...
body)
'Andreas
--
ceterum censeo redmondinem esse delendam.
Captain Obvious
R> are two reasonable definitions:
R> 1. A functional language is one that supports programming in a
R> functional style. On this definition, being a functional language is
R> not a dichotomy, it's a continuum, and all of these languages are to
R> some extent functional.
R> 2. A functional language is one that forces you to program in a
R> functional style. On this definition, none of these languages are
R> functional, including Lisp.
3. A functional language is one where functional style is preferred and
natural.
R> I personally prefer definition 1,
I strongly disagree with such definition, it doesn't make sense from
linguistical point of view.
"xxx-al language" should mean what language is about, not what it supports.
E.g. "logical language" is _mostly about_ logics, "imperative language" is
about imperative stuff etc.
If you want to say "language supports functional style/paradigm" -- say so.
And then you can talk about scale of that support.
But when you say "xxx is functional programming language", then it is
supposed to characterize primary programming style, otherwise it is totally
meaningless.
R> But there is
R> no reasonable way that you can say that Lisp is definitively a
R> functional language while Python and Javascript are definitively not.
Well, my point is that CL, Python and JavaScript support FP approximately to
same extent, and none of them is functional, as functional programming is
not a preferred programming style.
R> Sure. Why not? I write functional code in Python all the time. It's
R> annoying, but no more so than any of the zillion other annoyances that
R> coders have to face on a daily basis. And Python has some built-in
R> features (notably iterators and list comprehensions) that make
R> functional programming easier than in Lisp.
Aren't iterators inherently non-functional?
Captain Obvious
DV> purely functional. That's the kind of vocabulary fuzziness that leads
DV> to comments I've heard too often like:
Usually people who mention functional programming want to juxtapose it to
imperative programming.
If your definition of functional programming language includes CL and JS,
that's not juxtaposition at all.
So your definition destroys meaning. Term "functional language" becomes
unusable, but maybe if it pleases lispers so they know that they still use
functional programming language it's ok?
It doesn't need to be 100% pure functional, but I think it should have at
least some support for immutable data structures to qualify as functional.
DV> <Haskell guy>:
DV> Lisp? Ah yeah, that's this weird imperative language with lots of
DV> parens...
Well, I guess I'm more like a Haskell guy on this, except that I'm
programming mostly in CL. But I know a bit of Haskell, and I see that there
is an abyss between them.
Pascal Costanza
> R> I disagree. It depends on how you define functional language. There
> R> are two reasonable definitions:
>
> R> 1. A functional language is one that supports programming in a
> R> functional style. On this definition, being a functional language is
> R> not a dichotomy, it's a continuum, and all of these languages are to
> R> some extent functional.
>
> R> 2. A functional language is one that forces you to program in a
> R> functional style. On this definition, none of these languages are
> R> functional, including Lisp.
>
> 3. A functional language is one where functional style is preferred and
> natural.
>
> R> I personally prefer definition 1,
>
> I strongly disagree with such definition, it doesn't make sense from
> linguistical point of view.
> "xxx-al language" should mean what language is about, not what it supports.
> E.g. "logical language" is _mostly about_ logics, "imperative language"
> is about imperative stuff etc.
>
> If you want to say "language supports functional style/paradigm" -- say
> so. And then you can talk about scale of that support.
>
> But when you say "xxx is functional programming language", then it is
> supposed to characterize primary programming style, otherwise it is
> totally meaningless.
There is no primary programming style in Lisp. So we can only talk about
the programming styles it supports, not the ones it is "about".
And Lisp does support functional programming.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Didier Verna
> If you want to say "language supports functional style/paradigm" --
> say so. And then you can talk about scale of that support.
>
> But when you say "xxx is functional programming language", then it is
> supposed to characterize primary programming style, otherwise it is
> totally meaningless.
Where exactly can I find a legislation on what being functional is
"supposed to" mean ? In fact, this is exactly the idea I'm fighting
against. There is a silent and widespread assumption here, that a
language needs to have a /primary/ programming style, which is probably
to main source of misunderstanding and trolls about paradigms. Under
that assumption, you may be right, but then Lisp is nothing. It's not an
imperative language, not an OO one, it's not a meta-one, it's not a
functional one^C^C^C
Language[1] and thought go hand in hand. Your language reflects your
thoughts and vice-versa. When I claim that Lisp is a functional
language, I'm also advocating, from language to thought, the idea that
being multi-paradigm is important and shouldn't be regarded as a weird
corner-case. I'm trying to bend the language in order to make people
realize that there are silent assumptions that should be reconsidered.
> Well, my point is that CL, Python and JavaScript support FP
> approximately to same extent, and none of them is functional, as
> functional programming is not a preferred programming style.
That's because there is no preferred programming style, and my point is
that there shouldn't be any. Never.
> R> And Python has some built-in features (notably iterators and list
> R> comprehensions) that make functional programming easier than in
> R> Lisp.
> Aren't iterators inherently non-functional?
Mathematics are purely functional right? That's what everybody says.
Well, I find $\sum_{i=1}^{n} i$ pretty imperative and full of side
effects... unless iterators are in fact pretty functional :-)
The interesting question is: does an algorithm embed its own preferred
way of being expressed (i.e. its own paradigm). I believe so, and that's
why I use the "no primary paradigm" as my primary paradigm ;-). It seems
to me that even a mathematician would understand
(loop for i from 1 to 10 sum i)
better than
(labels ((sigma (a i) (if (> i 10) a (sigma (+ a i) (1+ i)))))
(sigma 0 1))
let alone abstracting true sigma, term and step functions.
Footnotes:
[1] not in the programming sense here, in the "natural language" one
Tim Bradshaw
> You know, Kenny, the arrogant Lisp weenie act would go over a lot better
> if you actually knew what you're talking about.
>
> ? (defun foo () (values))
> FOO
> ? (defun baz () (multiple-value-call (lambda (x) x) (foo)))
> BAZ
> ? (baz)
>> Error:
THis is not really any different to
(defun foo (x y)
(cons x y))
(foo 1)
RG
Tim Bradshaw <t...@tfeb.org> wrote:
Good grief, I'm surrounded by idiots. Of course it's different. Here
you're calling a function of two arguments with one argument. That has
nothing to do with whether or not (values) "really" returns NIL as Kenny
claimed. It doesn't. What does happen is that CL implicitly "expands"
zero values to NIL in some contexts -- but not all. And in particular,
not in the context of multiple-value-call. And this has nothing to do
with any compile-time optimizations, as Kenny also incorrectly claimed.
? (defun zero-values () (values))
ZERO-VALUES
? (defun tim () (cons (zero-values) (zero-values)))
TIM
? (defun kenny () (multiple-value-call 'cons (zero-values)
(zero-values)))
KENNY
? (tim)
(NIL)
? (kenny)
> Error: Too few arguments in call to #<Compiled-function CONS #x3000000D771F>:
And if that doesn't convince you:
? (defun maybe-zero-values (x) (if x (values)
'kenny-is-a-smug-lisp-weenie))
MAYBE-ZERO-VALUES
? (defun kenny2 (x) (multiple-value-call 'cons (maybe-zero-values x)
(maybe-zero-values x)))
KENNY2
? (kenny2 nil)
(KENNY-IS-A-SMUG-LISP-WEENIE . KENNY-IS-A-SMUG-LISP-WEENIE)
? (kenny2 t)
> Error: Too few arguments in call to #<Compiled-function CONS #x3000000D771F>:
rg
RG
"Captain Obvious" <udod...@users.sourceforge.net> wrote:
> DV> I also find particularly annoying when people assume that functional =
> DV> purely functional. That's the kind of vocabulary fuzziness that leads
> DV> to comments I've heard too often like:
>
> Usually people who mention functional programming want to juxtapose it to
> imperative programming.
Usually people who mention "data" want to distinguish it from "code".
That does not change the fact that code and data are fundamentally
indistinguishable, nor does it change the fact that artificial
constraints can be imposed to make them distinguishable, nor does that
change the fact that imposing such artificial constraints is generally
considered a bad idea here on C.L.L. What people usually want ought not
be confused with actual facts.
> If your definition of functional programming language includes CL and JS,
> that's not juxtaposition at all.
> So your definition destroys meaning. Term "functional language" becomes
> unusable, but maybe if it pleases lispers so they know that they still use
> functional programming language it's ok?
>
> It doesn't need to be 100% pure functional, but I think it should have at
> least some support for immutable data structures to qualify as functional.
Lisp can "provide some support for immutable data structures" by doing,
e.g.:
(shadow '(rplaca rplacd setf))
It doesn't seem to me that your definition is exactly a model of
semantic clarity.
rg
RG
"Captain Obvious" <udod...@users.sourceforge.net> wrote:
> R> I disagree. It depends on how you define functional language. There
> R> are two reasonable definitions:
>
> R> 1. A functional language is one that supports programming in a
> R> functional style. On this definition, being a functional language is
> R> not a dichotomy, it's a continuum, and all of these languages are to
> R> some extent functional.
>
> R> 2. A functional language is one that forces you to program in a
> R> functional style. On this definition, none of these languages are
> R> functional, including Lisp.
>
> 3. A functional language is one where functional style is preferred and
> natural.
>
> R> I personally prefer definition 1,
>
> I strongly disagree with such definition, it doesn't make sense from
> linguistical point of view.
> "xxx-al language" should mean what language is about, not what it supports.
This assumes that a language needs to be "about" something. That's a
very bad assumption.
> R> Sure. Why not? I write functional code in Python all the time. It's
> R> annoying, but no more so than any of the zillion other annoyances that
> R> coders have to face on a daily basis. And Python has some built-in
> R> features (notably iterators and list comprehensions) that make
> R> functional programming easier than in Lisp.
>
> Aren't iterators inherently non-functional?
No, not "inherently". It is true that iterators are internally stateful
so they can certainly be used in non-functional ways, but when used in
conjunction with functional constructs like list comprehensions they are
a very powerful tool for functional programming.
rg
Tim Bradshaw
> Good grief, I'm surrounded by idiots.
You are living in a hall of mirrors.
> Of course it's different. Here
> you're calling a function of two arguments with one argument.
And there you're feeding no values to a form which expects one. You
may observe a certain partly-broken symmetry there.
> That has
> nothing to do with whether or not (values) "really" returns NIL as Kenny
> claimed.
Why do you think I said it had anything to do with that? Because, you
know, I don't think I did. Obviously, though, you are much better at
interpreting what I wrote than I am.
Espen Vestre
> Cool, nice exception to the exception to the exclusion. But it is a
> compiler-macro that complains, so it is not that (values) does not
> return nil if asked (it better, it's in the spec) it's that
> multiple-value-call knows how to count.
I see you guys are having fun flaming each other... I think your wording
above is not quite right though. It's true that the spec says (section
3.1.7) "if the form produces zero values, then the caller receives nil
as a value", but it's misleading to say that (values) "returns nil if
asked".
I think it's better to compare it to what happenes if you try to assign
more variables than there are values in multiple-value-bind, all excess
variables get bound to nil:
CL-USER 6 > (let ((foo (values)))
foo)
NIL
CL-USER 7 > (multiple-value-bind (foo bar gazonk)
(floor 2 3)
(list foo bar gazonk))
(0 2 NIL)
CL-USER 8 >
I think it would be misleading to explain thas as "floor returns NIL as
its third value if asked" ;-)
--
(espen)
Pascal Costanza
Common Lisp is an infinite-functional language, because every form
returns an infinite number of values.
Or is it a multiple-values-limit-functional language?
Confused... ;)
Tim Bradshaw
> I think it's better to compare it to what happenes if you try to assign
> more variables than there are values in multiple-value-bind, all excess
> variables get bound to nil:
Or like calling a function all of whose arguments are optional. The
fact that (funcall (lambda (&optional x) x)) returns NIL doesn't
somehow mean that no-list-at-all is the same as NIL.
There is quite an interesting symmetry between multiple values and
function arguments. One of the places it the symmetry is broken is
that the handling of multiple values generally behaves as if all values
were optional, while the handling of function arguments generally
(unless you ask otherwise via &optional and so on) behaves as if all
arguments are mandatory. That's because that turns out to be the
useful behaviour: very frequently the use of multiple values is to be
able to say "here's the answer, and by the way here is some other stuff
you might be interested in", and the optional-by-default behaviour
captures that.
There are languages where function arguments are optional by default
(Perl is sort-of like this). I find that a pain.
Tim Bradshaw
>
> There is quite an interesting symmetry between multiple values and
> function arguments.
And of course, that's because, if you think of CPS-transforming things,
they are in fact exactly the same thing: values are the arguments you
pass to your continuation. This must be well-known, though I've only
just realised it.
RG
Tim Bradshaw <t...@tfeb.org> wrote:
> On 2010-04-30 11:52:53 +0100, RG said:
>
> > Good grief, I'm surrounded by idiots.
>
> You are living in a hall of mirrors.
Ah. That explains why all these idiots are so ruggedly handsome.
> > Of course it's different. Here
> > you're calling a function of two arguments with one argument.
>
> And there you're feeding no values to a form which expects one. You
> may observe a certain partly-broken symmetry there.
Yes, but feeding no values to a form that expects one is relevant to the
topic under discussion, namely:
> > That has
> > nothing to do with whether or not (values) "really" returns NIL as Kenny
> > claimed.
>
> Why do you think I said it had anything to do with that?
You didn't explicitly say so, but I assumed that was your intent because
that's what this thread of the conversation is about. Your example is
like saying that the sky is blue. It's true. The sky is indeed blue.
But that has nothing to do with the matter at hand.
rg
Giorgos Keramidas
> The important thing (not about being-a-functional-language but about
> being-a-Lisp) is that it's an *expression language*: There are no
> statements in Lisp. What that means is that if you can say x, you can
> say, for instance, (let ((y x) ...) freely (and this is true even for
> things like GO: Y will never actually be bound to anything because
> control will have been transferred, but it is syntactically a valid
> expression. What people actually mean when they say "everything
> returns a value" (which is false) is "everything is an expression".
>
> This is quite distinct from C, say: I can say "if (x) then; else;",
> but that's a *statement* not an expression, so I can't say "int foo =
> (if (x) then; else;);" for instnace: indeed there is a whole construct
> in C just for this: I have to say "int foo = (x? then : else);".
>
> What this buys you is syntactic composabilty: you can freely compose
> expressions with the result being another expression. In the above
> case, I can take x and make (let ((y x)) ...), and I can quite happily
> then have (let ((z (let ((y x)) ...))) ...), and so on.
True. I still remember the day I really grokked that in Lisp it is
perfectly valid to write:
(do-stuff (if some-condition true-argument false-argument))
In certain cases, this feels more aesthetically pleasing than having to
write two calls to do-stuff:
(if some-condition
(do-stuff true-argument)
(do-stuff false-argument))
In C there's no possibility to use the first way. The lack of syntactic
composability drives people towards cpp(1) preprocessor abuse. Then the
hairy bits of multiple macro-argument evaluation kick in, and fun ensues.
RG
Giorgos Keramidas <kera...@ceid.upatras.gr> wrote:
That's not quite true. C does have conditional expressions, they just
use a different syntax:
do_stuff(condition ? then : else)
rg
His kennyness
> There is no primary programming style in Lisp.
You need to write more Lisp. Some wise soul said Lisp gives us a million
ways of doing something, and (1- a million) of them are wrong.
kt
His kennyness
the vastly more interesting point is that all these yobbos are useless
usenet roadkill. The point was: lisp is indeed a functional language (in
the non-crazy obsessive sense) because every lisp form returns a value.
then some idiot jumped on the obvious (values) not knowing that that
form is the poster child for 'exception that proves a rule', as in "oh,
a form created to return multiple values includes the edge case of
returning no values? and don't worry you might accidentally be calling a
function that does this, we'll give you a nil as a solid guess as to
what you would like?" is really the most fantastically beautiful
non-exception exception one can conceive of, and in itself a testament
to the design of lisp that not only is the edge case allowed but it is
made transparent to unwitting callers. people think CL is a weirdo
language when it is in fact as practical and in the trenches friendly as
one can get. meanwhile, god forbid anyone remember the OT: lisp is
indeed a functional language because every form returns a value*.
kt
* I can dream, can't I?
His kennyness
> On 2010-04-30 11:52:53 +0100, RG said:
>
>> Good grief, I'm surrounded by idiots.
>
> You are living in a hall of mirrors.
>
>> Of course it's different. Here
>> you're calling a function of two arguments with one argument.
>
> And there you're feeding no values to a form which expects one. You may
> observe a certain partly-broken symmetry there.
>
>> That has
>> nothing to do with whether or not (values) "really" returns NIL as Kenny
>> claimed.
>
> Why do you think I said it had anything to do with that?
relax, that's just Ron being Erann.
kt
His kennyness
Now hold on there, desperado. /You/ drew a comparison and nothing but a
comparison between the choice made by the cubicle dweller who coded up
mvb and a different choice by the yobbo covered in donut debris who
coded up mvc. So there you are off in The Land of Haphazard Choice
citing it as the definition of how (values) should be understood, while
I am safely ensconced in the arms of our sacred CLHS with the only
problem being that you do not consider a caller to be "asking" for a
value. Sure, the Unsaved use setf. But in lisp that returns a value! Cuz
in Lisp, every form... oh, well.
meanwhile, here, I'll ask floor for its third value and see what it says:
(nth-value 3 (floor 42 10)) -> nil
The deepest problem here is that once again HK has been underestimated:
"ask" is nowhere to be found in the CLHS, and was deliberately chosen to
be undecidable in meaning in the context of Lisp. Ergo, one cannot hope
to prove HK wrong about His Usage thereof. All bow.
kt
RG
His kennyness <kent...@gmail.com> wrote:
> Tim Bradshaw wrote:
> > On 2010-04-29 16:42:18 +0100, RG said:
> >
> >> You know, Kenny, the arrogant Lisp weenie act would go over a lot better
> >> if you actually knew what you're talking about.
> >>
> >> ? (defun foo () (values))
> >> FOO
> >> ? (defun baz () (multiple-value-call (lambda (x) x) (foo)))
> >> BAZ
> >> ? (baz)
> >>> Error:
> >
> > THis is not really any different to
> >
> > (defun foo (x y)
> > (cons x y))
> >
> > (foo 1)
> >
>
> the vastly more interesting point is that all these yobbos are useless
> usenet roadkill. The point was: lisp is indeed a functional language (in
> the non-crazy obsessive sense) because every lisp form returns a value.
You really aren't paying attention. GO and THROW do not return.
But leaving this aside, imagine if CL did not have LAMBDA, FLET, LABELS,
FUNCTION, FUNCALL, REDUCE, or any of the MAP* functions. It would still
be true that (nearly) all of the remaining forms returned values. But
no sane person would call the resulting language functional. So...
> lisp is
> indeed a functional language because every form returns a value*.
No. Lisp is a functional language because functions are first-class
objects.
rg
RG
RG <rNOS...@flownet.com> wrote:
> In article <4bdba00c$0$31262$607e...@cv.net>,
> His kennyness <kent...@gmail.com> wrote:
>
> > Tim Bradshaw wrote:
> > > On 2010-04-29 16:42:18 +0100, RG said:
> > >
> > >> You know, Kenny, the arrogant Lisp weenie act would go over a lot better
> > >> if you actually knew what you're talking about.
> > >>
> > >> ? (defun foo () (values))
> > >> FOO
> > >> ? (defun baz () (multiple-value-call (lambda (x) x) (foo)))
> > >> BAZ
> > >> ? (baz)
> > >>> Error:
> > >
> > > THis is not really any different to
> > >
> > > (defun foo (x y)
> > > (cons x y))
> > >
> > > (foo 1)
> > >
> >
> > the vastly more interesting point is that all these yobbos are useless
> > usenet roadkill. The point was: lisp is indeed a functional language (in
> > the non-crazy obsessive sense) because every lisp form returns a value.
>
> You really aren't paying attention. GO and THROW do not return.
>
> But leaving this aside, imagine if CL did not have LAMBDA, FLET, LABELS,
> FUNCTION, FUNCALL, REDUCE, or any of the MAP* functions.
Doh, left out APPLY.
Jack
All Cartier replica watches sold at Hotwristwatch.com are brand-new and high
quality. Each Cartier Replica Watch produced is examined carefully by our
quality test department and each watch is inspected again before being sent
to our customer. It is our desire that you do experience the joy of shopping
when buying one of our Cartier Replica Watches at our site. Some Cartier
Watches may need to be special ordered, please call for availability on
Cartier watches. Best service you will receive from us.
"Zadirion" <zadi...@gmail.com>
??????:3a86d701-1dc2-4c48...@k33g2000yqc.googlegroups.com...
> I'm new to functional programming, just barely getting the hang of it,
> I hope.
> So from what I understand, side-effects are not desirable when writing
> functional code. This means setq and variables in general should be
> avoided.
>
> But suppose I have a list and I need its length not once, but twice or
> more inside my function. If i'm not supposed to use a variable to
> store the length of the list, how am I supposed to reuse the result of
> that computation (the length determining)?
>
> (setq len (length mylist))
> (concatenate 'list (subseq 0 (/ len 2)) (subseq (+ (/ len 2) 1) len))
>
> How am i supposed to achieve this without using the len variable? Or
> am I incorrectly understanding what functional programming is all
> about? (I come from a c++ background so imperative programming is all
> I know for now) I could call length each time where needed, but that
> is obviously very inefficient and unnecessary.
>
> Many thanks,
> Gabriel
His kennyness
> Hk> In Lisp, every form returns a value.
>
> What does GO return? And, importantly, WHERE does it return?
>
> Hk> God, you are worse than I thought. Could you just go away or shut up
> Hk> for ten years and learn something before speaking here again?
>
> Aha, come back when you learn about non-local control transfers.
Good lord, can you not even manage human discourse? Well, no, you are an
engineer.
The context is "is lisp a functional language?". Finding edge cases is
besides the point, but amusing for the pathetic types that just hang out
on usenet playing gotcha.
hth, kenzo
Joerthan Panest
RG
His kennyness <kent...@gmail.com> wrote:
> Captain Obvious wrote:
> > Hk> In Lisp, every form returns a value.
> >
> > What does GO return? And, importantly, WHERE does it return?
> >
> > Hk> God, you are worse than I thought. Could you just go away or shut up
> > Hk> for ten years and learn something before speaking here again?
> >
> > Aha, come back when you learn about non-local control transfers.
>
> Good lord, can you not even manage human discourse? Well, no, you are an
> engineer.
>
> The context is "is lisp a functional language?". Finding edge cases is
> besides the point
Not when the claim is being made that Lisp is functional *because* all
forms return a value. That is clearly false. At best, one might argue
that Lisp is functional because *most* forms return a value. But that
is actually true of most languages (for some value of "most"),
particularly if you include their standard libraries.
That Lisp does not distinguish between expressions and statements is a
useful property, but it is not the property that makes Lisp functional.
The property that makes Lisp -- or any language -- functional is
providing support for first-class functions.
rg
Pascal Costanza
Oh, indeed:
(1- a million) =>
Error: 1- got 2 args, wanted 1 arg.
[condition type: PROGRAM-ERROR]
(1- a million) is indeed wrong.
I should have asked you first...
markha...@gmail.com
Pascal brain damage is because they're European.
His kennyness
> In article <4bdc1796$0$5019$607e...@cv.net>,
> His kennyness <kent...@gmail.com> wrote:
>
>> Captain Obvious wrote:
>>> Hk> In Lisp, every form returns a value.
>>>
>>> What does GO return? And, importantly, WHERE does it return?
>>>
>>> Hk> God, you are worse than I thought. Could you just go away or shut up
>>> Hk> for ten years and learn something before speaking here again?
>>>
>>> Aha, come back when you learn about non-local control transfers.
>> Good lord, can you not even manage human discourse? Well, no, you are an
>> engineer.
>>
>> The context is "is lisp a functional language?". Finding edge cases is
>> besides the point
>
> Not when the claim is being made that Lisp is functional *because* all
> forms return a value. That is clearly false. At best, one might argue
> that Lisp is functional because *most* forms return a value.
"all" is the word people with balls use where other people say "most".
And in this case it was a deliberate trick to quickly identify the
usenidiots here now -- I've been away.
> But that
> is actually true of most languages (for some value of "most"),
> particularly if you include their standard libraries.
All Python statements return a value? C? Java? Are you barking mad?
>
> That Lisp does not distinguish between expressions and statements is a
> useful property, but it is not the property that makes Lisp functional.
> The property that makes Lisp -- or any language -- functional is
> providing support for first-class functions.
first-class functions are wonderful but take them away and one can still
program functionally.
kt
His kennyness
> On 01/05/2010 05:18, His kennyness wrote:
>> Pascal Costanza wrote:
>>> There is no primary programming style in Lisp.
>>
>> You need to write more Lisp. Some wise soul said Lisp gives us a million
>> ways of doing something, and (1- a million) of them are wrong.
>
> Oh, indeed:
>
> (1- a million) =>
> Error: 1- got 2 args, wanted 1 arg.
Wise souls do not quibble, and they certainly do not quibble with jokes.
Unless you thought you were being funny.... oh, my....
Well, maybe I misquoted the guy:
http://smuglispweeny.blogspot.com/2008/02/what-hell-is-fortune-cookie-file-anyway.html
Wow, I was off by (- kazillion a million)
kt
RG
His kennyness <kent...@gmail.com> wrote:
> RG wrote:
> > In article <4bdc1796$0$5019$607e...@cv.net>,
> > His kennyness <kent...@gmail.com> wrote:
> >
> >> Captain Obvious wrote:
> >>> Hk> In Lisp, every form returns a value.
> >>>
> >>> What does GO return? And, importantly, WHERE does it return?
> >>>
> >>> Hk> God, you are worse than I thought. Could you just go away or shut up
> >>> Hk> for ten years and learn something before speaking here again?
> >>>
> >>> Aha, come back when you learn about non-local control transfers.
> >> Good lord, can you not even manage human discourse? Well, no, you are an
> >> engineer.
> >>
> >> The context is "is lisp a functional language?". Finding edge cases is
> >> besides the point
> >
> > Not when the claim is being made that Lisp is functional *because* all
> > forms return a value. That is clearly false. At best, one might argue
> > that Lisp is functional because *most* forms return a value.
>
> "all" is the word people with balls use where other people say "most".
And "most" is the word that people with brains use when they mean "most."
But you can't have it both ways. Either you grant me the same
linguistic latitude that you claim for yourself, or you're a hypocrite.
Which do you choose? (HINT: That is a rhetorical question.)
> > But that
> > is actually true of most languages (for some value of "most"),
> > particularly if you include their standard libraries.
>
> All Python statements return a value? C? Java?
That is not what I said. Can you not read? Statements *by definition*
do not return a value. That is what distinguishes statements from
expressions (in languages that make such a distinction).
Lisp doesn't distinguish between statements and expressions. Instead,
Lisp conflates those two concepts into one, called a FORM. What I said
was that MOST FORMS return a value, and that this is true for most
languages.
If you're going to criticize that claim, you first have to decide what
it even means to talk about "most forms" in the context of languages
that distinguish between statements and expressions. This is where the
linguistic latitude I spoke of earlier comes into play. One reasonable
interpretation is that if you count up all the statements (i.e. all the
things that by definition don't return values) and all the expressions
(i.e. all the things that by definition do return a value) there will be
a lot more of the latter than the former, particularly (and this would
sound familiar to you if you had bothered to read and think about what I
wrote instead of attacking a straw man) if you include their standard
libraries.
> Are you barking mad?
No, but I have been known on occasion to become hopping mad.
> > That Lisp does not distinguish between expressions and statements is a
> > useful property, but it is not the property that makes Lisp functional.
> > The property that makes Lisp -- or any language -- functional is
> > providing support for first-class functions.
>
> first-class functions are wonderful but take them away and one can still
> program functionally.
That's true. You can take away everything but the S and K combinators
and still program functionally. But most people would not consider the
S-K calculus to be a "functional programming language". Most people
consider a functional programming language to be one that lets you do
things like MAP, REDUCE and COMPOSE, and create lexical closures. Those
things, by definition, cannot be done without first-class functions.
rg
Espen Vestre
> meanwhile, here, I'll ask floor for its third value and see what it says:
>
> (nth-value 3 (floor 42 10)) -> nil
I can "ask" nth-value for it googolth value, and it still returns nil:
CL-USER 9 > (defparameter *googol* (expt 10 100))
*GOOGOL*
CL-USER 10 > (nth-value *googol* (floor 42 10))
NIL
But the definition of nth-value actually says the following: "Evaluates
n and then form, returning as its only value the nth value yielded by
form, or nil if n is greater than or equal to the number of values
returned by form. (The first returned value is numbered 0.)".
> The deepest problem here is that once again HK has been
> underestimated: "ask" is nowhere to be found in the CLHS, and was
> deliberately chosen to be undecidable in meaning in the context of
> Lisp. Ergo, one cannot hope to prove HK wrong about His Usage
> thereof. All bow.
:-)
--
(espen)
Espen Vestre
> Common Lisp is an infinite-functional language, because every form
> returns an infinite number of values.
But is the space of lisp return values a Hilbert space?
;-)
--
(espen)
Pascal J. Bourguignon
> Tim Bradshaw wrote:
>> On 2010-04-29 16:42:18 +0100, RG said:
>>
>>> You know, Kenny, the arrogant Lisp weenie act would go over a lot better
>>> if you actually knew what you're talking about.
>>>
>>> ? (defun foo () (values))
>>> FOO
>>> ? (defun baz () (multiple-value-call (lambda (x) x) (foo)))
>>> BAZ
>>> ? (baz)
>>>> Error:
>>
>> THis is not really any different to
>>
>> (defun foo (x y)
>> (cons x y))
>>
>> (foo 1)
>>
>
> the vastly more interesting point is that all these yobbos are useless
> usenet roadkill. The point was: lisp is indeed a functional language
> (in the non-crazy obsessive sense) because every lisp form returns a
> value.
Would it kill you to say that in lisp, any form can be used as an
expression, whether it returns 0, 1, or more values, or whether it
returns at all, instead of saying something as wrong as "in lisp every
form returns a value"?
--
__Pascal Bourguignon__
Pascal J. Bourguignon
(nth-value (1+ multiple-values-limit) (values)) --> NIL
doesn't seem to be unconformant, so I would say infinite-functional.
--
__Pascal Bourguignon__
Pascal J. Bourguignon
In Scheme, multiple-values can only be handled by a function.
http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-9.html#%_idx_574
--
__Pascal Bourguignon__
Xah Lee
> That Lisp does not distinguish between expressions and statements is a
> useful property, but it is not the property that makes Lisp functional.
> The property that makes Lisp -- or any language -- functional is
> providing support for first-class functions.
no, not really.
most of the discussions trying to define or characterize functional
programing are idiotic.
if i'd pick on poster's argument that makes the most sense, that'd be
Kenny's.
Xah
His kennyness
You seek a usenettian immaculate precision from which Grand
Pontificators are exempt. This clash is the root of all your evils.
Choose one: usenettian hair-splitting angels-on-the-head-of-a-pin, or
the grabdness of kennyspeak.
kxo
Captain Obvious
XL> Kenny's.
Sure, mindless trolls like each other.
Raffael Cavallaro
> But you can't have it both ways. Either you grant me the same
> linguistic latitude that you claim for yourself, or you're a hypocrite.
You only get that latitude when you're usenet royalty.
Maybe if you signed your decrees^H^H^H^H^H^H^H posts "Emperor Ron," or
"His Ronnyness?"
;^)
warmest regards,
Ralph
--
Raffael Cavallaro
Xah Lee
wrote:
> XL> if i'd pick on poster's argument that makes the most sense, that'd be
> XL> Kenny's.
>
> Sure, mindless trolls like each other.
Kenny has a blog with photos as well as video and has published
software that won accolades.
I have resume and photos and publications on my site with accolades.
what the fuck is Captain Obvious? did you lead Sinbad and traveled the
7 seas?
i have a poem for u.
in the climb to geekdom,
you have few rungs to catch,
before you see my ass.
Xah
∑ http://xahlee.org/
☄
Tim Bradshaw
> Lisp doesn't distinguish between statements and expressions. Instead,
> Lisp conflates those two concepts into one, called a FORM. What I said
> was that MOST FORMS return a value, and that this is true for most
> languages.
And, in Lisp, ALL forms can be used in a place which syntactially
expects a value or values (possibly creating a run-time error if there
is a mismatch in value count, which may in turn be elevated to
compile-time in some cases with a sufficiently smart compiler). This
is not true in languages which have several kinds of form.
Tim Bradshaw
> But is the space of lisp return values a Hilbert space?
No, there's no norm, and I think Hilbert spaces need one
Espen Vestre
>> But is the space of lisp return values a Hilbert space?
>
> No, there's no norm, and I think Hilbert spaces need one
:-)
--
(espen)
His kennyness
> On May 1, 3:58 pm, "Captain Obvious" <udode...@users.sourceforge.net>
> wrote:
>> XL> if i'd pick on poster's argument that makes the most sense, that'd be
>> XL> Kenny's.
>>
>> Sure, mindless trolls like each other.
>
> Kenny has a blog with photos as well as video and has published
> software that won accolades.
And now I am working on Qxells, if only I could get that turd
AllegroServe to find a file. The scary thing is that I can give the
index.html to the browser and it finds the rest of qooxdoo lib stuff
sans problem! Give it to AllegroServe and ... man, not even a 403?!
Last time I did this I ended up moving the entire qooxdoo library into
my application directory!!!!!
This time I have grabbed the AllegroServe source and plan to teach it a
lesson.
> I have resume and photos and publications on my site with accolades.
>
> what the fuck is Captain Obvious? did you lead Sinbad and traveled the
> 7 seas?
Word up, Xah. But Cap'n O is not a bad guy, just a little wet behind the
ears. Give ''m twenty years, he'll be fine.
kt
His kennyness
> Xah Lee wrote:
>> On May 1, 3:58 pm, "Captain Obvious" <udode...@users.sourceforge.net>
>> wrote:
>>> XL> if i'd pick on poster's argument that makes the most sense,
>>> that'd be
>>> XL> Kenny's.
>>>
>>> Sure, mindless trolls like each other.
>>
>> Kenny has a blog with photos as well as video and has published
>> software that won accolades.
>
> And now I am working on Qxells, if only I could get that turd
> AllegroServe to find a file. The scary thing is that I can give the
> index.html to the browser and it finds the rest of qooxdoo lib stuff
> sans problem! Give it to AllegroServe and ... man, not even a 403?!
because it /is/ finding and sending back the files. Hmm, except the
beef, Application.js.
Anyone using aserve or paserve? I'd try Edi's if I could remember the name.
kt
His kennyness
Hunchentoot! But I just needed to publish one more directory, so on we
go to qxells or qooxcells or something. Let some yobbo port it to Hunch.
qooxells? qx-cells? qooxdoo-cl?
kt
Rob Warnock
+---------------
| Espen Vestre said:
| > But is the space of lisp return values a Hilbert space?
|
| No, there's no norm, and I think Hilbert spaces need one
Is Cheers a Hilbert space?
http://en.wikipedia.org/wiki/Norm_Peterson
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Johan Ur Riise
> His kennyness <kent...@gmail.com> writes:
>
>> meanwhile, here, I'll ask floor for its third value and see what it says:
>>
>> (nth-value 3 (floor 42 10)) -> nil
>
> I can "ask" nth-value for it googolth value, and it still returns nil:
>
> CL-USER 9 > (defparameter *googol* (expt 10 100))
> *GOOGOL*
>
> CL-USER 10 > (nth-value *googol* (floor 42 10))
> NIL
>
> But the definition of nth-value actually says the following: "Evaluates
> n and then form, returning as its only value the nth value yielded by
> form, or nil if n is greater than or equal to the number of values
> returned by form. (The first returned value is numbered 0.)".
We obviously need a new nth-value, free of this defect.
Here nth-value-x returns two values, the second is T if
the nth value in fact exists, nil else.
(defmacro nth-value-x (n form)
`(let ((reslist (multiple-value-list ,form)))
(if (> ,n (length reslist))
(values nil nil)
(values (nth ,n reslist) t))))
Björn Lindberg
Pascal Costanza
Tamas K Papp
> On 03/05/2010 13:19, Björn Lindberg wrote:
>> Joerthan Panest<joertha...@gmail.com> writes:
>>
>>> His kennyness<kent...@gmail.com> writes:
>>>
>>>> Pascal Costanza wrote:
>>>>> There is no primary programming style in Lisp.
>>>>
>>>> You need to write more Lisp. Some wise soul said Lisp gives us a
>>>> million ways of doing something, and (1- a million) of them are
>>>> wrong.
>>>
>>> That's funny. I heard it that (- a-million 1) were wrong.
>>
>> You need to write more Lisp.
>
> You need to write more Lisp.
Writing more Lisp is always good for one's soul, regardless of this
thread.
Best,
Tamas
Joerthan Panest
Thomas A. Russ
> On 01/05/2010 05:18, His kennyness wrote:
> > Pascal Costanza wrote:
> >> There is no primary programming style in Lisp.
> >
> > You need to write more Lisp. Some wise soul said Lisp gives us a million
> > ways of doing something, and (1- a million) of them are wrong.
>
> Oh, indeed:
>
> (1- a million) =>
> Error: 1- got 2 args, wanted 1 arg.
> [condition type: PROGRAM-ERROR]
>
> (1- a million) is indeed wrong.
>
> I should have asked you first...
You forgot to do
(setq *dwim-mode* t)
first.
--
Thomas A. Russ, USC/Information Sciences Institute
WJ
> "Captain Obvious" <udod...@users.sourceforge.net> wrote:
>
> > If you want to say "language supports functional style/paradigm" --
> > say so. And then you can talk about scale of that support.
> >
> > But when you say "xxx is functional programming language", then it
> > is supposed to characterize primary programming style, otherwise it
> > is totally meaningless.
>
> Where exactly can I find a legislation on what being functional is
> "supposed to" mean ? In fact, this is exactly the idea I'm fighting
> against. There is a silent and widespread assumption here, that a
> language needs to have a primary programming style, which is probably
> to main source of misunderstanding and trolls about paradigms. Under
> that assumption, you may be right, but then Lisp is nothing. It's not
> an imperative language, not an OO one, it's not a meta-one, it's not a
> functional one^C^C^C
>
> Language[1] and thought go hand in hand. Your language reflects your
> thoughts and vice-versa. When I claim that Lisp is a functional
> language, I'm also advocating, from language to thought, the idea that
> being multi-paradigm is important and shouldn't be regarded as a weird
> corner-case. I'm trying to bend the language in order to make people
> realize that there are silent assumptions that should be reconsidered.
>
>
> > Well, my point is that CL, Python and JavaScript support FP
> > approximately to same extent, and none of them is functional, as
> > functional programming is not a preferred programming style.
>
> That's because there is no preferred programming style, and my point
> is that there shouldn't be any. Never.
>
>
> > R> And Python has some built-in features (notably iterators and list
> > R> comprehensions) that make functional programming easier than in
> > R> Lisp.
>
> > Aren't iterators inherently non-functional?
>
> Mathematics are purely functional right? That's what everybody says.
> Well, I find $\sum_{i=1}^{n} i$ pretty imperative and full of side
> effects... unless iterators are in fact pretty functional :-)
>
> The interesting question is: does an algorithm embed its own preferred
> way of being expressed (i.e. its own paradigm). I believe so, and
> that's why I use the "no primary paradigm" as my primary paradigm
> ;-). It seems to me that even a mathematician would understand
>
> (loop for i from 1 to 10 sum i)
>
> better than
>
> (labels ((sigma (a i) (if (> i 10) a (sigma (+ a i) (1+ i)))))
> (sigma 0 1))
>
> let alone abstracting true sigma, term and step functions.
>
MatzLisp:
(1..10).reduce(:+)
==>55
Scheme:
(apply + (iota 10 1))
==> 55
Cthun
> MatzLisp:
>
> (1..10).reduce(:+)
> ==>55
What does your classic unsubstantiated and erroneous claim have to do
with Lisp, WJ? Clearly that is not Lisp code, WJ, since it is not
parenthesized as Lisp code would be,