Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Crafting Interpreters: Closures

craftinginterpreters.com

Post reply on HN
Print view View original

41–50 of 62 posts

Re: Crafting Interpreters: Closures

#41

Post by ufo »

Sniffnoy wrote: post #38

So, there's one thing here that strikes me as really weird. And I think it's best summed up at the end, where it discusses closing over a loop variable. It discusses how if you close over a loop variable, people expect that each function created will get a different value of the variable, even though there's only one variable, and closures close over variables, not values. It treats this as a special case. But to my…

This mechanism that you suggest about copying values is how Lua used to work before version 5.0, when they came up with the current upvalue mechanism.

Re: Crafting Interpreters: Closures

#42

Post by FreeFull »

chrisseaton wrote: post #39
Sniffnoy wrote: post #38

So, there's one thing here that strikes me as really weird. And I think it's best summed up at the end, where it discusses closing over a loop variable. It discusses how if you close over a loop variable, people expect that each function created will get a different value of the variable, even though there's only one variable, and closures close over variables, not values. It treats this as a special case. But to my…

I think some languages let you choose to capture variables or values - does C++ do that?

C++ and Rust do let you capture by value. Here is a Rust example that outputs exactly what you would naively expect.

    fn main() {
        let mut x = 1;
        let f = move || println!("{}", x);
        x = 2;
        let g = move || println!("{}", x);
        f();
        g();
    }

Re: Crafting Interpreters: Closures

#43

Post by munificent »

mrspeaker wrote: post #28
munificent wrote: post #10

Author here! Happy to answer questions, accept criticism, etc. :)

Do you have the back cover ready for this book? The back of Game Programming Patterns makes me happy every time I see it.

Ha, this has definitely come up for discussion.

My original plan was to have a photo with me and both of my dogs with the implication that each later book must feature yet another additional dog.

