5 ms·

Algol 60 also allowed whitespace in variable names. But they had a solution to avoid Fortran's confusion: keywords had to be specially marked. https://en.wikipe

• jll29 3y ago
  White space in variable names is a bad idea. And not everything that is possible is worth doing; e.g. I once designed a language ("Leazy") where keywords don't have to be declared, and can be used as variable names, just to show I could still write an LL(1) recursive descent parser for it. You don't want that in anything for daily use, as it introduces confusion.
  • nerdponx 3y ago
    Meanwhile both SQL (and more recently Python) have tokens that are keywords in certain contexts and regular identifiers in others.
    • Findecanor 3y ago
      PL/I was infamous for it being possible to express valid code that read "IF IF THEN THEN ELSE ELSE".
      • deleted 3y ago
        [deleted]
    • layer8 3y ago
      C++ has some contextual keywords as well: final (C++11) override (C++11) import (C++20) module (C++20)
      • wyldfire 3y ago
        But did they make those contextual in order to avoid conflicts with code that had existing identifiers before the new keyword was specified?
        • layer8 3y ago
          Yes.
      • tsimionescu 3y ago
        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).
    • twic 3y ago
      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.html#jls-3.9-200 https://docs.oracle.com/javase/specs/jls/se12/html/jls-3.htm...
  • avgcorrection 3y ago
    > 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. ;)
    • enriquto 3y ago
      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).
  • rogerbinns 3y ago
    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.
  • Someone 3y ago
    > 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-0_PL_I_Introduction_Feb77.pdf http://bitsavers.trailing-edge.com/pdf/ibm/series1/GC34-0084... pages 19-25 mentions A, B, E, F, P, R, S, V and X)
  • layer8 3y ago
    We’d have long debates about spaces vs. tabs in identifiers. ;)
  • ketralnis 3y ago
    > 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
  • julesnp 3y ago
    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
    • lifthrasiir 3y ago
      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-latest.pdf#page=25 https://fsharp.org/specs/language-spec/4.1/FSharpSpec-4.1-la...
      • chrismorgan 3y ago
        Why would you expect that? I would explicitly expect not that. Unicode normalisation (typically to NFC) maybe, but nothing more.
        • lifthrasiir 3y ago
          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.
  • deleted 3y ago
    [deleted]
• formerly_proven 3y ago
  Pfft, just make your syntax a prefix-free code.