Sounds like this may subvert Greenspun's Tenth Rule:
"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."
Learn C and build your own Lisp
101–110 of 150 posts
Re: Learn C and build your own Lisp
#102I've already programmed quite a bit of C and C++, and this seems like a great read + resource. I'd be curious to know how a non-developer or somebody coming from something like Ruby or Python that had never developed C felt about this.
Re: Learn C and build your own Lisp
#103At my undergrad institution, we have a class that does a project very similar to this. I recently completed the class and project and have a bit of advice for anyone looking to take up this challenge on their own.
First off, a small note: our project used C to implement Scheme (a lisp dialect), so it's similar but not exactly the same as this.
I'd recommend starting off with reading about the principles and coming up with a solution to each of the problems on your own instead of following a specific pattern as outlined in the book. For example, in our project, we decided to learn about the C basics, then just figure out how to make it 'act' like Scheme if given an input. Eventually, we thought of doing everything in a linked-list style to make organization and recursion easier and more natural, but coming to this conclusion on our own was very helpful.
Another thing is valgrind. As far as I could find, the text only mentions valgrind in one paragraph, but it's an excellent tool to check for memory leaks and errors.
Also, as mentioned in the book, a bonus is adding in GC. This turns out to be a pretty easy and a fun exploration of the different techniques available if you try a couple out for performance.
Our code in case you're interested: https://bitbucket.org/adamcanady/cs251_interpreter/src
Re: Learn C and build your own Lisp
#104In the last chapter, Bonus Projects, the author mentions Static Typing & type systems. If anyone's interested in learning more: I've implemented a few simple implementations of basic (and not so basic) type systems[1]. Currently, only 3 type systems are finished (Hindley Milner's Algorithm W, and Daan Leijen's extensible rows and first-class polymorphism), while gradual typing is almost done (based on [2], in branch…
Thanks for that paper, I'm currently designing a language and I'm wondering if I should use static or gradual typing. I'm currently doing static, but I want to investigate gradual. Anyway thanks! And I'll check out your code too...
Re: Learn C and build your own Lisp
#105If you are interested in this, you may find one of my Lisp implementation interesting too. It's implemented less than 1k lines of heavily-commented C, but it even supports a macro system and copying GC in addition to the common features you would usually see in small Lisps.
Re: Learn C and build your own Lisp
#106> Cat • cannot speak or program
A caption for a picture from chapter 5, preceding a look at the grammar of Doge - DogeLisp anyone?
Re: Learn C and build your own Lisp
#107Earlier quoted context omitted.
I agree with everything, though the idea of least cognitive load I think only runs skin deep (syntax). This helpful for small scripts which need to be scanned quickly, but anything non-trivial will already have a significant layer of abstraction which takes time to parse. Lisp people love their macros. Clojure has fancy data structures and control flow. It will take time to understand these things whether its in lisp…
> the idea of least cognitive load I think only runs skin deep (syntax) Perhaps... I'm not aware of any empirical study into the matter so my claim is mere speculation. There are, for example, plenty of highly productive Perl and Haskell programmers. Those languages are notorious for the gobs of arcane syntax. And yet their proponents claim it's an advantage. "Cognitive load," in my case refers to the amount of infor…
> There are, for example, plenty of highly productive Perl and Haskell programmers. Those languages are notorious for the gobs of arcane syntax.
I don't see anything arcane about Haskell's syntax. There are no surprises in vanilla\* Haskell syntax - no cruft in the syntax of expressions, no complicated syntactic sugar, you can see what is and isn't an infix function at a glance, same with type constructors (capital letters), etc.
What might be arcane is some peoples use of user-defined infix operators. But I don't know if I would lump that in with ''Haskell's syntax'', since that isn't part of the grammar of the language. But YMV.
\* I can't speak for GHC extensions or template Haskell
Re: Learn C and build your own Lisp
#108Re: Learn C and build your own Lisp
#109If you're interested in this, you might also enjoy "Write yourself a Scheme in 48 hours." It uses Haskell rather than C as the implementation language. https://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_...
WYASI48 is mentioned as an inspiration somewhere IIRC
Re: Learn C and build your own Lisp
#110Does it use a generator to generate lexer and parser or author is suggesting to write them manually?
Author here. A parser combinator library is used to do the parsing.
My one criticism is that it's a fairly big leap from learning C from ground zero to being a client of a complex, high-level library like mpc. I feel like the moment you hit the call to mpca_lang, anyone who really was learning C at the beginning shifted from "learning C" mode to "copy and paste C code I don't understand" mode.