On Wed, May 13, 2015 at 12:07 PM, zipher <dreamingforw...@gmail.com> wrote: > On Wednesday, May 13, 2015 at 10:27:23 AM UTC-5, Ian wrote: >> I don't know why I'm replying to this... > > Because you're trying to get an answer to a question that even Academia > hasn't answered or understood. > >> On Wed, May 13, 2015 at 8:44 AM, zipher <dreamingforw...@gmail.com> wrote: >> > On Tuesday, May 12, 2015 at 10:35:29 PM UTC-5, Rustom Mody wrote: >> >> How history U-turns!! >> >> Lisp actually got every major/fundamental thing wrong >> >> - variables scopes were dynamic by mistake >> >> - lambdas were non-first class because the locution 'first-class' was >> >> still 8 >> >> years in the future >> > >> > I think you're confused. LISP doesn't have variables. >> >> Yes, it does. > > No, Common LISP does, but as the website says Common LISP is a > "multi-paradigm" langauge. It's trying to be everything to everybody, just > like Python tried to do in the other direction, making "everything an > object". Python was trying to be too pure, while LISP was trying to be too > universal: be everything to everyone -- you might say "batteries included". > > True LISP, doesn't need a 'let' statement for example. To understand true > LISP you have to understand the modus operandi of the "lambda the ultimate" > crowd. Very few do from academic computer science. MIT understands it. You > think you understand it, but you don't.
By "true LISP" are you referring to the original specification by John McCarthy? Here's an example lambda S-expression from McCarthy's original paper: (LABEL, SUBST, (LAMBDA, (X, Y, Z), (COND ((ATOM, Z), (COND, (EQ, Y, Z), X), ((QUOTE, T), Z))), ((QUOTE, T), (CONS, (SUBST, X, Y, (CAR Z)), (SUBST, X, Y, (CDR, Z))))))) Ugh, what a mess. But ignoring that, tell us how many variables you see there. I'll give you a hint: I count more than two. > It's only abstractions, like math. It's purpose is to output a final result, > that is all. It's not at all to make commercial applications. It's rather > like Asimov's computer in the Last Question. It's a whole different model of > computation. Instead of a Turing Tape or VonNeumann stream, you have > hierarchies of expressions all evaluating... > > ...well I would say all at the same time, but since I have to constrain my > description to a common set of reality that is shared with you, then I'd say > "on the stack frame". It's why they had specialized machines to run true > LISP. Sure. Lisp machines never, ever ran computer graphics applications. Or medical image processing. Nope, never, because that would be commercial and dirty and a hideous perversion of the idol of computer science created by the prophet McCarthy. Text editors? Heavens to Betsy, now you're just trying to shock me, aren't you! >> > with an entirely different model computation than other programming >> > languages which use variables all the time. To the extent that it DOES >> > have variables, it's to accommodate those coming over from iterative >> > programming. >> >> What is "iterative programming"? If you mean "writing programs that >> work iteratively", then this describes both functional and procedural >> styles alike. > > Yes, and LISP is neither. Although LISP is a functional style, that is only > by appearance. It's completely different from Haskell, which I would > describe as a true functional language. The difference is how the program is > lexed in the mind or on the machine. But that's too difficult to explain on > this thread. And Fermat had a truly marvelous proof, which you would think wonderful, if only he had enough room in that infamous margin. >> The opposite of "iterative programming" would then be a style where >> the program can't ever repeat anything. That would be a very limited >> language and would *not* be equivalent to a Turing machine. > > > The "opposite" of iterative programming is recursive programming. It's not > limited, except that it has an entirely different relationship to data, one > orthogonal to iterative computation. Iteration is a type of recursion. Specifically, it's the type of recursion that doesn't require keeping a stack of values from each higher-up repetition in the evaluation. Also known as "linear recursion" or "tail recursion". Often people use the word "iteration" to mean a syntactic construct that repeats itself without explicit reference to a function and "recursion" to mean a syntactic construct where a function explicitly repeats itself, but from a theoretical standpoint this is all just syntax. The two constructs are fundamentally the same. > >> > And the idea of lambdas were already encoded by the use of special >> > expressions, set-off by parenthesis. So they practically *defined* the >> > concept of lambdas. >> >> LISP is also the reason why we're cursed with the terrible name >> "lambda" for anonymous functions rather than something more mnemonic >> (like "function"). > > No, you haven't understood, padawan. *plonk* -- https://mail.python.org/mailman/listinfo/python-list
