101–110 of 195 posts
Earlier quoted context omitted.
C has homoiconicity: you can represent C source code as C strings.
You can't natively index into a string and get any C syntactic token out of it besides a char.
I’d also encourage you to give it a try and have some fun with it! I’m using it for some of the 3D demos in my book. It’s definitely not a silver bullet, but I’ve found it can be pretty productive.
Personally, my favorite Lisps are Racket, Common Lisp, and Clojure, in that order. I’ve also been tempted to give Chicken Scheme a try! :)
I've been designing my own small language runtime in Rust (VM + JIT + AOT backends) mostly as a way to actually understand tradeoffs compiler authors make instead of just reading about them. Racket's approach to macros and language-oriented programming is one of the things I keep coming back to as a reference curious how much of that flexibility comes at a real runtime cost vs. being mostly a compile-time abstraction…
I can answer that for Common Lisp, specifically the SBCL implementation (there's several others). It compiles every function to native code (you can even inspect the assembly with `disassemble`). Macros are executed before code is compiled. Hence, once you've compiled a function, the macro disappears since its only role is to generate the expressions that are going to actually be compiled and then executed. For examp…
Racket ---expand the macros---> Simplified Racket "Kernel"
Simplified Racket "Kernel"---schemify---> Rumble (that is Chez Scheme + a few libraries and macros)
Rumble ---expand the macros---> Simplified Chez Scheme
Simplified Chez Scheme ---constants propagation/folding/other---> Simplified Chez Scheme
Simplified Chez Scheme ---compiler---> native code
You can see the result with https://pkgs.racket-lang.org/package/disassemble
Nothing against Lisp, but to correct the record: > For decades, Lisp was the language of artificial intelligence. [...] Then came the "AI winter," funding dried up, and Lisp went from star to cult language. Lisp had fallen from relevance before then. Only the United States was still using it, and mostly out of technical debt and a stubborn refusal to move on. Prolog displaced it in the late 1970s, and even within the…
I've read a large factor was minicomputers and microcomputers running Unix in C became much more affordable, and when the Berlin Wall fell in 1989 DoD funding for powerful and expensive Lisp workstations quickly dried up. And the nascent free software Lisp offerings left a lot to be desired (to be developed). This visualization of relative programming language popularity shows Lisp was the 3rd most popular general pu…
> This visualization of relative programming language popularity shows Lisp was the 3rd most popular general purpose language
Which is fine, and makes sense. But I'm addressing a claim about Lisp being "the Language" for the era of symbolic AI. Which is decidedly not high volume, nor is it general at all, it's really quite specific.
I'm correcting it, because I know Americans are heavily culturally silo'd on this, and symbolic AI is especially esoteric. Most people probably can't name a single commercial expert system off the top of their head, and that's not unreasonable. Our cultural view of symbolic AI is rife with American exceptionalism (I theorize partially because of government involvement) that just doesn't track with reality. Speaking as an American.
Nothing against Lisp, but to correct the record: > For decades, Lisp was the language of artificial intelligence. [...] Then came the "AI winter," funding dried up, and Lisp went from star to cult language. Lisp had fallen from relevance before then. Only the United States was still using it, and mostly out of technical debt and a stubborn refusal to move on. Prolog displaced it in the late 1970s, and even within the…
And then mini/microKanren put Prolog in its rightful place: that of a useful DSL instead of a poor general purpose language.
Anyways the embedded inference engine as an idea failed a long time ago, Americans convinced themselves it was the way to do things and just refused to ever let it go. It's just extra baggage on the important bit, which is the symbolic computation. miniKanren has a niche more in line with a theorem solver.
Earlier quoted context omitted.
C has homoiconicity: you can represent C source code as C strings.
You can't run that code within the language so no, obviously not. And even if you could, strings + eval alone is not homoiconicity--programs are not manipulated by the compiler as unstructured text strings.
Earlier quoted context omitted.
Yeah, there's a toggle for it in read-syntax mode. https://docs.racket-lang.org/reference/Reading.html#%28def._...
How do you get that to work? #lang racket (read-syntax-accept-graph #t) (let ((a '#0=(0 . #0#))) (display (car a))) ...which of course doesn't work, because `(read-syntax-accept-graph)` is a run-time thing, and the circular-list structure is a `read`-time thing. I couldn't figure it out with this either: https://stackoverflow.com/questions/51942188/read-syntax-for... ...just to make sure I wasn't going crazy, this: (…
That read-syntax doesn't just accept everything accepted by plain read is one of my biggest annoyances with Racket.