A (possibly stupid) question: is it possible to generalize this pattern and will it bring any kind of improvements? I'm thinking that for functions shaped like (LAMBDA () X), where X is a literal object or a lexical variable, COMPILE can keep a hash-table with the X being its weak keys and the respective compiled functions being their values. Whenever a form like (LAMBDA () X) is encountered as an argument to COMPILE, it can "intern" the function in the table (if necessary) and return it.
I have no idea if it would bring any or a lot of gains besides the cases for NIL (and maybe T) because of CONSTANTLY and closures, but it's a thought that came to my mind upon first reading this commit.
You would expect there to be some mutual respect between SBCL developers and users because it’s such a tiny group of people who are intelligent and capable programmers.
Thought this was quite fun. In general, following SBCL development (via the useful Atom feed) has been a very instructive and sometimes entertaining endeavour!
Tell me about it: I still think in Scheme when I’m writing any other of CL’s dynamically typed, garbage-collected, first-class function progeny. I just wish that more languages had symbols.
Symbols exist as data structures at runtime that can be inspected, have their names compared, and have a value that is separate from their name. Enums typically don't do any of that.
https://github.com/search?q=lang%3A%22Common+Lisp%22+%22%28l... and https://github.com/search?q=lang%3A%22Common+Lisp%22+%22(lam... indeed gives quite a lot of results.
A (possibly stupid) question: is it possible to generalize this pattern and will it bring any kind of improvements? I'm thinking that for functions shaped like (LAMBDA () X), where X is a literal object or a lexical variable, COMPILE can keep a hash-table with the X being its weak keys and the respective compiled functions being their values. Whenever a form like (LAMBDA () X) is encountered as an argument to COMPILE, it can "intern" the function in the table (if necessary) and return it.
I have no idea if it would bring any or a lot of gains besides the cases for NIL (and maybe T) because of CONSTANTLY and closures, but it's a thought that came to my mind upon first reading this commit.
You would expect there to be some mutual respect between SBCL developers and users because it’s such a tiny group of people who are intelligent and capable programmers.
Thought this was quite fun. In general, following SBCL development (via the useful Atom feed) has been a very instructive and sometimes entertaining endeavour!
If that's what an industrial-strength compiler for a relatively niche language has to do, imagine what special cases LLVM and GCC have to deal with!
> for a relatively niche language
Thinking of the queen of languages relegated to "a relatively niche language" really made me sad.
Tell me about it: I still think in Scheme when I’m writing any other of CL’s dynamically typed, garbage-collected, first-class function progeny. I just wish that more languages had symbols.
> I just wish that more languages had symbols.
They're just a global enum, almost all languages have enums.
Symbols exist as data structures at runtime that can be inspected, have their names compared, and have a value that is separate from their name. Enums typically don't do any of that.
Symbols are dynamic, not static. And uninterned symbols exist.
You could say that it's a global (per package) weak hash table, from my understanding.
Is the implementation specified that they are a global enum? I don't believe so.
I'd love to see a list of such curious commits!