Live data from Hacker News

Weird Lexical Syntax

justine.lol

1–10 of 234 posts

Re: Weird Lexical Syntax

#4
post #2

I've done a fair bit of forth and I've not seen c" used. The usual string printing operator is ." .

Counted (“Pascal”) strings are rare nowadays so C" is not often used. Its addr len equivalent is S" and that one is fairly common in string manipulation code.

Re: Weird Lexical Syntax

#6
post #2

I've done a fair bit of forth and I've not seen c" used. The usual string printing operator is ." .

Right, c" is for when you want to pass a literal string to some other word, not print it. But I agree that it's not very common, because you normally use s" for that, which leaves the address and length on the stack, while c" leaves just an address on the stack, pointing to a one-byte count field followed by the bytes. I think adding c" in Forth-83 (and renaming " to s") was a mistake, and it would have been better to deprecate the standard words that expect or produce such counted strings, other than count itself. See https://forth-standard.org/standard/alpha, https://forth-standard.org/standard/core/Cq, https://forth-standard.org/standard/core/COUNT, and https://forth-standard.org/standard/core/Sq.

You can easily add new string and comment syntaxes to Forth, though. For example, you can add BCPL-style // comments to end of line with this line of code in, I believe, all standard Forths, though I've only tested it in GForth:

    : // 10 word drop ; immediate
Getting it to work in block files requires more work but is still only a few lines of code. The standard word \ does this, and see \ decompiles the GForth implementation as

  : \
    blk @
    IF     >in @ c/l / 1+ c/l * >in ! EXIT
    THEN
    source >in ! drop ; immediate
This kind of thing was commonly done for text editor commands, for example; you might define i as a word that reads text until the end of the line and inserts it at the current position in the editor, rather than discarding it like my // above. Among other things, the screen editor in F83 does exactly that.

So, as with Perl, PostScript, TeX, m4, and Lisps that support readmacros, you can't lex Forth without executing it.

Re: Weird Lexical Syntax

#7
Another syntax oddity (not mentioned here) that breaks most highlighters: In Java, unicode escapes can be anywhere, not just in strings. For example, the following is a valid class:

    class Foo\u007b}
and this assert will not trigger:

    assert
        // String literals can have unicode escapes like \u000A!
        "Hello World".equals("\u00E4");

Re: Weird Lexical Syntax

#9
Meanwhile NeoVim doesn’t syntax highlight my commit message properly if I have messed with "commit cleanup" enough.

The comment character in Git commit messages can be a problem when you insist on prepending your commits with some "id" and the id starts with `#`. One suggestion was to allow backslash escapes in commit messages since that makes sense to a computer scientist.[1]

But looking at all of this lexical stuff I wonder if makes-sense-to-computer-scientist is a good goal. They invented the problem of using a uniform delimiter for strings and then had to solve their own problem. Maybe it was hard to use backtick in the 70’s and 80’s, but today[2] you could use backtick to start a string and a single quote to end it.

What do C-like programming languages use single quotes for? To quote characters. Why do you need to quote characters? I’ve never seen a literal character which needed an "end character" marker.

Raw strings would still be useful but you wouldn’t need raw strings just to do a very basic thing like make a string which has typewriter quotes in it.

Of course this was for C-like languages. Don’t even get me started on shell and related languages where basically everything is a string and you have to make a single-quote/double-quote battle plan before doing anything slightly nested.

[1] https://lore.kernel.org/git/vpq3808p40o.fsf@anie.imag.fr/

[2] Notwithstanding us Europeans that use a dead-key keyboard layout where you have to type twice to get one measly backtick (not that I use those)

Re: Weird Lexical Syntax

#10

  select'select'select
is a perfectly valid SQL query, at least for Postgres.

Languages' approach to whitespace between tokens is all over the place

Post reply on HN