"Well, okay, there was the discussion the other day that C compilers can pull out loop invariants and other things. I wonder if we can just do this through codewalkers, macros and Coalton/CLTL2."

holy shit I really hate it in CL implementation can we get On the expressive power of programming languages for optimisations, you absolutely cannot do that through local macros
Google doesn't give me a rate for retrofitting junk to SBCL for their deeds, youse are ridiculous, I'm over it.
"And unless someone were to tell or convince me that a better compiler than SBCL can be written and streamlined in under a 1000 hours, I'm probably going to use my 300 hours [/year usable on Lisp work] to make-do with whatever we already have."

everyone else thanks you for them having to waste their 300 hours kludging for bad compilers, can I get mine back while we're at it
If Mark Miller didn't blow the name on some whining this would be very excellently titled "tragedy of the Common Lisp".
Follow

@hayley

regarding this erights.medium.com/the-tragedy to be fair, C++ is a large and complex language but it keeps growing. Also Java has new features, and/or more dialects like Kotlin.

Common Lisp can grow as libraries, DSL and macros (because it is an extensible language), but its specification is stable and immutable. It is a mature and usable language, without the needing to add other things.

@mzan Threads cannot be implemented as libraries, DSLs or macros, much the same as general purpose optimisations (my original complaint). Of course optimisations are an implementation detail and not a language detail, but there's the same principle.

@hayley yes, I agree. Obviously my "without the needing to add other things" was a partial hype.

JVM now supports virtual-threads, but in CL threads are a de-facto standard and there are also DSL in CL for green/cooperative-threads and maybe it is not so hard to add something at the compiler implementation level.

Global user-specified optimizations are outside the scope of CL macro, because they can walk only local code. But you can put all the DSL inside a grouping macro, like Coalton is doing. In this way you can abuse the macros, but you can support more declarative DSL, needing a lot of analysis, and not only "stupid" code expansion.

C-like global optimizations can be supported from CL compilers, if one has a way to tell which parts of the implementation is sealed. CLOS has already an API for this, IIRC. Some commercial compilers are already doing this on normal CL code, IIRC.

OCaml added recently a very complete and powerful effect system, well integrated in the language. But the venerable conditions system of CL is good enough in a lot of cases, and still years ahead respect other mainstream PL.

@hayley ah, I found recently this DSL nikodemus.github.io/screamer/ and it supports both global compilation and interactive programming. It is doing many tricks: it redefines "defun"; it performs a code-walk on the entire loaded package; it maintains a data-structure at run-time with Screamer-compiled/managed functions and their dependencies, and so on.

Sign in to participate in the conversation
Qoto Mastodon

QOTO: Question Others to Teach Ourselves
An inclusive, Academic Freedom, instance
All cultures welcome.
Hate speech and harassment strictly forbidden.