Even more fun is zero length names. In SQLite they didn't require table and column names to be at least one character, so you can do this:

    CREATE TABLE []([] []);

Which will create a table with zero length name containing one column with a zero length name and zero length type. And yes you can do all the regular SQL against them providing you quote the zero length name.

> where keywords […] can be used as variable names

PL/I has that, too, because the designers thought you couldn’t expect programmers to know all keywords. For PL/I, that’s a correct assumption. Implementations can have hundreds of keywords, and some of them are single-letter (http://bitsavers.trailing-edge.com/pdf/ibm/series1/GC34-0084... pages 19-25 mentions A, B, E, F, P, R, S, V and X)

Meanwhile both SQL (and more recently Python) have tokens that are keywords in certain contexts and regular identifiers in others.

PL/I was infamous for it being possible to express valid code that read "IF IF THEN THEN ELSE ELSE".

Yep. One of the goals was that there would be no reserved words. Not sure why.

    IF IF = THEN THEN THEN = ELSE ELSE = END END

C++ has some contextual keywords as well:

  final (C++11)
  override (C++11)
  import (C++20)
  module (C++20)

But did they make those contextual in order to avoid conflicts with code that had existing identifiers before the new keyword was specified?

Yes.

C# is probably the king of contextual keywords, they have tens of them. They started I believe with `yield return` and `yield break` and then added all of the LINQ ones (select, from, where etc), and kept adding others (notnull, record, required, etc).

Java too:

> A further ten character sequences are restricted keywords: open, module, requires, transitive, exports, opens, to, uses, provides, and with. These character sequences are tokenized as keywords solely where they appear as terminals in the ModuleDeclaration, ModuleDirective, and RequiresModifier productions (§7.7).

https://docs.oracle.com/javase/specs/jls/se12/html/jls-3.htm...

> White space in variable names is a bad idea.

Pff. You can have your cake and eat it too: disallow whitespace in variable names except no-break space. ;)

And the same thing for filenames!

Writing shell script under the assumption that filenames do not contain spaces is a liberating experience. I want more of that! And it is nearly possible, by tr ' ' 0x00A0'ing every call to fopen, (probably as an option for mount).

We’d have long debates about spaces vs. tabs in identifiers. ;)

> White space in variable names is a bad idea.

In many contexts yes but as a blanket statement no. Calca allows whitespace in names and it is a delight to write as a result

I think the way F# implemented it is pretty good: if you want to use a keyword or whitespace in a variable or function name, it has to be enclosed in double backticks.

e.g:

  [<Property>]
  let ``Reverse of reverse of a list is the original list`` (xs:list<int>) =
      List.rev(List.rev xs) = xs

I'm not sure if F#'s implementation is good enough. The specification [1] suggests that it doesn't do any additional normalization to the resulting identifier, so otherewise identical identifiers with a single space, a single tab and two spaces would be different. I would expect them to collapse into a single space character.

[1] https://fsharp.org/specs/language-spec/4.1/FSharpSpec-4.1-la...

Why would you expect that? I would explicitly expect not that. Unicode normalisation (typically to NFC) maybe, but nothing more.

Mostly because it's rare to see identifiers with whitespace allowed after all. So this has to fulfill some specific needs.

The main use case here seems like self-describing properties that will be hardly referenced elsewhere. In principle this doesn't really need any new syntax, as you can put the description into the attribute (`[<Property>]` here) and the name itself can remain arbitrary or even be made anonymous. But we've got textual identifiers instead. So I guess that some code does refer to those textual identifiers, and if that's the case, being able to ignore invisible differences when comparing textual identifiers looks like a good idea as well.