On Wednesday, May 13, 2015 at 4:39:52 PM UTC-5, Ian wrote: > 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.
LoL, it's an interesting example you've thrown up there. It's more than just a mess though. The problem is the use of the quote. I was hoping you wouldn't include it. The problem is that its a compromise to interact with your mental-visual lexer. It's like Javascript which runs on no virtual machine anyone's heard of. It's too magical. > 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! CLISP =/= LISP. > > 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. Ha, you know, I actually think I found the proof he alleges. You have to visualize the problem geometrically. > 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". You are so confused, it boggles. Can anyone else assert this? Mark -- https://mail.python.org/mailman/listinfo/python-list
