This is MUCH more than a 'Build Your Own Lisp'. To the point of almost being anything but.
This is an amazing resource for getting started with learning C by making your own "programming language", independent of any Lisp conventions.
For me, the most 'lispy' aspect of 'making your own lisp' is prebaked by the author with their using their own prebuilt parser library 'mpc'. (I was unable to find a link to the source in the book, so https://github.com/orangeduck/mpc )
I was unable to find any instance of 'car' or 'cdr' or 'caddar' and their like, which I feel is the real 'build your own lisp' epiphany.
The parser is so widely, and wildly, useful that it is independent of notation style, for instance, lisp's nearly ubiquitous 'polish notation'. (or its variants, for instance, 'cambridge polish notation')
Perfect example:
Under 'Chapter 9: Reading Expressions':
> Don't Lisps use Cons cells?
> Other Lisps have a slightly different definition of what an S-Expression is. In most other Lisps S-Expressions are defined inductively as either an atom such as a symbol of number, or two other S-Expressions joined, or cons, together.
> This naturally leads to an implementation using linked lists, a different data structure to the one we are using. I choose to represent S-Expressions as a variable sized array in this book for the purposes of simplicity, but it is important to be aware that the official definition, and typical implementation are both subtly different.
Unfortunately, part of the pragmatic usefulness of newer Lisps (Clojure and Janet) is the abandonment of CAR and CDR in favor of efficient distinct data structure types backed by efficient bases (tries, arrays, arraylists, hashmaps) and a focus on homoiconicity as the winning feature, separated forcefully from the idea of linked lists and CAR/CDR.
I'm honestly not sure why this sentence starts with "unfortunately".
Linked lists are comically inefficient on modern hardware and naming two of your fundamental operations based on CPU instructions from a chip from the 60s is not what I would call good API design.
1954, actually. But it's a minor thing. You don't need to know anything about the IBM 704 to write Lisp. A cons cell is a specific data structure and its components have specific, if unusual names. There's a lot of unintuitively named symbols in Lisp that are better targets for criticism than car and cdr.
From a compute standpoint I guess I'm wrong. But from a modeling power perspective, I definitely prefer the clarity and uniformity of Clojure's standard library functions. Maybe that has something to do with its distinct data types, maybe not.
Data structure types. In standard CL and Scheme, data structures are implemented at their base using cons cells, and their interpretation as tables, trees, queues, etc. is up to library functions. Unless I have somehow misinterpreted the selling points of classic Lisps, because Clojure and Janet data structures sell themselves as being not built this way. Clojure makes a different trade-off by building all its data structures off of hash array-mapped tries. But Janet goes out of its way to use efficient and closely-mapped base stores, even if the contained elements are dynamic Janet objects.
> In standard CL and Scheme, data structures are implemented at their base using cons cells
That's not true. Both CL and Scheme have other data structures besides cons cells, and that's been true for the Lisp family of languages for nearly 70 years now.
This bizarre belief that everything is a cons cell in Lisp and Scheme needs to go away.
For someone who initiated hostility, you're a dismal failure at supporting your arguments. I'm not reading two entire manuals to find the citations you're referring to and should've cited yourself.
> I'm not reading two entire manuals to find the citations you're referring to and should've cited yourself.
C-f that PDF for "array". For the other manual, I linked the TOC. It's right there on the page (arrays and hash tables, and you can follow up with structures and objects) and there's no reason to read the entire manual. I figured most people knew how to use a table of contents, I apologize if I expected too much from you.
Ok, so I am sorry but this is an extremely uninformed take. Please have a look around in Racket's documentation before going any further: https://docs.racket-lang.org/
> efficient distinct data structure types backed by efficient bases
...do not require abandoning CAR and CDR, I think. See all other lisps having vectors, hashmaps, etc. Perhaps you're talking for code representation ? But I don't think that true for all 'traditional' lisps either. Also, there's been some innovation regarding lists: https://docs.racket-lang.org/reference/treelist.html
This is an amazing resource for getting started with learning C by making your own "programming language", independent of any Lisp conventions.
For me, the most 'lispy' aspect of 'making your own lisp' is prebaked by the author with their using their own prebuilt parser library 'mpc'. (I was unable to find a link to the source in the book, so https://github.com/orangeduck/mpc )
I was unable to find any instance of 'car' or 'cdr' or 'caddar' and their like, which I feel is the real 'build your own lisp' epiphany.
https://en.wikipedia.org/wiki/CAR_and_CDR
The parser is so widely, and wildly, useful that it is independent of notation style, for instance, lisp's nearly ubiquitous 'polish notation'. (or its variants, for instance, 'cambridge polish notation')
Perfect example:
Under 'Chapter 9: Reading Expressions':
> Don't Lisps use Cons cells?
> Other Lisps have a slightly different definition of what an S-Expression is. In most other Lisps S-Expressions are defined inductively as either an atom such as a symbol of number, or two other S-Expressions joined, or cons, together.
> This naturally leads to an implementation using linked lists, a different data structure to the one we are using. I choose to represent S-Expressions as a variable sized array in this book for the purposes of simplicity, but it is important to be aware that the official definition, and typical implementation are both subtly different.
https://www.buildyourownlisp.com/chapter9_s_expressions#Read...
This is an awesome educational resource.
I think I would promote it more broadly than "Build Your Own Lisp".