LuaJIT

LuaJIT

no match for python, ``faggot''

You're just one butthurt python faggot, aren't you?

sorry but Javascript already exists

>>4
Hahahaha, funny joke.

>>5
:<

How LUA is better than Haskell?

>>7
people use it!

I am far from an expert at Lua, but I have done a couple of semi-serious projects in the language and will try to recall specifically what I didn't like:
- Simple-minded people seems love Lua due to Baby Duck Syndrome and too much World of Warcraft farming, instead of education.
- Yet another boring, badly designed, slow scripting language. Nothing to see here.
- No, wait! Lua managed to screw royally even where other scripting crap works nice - there is no list/vector type in Lua: you can't access elements sequentially or by an integer index. That needs some talent!

>>8
Some "people" use human faeces as a sexual stimulant

http://en.wikipedia.org/wiki/Coprophilia

check 'em

>>9
you can't access elements sequentially or by an integer index.
0/10

>>12
http://lua-users.org/wiki/TablesTutorial
Lua stores all elements in tables generically as key-value pairs. Lua does not differentiate between arrays and dictionaries. All Lua tables are actually dictionaries.

http://lua-users.org/wiki/TablesTutorial
This didn't work because when we tried to retrieve the value of a[{1,2,3}] we constructed another table, i.e. the table that we used as a key in the table constructor is not the same one as we used to retrieve the value.

the fucking tutorial is full of Lua-criticism!

>>13
you'll have to explain how this prevents you from ``accessing elements sequentially or by an integer index''

>>14
and that has absolutely nothing to do with what you were talking about earlier

-10/10

>>15
Please, implement CAR and CDR in Lua.

>>16
I was talking about Lua being shit. The fact that in Lua {1,2,3} != {1,2,3} is the essence of shitness.

>>18
I don't know if that applies to Lua, but most languages separate referential equality from data equality.

>>9
argumentum ad hominem, subjective reasoning, no sources, didn't read the manual
0/10

>>13
lua-users.org
5/10

>>18
deep object comparison
0/10

>>17
function car(t) return t[1] end
function cdr(t) return { unpack(t,2) } end
keep on trollin'

Why `t = {"a","b","c"}; print(t[2])` works, but `print({"a","b","c"}[2])` doesnt?

>>19
Most languages are shit like JS/PHP. Where you have

var foo = [0];
foo == foo  // true
foo == !foo // true

>>20
Your answer shows that you're out of viable arguments. I will interpret it as your surrender.

>>21
http://doris.sourceforge.net/lua/weblua.php
Lua script:
unpack({1,2,3},2)

Run using lua generates:
error: attempt to call global `unpack' (a nil value)

>>14
actually this is my biggest beef with Lua: mutable data structures. The language is awkwardly "almost functional." I would love Lua with immutable persistent tables so that you could compare equality and key by them and do all sorts of functional shenanigans. Lua should be more like its second cousin Clojure.


>>21
what the fuck? does unpack even take more than one argument? what you smokin, son?

function car(l) return l[1] end
function cdr(l) return l[2] end
function cons(a,l) return {a,l} end
function map1(f,l)
  local r
  if l then
    return cons(f(car(l),map1(f,cdr(l)))
  end
end

>>22
>Run using lua generates
>error: attempt to call global `unpack' (a nil value)
because lua 4.0 has been out of date since 2003

>>23
does unpack even take more than one argument?
http://www.lua.org/manual/5.1/manual.html#pdf-unpack
it takes up to 3, thank you very much!

>>24
i.e. Lua is unstable shit.

>>23
function cdr(l) return l[2] end
but that returns only 2nd element, not the table without the first element! It's like this ugly Set Theory, where you have to do special Axiom of Choice magic.

LuaJIT?










































More like LuaSHIT

^Forced ^Flushing ^Of L1/L2 ^Cache per operation

it's no javascript

I really can't see why one would choose to use an interpreter outside of development for any purpose other than green threads.

