Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Weird Lexical Syntax

justine.lol

Post reply on HN
Print view View original

121–130 of 234 posts

Re: Weird Lexical Syntax

#121

Post by autarch »

Izkata wrote: post #118
autarch wrote: post #63

Earlier quoted context omitted.

Perl lets you do this too: my $foo = 5; my $bar = 'x'; my $quux = "I have $foo $bar\'s: @{[$bar x $foo]}"; print "$quux\n"; This prints out: I have 5 x's: xxxxx The "@{[...]}" syntax is abusing Perl's ability to interpolate an _array_ as well as a scalar. The inner "[...]" creates an array reference and the outer "@{...}" dereferences it. For reasons I don't remember, the Perl interpreter allows arbitrary code in the…

> For reasons I don't remember, the Perl interpreter allows arbitrary code in the inner "[...]" expression that creates the array reference. ...because it's an array value? Aside from how the languages handle references, how is that part any different from, for example, this in python: >>> [5 * 'x'] ['xxxxx'] You can put (almost) anything there, as long as it's an expression that evaluates to a value. The resulting v…

I understand that's constructing an array. What's a bit odd is that the interpreter allows you to string interpolate any expression when constructing the array reference inside the string.

Re: Weird Lexical Syntax

#122

Post by IshKebab »

jart wrote: post #93
IshKebab wrote: post #48

I don't understand why you wouldn't use Tree Sitter's syntax highlighting for this. I mean it's not going to be as fast but that clearly isn't an issue here. Is this a "no third party dependencies" thing?

I don't want to require everyone who builds llamafile from source need to install rust. I don't even require that people install the gperf command, since I can build gperf as a 700kb actually portable executable and vendor it in the repo. Tree sitter I'd imagine does a really great highly precise job with the languages it supports. However it appears to support fewer of them than I am currently. I'm taking a breadth…

I think the Rust component of tree-sitter-highlight is actually pretty small (Tree Sitter generates C for the actual parser).

But fair enough - fewer dependencies is always nice, especially in C++ (which doesn't have a modern package manager) and in ML where an enormous janky Python installation is apparently a perfectly normal thing to require.

Re: Weird Lexical Syntax

#123

Post by nathell »

murkt wrote: post #113

Author hasn’t tried to highlight TeX. Which is good for their mental health, I suppose, as it’s generally impossible to fully highlight TeX without interpreting it. Even parsing is not enough, as it’s possible to redefine what each character does. You can make it do things like “and now K means { and C means }”. Yes, you can find papers on arXiv that use this god-forsaken feature.

Same with Common Lisp (you can redefine the read table), although that’s likely abused less often on arXiv.

Re: Weird Lexical Syntax

#124

Post by Izkata »

autarch wrote: post #121
Izkata wrote: post #118

Earlier quoted context omitted.

> For reasons I don't remember, the Perl interpreter allows arbitrary code in the inner "[...]" expression that creates the array reference. ...because it's an array value? Aside from how the languages handle references, how is that part any different from, for example, this in python: >>> [5 * 'x'] ['xxxxx'] You can put (almost) anything there, as long as it's an expression that evaluates to a value. The resulting v…

I understand that's constructing an array. What's a bit odd is that the interpreter allows you to string interpolate any expression when constructing the array reference inside the string.

It's not...? Well, not directly: It's string interpolating an array of values, and the array is constructed using values from the results of expressions. These are separate features that compose nicely.

Re: Weird Lexical Syntax

#125

Post by wslh »

wslh wrote: post #53
TomatoCo wrote: post #45

I think my favorite C trigraph was something like do_action() ??!??! handle_error() It almost looks like special error handling syntax but still remains satisfying once you realize it's an || logical-or statement and it's using short circuiting rules to execute handle error if the action returns a non-zero value.

Did you choose the legacy C trigraphs over || for aesthetic purposes?

Could you review my comment on HN? Please educate me if there is something I haven’t understood, rather than downvoting my question.

Re: Weird Lexical Syntax

#126

Post by pdw »

panzi wrote: post #117
Tarean wrote: post #102

Earlier quoted context omitted.

As of python 3.6 you can nest fstrings. Not all formatters and highlighters have caught up, though. Which is fun, because correct highlighting depends on language version. Haskell has similar problems where different compiler flags require different parsers. Close enough is sufficient for syntax highlighting, though. Python is also a bit weird because it calls the format methods, so objects can intercept and react to…

I didn't mean nested f-strings. I mean this is a syntax error: >>> print(f"foo {"bar"}") SyntaxError: f-string: expecting '}' Only this works: >>> print(f"foo {'bar'}") foo bar

