Really enjoying Janet, but it has some sad and seemingly unnecessary syntax differences to the rest of the lisps and lisp-likes.

I have ignored it because quasiquote is `;’ and that just pisses me off. I should not have such a strong reaction, but I do.

Yes, we shouldn't, but sometimes superficial features can be quite important.

I've ignored CL because it seems like the BASIC or bloated kitchen-sink of lisp/likes, but probably mainly because 'car'? 'cdr'? 'setq'? seriously?

But that's just how Lisp works. Emacs Lisp (not CL) uses those too. It's Scheme that decided to rename car and cdr (and by doing so obscure how things are implemented underneath).

But they're nonsensical.

I understand the history; some to-do with registers, but the names make no sense conceptually.

Scheme renamed them? When did that happen? R5RS? R6RS? R7RS? IEEE Scheme?

Okay, you're right. They are there as well. And actually the "first" and "rest" functions aren't even standard but are just there in some implementations as synonyms.

I know this part of the conversation is focusing on Scheme, but wanted to mention that first and rest are standard CL functions:

http://clhs.lisp.se/Body/f_firstc.htm#first

http://clhs.lisp.se/Body/f_rest.htm#rest

so it actually is like this: Scheme kept car and cdr.

Common Lisp added FIRST, REST, SECOND, THIRD, ..., TENTH and some others to the language standard in the early 80s.

lol, as I said, 'kitchen sink'. And then there's all that business with 'caar' 'caaddr', or whatever. I mean, just no.

Lisp is old. Thus software from several decades back can run.

Sure, but that's no reason to keep carrying past mistakes.

I don't understand why languages don't have a 'version' id as the very first thing, and then you can run appropriate interpreter/compiler given the version.

New versions of the language can drop historical mistakes.

You could kick-start the process in any existing language by making a next release that requires a version tag (and which maybe strips out a ton of legacy cruft). It would then default to a 'legacy' interpretation if the tag isn't present.

> I don't understand why languages don't have a 'version' id as the very first thing, and then you can run appropriate interpreter/compiler given the version.

Common Lisp may have that. My Symbolics Lisp Machine runs six different Common Lisp variants and additionally ZetaLisp side by side in one system.

There are often feature symbols which note language versions: CLtL1, CLtL2, ANSI90, ANSI-CL. It also has packages, where LISP will mean symbol table with CLtL1 symbols and COMMON-LISP will mean a symbol table with CLtL2 symbols.

> New versions of the language can drop historical mistakes.

Lisp may not work that way:

Lisp is not just a language, it is a running system. One can load many different libraries and programs into one running Lisp. Some older code will use CAR/CDR and some newer code won't. It still runs side by side in the same ONE environment and will call each other.

I can for example say:

#+ansi-cl (print "this is code for an ANSI CL compatible Common Lisp")

#-ansi-cl (error "this is Common Lisp does not support ANSI CL")

This will check if the Common Lisp has the features ANSI-CL.

Since cons cells and lists made of cons cells are so fundamental to Lisp, that it would be painful to support software where such a core data structure would be changed (for example by renaming the core operators).

Again, code from several decades with different language variants can be running in one Lisp.

In TXR Lisp, I made ^ quasiquote. That wasn't some run-to choice or anything; there is a history behind it. Before there as a TXR Lisp, only TXR, backquote was used for interpolated strings: `@foo @bar`, so the character was not available for quasiquoting.

In hindsight, ^ is nice because it stands out. I might have been influenced by ^ptr syntax from Pascal for dereferencing a pointer. Or exponentiation in some languages x^2. Hat denotes "power" and quasiquote is power!

(For a while I experimented with an idea of making regular quote ' somehow intelligent so it could do quasiquoting when unquotes are present. The semantic restrictions are too severe though and cannot be fixed: e.g. you can't do the equivalent ^(foo '(bar ,unquote-here)) with '(foo '(bar ,unquote-here)) where the unquote isn't going to the quote that we want.)

Because @ is significant, I had to turn ,@ into ,*. That's not too bad because * already denotes repetitions in regex: zero or more. And splicing brings in zero or more, so ...

The only issue is that if you want to interpolate a special variable, you have to write , *foo* and not ,*foo, because the latter actually means , foo*.

Common Lisp has the same issue with @, but @ isn't a popular symbol prefix, so it rarely comes up:

  [1]> (defvar @foo@ '(1 2 3))
  @FOO@
  [2]> `'(,@foo@)

  *** - SYSTEM::READ-EVAL-PRINT: variable FOO@ has no value
  [...]


  [4]> `'(, @foo@)
  '((1 2 3))

None of these options lift the `;` into something I have to parse as code, not documentation, so you’re all good!

:)

Ugh. I meant `;` is unquote-splicing, which is an operator within a quasiquote. Sorry for my brain fart.

Link: https://janet-lang.org/