Mal – Make a Lisp, in 68 languages • Hacker News Board

Re: Mal – Make a Lisp, in 68 languages

#71

Post by spc476 » Wed, Sep 13, 2017, 9:56 PM UTC

omginternets wrote: post #67

spc476 wrote: post #49

Earlier quoted context omitted.

I'll use x86-32 for elaboration [1]. When the CPU sees the byte sequence 0xB8 0x90 0x41 0x5A 0x7B, it has to interpet what those bytes mean. It sees the 0xB8, so then it knows that you are loading the EAX register with an immedate value. The next four bytes (0x90, 0x41, 0x5A, 0x7B) are read and stored into EAX (as 0x7B5A4190, because Intel is little endian). That is the case for all instructions. Each one is interpre…

Gotcha, but then (unless I'm misunderstanding) one of these interpreters is not like the other. Namely, assembly 'interpretation' happens on bare metal. Were you previously suggesting that understanding a lisp interpreter will help in understanding CPU architecture? (Good luck recovering from the hurricane! Keep your head down!)

I was replying more to jospar's post about learning what an 'if' was, what a 'boolean' was, etc. What's an 'if'? Ultimately it's a comparison of two numbers and a transfer of control based upon said comparison. Some architectures that's one instruction, some two.

Re: Mal – Make a Lisp, in 68 languages

#72

Post by kazinator » Wed, Sep 13, 2017, 10:42 PM UTC

gbacon wrote: post #70

kazinator wrote: post #58

Earlier quoted context omitted.

This code could take advantage of the fact that the type is a union. One can bend the rules of prim-and-proper well-defined ISO C just a little bit and assign to the simplest function pointer, taking advantage of all function pointers having the same representation on every machine known to mortal hacker, and all being overlaid by the union. Thus all the cases collapse down to this: mv->val.u.f0 = (void (*)(void)) fu…

I can respect the author taking the trouble to avoid undefined behavior. Technically correct is the best kind of correct.

That sort of love affair with ISO gospel lands on the rocks as soon as your Lisp stuffs a couple of tag bits into a C pointer.

Re: Mal – Make a Lisp, in 68 languages

#73

Post by earenndil » Thu, Sep 14, 2017, 3:08 AM UTC

sassy_samurai wrote: post #25

There is a similar project called "Build Your Own Lisp"[0] (BYOL), which is a book that walks one through making a Lisp in C. Has anybody here done BYOL? How does it compare to MAL? If you had to choose one to learn how to create a Lisp, which would you choose? [0]: http://www.buildyourownlisp.com/

I looked at BYOL a while ago, but was turned off by the fact that the author wants you to use his parser. I don't know why, but I didn't like that. I feel like there's value in using a pre-existing, widely-used parser like yacc/lex, for no other reason than that it already exist and is widely used.

Re: Mal – Make a Lisp, in 68 languages

#74

Post by sassy_samurai » Thu, Sep 14, 2017, 6:44 PM UTC

earenndil wrote: post #73

sassy_samurai wrote: post #25

There is a similar project called "Build Your Own Lisp"[0] (BYOL), which is a book that walks one through making a Lisp in C. Has anybody here done BYOL? How does it compare to MAL? If you had to choose one to learn how to create a Lisp, which would you choose? [0]: http://www.buildyourownlisp.com/

I looked at BYOL a while ago, but was turned off by the fact that the author wants you to use his parser. I don't know why, but I didn't like that. I feel like there's value in using a pre-existing, widely-used parser like yacc/lex, for no other reason than that it already exist and is widely used.

Oh man, that's a bummer. I think one of the great joys in constructing your own compiler or interpreter is making your own lexer and parser. Doesn't using a pre-made lexer/parser kind of defeat the purpose of making your own compiler/interpreter?