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

191–200 of 234 posts

Re: Weird Lexical Syntax

#191

Post by quietbritishjim »

teo_zero wrote: post #179
layer8 wrote: post #100

The author may have missed that lexing C is actually context-sensitive, i.e. you need a symbol table: https://en.wikipedia.org/wiki/Lexer_hack Of course, for syntax highlighting this is only relevant if you want to highlight the multiplication operator differently from the dereferencing operator, or declarations differently from expressions. More generally, however, I find it useful to highlight (say) types different…

> this is only relevant if you want to highlight the multiplication operator differently from the dereferencing operator Can you mention one editor which does that?

I don't think they implied there is. The sentence you quoted is essentially "this is relevant for their article about weird lexical syntax, but (almost definitely) not relevant to their original problem of syntax highlighting".

Re: Weird Lexical Syntax

#192

Post by Kwpolska »

metadat wrote: post #64

> The languages I decided to support are Ada, Assembly, BASIC, C, C#, C++, COBOL, CSS, D, FORTH, FORTRAN, Go, Haskell, HTML, Java, JavaScript, Julia, JSON, Kotlin, ld, LISP, Lua, m4, Make, Markdown, MATLAB, Pascal, Perl, PHP, Python, R, Ruby, Rust, Scala, Shell, SQL, Swift, Tcl, TeX, TXT, TypeScript, and Zig. A few (admittedly silly) questions about the list: 1. Why no Erlang, Elixir, or Crystal? Erlang appears to be…

"Shell" in the context of a syntax highlighting language picker almost always means a Unixy shell, most likely something along the lines of Bash.

Re: Weird Lexical Syntax

#193

Post by IshKebab »

chubot wrote: post #164
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?

Have you developed against TreeSitter? Some feedback from people who use it here - https://news.ycombinator.com/item?id=39783471 And here - https://lobste.rs/s/9huy81/tbsp_tree_based_source_processing...

Yes I have, and it worked very well for what I was using it for (assembly language LSP server). I didn't run into any of the issues they mentioned (not saying they don't exist though).

For new projects I use Chumsky. It's a pure Rust parser which is nice because it means you avoid the generated C, and it also gives you a fully parsed and natively typed output, rather than Tree Sitter's dynamically typed tree of nodes, which means there's no extra parsing step to do.

The main downside is it's more complicated to write the parser (some fairly extreme types). The API isn't stable yet either. But overall I like it more than Tree Sitter.

Re: Weird Lexical Syntax

#194

Post by broken-kebab »

mqus wrote: post #46
__MatrixMan__ wrote: post #33

