I'm working on a Lisp dialect which is far from done and changing every day but I thought I would share it: https://github.com/lodenrogue/hith It uses python for the interpreter.
Neat. What is the primary use case for this dialect?
A road to Lisp: Why Lisp
161–170 of 322 posts
Re: A road to Lisp: Why Lisp
#162Earlier quoted context omitted.
(I think you meant “if condition is false”) Technically you can accomplish the same thing in languages with first class functions if the caller wraps their code in a lambda.
No, I meant "if condition is true". The point is that in most/all languages, if the condition is true, the else branch is not evaluated. And it's usually OK to put code in there that can crash when the condition is true, because we know it won't be evaluated. But if you make an if function like I did above in, say, Python, both the then_path and the else_path are evaluated before the decision is made. > Technically y…
Well, as mentioned that's why you create two lambdas as the branches. This is pretty much what thunks are in some languages (like Haskell), so this example doesn't strictly require macros per se.
Re: A road to Lisp: Why Lisp
#163I must admit - I still don't understand macros. I get that they're code that's generated at compile time. But I don't understand how that's different than a function which evaluates other functions. I guess the latter would actually be evaluated at runtime? I think I get it conceptually but I'm not sure I have the muscle memory to reach for them. Anybody here have an "ah hah!" Moment with macros?
Sure, macros are functions that take functions as input, and produce new functions as output. But they take the function's symbols as input and produce a new set of symbols. So a macro can extend the syntax of the language without having to modify the core language system. Anyway, what's unique about Lisp macros vs say, Rust macros, or C style preprocessors, is "homoiconicity". The data structure that a Lisp macro ta…
At the same time, you get a mushy tree as input, instead of a properly typed AST "object" with accessible "function name", "method parameters" everything that you can just refer to.
It will be the third arguments' 2nd arg with s-exprs, following your arbitrary pattern you figured you want to use. So it's very arguable which is easier to use, sure for some "party tricks" lisps will win, for anything more useful my vote would go with rust/Scala macros for sure. So again, you win nothing by homoiconicity, the by-the-compiler implemented parse function is more complex in rust, which is 100% abstracted away.
Re: A road to Lisp: Why Lisp
#164Earlier quoted context omitted.
If you squint enough, JS is a lisp.. Define a goddamn language, syntax is not enough to define one! What are the semantics? Without that you are just talking about syntax trees like they would mean anything
> If you squint enough, JS is a lisp.. Yes, that is true. I'm not big on the idea that Lisp is defined by parentheses. The implementation strategies are another way to look at it. That doesn't capture it either, but it's an angle to try.
So then what it is? Because otherwise it's a magical nothing-term to which everything lisp people like applies, but no criticism can ever reach it because "that's not really lisp, see it's different in this other implementation"
Re: A road to Lisp: Why Lisp
#165Earlier quoted context omitted.
> The former have been table stakes for interpreted languages I used to think so too back in the day when I was getting into Clojure. It was much later when I realized that when Lisp people talk about the REPL they’re usually talking not so much about the interactive CLI where you can evaluate commands easily but more so the ability to connect your program to a live session where you can quickly evaluate forms within…
you can do that in a python debugger?
the python debugger is cool but is an inferior experience. It isn't only about a REPL, but about the editing experience, and about the language being thought from the ground up for long-living programs. See: https://mikelevins.github.io/posts/2020-12-18-repl-driven/
Re: A road to Lisp: Why Lisp
#166I'm working on a Lisp dialect which is far from done and changing every day but I thought I would share it: https://github.com/lodenrogue/hith It uses python for the interpreter.
Neat. What is the primary use case for this dialect?
Its general purpose. For now I'm trying to build out all the basic language features. Once its built I'll use it as my daily driver for whatever I'm coding.
It's a lisp so it can be used for anything since macros have been implemented. You can create your own syntax using macros.
Re: A road to Lisp: Why Lisp
#167Don't miss out, we had new excellent editors and tools being released in the last months:
Mine: a complete, single-download application that comes with everything needed to experience the interactive and incremental development programming workflow, including hot-reloading and on-the-fly debugging. For CL and Coalton.
https://coalton-lang.github.io/20260424-mine/
OLIVE: a new hand-made plugin for VSCode.
ICL: a new REPL for the terminal and the browser with advanced features.
as a bonus: a JupyterLite kernel based on JSCL that runs 100% in the browser.
find them all: https://lispcookbook.github.io/cl-cookbook/editor-support.ht...
Re: A road to Lisp: Why Lisp
#168[dead]
Re: A road to Lisp: Why Lisp
#169[dead]
Re: A road to Lisp: Why Lisp
#170[dead]
Well, compilers have layers - you ain't outputting assembly from the AST layer directly, usually there is some kind of IR. Like LLVM have plenty of layers.
And for a simple DSL you can usually just use a sufficiently expressive language, no need for macros. Like kotlin/Scala has html DSLs that look pretty decent.
For anything more complex though, you can't just "compose stuff", a type system is a global property so for that you literally have to write something way more complex than a local macro should contain.