Good functional programming habbit?
in [Lisp]
|
Prev: Searching some references
Next: Comparing Lisp to Python, what you consider more important:speed or macros.
From: RG on 1 May 2010 13:53 In article <4bdc4e3d$0$22534$607ed4bc(a)cv.net>, His kennyness <kentilton(a)gmail.com> wrote: > RG wrote: > > In article <4bdc1796$0$5019$607ed4bc(a)cv.net>, > > His kennyness <kentilton(a)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
From: Espen Vestre on 1 May 2010 14:21 His kennyness <kentilton(a)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.)". > 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)
From: Espen Vestre on 1 May 2010 14:23 Pascal Costanza <pc(a)p-cos.net> writes: > 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)
From: Pascal J. Bourguignon on 1 May 2010 16:19 His kennyness <kentilton(a)gmail.com> writes: > 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__
From: Pascal J. Bourguignon on 1 May 2010 16:23
Pascal Costanza <pc(a)p-cos.net> writes: > On 30/04/2010 16:15, Espen Vestre wrote: >> His kennyness<kentilton(a)gmail.com> writes: >> >>> 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" ;-) > > 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... ;) (nth-value (1+ multiple-values-limit) (values)) --> NIL doesn't seem to be unconformant, so I would say infinite-functional. -- __Pascal Bourguignon__ |