This was a fun read, but it left me a bit more sympathetic to the lisp perspective, which (if I've understood it) is that syntax, being not an especially important part of a language, is more of a hurdle than a help, and should be as simple and uniform as possible so we can focus on other things. Which is sort of ironic because learning how to do structural editing on lisps has absolutely been more hurdle than help s…

Having a simple syntax might be fine for computers but syntax is mainly designed to be read and written by humans. Having a simple one like lisp then just makes syntactic discussions a semantic problem, just shifting the layers. And I think an complex syntax is far easier to read and write than a simple syntax with complex semantics. You also get a faster feedback loop in case the syntax of your code is wrong vs the…

The problem with this statement is that it assumes parsing-easiness as something universal, and stable. And this is certainly not true. You may believe syntax A is so much easier simply because it's the syntax you have been dealing with most of your career thus your brain is trained for it. On top of it a particular task can make a lot of difference: most people would agree that regex is simplification versus writing the same logic in usual if-then way for pattern matching in strings, but I'm not sure many would like to have their whole programs looking that way (but even that could be subjective, see APL).

Re: Weird Lexical Syntax

#195

Post by mstade »

kergonath wrote: post #182
wslh wrote: post #176

Earlier quoted context omitted.

My question was precisely about why the user like trigraphs over using just || on this case. It is a very clear question and makes all the sense.

The post shows a “favorite C trigraph” thing, not that they were going out of their way to use trigraphs in actual code or that you should. Using trigraphs is the whole premise so no, your question makes no sense in that context. FWIW the ??!??! double trigraph as error processing is funny because of the meaning of ?! and various combinations of ? and !. It is funny and it has trigraphs. That’s the whole point.

My reading of the downvoted question was one of genuine curiosity of why the author chose that as a favorite trigraph, as in “why that one instead of another”, not as criticism of the choice of trigraph over something more conventional. I may be wrong of course, but it didn’t seem like a particularly malicious question to me and your rationale unfortunately doesn’t convince me otherwise. Not that it has to, this is all very subjective after all, but just offering up a counter opinion.

I gave the question a +1 because I, as previously stated, read it to be genuine curiosity. Maybe a smiley would’ve helped, I don’t know. ¯\_(ツ)_/¯

Re: Weird Lexical Syntax

#196

Post by jaen »

lupire wrote: post #37

> You'll notice its hash function only needs to consider a single character in in a string. That's what makes it perfect, Is that a joke? https://en.m.wikipedia.org/wiki/Perfect_hash_function

No. Taking the value of a single character is a correct perfect hash function, assuming there exists a position for the input string set where all characters differ.

Re: Weird Lexical Syntax

#197

Post by chubot »

jwilk wrote: post #175
chubot wrote: post #162

Earlier quoted context omitted.

Yup, bash and GNU Make have the same issue as Perl does, and I mention the C++ issue here too: Parsing Bash is Undecidable - https://www.oilshell.org/blog/2016/10/20.html I remember a talk from Larry Wall on Perl 6 (now Raku), where he says this type of thing is a mistake. Raku can be statically parsed, as far as I know.

Parsing POSIX shell in undecidable too: https://news.ycombinator.com/item?id=30362718

Yes, good point -- aliases makes parse time depend on runtime. That is mentioned in

Morbig: A static parser for POSIX shell - https://scholar.google.com/scholar?cluster=15754961728999604...

(at the time I wrote the post about bash, I hadn't implemented aliases yet)

But it's a little different since it is an intentional feature, not an acccident. It's designed to literally reinvoke the parser at runtime. I think it's not that good/useful a feature, and I tend to avoid it, but many people use it.

Re: Weird Lexical Syntax

#198

Post by michaelcampbell »

dahart wrote: post #43
susam wrote: post #36

> Every C programmers (sic) knows you can't embed a multi-line comment in a multi-line comment. And every Standard ML programmer might find this to be a surprising limitation. The following is a valid Standard ML program: (* (* Nested (**) *) comment *) val _ = print "hello, world\n" Here is the output: $ sml Given how C was considered one of the "expressive" languages when it arrived, it's curious that nested commen…

There are 3 things I find funny about that comment: ML didn’t have single-line comments, so same level of surprising limitation. I’ve never heard someone refer to C as “expressive”, but maybe it was in 1972 when compared to assembly. And what bearing does the comment syntax have on the expressiveness of a language? I would argue absolutely none at all, by definition . :P

I was barely too young for this to make much of an impact at the time, (but older than many, perhaps most, here), I understand why C was considered a "high level language", but it still hits me weird, given today's context.

Re: Weird Lexical Syntax

#199

Post by dahart »

susam wrote: post #127
dahart wrote: post #65

Earlier quoted context omitted.

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 o…

Given the neighboring thread where I just learned that the lexer runs before the preprocessor, I’m not sure that would be the outcome. There’s no reason to assume the comment terminator wouldn’t be ignored in strings. And even today, you can safely write printf(“hello // world\n”); without risking a compile error, right?

Re: Weird Lexical Syntax

#200

Post by James_K »

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.

Easiest way to get downvotes is to ask people not to give them. You just gotta ignore the haters.
Post reply on HN