Live data from Hacker News

Writing Your Own Programming Language

github.com

91–95 of 95 posts

Re: Writing Your Own Programming Language

#91
post #20

Earlier quoted context omitted.

Because languages like this map so closely to the AST (as someone else pointed out) you don't need to deal with complexities such as look aheads, regular expressions, and formal syntax definitions (BNFs). I suppose this makes it a good getting started point. Most more complex languages you'd use something like lex and yacc which would add quite a bit more overhead to the tutorial. The danger of these tutorials is the…

> Most more complex languages you'd use something like lex and yacc which would add quite a bit more overhead to the tutorial. Very few production compilers use lex/yacc type parsers, because error handling and recovery is painful. Most end up with hand-written recursive-descent parsers.

I was recently reading http://book.realworldhaskell.org/read/using-parsec.html, which made me think about this very thing. I never liked working with parser generators because they felt so unwieldy, but I wondered if a system like parsec might be extensible enough to simplify the entire process greatly.

Re: Writing Your Own Programming Language

#92
post #20

Earlier quoted context omitted.

> Most more complex languages you'd use something like lex and yacc which would add quite a bit more overhead to the tutorial. Very few production compilers use lex/yacc type parsers, because error handling and recovery is painful. Most end up with hand-written recursive-descent parsers.

I was recently reading http://book.realworldhaskell.org/read/using-parsec.html , which made me think about this very thing. I never liked working with parser generators because they felt so unwieldy, but I wondered if a system like parsec might be extensible enough to simplify the entire process greatly.

Yes, libraries/frameworks like that are certainly easier to work with than generators.

Re: Writing Your Own Programming Language

#93
post #88
post #87

Earlier quoted context omitted.

> Not quite sure what you mean there. The Reader is the thing which reads the many Lisp data structures: lists, symbols, floats, integers, strings, characters, vectors, arrays, structures, ... > Which can be incredibly simple since you only have the persistent global scope and the list local scope, so you only discard data that goes out of scope. There are no references Lisp has references. > Heck, you could probably…

I think you're completely failing to understand my point. https://stackoverflow.com/questions/3482389/how-many-primiti... You only need about 9 primitives and can build the rest from there. You can implement arithmetic as macros and functions, from scratch. >Internally the symbol table is a hash-table in most Lisp implementations. Point me at a language that won't require a symbol table that is not assembler. Really…

> You only need about 9 primitives and can build the rest from there.

You can't practically. No actual Lisp is developed that way. It's mostly without any practical use. It's a theoretical idea from lambda calculus. It is not an implementation technique for Lisp. It's also not special to Lisp, any Functional Programming language can do that. Note also that one does not need macros for that.

In a real Lisp implementation, numbers are not implemented based on functions. Any real-world Lisp implementation will use the facilities of a processor to represent numbers (integers, floats, ...) and to do computation with numbers. Thus numbers are a separate data type with their own operations. Both the data type and the operations will need to be implemented - the basic operations you mentioned won't help. Thus for a real Lisp, you will a) need to implement numbers using the machine facilities and you will need to understand them. For example floating point operations are in Lisp not simpler than in C, C++, Ada, Java, or any other language which provides floating point operations.

Any language which does not provide floating point operations (like an imaginary primitive Lisp) is simpler than a language with floating point operations (like most existing Lisp languages).

So, an imaginary primitive Lisp is simple. But that has no practical implications, since actual Lisp programming languages are not primitive, and thus not simple. See the definitions of popular Lisp dialects.

> You can implement arithmetic as macros and functions, from scratch.

You don't need macros. And no, nobody does that, because it is not practical.

> Point me at a language that won't require a symbol table that is not assembler.

Why?

> Point me at a language that is simpler to implement than LISP and is not assembler. (and maybe not brainfuck)

Forth. Basic. Logo.

> If you have a turing complete language, you can do everything. I don't think you know what a turing-complete language is.

I know what that is. I think you don't know what algorithmic complexity is and what the difference between a linked list and a vector is.

> How nitpicky.

No, it shows you that macros are neither necessary nor sufficient to implement an object system.

> Compared to most other popular languages, it is.

Basic is simpler. Forth is simpler. Logo is simpler.

Re: Writing Your Own Programming Language

#94
post #88
post #87

Earlier quoted context omitted.

> Not quite sure what you mean there. The Reader is the thing which reads the many Lisp data structures: lists, symbols, floats, integers, strings, characters, vectors, arrays, structures, ... > Which can be incredibly simple since you only have the persistent global scope and the list local scope, so you only discard data that goes out of scope. There are no references Lisp has references. > Heck, you could probably…

I think you're completely failing to understand my point. https://stackoverflow.com/questions/3482389/how-many-primiti... You only need about 9 primitives and can build the rest from there. You can implement arithmetic as macros and functions, from scratch. >Internally the symbol table is a hash-table in most Lisp implementations. Point me at a language that won't require a symbol table that is not assembler. Really…

Forth has a minimal set of primitives as well, and an even simpler parser (it's literally "read until next space" and "search a linked list to see if this matches an existing word, otherwise, is this a number?, otherwise, yell")

Re: Writing Your Own Programming Language

#95
post #94
post #88

Earlier quoted context omitted.

I think you're completely failing to understand my point. https://stackoverflow.com/questions/3482389/how-many-primiti... You only need about 9 primitives and can build the rest from there. You can implement arithmetic as macros and functions, from scratch. >Internally the symbol table is a hash-table in most Lisp implementations. Point me at a language that won't require a symbol table that is not assembler. Really…

Forth has a minimal set of primitives as well, and an even simpler parser (it's literally "read until next space" and "search a linked list to see if this matches an existing word, otherwise, is this a number?, otherwise, yell")

And, likewise, the Turing completeness of those primitives doesn't mean what some naive new computer scientists think it means. Turing completeness doesn't mean that those primitives constitute a language which can be extended to become any language; it means that for any given Turing machine, those primitives can be used to write a program which computes the same thing as that Turing machine. That program might be, for instance, a small state machine dispatcher accompanied by a big table with some initial contents. VirtualBox can run an entire PC, and that PC can run an OS, under which we have a C++ compiler. That doesn't mean VirtualBox has been extended to be a C++ language implementation.
Post reply on HN