Live data from Hacker News

Robpike/Lisp: Toy Lisp 1.5 interpreter in Go

github.com

31–40 of 73 posts

Re: Robpike/Lisp: Toy Lisp 1.5 interpreter in Go

#31
post #24

Earlier quoted context omitted.

Dyalog is an APL vendor, they also offer a non-commercial license and high quality documentation. They have a case study of a school management system that is a record keeping system [0]. [0] https://www.dyalog.com/case-studies/education.htm

Thanks! Btw, what would be the open source alternative (of APL) that is popular and used in production?

There is a GNU implementation of APL (https://www.gnu.org/software/apl/). Not sure if it is used in commercial applications or not. I would imagine that if you are doing commercial work with APL you are going to be paying for Dyalog.

Re: Robpike/Lisp: Toy Lisp 1.5 interpreter in Go

#32
post #7

I hope one day when I grow old I get to engage in fun pasttimes like what Rob did.

A few weeks ago, I went through "Make a Lisp" [1] using C#. It only took a few days to get to a pretty useful implementation. I "cheated" quite a bit using the existing C# implementation from the repo as a reference, but my end result looks pretty different. Learned a TON. Highly recommended.

[1] https://github.com/kanaka/mal

Re: Robpike/Lisp: Toy Lisp 1.5 interpreter in Go

#33
post #14

It is a pedagogical experiment to see just how well the interpreter (actually EVALQOUTE/APPLY) defined on page 13 of that book really works. The answer is: perfectly, of course. Well timed! I've just been trying this out myself after reading Maxwell's Equations of Software [1]. It's fun realising that the "base" functions you're doing in Go can be reduced to even more fundamental forms using the Lisp you're implement…

Well-timed for you, but Pike could have benefited from doing this experimentation forty years earlier. Who knows where he would be now?

It's not like this is Pike's first contact with Lisp, he wrote an APL interpreter in it: https://www.youtube.com/watch?v=PXoG0WX0r_E

Note, that's not the topic of the talk, it's just mentioned in it.

Re: Robpike/Lisp: Toy Lisp 1.5 interpreter in Go

#36
post #35

He mentions "pedagogical" and "teaching tool". Who is he teaching? I would love to be his student.

I read that more in a context of "teaching oneself". However, I think he's at google atm: http://herpolhode.com/rob/

I thought that maybe he is teaching Google employees.

Re: Robpike/Lisp: Toy Lisp 1.5 interpreter in Go

#37
Interesting: https://github.com/robpike/lisp/blob/master/lisp1_5/parse.go...

    // Expr represents an arbitrary expression.
    type Expr struct {
        // An Expr is either an atom, with atom set, or a list, with car and cdr set.
        // Car and cdr can be nil (empty) even if atom is nil.
        car  *Expr
        atom *token
        cdr  *Expr
    }
Instead of using interface types for expressions, there is a simple expression structure type with fields that may or may not be set depending on what type of value it is.

I probably never would have done it that way, I would probably use an interface type instead. This way actually saves space in cons objects… in the above version, a cons is 24 bytes, and below it would be 32:

    type Expr interface { }
    type Cons struct { car, cdr Expr }
Not efficient compared to modern Lisp interpretations, but an interesting choice.

Re: Robpike/Lisp: Toy Lisp 1.5 interpreter in Go

#38
post #3

Earlier quoted context omitted.

Personally, I find that one much more interesting. Before I was familiar with array languages, I hoped that functional programming and lisp would become the new zeitgeist of software development. Now, I think that array languages have the most promise in revolutionizing the discipline. While it probably wont happen, I wouldn't complain if array languages became the defacto norm for most new applications.

I always get the feeling that a lot of languages would be well served by having an APL or prolog implementation added as a library or macro; this would let teams leverage these tools down in the core of their application without having to compromise on how they create APIs. Closest I’ve seen to this was core.logic in the Clojure community, but it appears to be dead.

Something like this? http://shenlanguage.org/

The idea seems pretty damn intriguing.

Re: Robpike/Lisp: Toy Lisp 1.5 interpreter in Go

#39
post #4
post #3

Earlier quoted context omitted.

Personally, I find that one much more interesting. Before I was familiar with array languages, I hoped that functional programming and lisp would become the new zeitgeist of software development. Now, I think that array languages have the most promise in revolutionizing the discipline. While it probably wont happen, I wouldn't complain if array languages became the defacto norm for most new applications.

Is it a deeper rabbit hole than FP? Could you give some links or good array language names?

If you want something in between, i'd suggest Julia, which has taken a lot of array programming concepts and ported them into a functional language, so you can get the ideas without going so far down the rabbit hole that everything is an array.

The problem though might be that those ideas (like Julia's broadcast) are so seamlessly integrated into it's functional paradigm that you won't "really" know which parts are parts where you've been tricked into doing array programming.

Re: Robpike/Lisp: Toy Lisp 1.5 interpreter in Go

#40
post #35

Earlier quoted context omitted.

I read that more in a context of "teaching oneself". However, I think he's at google atm: http://herpolhode.com/rob/

I thought that maybe he is teaching Google employees.

I'm pretty sure it's a small project to teach himself.
Post reply on HN