Here we are!
- Lua Tables are mutable and encourage modification, instead of creation, meaning there is no easy way to do functional programming with Lua.
- `t={[{1,2,3}]="abc"}; print(t[{1,2,3}])` wont print "abc", meaning that `{1,2,3} != {1,2,3}`. In general, Lua's logic seems odd: "nil+1" results in error, while "(not nil)+1" eval to 2.
- Lua uses floating point values instead of integers and 1234567890123456789 would result into 1.234567890123457e+18
- Lua is unstable: API changes frequently, functions are being added and deleted continuously, `table.foreach` being a good example of to be deleted function, and then there is `table.unpack`, which present only in some versions of Lua.
- Lua is inconsistent: `t = {"a","b","c"}; print(t[2])` works, but `print({"a","b","c"}[2])` fails.
- Hash-Table as a primary data structure has some issues. There is no simple and safe way to implement FIRST and REST function from Lisp: either you have to copy whole Table or modify it, and sequential access is somewhat slow. There is no easy way to remove an element from a list. Even worse, the size of a list may not be what you expect: "b={};b[666]="a";print(#b)" will print 1. Lua Tables also don't provide advantages of catenable double-ended queues -- a silver bullet data strucure, you'll find in modern Lisps and Haskell.
- Lua's REPL wont pretty-print tables, instead it'll print something like "table: 0x807e978"
- Hashtables hold much of Lua's data, and even simple variable access goes through table system, producing several L2 cache misses in process just to get to value. That makes Lua slower than comparable alternatives, like Lisp.
- Table indexing starts from 1, instead of 0, like everything in computing. That acts as a source of errors and confusion, when interfacing with external APIs or converting algorithm from Lua to C/C++, while 0 still acts as a dangling pointer.
- Lua's GC is a naive mark-and-sweep implementation, which stores the mark bit directly inside objects, a GC cycle will thus result in all objects being written to, making their memory pages `dirty` and Lua's speed proportional to the number of allocated objects. Lua simply was not designed to support hundred thousand objects allocation per second.
- Quirky syntax with underscores for special variables and cryptic symbols for simple functions, like `#xs` for `length(xs)` and `x = start,end,step` instead of range(start,end,step), while logical connectives (`and`, `or` in place of `&&`, `||`) are hard to notice between other symbols. do/then/end everywhere could be annoying.
- Lua was built as a glue language, and it shows. Much of Lua hype comes from it's usage as a simple integrated scripting language in video games industry. That makes typical Lua user a teenage gamer with little expectations or taste for computation features and productivity.

>>31
>In general, Lua's logic seems odd: "nil+1" results in error, while "(not nil)+1" eval to 2
still not proofreading are we

>>31
What do Lua, Python, Ruby, and PHP have in common?
They're all shit!

>>31
You must be the ``in Lisp'' goy

>>32
That is an imageboard post! Nobody cares about it's quality.

>>34
At least I'm not a jew. Some evil people here tried to insult me like that, calling me a "jew".

>>31
http://www.lua.org/about.html
fast, lightweight, embeddable scripting language
ideal for configuration, scripting, and rapid prototyping
emphasis on embedded systems

http://www.lua.org/doc/hopl.pdf
[i]One of Tecgraf’s largest partners was (and still is) Petrobras,
the Brazilian oil company. Several Tecgraf products
were interactive graphical programs for engineering applications
at Petrobras. By 1993, Tecgraf had developed little
languages for two of those applications: a data-entry application
and a configurable report generator for lithology profiles.
These languages, called DEL and SOL, were the ancestors
of Lua. We describe them briefly here to show where
Lua came from.

Please give me an good Lisp or Haskell implementation that:
  - is < 500K
  - has configurable gc cycles
  - has better C <=> script ffi api

I tried to use some Scheme implementations, but they weren't what I expected.

>>36
I tried to use some Lua implementations, but they weren't what I expected.

>>37
yeah i was expecting horribly-designed hacks ala php but i was left disappointed

>>38
Agree. They were much worse -- you have to write half of your code in C/C++! Then use scary toLua++ bindings, exporting half of stuff manually.

>>31
which stores the mark bit directly inside objects
there
Sorry but there's no other way.  If you seriously think about using double indirection or storing the GC flags in a separate table, then yo'ure retarded.

>>40
There are generational GCs, which scan only current generation.

