Señor program

what should i do for it?

Danmaku.

LISP interpreter with TAIL CALL OPTIMIZATION! and ENTERPRISE CLOSURES!

>>3
something that is not a grand challenge problem

Uh, what? It's not that difficult. Lisp is easy to parse, and there are plenty of articles that show how to do trampolining for tail calls and supporting closures.

Unless I am misunderstanding what ``grand challenge problem'' means.

Create a COBOL 85 with unification and backtracking.

>>6

beautiful

>>4
If you can't write a simple interpreter for a simple language, then you're an uneducated idiot, who doesn't know how his computer works.

>>8
it isn't the language that is hard, it's the virtual machine/byte code compiler/native code compiler, sporting enough features and a sufficiently large standard library to mean the common lisp specification. The fact that you don't understand this shows that you have never thought about the implementation of the backend of a high level language before.

just make a board game

Senor dubs!

>>9
An interpreter isn't the sane thing as a virtual machine. Geeze, maybe you should pratice what you preach, and like, think about the implementation.

>>12
*isn't the same thing*

sgfdsgfdsgfd

>>12

yeah, they aren't necessarily the same thing. But interpreters are often implemented as byte code compilers which dynamically compile code to byte code and then execute the byte code on the virtual machine. It doesn't need to be that way, but it can be difficult to efficiently run the code without first converting it to an intermediate representation.


>>4

how about a light cycle game with an unbeatable ai?

>>8
I'd say implementing a lisp isn't particularly simple at all and theres a reason mainly post grads make them, the parser is easy though. Implementing a lisp entails that it supports some type of macro system and perhaps closures, more importantly function definitions, but the biggest hurdle I think is that since Lisp doesn't have statements, structures and divisions but just forms everything has to fit together in the big tao of the language, the semantics can't be band-aided for this and that statement, everything has to fit.

Implementing BASIC is simpler just by the expectations of what it will be capable of, its syntax isn't particularly hard and can be parsed a line at a time (Altair BASIC simply tokenized words as they were entered by keystroke using a simple FSM, and executed them just by reading the tokens from left to right until the EOL token with a subsequent address to jump to, at run time), and semantics can be rough and stupid but they'll be isolated to every statement.

Also, Forth is arguably simpler for a statement-less language as the evaluation model is simpler.

>>16

yeah, the stack based languages would have a trivial translation to a stack based byte code. One would just need to implement the byte code interpreter. Although some parsing would be needed for extracting the subroutine definitions and storing them as arrays of byte code instructions.