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 30 Apr 2010 13:25 In article <hrekoo$n7$1(a)news.eternal-september.org>, Tim Bradshaw <tfb(a)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
From: Giorgos Keramidas on 30 Apr 2010 09:50 On Thu, 29 Apr 2010 14:02:16 +0100, Tim Bradshaw <tfb(a)tfeb.org> wrote: > 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.
From: RG on 30 Apr 2010 18:48 In article <87vdb96odz.fsf(a)kobe.laptop>, Giorgos Keramidas <keramida(a)ceid.upatras.gr> wrote: > On Thu, 29 Apr 2010 14:02:16 +0100, Tim Bradshaw <tfb(a)tfeb.org> wrote: > > 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. That's not quite true. C does have conditional expressions, they just use a different syntax: do_stuff(condition ? then : else) rg
From: His kennyness on 30 Apr 2010 23:18 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. kt
From: His kennyness on 30 Apr 2010 23:29
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. 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? |