And there is also a very advanced algorithm for GCing entire distributed networks of data
http://cs.au.dk/~beta/Papers/Train/train.html

>>39
C++
Hahahahahaha, funny joke.

>>39

C/C++

Produces a value of : 1

ITT: people criticize Lua in terms of being a general purpose scripting language, which is was never intended to be.

>>45
Poor is that soldier, who does not dream of becoming a Führer.

>>44
http://www.codenix.com/~tolua/tolua++.html
integration of C/C++ code with Lua.
maps C/C++ constants, external variables, functions, classes, and methods to Lua.

deal with it.

Lua is a fucking joke does it even have any users?

>>47
Integration of 1 code with Lua.
maps 1 constants, external variables,...

That makes no sense sir...

>>49
What language are you using for parsing the expression C/C++, how are you certain that C is an integer and how are you certain the implementation is defined?

>>31

>- Lua Tables are mutable and encourage modification, instead of creation, meaning there is no easy way to do functional programming with Lua.

Be creative. You are welcome to make shallow copy and comparison functions, or implement a balanced immutable red black tree. lua has closures and tail call optimization, making it much better for functional programming than most other popular languages.

>- `t={[{1,2,3}]="abc"}; print(t[{1,2,3}])` wont print "abc", meaning that `{1,2,3} != {1,2,3}`. In general, Lua's logic seems odd: "nil+1" results in error, while "(not nil)+1" eval to 2.

Yeah, you can't use table keys with deep equality in lua. There is an issue with mutable keys. This is solved nicely in python by providing immutable tupples that can be used as keys. One work around is to stringify the keys, although you have to make the stringification function one to one.

>- Lua uses floating point values instead of integers and 1234567890123456789 would result into 1.234567890123457e+18

Well that's interesting. I wasn't aware of that myself. They don't require it though:

