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?
Robpike/Lisp: Toy Lisp 1.5 interpreter in Go
31–40 of 73 posts
Re: Robpike/Lisp: Toy Lisp 1.5 interpreter in Go
#32I hope one day when I grow old I get to engage in fun pasttimes like what Rob did.
Re: Robpike/Lisp: Toy Lisp 1.5 interpreter in Go
#33It 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?
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
#34GOMODULE111, who needs it? :)
Re: Robpike/Lisp: Toy Lisp 1.5 interpreter in Go
#35He mentions "pedagogical" and "teaching tool". Who is he teaching? I would love to be his student.
Re: Robpike/Lisp: Toy Lisp 1.5 interpreter in Go
#36Re: Robpike/Lisp: Toy Lisp 1.5 interpreter in Go
#37 // 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
#38Earlier 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.
The idea seems pretty damn intriguing.
Re: Robpike/Lisp: Toy Lisp 1.5 interpreter in Go
#39Earlier 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?
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.