A slight nitpick, but I like how we went from Scheme's "define" over the classic "defun", through Clojure's "defn" and Bel's "def" to PicoLisp's "de". Looking forward to seeing the next S-expression language defining functions with "d".
Yeah, the list isn't in chronological order (I believe "defun" was standardised years before the algorithmic programming language Scheme was conceived), it's more about the d-evolution.
I love(d) PicoLisp. I have run Windows, Linux (many flavors on many machines), and MacOS, but my working OS is Windows, and I could not get the x64 PicoLisp running on Windows back then without using Cygwin or MinGW. I can run it on WSL[1], however, it still requires a POSIX environment. Is there a way to compile a Windows binary without the POSIX required for a working PicoLisp environment?
I know it switched to an LLVM-IR base, but I don't know enough about the POSIX dependencies and creating a Windows binary.
I love PicoLisp's succinctness (I program in J and APL, learning BQN), practicality with a Prolog and built-in database. It has certainly been around for a while like me; I've been programming since 1978.
[Edit/Add] I really liked Shen[2], a Lisp built on Kλ, a small Lisp of 46 or so functions, which allows Shen to be ported to many platforms and other languages. Shen also has a Prolog, pattern matching, optional lazy evaluation and static type checking, and more. For me, it is between Shen and PicoLisp to displace my use of SBCL.
Wouldn’t surprise me if it could be made to work in Justines “APE”. I ported PicoLisp to Windows many years ago by removing some POSIX stuff, don’t remember what exactly. But that was when it was written i C and 32 bit.
I think it’s more of an effort missing to port it, the core is extremely small.
The problem with Lisp is that there are different dialects, and if you program in more than one, you need to be aware of the differences between them. It would be nice to be able to switch between them on different projects without being caught out by their differences before getting used to the other dialect, or having to context-switch. It would also be nice to port programs from one dialect to another without major editing. But Picolisp is another dialect, which on the surface is quite different from Common Lisp and Scheme/Racket and, I assume, Clojure. If you want to keep your Lisp implementation small, why not just implement a subset of Common Lisp, or build/use a Scheme variant?
Lisp is a family of languages, not any single one. There's (thankfully, lisps needs innovation like everything else) room for different types.
In the C family for example, you have both C and Javascript.
> It would also be nice to port programs from one dialect to another without major editing
If the languages are the same, they wouldn't be different dialects, they would be the same language, so porting them doesn't make much sense. I think the closest thing to what you're describing is Clojure, where you can swap the targeted environment (JVM if you're working on a server, babashka if you're making a script, javascript if it's a web app, dart/flutter if you're making mobile apps, etc...)
C and Javascript are very different languages with similar syntax. Common Lisp and Picolisp are very similar languages/dialects with different syntax/function names. Common Lisp based its syntax on Maclisp so that Maclisp code could run without much alteration on common Lisp systems.
> In the C family for example, you have both C and Javascript.
There is no reasonable sense in which JavaScript is in the “C family”. It's not really even in the broader Algol family that C is in, being most closely related to Self and Scheme (the latter being in the Lisp family.)
This only sounds like a 'problem' because the lisp dialects are so similar that you would almost expect them to be the same, no?
That seems like a nice feature - you know Common Lisp so you have to only learn some nuances to write PicoLisp effectively.
When it comes to the c-family of languages, you wouldn't expect a complaint about having to be aware of the differences between C and JavaScript since you can't even entertain the idea that they are all that similar.
I have my own libs that equalize lisps/schemes for everything I use it for. That really wasn't that much work. I don't work with clojure because I insist on s-expressions all the way, so I cannot speak of that.
There's no mistake that there's a lineage from, say, C to JavaScript. Nor the lineage along the line of S-expression languages.
But when folks speak of JavaScript, or Java, they never refer to them as "C" or "a C". But when something is written in a S-expression language, suddenly it's all Lisp.
"3D graphics is Lisp!" is the headline, then you learn it's some S-expr language that is not Common Lisp.
Common Lisp is a Thing, much like C is a Thing. There are several implementations that call consider themselves compatible with Common Lisp. It has the closest ties and heritage to Lisp 1.5 ("the" Lisp).
Scheme is a thing. When it comes to the "family of languages" idea, Scheme is most certainly practiced that way. There are a LOT of Schemes out there, all with various levels of compatibility and conformance to the assorted Revised Standard documents, but at the same time they all solve different problems.
At a time there were several Lisps, but they were all essentially merged into Common Lisp. Now, we have "one" Lisp, and Scheme. Scheme forked off down its own branch, making conscious decisions to differ from the Lisps of the day. It's fair to point out that two Lisps survived that time, the other being Emacs Lisp.
Then there's things like Clojure, AutoLisp, or even this PicoLisp which are S-expr based languages, but that's about where the similarity ends. They're as much the same as Java and C, and probably not even that close to be honest.
I ported some simple C to Java. It was a fairly trivial mechanical conversion, but 80% of the code just drag and dropped across. But I would never call Java a C or vice a versa.
Pascal is not an Algol, despite the heritage. "Structured programming language" is the vernacular. All of them are that: Algol, Pascal, C, Common Lisp, Schema, Java. But, of course, we don't disuss the s-expr languages in those terms, even though they are, indeed, supportive of "structured programming".
When I see "Lisp" I think Common Lisp. Lisp == Common Lisp, Scheme == (one of the) Scheme, Emacs == Emacs Lisp (we almost never hear of someone doing XXX in "Emacs Lisp", it's almost always just "Emacs"). That's how I divide up the world.
> Dual-core Arm Cortex M0+ processor, flexible clock running up to 133 MHz
> 264kB of SRAM, and 2MB of on-board flash memory
I wonder if my lisp can run on that... It targets freestanding Linux environments and is able to manage statically allocated memory all by itself. The hash table of system calls alone took up about 200 kB of memory last time I measured it but if I replaced those tables with direct hardware integration...
Readit News
I know it switched to an LLVM-IR base, but I don't know enough about the POSIX dependencies and creating a Windows binary.
I love PicoLisp's succinctness (I program in J and APL, learning BQN), practicality with a Prolog and built-in database. It has certainly been around for a while like me; I've been programming since 1978.
[Edit/Add] I really liked Shen[2], a Lisp built on Kλ, a small Lisp of 46 or so functions, which allows Shen to be ported to many platforms and other languages. Shen also has a Prolog, pattern matching, optional lazy evaluation and static type checking, and more. For me, it is between Shen and PicoLisp to displace my use of SBCL.
I think it’s more of an effort missing to port it, the core is extremely small.
In the C family for example, you have both C and Javascript.
> It would also be nice to port programs from one dialect to another without major editing
If the languages are the same, they wouldn't be different dialects, they would be the same language, so porting them doesn't make much sense. I think the closest thing to what you're describing is Clojure, where you can swap the targeted environment (JVM if you're working on a server, babashka if you're making a script, javascript if it's a web app, dart/flutter if you're making mobile apps, etc...)
There is no reasonable sense in which JavaScript is in the “C family”. It's not really even in the broader Algol family that C is in, being most closely related to Self and Scheme (the latter being in the Lisp family.)
That seems like a nice feature - you know Common Lisp so you have to only learn some nuances to write PicoLisp effectively.
When it comes to the c-family of languages, you wouldn't expect a complaint about having to be aware of the differences between C and JavaScript since you can't even entertain the idea that they are all that similar.
There's no mistake that there's a lineage from, say, C to JavaScript. Nor the lineage along the line of S-expression languages.
But when folks speak of JavaScript, or Java, they never refer to them as "C" or "a C". But when something is written in a S-expression language, suddenly it's all Lisp.
"3D graphics is Lisp!" is the headline, then you learn it's some S-expr language that is not Common Lisp.
Common Lisp is a Thing, much like C is a Thing. There are several implementations that call consider themselves compatible with Common Lisp. It has the closest ties and heritage to Lisp 1.5 ("the" Lisp).
Scheme is a thing. When it comes to the "family of languages" idea, Scheme is most certainly practiced that way. There are a LOT of Schemes out there, all with various levels of compatibility and conformance to the assorted Revised Standard documents, but at the same time they all solve different problems.
At a time there were several Lisps, but they were all essentially merged into Common Lisp. Now, we have "one" Lisp, and Scheme. Scheme forked off down its own branch, making conscious decisions to differ from the Lisps of the day. It's fair to point out that two Lisps survived that time, the other being Emacs Lisp.
Then there's things like Clojure, AutoLisp, or even this PicoLisp which are S-expr based languages, but that's about where the similarity ends. They're as much the same as Java and C, and probably not even that close to be honest.
I ported some simple C to Java. It was a fairly trivial mechanical conversion, but 80% of the code just drag and dropped across. But I would never call Java a C or vice a versa.
Pascal is not an Algol, despite the heritage. "Structured programming language" is the vernacular. All of them are that: Algol, Pascal, C, Common Lisp, Schema, Java. But, of course, we don't disuss the s-expr languages in those terms, even though they are, indeed, supportive of "structured programming".
When I see "Lisp" I think Common Lisp. Lisp == Common Lisp, Scheme == (one of the) Scheme, Emacs == Emacs Lisp (we almost never hear of someone doing XXX in "Emacs Lisp", it's almost always just "Emacs"). That's how I divide up the world.
PicoLisp is as much a Lisp as Java is a C.
> 264kB of SRAM, and 2MB of on-board flash memory
I wonder if my lisp can run on that... It targets freestanding Linux environments and is able to manage statically allocated memory all by itself. The hash table of system calls alone took up about 200 kB of memory last time I measured it but if I replaced those tables with direct hardware integration...