http://www.lua.org/manual/5.1/manual.html#2.2
Number represents real (double-precision floating-point) numbers. (It is easy to build Lua interpreters that use other internal representations for numbers, such as single-precision float or long integers; see file luaconf.h.

>- Lua is unstable: API changes frequently, functions are being added and deleted continuously, `table.foreach` being a good example of to be deleted function, and then there is `table.unpack`, which present only in some versions of Lua.

Yeah they've made changes. But the API is very small and simple. Most of the changes are additions of new features, like variable argument functions and unpack. and table.foreach is trivial to replace, which is likely why it was removed.

>- Lua is inconsistent: `t = {"a","b","c"}; print(t[2])` works, but `print({"a","b","c"}[2])` fails.

The parser can be finiky. But that is completely possible to do with some parens:

Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio
print(({"a", "b", "c"})[2])
b


- Hash-Table as a primary data structure has some issues. There is no simple and safe way to implement FIRST and REST function from Lisp: either you have to copy whole Table or modify it, and sequential access is somewhat slow. There is no easy way to remove an element from a list. Even worse, the size of a list may not be what you expect: "b={};b[666]="a";print(#b)" will print 1. Lua Tables also don't provide advantages of catenable double-ended queues -- a silver bullet data strucure, you'll find in modern Lisps and Haskell.

Not every algorithm must traverse a data structure using first rest style. Plain iteration works just as well, and can be expressed recursively if you want to go there.

A doubly linked list is not that difficult to implement. And lua has pretty nice support for iterators. I actually concatenate iterators.

- Lua's REPL wont pretty-print tables, instead it'll print something like "table: 0x807e978"


Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio
t = {action = "learn lua before finding fault with it"}
setmetatable(t, {__tostring = function(instructions) return "You should really " .. instructions.action end})
print(t)
You should really learn lua before finding fault with it



>- Hashtables hold much of Lua's data, and even simple variable access goes through table system, producing several L2 cache misses in process just to get to value. That makes Lua slower than comparable alternatives, like Lisp.

Have you confirmed this with profiling? A hash table that doesn't use chaining is usually kept at a length that is twice the number of elements stored. Your beef is with hash tables being used for structures? Most sane structures will have maybe 8 to 10 entries in it, so a hash table of length 20. Assuming each pointer is between 4 to 8 bytes long, the array will be 80 - 160 bytes long? That ought to fit in a cache.

If you want to avoid cache misses though, you should use a langauge like C or seeples. Something that lets you explicity control where your objects are allocated. Using a language where objects can only contain references to other objects will cause a lot of jumping around in memory.

- Table indexing starts from 1, instead of 0, like everything in computing. That acts as a source of errors and confusion, when interfacing with external APIs or converting algorithm from Lua to C/C++, while 0 still acts as a dangling pointer.

You can still use A[0] if you want to. zero is a valid key. And if you want the ipairs function to iterate from zero up to #A, you can make one yourself. And indecies starting at zero is not always ideal. Check the formula for a d-way heap (the priority queue implementation) and you'll see what I mean.

- Lua's GC is a naive mark-and-sweep implementation, which stores the mark bit directly inside objects, a GC cycle will thus result in all objects being written to, making their memory pages `dirty` and Lua's speed proportional to the number of allocated objects. Lua simply was not designed to support hundred thousand objects allocation per second.

If you'd like to change this by having an ID array, it would not be very difficult to implement. You can download the source and make your change and release it as Clean Page Lua ^1.0.
http://www.lua.org/ftp/

- Quirky syntax with underscores for special variables and cryptic symbols for simple functions, like `#xs` for `length(xs)` and `x = start,end,step` instead of range(start,end,step), while logical connectives (`and`, `or` in place of `&&`, `||`) are hard to notice between other symbols. do/then/end everywhere could be annoying.

You criticize #A instead of length(A), but support A && B instead of A and B?

- Lua was built as a glue language, and it shows. Much of Lua hype comes from it's usage as a simple integrated scripting language in video games industry. That makes typical Lua user a teenage gamer with little expectations or taste for computation features and productivity.

True. Some people that begin that way get past that stage, and some don't. I started using lua for its simplicity, support for functional style, readability, flexibility, and performance. As for it's presence in the gaming industry, lua wouldn't be used if it didn't fill a niche.

>>31
Whoa, boy.
Lua Tables are mutable and encourage modification, instead of creation, meaning there is no easy way to do functional programming with Lua.
Lua was designed to be a high-level scripting/configuration language for applications written in C. In C, Lua tables are built piece by piece. They represent everything from arrays to hash tables to environments. What possible benefit could come from making them immutable? And what good would be functional bindings to C code?
In general, Lua's logic seems odd: "nil+1" results in error, while "(not nil)+1" eval to 2.
nil is a not a number. 1 is a number. 1 is not nil. Booleans are represent as integers, just as they are in C. How is this not logical?
1234567890123456789 would result into 1.234567890123457e+18
Lua doesn't have bignums. Large integers are converted to doubles. It's unlikely that an exact integer that large would be useful, for say, indexing an array. Lose in precision is better than overflows.
Lua is unstable: API changes frequently, functions are being added and deleted continuously, `table.foreach` being a good example of to be deleted function, and then there is `table.unpack`, which present only in some versions of Lua.
Lua is the only language that has ever deprecated a function? Some people insist on using version 4.x because it's simpler. The current version is 5.x. Since when are major versions of scripting languages meant to be backwards compatible?
Lua is inconsistent: `t = {"a","b","c"}; print(t[2])` works, but `print({"a","b","c"}[2])` fails.
In C char *s = "abc"; putchar(s[1]); works but putchar("abc[1]"); fails. Not understand the lexical conventions of the language you're programming in does not make the language inconsistent.
Hash-Table as a primary data structure has some issues
What does this have to do with Lua? Lua tables are not hash tables, though there is an abstraction to interface them as such.
Lua's REPL wont pretty-print tables
C doesn't pretty-print arrays. What's your point?
Hashtables hold much of Lua's data, and even simple variable access goes through table system, producing several L2 cache misses in process just to get to value. That makes Lua slower than comparable alternatives, like Lisp.
Symbols in Lisp are accessed through hash tables.
Table indexing starts from 1, instead of 0, like everything in computing
Except Matlab, to which Lua is syntactically similar. In any case, it's consistent with how the Lua stack is indexed in the C API. In some cases, it makes sense  and/or is mandatory to iterate the stack incrementally from the bottom (1) and sometimes it makes sense and/or is mandatory to iterate the stack decrementally from the top (-1).
Lua's GC is a naive mark-and-sweep implementation
That was a long time ago. There's a new incremental GC now.
Lua was built as a glue language, and it shows.
Lua was built as high-interface to low-level code, and it shows, because there's not a single language that does it better.

>>50
assuming C is a Integer then yes it evaluates to 1.

C++ is post increment and should be (by any sane compiler designer) be evaluated post-expression and thus C/C++ => 1 and C = C + 1 afterwards.

If C is a floating point then the same still applies.

>>51
Be creative. You are welcome to make shallow copy and comparison functions, or implement a balanced immutable red black tree.
It would be easier to use Lisp instead.

>>52
C doesn't pretty-print arrays. What's your point?
C is shit.

Lua tables are not hash tables
Fuck off.
http://pgl.yoyo.org/lua/docs/luaarchitecture.doc
Internally, a table is implemented as ... a hash table

Symbols in Lisp are accessed through hash tables.
They're open coded, like in your C/C++.

>>54
It would be easier to use Lisp instead.
Yes, if your goal is write Fibonacci and factorial functions.

For programmers with unbounded creativity who prefer not to be bounded by the limitations useless toy languages, Lua has applications.

>>56
Your answer shows that you're out of viable arguments. I will interpret it as your surrender.

>>57
Your answer
Could you repeat the question?

>>54

allow me to rephrase:

Be resourceful. You are welcome to find a library providing shallow copy and comparison functions, or a balanced immutable red black tree.

Shallow copy and comparison functions are easy as shit to write though. The kicker is integrating shallow and deep equality with the tables. It really sucks when you need to use tupple keys for a table in lua. It just sucks man.

>>55

lisp is much more flexible than seeples and see. Any language that supports eval will need to have a symbol table present at runtime.

indexing from 1, what a joy

one word... Flawed Array Gap

thread over

>>59
http://en.wikipedia.org/wiki/Greenspuns_tenth_rule

>>58
"Why should we use Lua?"

>>53
C++ is post increment and should be (by any sane compiler designer) be evaluated post-expression and thus C/C++ => 1 and C = C + 1 afterwards.
This is complete gibberish in the context of the programming language C and it's extended family. Read about sequence points in the standard(s), make sure you understand what you're talking about before you judge what is "sane" or not as what you're currently saying is completely nonsensical.

>>62
tupple keys aren't really that advanced.

>>63
Who is we? Some people have their own reasons, and enjoy using lua everyday. And some people have their reasons for not using lua for their application, and enjoy not using lua everyday.

>>61
there are times where it makes sense.

>>65
aren't really that advanced.
There is nothing "advanced" with Lisp

Lisp is simple and efficient, it's just hard to throw away all that "advanced" bloat and accept the minimalism and uniformity as your only lord and saviour.

>>67
umena C?

>>68
What does the char (*(*x())[])() do?


Lisp   | C/C++
-------|-----------------------------------------------------
format | printf fprintf sprintf snprintf vsprintf vfprintf vsprintf vsnprint
       | asprintf vasprintf dprintf vdprintf wprintf putchar fputchar putwchar
       | putc fputc fputwc puts fputs fputws write fwrite
       | ostream ofstream streambuf streingstream ostringstream stringbuf
       | fstream filebuf ios ios_base cout cerr std clog << endl ends hex oct
       | boolalpha dec flush internal setw noboolalpha noshowbase noshowpos left
       | right resetiosflags scientific setbase setfill setiosflags setprecision
       | showbase showpoint showpos skipws unitbuf nouppercase uppercase ws

>>69
Nothing, that's not a char.

C/C++    | Lisp
---------|---------------------------------------------------
vfprintf | format write prin1 princ print pprint
         | copy-pprint-dispatch formatter pprint-dispatch
         | pprint-exit-if-list-exhausted pprint-fill
         | pprint-linear pprint-tabular pprint-indent
         | pprint-logical-block pprint-newline pprint-pop
         | pprint-tab print-object print-unreadable-object
         | set-print-dispatch write-to-string prin1-to-string
         | princ-to-string *print-array* *print-base*
         | *print-radix* *print-case* *print-circle*
         | *print-escape* *print-gensym* *print-level*
         | *print-length* *print-lines* *print-miser-width*
         | *print-pprint-dispatch* *print-pretty*
         | *print-readably* *print-right-margin*
         | print-not-readable print-not-readable-object

>>70,72
oh lol

(display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline) (display) (newline)

Whoa, this is becoming a well-done steak of stupidity. Now I feel like I could do some shitposting.

>>75
go play with your toys, kiddo; you'll never amount to anything remarkable

>>67
the only thing simple about lisp is its translation to an abstract syntax tree. The overall language and implementation is incredibly complicated. You are talking about syntax, which is really language independent. One could make a sexp to c compiler very easily. It is just another encoding of the abstract syntax tree.

>>69

Well, it is almost a function definition, or it is almost a type declaration. You forgot to add { with code in it } at the end, or a semi colon.

char (*(*x())[])();

x is a function that returns a pointer to an array of pointers to functions that return char.

x() is a pointer to an array of pointers to functions that return char.

x()[n] is a pointer to a function that returns char.

x()[n]() is a char.

This syntax is useful for keeping track of types. You may say that keeping track of types in code is complex, but there are types, no matter how you look at it. Values at run time will have types, and if the types are not documented in the code, then you have to keep track of the types in your head, which I find more complex.

>>77
Values at runtime will have types...
0x4004e4

>>72
Use modern Lisp already.

>>77
The overall language and implementation is incredibly complicated.
Yeah!
http://mitpress.mit.edu/sicp/full-text/sicp/book/node77.html

(define (eval exp env)
  (cond ((self-evaluating? exp) exp)
        ((variable? exp) (lookup-variable-value exp env))
        ((quoted? exp) (text-of-quotation exp))
        ((assignment? exp) (eval-assignment exp env))
        ((definition? exp) (eval-definition exp env))
        ((if? exp) (eval-if exp env))
        ((lambda? exp)
         (make-procedure (lambda-parameters exp)
                         (lambda-body exp)
                         env))
        ((begin? exp)
         (eval-sequence (begin-actions exp) env))
        ((cond? exp) (eval (cond->if exp) env))
        ((application? exp)
         (apply (eval (operator exp) env)
                (list-of-values (operands exp) env)))
        (else
         (error "Unknown expression type - EVAL" exp))))

>>80
You have no idea what you're talking about.
That's akin to saying that diff is trivial to implement because you can just do this:
#include <unistd.h>

int main(int argc, char* argv[])
{
  (void) argc;
  execvp("diff", argv);

  return -1;
}

>>81
>>80 implements evaluator, your code just calls already present evaluator.

>>82
execvp("diff", argv) is the implementation of a diff evaluator.

>>81
Here's the eval/apply for a Scheme interpreter I wrote in C. The whole thing is about 1600 lines of code. More than half the code is just primitive procedure definitions, so the core is less than 800 lines.

object *eval(object *exp, object *env) {
    object *seq, *var, *val, *proc, *args;

    while (!is_self_evaluating(exp)) {
        if (is_variable(exp))
            return lookup_variable_value(exp, env);
        if (is_quoted(exp)) {
            return cadr(exp);
        } else if (is_quasiquoted(exp)) {
            return eval_quasiquote(cadr(exp), env);
        } else if (is_delay(exp)) {
            return compound(cons(nil, cdr(exp)), env);
        } else if (is_lambda(exp)) {
            return compound(cdr(exp), env);
        } else if (is_definition(exp)) {
            seq = cdr(exp);
            if (is_symbol(car(seq))) {
                return define_variable(car(seq), eval(cadr(seq), env), env);
            } else {
                var = caar(seq);
                val = make_lambda(cdar(seq), cdr(seq));
                exp = cons(car(exp), cons(var, cons(val, nil)));
            }
        } else if (is_assignment(exp)) {
            return set_variable_value(cadr(exp), eval(caddr(exp), env), env);
        } else if (is_if(exp)) {
            if (is_true(eval(cadr(exp), env)))
                exp = caddr(exp);
            else if (cdddr(exp))
                exp = cadddr(exp);
            else
                return boolean(false);
        } else if (is_cond(exp)) {
            for (seq = cdr(exp); seq; seq = cdr(seq))
                if (is_tagged_list(car(seq), "else") ||
                    is_true(eval(caar(seq), env))) {
                    for (seq = cdar(seq); cdr(seq); seq = cdr(seq))
                        eval(car(seq), env);
                    break;
                }
            if (!seq)
                return boolean(false);
            exp = car(seq);
        } else if (is_case(exp)) {
            val = eval(cadr(exp), env);
            for (exp = cddr(exp); exp; exp = cdr(exp))
                for (seq = caar(exp); seq; seq = cdr(seq))
                    if (is_eq(seq, symbol("else")) || is_eqv(car(seq), val)) {
                        for (seq = cdar(exp); cdr(seq); seq = cdr(seq))
                            eval(car(seq), env);
                        break;
                    }
            if (!seq)
                return boolean(false);
            exp = car(seq);
        } else if (is_begin(exp)) {
            for (seq = cdr(exp); seq && cdr(seq); seq = cdr(seq))
                eval(car(seq), env);
            if (!seq)
                return nil;
            exp = car(seq);
        } else if (is_and(exp)) {
            for (seq = cdr(exp); seq && cdr(seq); seq = cdr(seq))
                if (is_false(eval(car(seq), env)))
                    return boolean(false);
            if (!seq)
                return boolean(true);
            exp = car(seq);
        } else if (is_or(exp)) {
            for (seq = cdr(exp); seq && cdr(seq); seq = cdr(seq))
                if (is_true(val = eval(car(seq), env)))
                    return val;
            if (!seq)
                return boolean(false);
            exp = car(seq);
        } else if (is_let(exp)) {
            var = val = nil;
            for (seq = cadr(exp); seq; seq = cdr(seq)) {
                var = cons(caar(seq), var);
                val = cons(eval(cadar(seq), env), val);
            }
            env = extend_environment(var, val, env);
            for (seq = cddr(exp); cdr(seq); seq = cdr(seq))
                eval(car(seq), env);
            exp = car(seq);
        } else if (is_let_star(exp)) {
            env = environment(env);
            for (seq = cadr(exp); seq; seq = cdr(seq))
                append_variable(caar(seq), eval(cadar(seq), env), env);
            for (seq = cddr(exp); cdr(seq); seq = cdr(seq))
                eval(car(seq), env);
            exp = car(seq);
        } else if (is_application(exp)) {
            proc = eval(car(exp), env);
            args = list_of_values(cdr(exp), env);
            if (is_compound(proc)) {
                seq = to_compound(proc).proc;
                env = to_compound(proc).env;
                env = extend_environment(car(seq), args, env);
                for (seq = cdr(seq); seq && cdr(seq); seq = cdr(seq))
                    eval(car(seq), env);
                exp = car(seq);
            } else if (is_primitive(proc)) {
                return to_primitive(proc)(args);
            } else {
                error("apply", "not applicable", proc);
            }
        } else {
            error("eval", "unknown expression type", exp);
        }
    }
    return exp;
}

>>83
http://www.kernel.org/pub/linux/kernel/v3.0/testing/linux-3.3-rc5.tar.bz2 is the implementation of a Unix OS.

>>84
Now write an eval/apply for C++ interpreter.

>>84
I should also mention that this is tail call optimized. I could have wrote it as a simple, modularized dispatch exactly like in SICP if I wanted to disregard proper tail calls.

>>84
Please,, friend,, if you”re going to write an interpreter,, do it in Lisp,, not C. Heil Hitler.

>>88
omg so edgy.

>>21
also
http://codepad.org/naAWc2vt
Terrible!

If it ain't Lisp, it's crap.

>>90
setmetatable({ }, { __index
is that Perl?

>>2
No, Perl would look like %{}{^{(&}$^{}}}*}

Moar liek LuaSHIT, amirite gaiz!?

>>94
no that would be javascript

>>95
no that would be javashit

>>96
no that would be shavajit

gc is jit

>>94
Speaking of which, Lisp is fucking shit.

javascript would own this bitch, ``midget scrubbing faggots''

>>100
nice dubs bro