You're using an old Python version. On recent versions, it's perfectly fine:

    Python 3.12.7 (main, Oct  3 2024, 15:15:22) [GCC 14.2.0] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> print(f"foo {"bar"}")
    foo bar

Re: Weird Lexical Syntax

#127

Post by susam »

dahart wrote: post #65
susam wrote: post #62

Earlier quoted context omitted.

> ML didn’t have single-line comments, so same level of surprising limitation. It is not quite clear to me why the lack of single-line comments is such a surprising limitation. After all, a single-line block comment can easily serve as a substitute. However, there is no straightforward workaround for the lack of nested block comments. > I’ve never heard someone refer to C as “expressive”, but maybe it was in 1972 whe…

Fair enough. From my perspective, lack of single line comments is a little surprising because most other languages had it at the time (1973, when ML was introduced). Lack of nested comments doesn’t seem surprising, because it isn’t an important feature for a language, and because most other languages did not have it at the time (1972, when C was introduced). I can imagine both pro and con arguments for supporting nes…

> C certainly could have added support for nested comments at any time

After C89 was ratified, adding nested comments to C would have risked breaking existing code. For instance, this is a valid program in C89:

  #include 

  int main() {
      /* /* Comment */
      printf("hello */ world");
      return 0;
  }
However, if a later C standard were to introduce nested comments, it would break the above program because then the following part of the program would be recognised as a comment:

      /* /* Comment */
      printf("hello */
The above text would be ignored. Then the compiler would encounter the following:

      world");
This would lead to errors like undeclared identifier 'world', missing terminating " character, etc.

Re: Weird Lexical Syntax

#128

Post by weinzierl »

autarch wrote: post #63
pdw wrote: post #22

Some random things that the author seem to have missed: > but TypeScript, Swift, Kotlin, and Scala take string interpolation to the furthest extreme of encouraging actual code being embedded inside strings Many more languages support that: C# $"{x} plus {y} equals {x + y}" Python f"{x} plus {y} equals {x + y}" JavaScript `${x} plus ${y} equals ${x + y}` Ruby "#{x} plus #{y} equals #{x + y}" Shell "$x plus $y equals $…

Perl lets you do this too: my $foo = 5; my $bar = 'x'; my $quux = "I have $foo $bar\'s: @{[$bar x $foo]}"; print "$quux\n"; This prints out: I have 5 x's: xxxxx The "@{[...]}" syntax is abusing Perl's ability to interpolate an _array_ as well as a scalar. The inner "[...]" creates an array reference and the outer "@{...}" dereferences it. For reasons I don't remember, the Perl interpreter allows arbitrary code in the…

You also don't need quotes around strings (barewords). So

    my $bar = x;
should give the same result.

Good luck with lexing that properly.

https://perlmaven.com/barewords-in-perl

Re: Weird Lexical Syntax

#129

Post by LukeShu »

panzi wrote: post #96
pdw wrote: post #22

Some random things that the author seem to have missed: > but TypeScript, Swift, Kotlin, and Scala take string interpolation to the furthest extreme of encouraging actual code being embedded inside strings Many more languages support that: C# $"{x} plus {y} equals {x + y}" Python f"{x} plus {y} equals {x + y}" JavaScript `${x} plus ${y} equals ${x + y}` Ruby "#{x} plus #{y} equals #{x + y}" Shell "$x plus $y equals $…

Is this a bash-ism? "$x plus $y equals $((x+y))"

"$((" arithmetic expansion is POSIX (XCU 2.6.4 "Arithmetic Expansion").

But if I'm not mistaken, it originated in csh.

Re: Weird Lexical Syntax

#130

Post by samatman »

wslh wrote: post #125
wslh wrote: post #53

Earlier quoted context omitted.

Did you choose the legacy C trigraphs over || for aesthetic purposes?

Could you review my comment on HN? Please educate me if there is something I haven’t understood, rather than downvoting my question.

The grandparent post is specifically about trigraphs. Saying something about trigraphs was the end-in-itself, trigraphs were chosen to illustrate something about trigraphs. So your question made no sense. Hope that helps.
Post reply on HN