Live data from Hacker News

Mal – Make a Lisp, in 68 languages

github.com

61–70 of 74 posts

Re: Mal – Make a Lisp, in 68 languages

#61
post #44

Earlier quoted context omitted.

You climed in the wrong direction. What you want is assembly. That's where software ends up. Also, it's interpreters all the way down. Even assembly is interpreted.

>Also, it's interpreters all the way down. Even assembly is interpreted. Speak truth to power. Every time someone says this there seem to be nothing but haters.

> Every time someone says this there seem to be nothing but haters.

Because it's not completely true. If a CPU is microcoded, then it's accurate to say "assembly is interpreted" because every instruction is effectively an address into a lookup table of microinstructions. But in a non-microcoded (e.g. purely RISC) CPU, the bits of the instruction word are effectively enable and data lines to a bunch of hardware logic gates and flip-flops, which cause register transfers and arithmetic operations to happen. In this case, the ones and zeros in the instruction word are voltage levels on logic gates. Calling the latter "interpretation" is a stretch.

To be fair, there aren't many pure RISC implementations around these days. Most everything has some degree of microcode involved, so to that extent you're right.

Re: Mal – Make a Lisp, in 68 languages

#62
post #44
post #42

Earlier quoted context omitted.

After being a user of languages for a long time, writing my own LISP was the experience of leaving Platons cave and seeing what the thing I use daily really is made of. What is "if"? What is a boolean, a variable, a function? It's a beautiful thing. I wish I would never have to climb down into the cave (languages with more advanced parsers) again.

You climed in the wrong direction. What you want is assembly. That's where software ends up. Also, it's interpreters all the way down. Even assembly is interpreted.

Which might be a Scheme CPU formally derived and verified via LISP-based tech:

https://www.cs.indiana.edu/pub/techreports/TR413.pdf

Or recently this way:

http://scheme2006.cs.uchicago.edu/05-saint-mleux.pdf

Interesting enough, the primitive versions of LISP that aren't high-performance (i.e. advanced compilers) could probably be done by hand in hardware where the whole thing was bootstrapped up with LISP-only tech. The LISP would start/stop at the abstract, state machines or RTL of the bootstrapped version.

EDIT: Good luck on making it through the hurricane. Feel for yall out there.

Re: Mal – Make a Lisp, in 68 languages

#64
post #34

I am curious why is hackernews always so happy and obsessed with lisp, there is almost daily a lisp post on the frontpage. I dont really care/mind but I am just curious as why people love lisp so much. The only thing that I notice about Lisp are the bracket jokes and memes.

> The only thing that I notice about Lisp are the bracket jokes and memes. You have also noticed that lots of people use it to create cool things which reach the HN front page.

Including the front page itself.

Re: Mal – Make a Lisp, in 68 languages

#65
post #44

Earlier quoted context omitted.

You climed in the wrong direction. What you want is assembly. That's where software ends up. Also, it's interpreters all the way down. Even assembly is interpreted.

>Also, it's interpreters all the way down. Even assembly is interpreted. Speak truth to power. Every time someone says this there seem to be nothing but haters.

Not only is machine code interpreted, the so-called "asynchronous interrupts" are just periodically polled for in between the fetching, decoding and executing.

Re: Mal – Make a Lisp, in 68 languages

#66

Earlier quoted context omitted.

>Also, it's interpreters all the way down. Even assembly is interpreted. Speak truth to power. Every time someone says this there seem to be nothing but haters.

> Every time someone says this there seem to be nothing but haters. Because it's not completely true. If a CPU is microcoded, then it's accurate to say "assembly is interpreted" because every instruction is effectively an address into a lookup table of microinstructions. But in a non-microcoded (e.g. purely RISC) CPU, the bits of the instruction word are effectively enable and data lines to a bunch of hardware logic…

It's interpreted because the instructions are fetched one by one. A piano roll is intepreted, even though its holes just activate keys with a "horizontal encoding". It is interpreted because it moves through the piano, and a little piece of it activates a behavior any one time, without leaving a permanent record.

Re: Mal – Make a Lisp, in 68 languages

#67
post #49

Earlier quoted context omitted.

>Even assembly is interpreted. Could you please elaborate on this point? I'm still very much in the cave.

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!)

Re: Mal – Make a Lisp, in 68 languages

#68

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/

Actually you might like stage0 http://git.savannah.nongnu.org/cgit/stage0.git/ It literally goes from a 280byte hex monitor all the way through a compacting garbage collected lisp and FORTH

Without the assumption that any other software exists

Re: Mal – Make a Lisp, in 68 languages

#69
There is another Lisp implemented in 42 languages (including Ceylon, Dylan, Oz, Pike, Scratch, Smalltalk, SML etc.):

https://github.com/zick/ZickStandardLisp

The benchmark results of 42 implementations are very impressive:

http://blog.bugyo.tk/lyrical/wp-content/uploads/2014/12/stag... http://blog.bugyo.tk/lyrical/wp-content/uploads/2014/12/stag... http://blog.bugyo.tk/lyrical/wp-content/uploads/2014/12/stag...

which are discussed in Japanese at:

http://blog.bugyo.tk/lyrical/archives/2024

Re: Mal – Make a Lisp, in 68 languages

#70
post #9

Earlier quoted context omitted.

This could be made massively less ugly and more readable by typedef'ing the function pointer types by the way. Then one could just write: case 13: mv->val.f13 = (F13)func; break; As a C programmer I got to say people in general don't use typedef for function pointer types often enough. The types are so ugly and verbose, they should be typedef'ed by default.

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.
Post reply on HN