Daily reminder that LISP is Jewish

i i i i i i i ooooo o ooooooo ooooo ooooo
I I I I I I I 8 8 8 8 8 o 8 8
I \ `+' / I 8 8 8 8 8 8
\ `-+-' / 8 8 8 ooooo 8oooo
`-__|__-' 8 8 8 8 8
| 8 o 8 8 o 8 8
------+------ ooooo 8oooooo ooo8ooo ooooo 8

Welcome to GNU CLISP 2.49 (2010-07-07) <http://clisp.cons.org/>

CLisp is not a lisp.

>>2
CLisp is a Common Lisp implementation

>>3
Common Lisp is not a Lisp.

>>4
The Only True Lisp is the one described in McCarthy's paper.
The others are just sellouts, like those artists who stopped releasing vinyls. A laminated, signed by Sussman, copy of SICP and McCarthy's paper on Lisp is all you need to be a computer scientist.

>>5

The Only True Lisp is the one described in McCarthy's paper.

It's dynamically scoped and contains at least one bug because of that though.

picolisp is the most approximate LISP!

http://klisp.org/
Kernel is perhaps the simplest and most general practical Scheme, where everything is first-class; it's just a shame about the (necessary?) distinction between applicative and operative procedures.

>>8

an applicative is nothing more than a wrapper to induce operand evaluation, around an underlying operative

>>5
SICP is incompatible with McCarthy Lisp.

>>9
That sounds more like an implementation detail than anything meaningful a progdolyte could surface on a skim-read. The author deemed it necessary to put sigils on the operatives, which signals that there is a semantically significant difference.

>>8

practical Scheme
practical Scheme
practical Scheme

Edible stones. Beautiful shit. Intelligent negroes.

>>8

usually environments are optimized for specialized uses as static offsets into specialized base pointers or object pointers or class variable pointers held in registers, or resolved to static variables, or even different optimized versions of slots - each case optimized to a very specific implementation of that.

But Kernel doesn't have pre-built specialized implementations of environments, environments are created in user code and can be any sort of spaghetti the user wants. And in computing there isn't ONE implementation of objects or modules or any of those things - it's just important the the compiler know ahead of time what model is used so that it can optimize to it.

So it would be very hard indeed for a Kernel system to analyze a users code, figure out which kinds of patterns of environment inheritance the user has created over and over, find the most efficient flattened model of it, and put that in the code.

Kernel very much breaks the mapping from user code to machine code that was the original purpose of high level languages.

>>13
How many marijuanas have you had today?

>>8

The principal programming activity of interest here will be meta-programming. There will be no role in the discussion for macros, which address abstraction but not meta-programming; and fexprs, which address both, will be contrasted with quotation (which addresses meta-programming but not abstraction).

This man has no functioning brain.

(continuing from >>15)

Macros are meta-programming, by definition as code that creates code. Meta-programming is a way to create abstractions, though not the only one. Therefore, macros address both.

Quotation is not abstraction, nor meta-programming. It is simply a tool for managing data structures and capturing source code.

Fexprs cannot perform meta-programming, because they do not programmatically generate programs, but rather calculate direct non-meta results of expression evaluation. Fexprs cannot be used compositionally with other source-manipulating constructs except as a leaf. Hence it can only perform the shallowest form of both abstraction and meta-programming, arguably a degenerate form that would not earn those descriptions in the first place.

Fexprs are shit, and Shutt's raging boner for them is a banner proclaiming his stupidity. There's a reason Lispers stopped using them decades ago.

>>16
http://www.dalnefre.com/wp/2011/11/fexpr-the-ultimate-lambda/

>>16
Macros, as implemented in RnRS, are crippled. They are only run at the syntax phase (not the runtime phase), are not first-class, and have their own special sublanguage.
I don't see how Fexprs, which entirely subsume macros and address the above failures, are shit in comparison.

>>18
Lets not get carried on the "subsume" part.
Macros have their value in that they cost zero runtime.

>>19
Seeing as any Lisp system worth using gives you a REPL for every program, you never practically feel that benefit.

>>18
First, "syntax phase" happens at runtime. While there is an organizational distinction, there's no real distinction. You can invoke any of this whenever you want.

Second, Common Lisp has real macros, no sublanguages, first class (though opaque). I don't give a shit about Scheme's misplaced "minimalism."

Third, prove to me that Fexprs "entirely subsume macros". They can't return source code that other fexprs process. Hence, they cannot perform meta-programming.

>>21

Macros, as implemented in RnRS

I could have been talking about cpp's #define and you would have come back with something similar, huh?

They can't return source code that other fexprs process

How does id not fit the bill?
How, in fact, does ``source code'' come into this at all?

I understand that you deliberately haven't worked with fexprs because nobody else has, and therefore you have an acidic repulsion to the very notion of the word, but how about you try using things before saying what they can't do, and give demontration behind your reasoning? You are using exactly the emotion and phrasing of someone who hates something because they don't understand it, and that is a dangerous mindset to have.

>>22
sweet dubs bro

>>22

How, in fact, does ``source code'' come into this at all?

Because that's what meta-programming is, you brainless dick.