Live data from Hacker News

Learn C and build your own Lisp

buildyourownlisp.com

121–130 of 150 posts

Re: Learn C and build your own Lisp

#121
post #5

In 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...

I hope you find it useful. Also, I don't know what kind of language you're designing, but if it's an object oriented language, you might be more interested in some other papers on gradual typing, for example:

[1] J Siek, W Taha - Gradual Typing for Objects - http://www.cs.colorado.edu/~siek/gradual-obj.pdf [2] T Wrigstad, FZ Nardelli, S Lebresne, J Östlund, J Vitek - Integrating Typed and Untyped Code in a Scripting Language - https://www.cs.purdue.edu/homes/jv/pubs/popl10.pdf [3] A Rastogi, A Chaudhuri, B Hosmer - The Ins and Outs of Gradual Type Inference - http://www.cs.umd.edu/~avik/papers/iogti.pdf

Re: Learn C and build your own Lisp

#122
post #68

Earlier quoted context omitted.

In examples, magic numbers are OK. It's in large production systems (that will require tuning, which becomes impossible with "magic numbers") that they're a code smell. I'd much rather, in a small example, see: new int[2048]; than #define TWENTYFORTYEIGHT 2048 new int[TWENTYFORTYEIGHT]; Also, it's generally OK to use a "magic number" if you know that the constant will only be used in that one place, or that there is…

In my experience, aliasing numbers to words has never improved any code in any way whatsoever, and sometimes causes more headaches since numbers are easy and natural to reason about numerically (big surprise...), while values such as TWENTYFORTYEIGHT impose more mental overhead and open you up to typos. It strikes me as a symptom of the "magic numbers are evil witchcraft" religion gone to the extreme. The whole point…

#define M_PI 3.14159265358979323846 is usually nicer than seeing (and possibly mistyping) those digits of pi each time.

Re: Learn C and build your own Lisp

#123
Thank you for writing this and sharing it for the common good. I've been wanting to relearn C since I've switched to Python for work. Hopefully this book will be good practice because I've been wanting to implement a Lisp interpreter on a micro controller for quite sometime. I have plenty of PIC18F4550 micro controllers lying around.

Also, I liked the cat pictures and hope you'll add more of those in the next edition, perhaps.

Re: Learn C and build your own Lisp

#125
post #97

Earlier quoted context omitted.

That would be for libedit: http://thrysoee.dk/editline/

I've installed this, but I still get this error: fatal error: 'editline/history.h' file not found Any advice would be greatly appreciated.

Are you using Mavericks? You need to import the library using #include .

Other problem is that the code won't work with this library. You need to rework it using the following example: http://www.cs.utah.edu/~bigler/code/libedit.html

There's a lot more to set up and tear down when using the Mavericks' editline; it's not so user-friendly for a beginner as the code in the example.

Re: Learn C and build your own Lisp

#126
post #76

Earlier 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…

Enough use of macros means cognitive load for even simple code can be massive though. You can't really know what the result will be, especially if the entire program can be rewritten in some cases by a macro. If you constrain their use enough, sure, you will not run into these problems. But in any language it comes down to cognitive load vs expressiveness, in how you chose to wield it. Generally, more dense code requires more thinking to understand, and the resulting complexity has to do with the underlying structure, rather then the particulars used to represent it.

Re: Learn C and build your own Lisp

#128
post #44

If I decided to work through this, and thought it was really good, I'd be unable to make a donation because I don't dabble in cryptocurrencies. Why not make donating "real" money possible, as well?

It's called "fiat", not "real".

FWIW, cryptocurrencies are far more fiat than dollars. You can pay taxes in dollars, for example, so they're not even a pure fiat currency.

Re: Learn C and build your own Lisp

#130
post #35

This is a good stuff. 4 years ago, I wrote a Lisp in 500 lines of C in one day after finishing SICP. Typing it out did made what I learned more concrete. https://gist.github.com/sanxiyn/523967

It might be easier to understand your program than to learn the language directly.
Post reply on HN