Unfortunately, Ginny, the dog in the photo on the back of Game Programming Patterns died earlier this year. (This makes it even more meaningful to me that she is immortalized on the book. You'd be surprised how many strangers have asked me about her.)

So, I don't have any firm plans, but I might just try to do a new photo with me and my other dog, Benny. He's getting pretty old too, though, so I guess the pressure is on for me to finish the book.

Re: Crafting Interpreters: Closures

#44

Post by mindv0rtex »

beardface wrote: post #9
whoback wrote: post #3

Earlier quoted context omitted.

Any more gems like this you would recommend?

This is a great introduction to writing an interpreter if you know, or are learning, Go: https://interpreterbook.com/ There's a follow-up as well: https://compilerbook.com/

Wish there were more books like this for other languages... I like learning programming languages, but between a job and a family, with 30 mins in the evening to myself until I'm totally brain dead, I can't write any code myself that's not job related. Books like these let me learn and experience new languages vicariously.

Re: Crafting Interpreters: Closures

#45

Post by Gibbon1 »

chrisseaton wrote: post #39
Sniffnoy wrote: post #38

So, there's one thing here that strikes me as really weird. And I think it's best summed up at the end, where it discusses closing over a loop variable. It discusses how if you close over a loop variable, people expect that each function created will get a different value of the variable, even though there's only one variable, and closures close over variables, not values. It treats this as a special case. But to my…

I think some languages let you choose to capture variables or values - does C++ do that?

Sort of related with gcc's nested function extension, you can reference variables that in scope when the function is defined. If you pass a pointer to the nested function is can access those variables (via a trampoline on the stack).

To me that's been very useful to have both to get around not being able to use malloc.

Meaning I think it's a good idea actually.

Re: Crafting Interpreters: Closures

#46

Post by koonsolo »

rhencke wrote: post #2

This is one of my favorite books(-in-progress) to follow along with. If you've ever even had a passing curiosity in how interpreters work, I highly recommend checking it out from the beginning: http://craftinginterpreters.com/welcome.html The writing is charming and approachable, while still packed with an impressive amount of knowledge.

> The writing is charming and approachable, while still packed with an impressive amount of knowledge.

It's actually the best technical writing I have ever seen, and I have read a lot. He can explain a complex thing really easy, and bring it very personally, as if he's a good, relaxed and funny friend explaining things.

Re: Crafting Interpreters: Closures

#47

Post by tempguy9999 »

vanderZwan wrote: post #26
munificent wrote: post #25

Earlier quoted context omitted.

Yes. I love this book. At a practical level, it's pretty (very) outdated. It talks about things like sorting when your data is stored on tape. But it's just a beautiful, succinct book. If you get tired of how messy, fast-moving, and chaotic a lot of software development can be, it's a delightful respite. It cleanses and orders the mind.

From what I have read about Wirth his way of thinking is the computer science equivalent of Bauhaus minimalism. Which oddly enough doesn't appeal to me in the design of everyday things all that much (I can definitely respect it though), but feels very fitting for computer science.

Wirth's minimalism is, IMO, driven by some semi- or full understanding of formal semantics, wherein simplicity is essential to correctness in implementation of the language (as the language designer), and essential to the correct use of the language (as a programmer). This is my opinion formed from what I read so beware.

C.A.R. Hoare has excellent stuff to say on this and hardware design - here's his 1982 turing award lecture https://dl.acm.org/ft_gateway.cfm?id=1283936&type=pdf and it's well worth reading (quite short).

Extracts:

" [...]in May 1965, Niklaus Wirth was com- missioned to collate them into a single language design [the successor to algol 60]. I was delighted by his draft design which avoided all the known defects of ALGOL 60 and included several new features, all of which could be simply and efficiently implemented, and safely and conveniently used.

The description of the language was not yet complete. I worked hard on making suggestions for its improve- ment and so did many other members of our group. By the time of the next meeting in St. Pierre de Chartreuse, France in October 1965, we had a draft of an excellent and realistic language design which was published in June 1966 as "A Contribution to the Development of ALGOL", in the Communications of the A CM. It was implemented on the IBM 360 and given the title ALGOL W by its many happy users. It was not only a worthy successor of ALGOL 60, it was even a worthy predecessor of PASCAL."

But people wanted as much as possible in so instead...

"Three months came and went--not a word of the new draft appeared. After six months, in October 1966, the ALGOL working group met in Warsaw. It had before it an even longer and thicker document, full of errors corrected at the last minute, describing equally obscurely yet another different, and to me, equally unattractive language. The experts in the group could not see the defects of the design and they firmly resolved to adopt the draft, believing it would be completed in three months. In vain, I told them it would not. In vain, I urged them to remove some of the technical mistakes of the language, the predominance of references, the default type conversions. Far from wishing to simplify the lan- guage, the working group actually asked the authors to include even more complex features like overloading of operators and concurrency."

[...]

"At last, in December 1968, in a mood of black depression, I attended the meeting in Munich at which our long-gestated monster was to come to birth and receive the name ALGOL 68." [Edit: added this para]

I think Wirth (or Hoare?) said algol 60 was an improvement algol 68. [Sentence edited]

He then goes on to describe the creation of PL/1 which is an even worse experience.

Anyway, the whole paper's well worth reading. It has a lot of good stuff and is only 9 sides long.

Re: Crafting Interpreters: Closures

#48

Post by munificent »

koonsolo wrote: post #46
rhencke wrote: post #2

This is one of my favorite books(-in-progress) to follow along with. If you've ever even had a passing curiosity in how interpreters work, I highly recommend checking it out from the beginning: http://craftinginterpreters.com/welcome.html The writing is charming and approachable, while still packed with an impressive amount of knowledge.

> The writing is charming and approachable, while still packed with an impressive amount of knowledge. It's actually the best technical writing I have ever seen, and I have read a lot. He can explain a complex thing really easy, and bring it very personally, as if he's a good, relaxed and funny friend explaining things.

Thank you! :D

Re: Crafting Interpreters: Closures

#50

Post by markdog12 »

koonsolo wrote: post #46
rhencke wrote: post #2

This is one of my favorite books(-in-progress) to follow along with. If you've ever even had a passing curiosity in how interpreters work, I highly recommend checking it out from the beginning: http://craftinginterpreters.com/welcome.html The writing is charming and approachable, while still packed with an impressive amount of knowledge.

> The writing is charming and approachable, while still packed with an impressive amount of knowledge. It's actually the best technical writing I have ever seen, and I have read a lot. He can explain a complex thing really easy, and bring it very personally, as if he's a good, relaxed and funny friend explaining things.

Then you should check his book on game programming patterns:

http://gameprogrammingpatterns.com/index.html

Post reply on HN