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

An Exploration of SBCL Internals (2020)

simonsafar.com

Post reply on HN
Print view View original

171–180 of 194 posts

Re: An Exploration of SBCL Internals (2020)

#171

Post by phs2501 »

aidenn0 wrote: post #166
User23 wrote: post #160

Earlier quoted context omitted.

I thought SBCL was a compiler only implementation? CMUCL did have an interpreter though.

It was until someone resurrected the evaluator it inherited from CMUCL

CMUCL's interpreter evaluated IR1 (the first intermediate representation of its compiler) IIRC, so it wasn't possible to have a truly compilerless CMUCL _and_ a functional EVAL. I believe this IR1 interpreter was dropped from SBCL very early on. When SBCL gained an interpreter again it was a simple metacircular evaluator a la SICP that was unrelated to anything inherited from CMUCL. (This is all as of 15 or so years ago, I'm sure things have evolved since then!)

Re: An Exploration of SBCL Internals (2020)

#172

Post by spit2wind »

nurettin wrote: post #64
ilrwbwrkhv wrote: post #39

Earlier quoted context omitted.

I still haven't found an environment which lets you build the system as seamlessly as SBCL. The REPL allows you to build the code at runtime and update the system in place. Since I was a solodev, bug fixing and building the thing without going on the wrong path was worth I think months and years of my time. edit: Once you get the idea of a running Lisp image and you are updating the image it's a game changer. You are…

So a jupyter notebook is just a bad lisp repl

This is what the lisp repl is like. There's not much else like it: https://www.youtube.com/watch?v=_B_4vhsmRRI

PS: You can also do copy and paste :)

Re: An Exploration of SBCL Internals (2020)

#173

Post by nxobject »

fooker wrote: post #35
anothername12 wrote: post #3

A lot of people write Lisp interpreters, post it to HN and call it a day, but I think compilation is the far more interesting task for a Lisp implementation. SBCL is great to poke around in and the decompiler’s great. Also check out ABCL, ECL for what compilation to JVM bytecode and C looks like.

This is a bit Haskell oriented, but the "Implementation of Functional Programming Languages" by SPJ is one of my all time favorite books. https://simon.peytonjones.org/slpj-book-1987/ These compilers were pulling heroic data structure optimization stunts in 1985, that no modern production compiler for major compiled languages can replicate in 2024.

Huh – I didn't know he'd left MSR for Epic Games.

Re: An Exploration of SBCL Internals (2020)

#174

Post by ssafar »

amock wrote: post #10

remember that we're on x86 here, which is a big-endian architecture While I wish this were true, x86 is little-endian.

Apparently, I even made up an explanation for why "big-endian == start with the least significant bit" totally makes sense... couldn't convince the Universe this way either though.

Thanks for catching it, fixed!

Re: An Exploration of SBCL Internals (2020)

#175

Post by kunley »

coliveira wrote: post #95
linguae wrote: post #20

Earlier quoted context omitted.

Let’s make a trip back to the early and mid 1990s when C++ was a young language and Java was under development (it was released in 1995). At the time the most popular object-oriented language was Smalltalk, Common Lisp was at its peak of commercial popularity (largely in symbolic AI niches), and there were other niche OO languages that were heavily influenced by Smalltalk and Common Lisp (Objective-C in the NeXT worl…

Java claim to fame was to be close enough to C++ but portable in binary form. This made it possible for millions of people to learn it quickly. Lisp is too distant from C++ to have had any change.

Which is funny because it was marketed as close, while in reality being quite different from C++: all methods virtual, interfaces, type erasure, no method overloading, no operator overloading, no templates, to name just first things coming to mind.

We've been fooled in 90s so easily!

Re: An Exploration of SBCL Internals (2020)

#176

Post by dmytrish »

fooker wrote: post #45
thewakalix wrote: post #40

Earlier quoted context omitted.

Why? Is it mostly because of Haskell's purity (side-effect-freeness), so optimizations can change expressions more freely and safely?

That, and the uniform s-expr/gadt representation of data structures instead of going wild with clever pointers.

I am not sure I understand what you mean in the context of Haskell.

Re: An Exploration of SBCL Internals (2020)

#177

Post by kunley »

ilrwbwrkhv wrote: post #39
fooker wrote: post #13

Earlier quoted context omitted.

>Couldn't have done it without SBCL Could you elaborate this part?

I still haven't found an environment which lets you build the system as seamlessly as SBCL. The REPL allows you to build the code at runtime and update the system in place. Since I was a solodev, bug fixing and building the thing without going on the wrong path was worth I think months and years of my time. edit: Once you get the idea of a running Lisp image and you are updating the image it's a game changer. You are…

What about state belonging to the older code, updating http handlers, user sessions, etc, on production? While living-in-the-image seems admirable, I always wondered how it blends with real production and real ops.

The only thing I heard about this is Paul Graham's story on fixing particular bug in viaweb while talking to the user, but that's just one story from 90s. Would be great to hear more with regard to more modern setup.

Re: An Exploration of SBCL Internals (2020)

#178

Post by treadmill »

potta_coffee wrote: post #15
FredPret wrote: post #4

Earlier quoted context omitted.

I’ve tried multiple times to get into SBCL, but every time I run into the problem that I have to learn Emacs first. I know there are lots of other ways to work with SBCL, but they are either second-class citizens or paid.

I'm in the same boat. I just don't care about EMACS, don't like it, and there's little incentive when I'm just playing around. It's a shame because Lisp is really fun and interesting. I just don't want to spend so much time dicking around with an editor just so I can write some code.

Try neovim + vlime!

Re: An Exploration of SBCL Internals (2020)

#179

Post by nurettin »

anonzzzies wrote: post #78
nurettin wrote: post #64

Earlier quoted context omitted.

So a jupyter notebook is just a bad lisp repl

In my opinion it’s indeed like Greenspun’s 10th rule; it’s a vague imitation. If people weren’t so squeamish about parans the world would be a nicer place. The tech is there for a long time already.

I love lisp. I love the stability, the macros, the crash handlers, the repls, the elitism, slime, emacs, the works. But IMO sexpr is straight out terrible and hacking around that is a chore.

Re: An Exploration of SBCL Internals (2020)

#180

Post by fooker »

dmytrish wrote: post #176
fooker wrote: post #45

Earlier quoted context omitted.

That, and the uniform s-expr/gadt representation of data structures instead of going wild with clever pointers.

I am not sure I understand what you mean in the context of Haskell.

https://wiki.haskell.org/GADTs_for_dummies
Post reply on HN