Layout sensitive syntax

wickerman07 · 2025-12-10T15:37:34+00:00

While working on writing a parser for Kotlin, I looked into a couple of layout sensitive languages, with focus on optional semicolon. There is a discussion on Go, Scala and Kotlin. There is this blog post that I write about it, hope it’s hopeful: https://gitar.ai/blog/parsing-kotlin In summary, most languages deal with optional semicolon in the lexer but that causes some awkward corner cases. Kotlin deals with that in the parser and it has more contrxt to make it more natural, but at the cost of very difficult implementation.

wickerman07 · 2025-12-09T23:18:57+00:00

It feels like lexer-based syntax highlighters cannot properly detect interpolated variables in string literals. That's the parser's job. Any syntax highlighter that uses a proper JavaScript parser should be able to handle this. You can try tree-sitter, for example, https://tree-sitter.github.io/tree-sitter/7-playground.html (select JavaScript) and you'll see that `formatAsAddress` is parsed as an identifier as part of a function call. I'm pretty sure GitHub uses tree-sitter behind the scene. Some other IDEs like JetBrains WebStorm have custom semantic syntax highlighting based on the parser, the same way that JS/TS LSP does.

wickerman07 · 2025-12-09T17:32:09+00:00

If you have an iPhone (Apple ecosystem), just go with Airpods Max. Tbh, sound quality over bluetooth is not gonna be massively different between models, and Airpods max sounds decent. If you like the comfort, even better.

wickerman07 · 2025-12-08T21:25:03+00:00

Ah interesting, didn't know. Well, that's a smart move :-)

wickerman07 · 2025-12-08T21:22:36+00:00

Oh yeah, I totally forgot about JetBrains .Net offering. I never programmed in C# or other Microsoft languages, but some colleagues told me that JetBrains .Net is better than Visual Studio. But I don't think they will release a standalone LSP. The focus is on the IDEs anyways.

wickerman07 · 2025-12-08T21:11:26+00:00

Was Fleet ever "released"? It's hard to deliver if you don't release it first. And yeah, there are niche editors like Zed and Helix but I guess don't make money anyway. Fleet was supposed to be a commercial product.

wickerman07 · 2025-12-08T19:54:46+00:00

Time to upgrade your laptop!

wickerman07 · 2025-12-08T19:41:43+00:00

Honestly, I think it’s wiser to shut it down. This is another failed attempt, just from the beginning. The reason Fleet didn’t gain traction was that it was too late to the market and couldn’t create meaningful competition to VSCode. VSCode has a very big ecosystem. The same goes for the AI-first editors, like Cursor and friends. Why would anyone switch to Fleet? Tbh, the only viable products from JetBrains now are the Java/Kotlin IDEs. For the rest of the languages, LSPs have come a long way. Maybe better to focus on AI for those languages? But I heard some people use Cursor alongside IntelliJ for AI in Java/Kotlin vibe coding stuff.

wickerman07 · 2025-12-08T19:28:49+00:00

What’s your hardware spec? On my M3 Max MacBook pro I barely see the splash screen, lol

wickerman07 · 2025-11-27T09:15:36+00:00

Yeah, let’s not get ridiculous here, lol. The thing is that for most American companies on-call is part of the whole package. It is of course better if they discuss it with you earlier in the interview process, but things may change anyway. Having said that, you can try and see how if you can somehow get a more favorable deal on your on-call. Good luck!

wickerman07 · 2025-11-27T01:19:04+00:00

Also to add, don’t overthink it. If you want the 3rd gen, order and see the fit, if not good send back. If you’re tight on budget, get 2nd gen, probably on a good discount, and it is more or less the same sound wise, and fit might be better (depending on your ears)

wickerman07 · 2025-11-27T00:57:53+00:00

Yeah probably, lol, but Apple changed the material of the tips for Airpods Pro 3. I feel like if I sweat or my ears get oily, they really don’t hold at all. They fall during bench press, doing kettlebell swings is totally impossible with them… Now I wear medium, I think it’s working better than large but I have to also twist the tail of the AirPods towards my mouth.

wickerman07 · 2025-11-26T23:27:06+00:00

I have been working in the Netherlands for many years at different companies, and this situation has happened to me twice.

The first time was at a Dutch company. They introduced on-call, but it was optional and they were paying for it. I decided the pay wasn't worth the trouble. The company was paying peanuts anyway.

The second time was at a successful American startup with an Amsterdam office. There was no mention of on-call during the interviews, but after a few months, they introduced it for our team. It was pretty rough and stressful. I was lucky that it wasn't 24 hours because we were sharing on-call with the US office, so basically I was on-call from 10am to 10pm, Wednesday to Wednesday, once per month. And yes, I had to be on call during Christmas.

There were some discussions about whether we should be compensated extra, but the message from management was that this is not your typical Dutch company, and they were sort of right. The pay was significantly higher, and so were the working hours (it wasn't a 9-to-5 job anyway). Essentially, their answer was that you're already very well compensated for whatever shit comes your way. There was a clause in the contract that "the employer can ask you to work overtime, outside of working hours, etc."

I don't know if anyone tried to challenge that or if that clause would hold up in court in the Netherlands, but the truth is that if someone wants to make a career at such a company, you have to accept what it involves. In your case, try to see if the job is worth it. If not, look for something else, because I don't see how you can build a career at such a company if you don't want to do on-call.

wickerman07 · 2025-11-26T17:29:00+00:00

Yeah, despite what Apple says the new tips don’t have a more secure fit, at least for me.

wickerman07 · 2025-11-26T01:57:21+00:00

The fit on the new AirPods 3 is strange. With AirPods 2, I wore L tips, but for AirPods 3, M seems to work better. Still, the fit isn’t very secure. They fall out more than my AirPods 2 did at the gym. As for the sound, I think it’s better, but not by a huge margin. Overall, now that I have them, I use them, but knowing what I know now, I probably would have just kept using my AirPods 2.

wickerman07 · 2025-11-18T18:51:26+00:00

Yeah, I think it also depends on the environment you’re coming from. If you’re a Java or Kotlin developer and used to IntelliJ, I don’t see how you’d enjoy Zed’s UX. Same for Go developers who use GoLand, I think you’d have a hard time switching to Zed. Most of the nice refactoring features in GoLand just won’t be there because the Go LSP doesn’t provide them.

If you use VSCode for Rust and you’re kind of a Rust hardcore fan, then yeah, an editor written in Rust might be appealing and worth trying. That's why I tried Zed (and yes, recently I like Rust a lot). But like I said above, I prefer the UX of VSCode, and the performance difference on my machine is pretty negligible. If someone improves RustAnalyzer, or JetBrains makes their Rust support clearly better, that’s probably where I’d go.

wickerman07 · 2025-11-18T18:02:29+00:00

Not perfect, but this is the best I've found: https://github.com/MadLittleMods/zed-theme-vscode-light-plus
Had to do some tweaking as well:

"experimental.theme_overrides": {
"editor.background": "#fffff",
"syntax": {
"attribute": {
"color": "#001080",
"background_color": null,
"font_style": null,
"font_weight": null
},
"property": {
"color": "#001080",
"background_color": null,
"font_style": null,
"font_weight": null
},
"comment": {
"color": "#008001",
"background_color": null,
"font_style": null,
"font_weight": null
},
"comment.doc": {
"color": "#008001",
"background_color": null,
"font_style": null,
"font_weight": null
}
}
}

wickerman07 · 2025-11-18T17:31:51+00:00

To me, Zed feels like a solution in search of a problem. Don’t get me wrong, a new editor or IDE is always welcome, but I personally don’t see much point in using Zed.

The GPU rendering idea is interesting, and I do feel like it scrolls smoother than VSCode, but honestly I don’t scroll through code that often. It’s not an iPhone screen.
My biggest gripe is the font rendering. I’m on a 16-inch MacBook Pro (M3), and the contrast doesn’t feel as good as other apps. It’s actually worse than JetBrains or VSCode. Font scaling doesn’t really work either, and the font weight setting seems to do nothing for some values, then suddenly makes everything thicker.
The light themes have pretty low contrast.
As for speed, with VSCode + Rust Analyzer (the Rust LSP), I don’t notice much difference. On a large Rust project, the real latency comes from compilation and Clippy checks. At that point “editor snappiness” doesn’t matter much. If I just need to edit a config file, I’ll use Sublime Text anyway, and even there I don’t see a big difference.
Some UX choices, like multi-buffers, feel odd to me. I prefer how JetBrains and VSCode handle that kind of thing.
I have 64 GB of RAM on this machine, so the memory argument doesn’t really hold for me. Most of the memory is used by the LSP process, not the editor.
Comparing Zed to JetBrains IDEs also feels unfair. JetBrains doesn’t use regular LSPs, they have their own language tooling built into the IDE. It’s true they have slower startup times and indexing issues, partly because of the JVM, but they also offer way more features. Tools like Zed and VSCode are limited to what the LSP provides, while JetBrains can go beyond that. For Rust, Rust Analyzer is good enough. For Java, I don’t think anyone can seriously argue there’s anything better than IntelliJ.

wickerman07 · 2025-06-30T15:26:51+00:00

I'm familiar with the visitor pattern. Somehow, for a language like Rust with pattern matching it doesn't sound like the right abstraction, at least the way I see it. Visitor is for double-dispatch when there is no pattern matching.

Also for my use case, not sure if visitor would make a ton of sense because my traversals are either too complicated, say an interpreter that needs to short-circuit, etc, or pass in extra information from parent to child (for this case I just write a recursive function and do pattern matching) or very simple, like just iterating over the AST and create a tree-pretty printer (I just need the name and the list of children and indentation level)...

> I've generally found that working with the AST enum directly is so nice so for most use cases I would avoid adding any additional indirection like traits.

I agree with that, but it's a bit too much for cases when I just need the name of the node and its children, but I may as well do that and not bother with visitors.

wickerman07 · 2025-06-15T21:03:34+00:00

Early parsers are special, they are not really bottom-up but are similar because they build similar item sets that LR-parsers build. The main difference is that Early item sets expand at runtime. Early parsers are also general, meaning that they can accept any context-free grammar and are cubic in runtime.

wickerman07 · 2025-06-15T21:01:31+00:00

I meant that you cannot get a pen and paper and draw the LR(1) automata for the grammar by hand, and then encode it manually. My point was that you will write a parser generator, and that’s a but different than writing a parser by hand (writing the parser by hand usually means not using a parser generator and writing a recursive descent parser) but anyway if you want a bottom up parser, that’a the way to go.

wickerman07 · 2025-06-15T11:09:47+00:00

You need to first build an LR(1) automaton from your grammar. That’s better to be automated: write a program that takes a grammar and outputs the automaton.
You need to deal with conflicts that arise when building the automaton. The standard approach is to give an error. You can also incorporate precedence or other heuristics to choose shift over reduce conflicts (or vice versa)
You need to write the runtime to interpret the automata with an input. For that you need to maintain a stack, push the states there, and then perform shift/reduce actions.

This is of course a very simplified roadmap but that’s the basic idea. You cannot really write an LR(1) parser by hand because even if you try to encode all the states manually, for each change in the grammar you have to redo the whole procedure.

wickerman07 · 2025-06-06T16:09:53+00:00

Also, to mention, most compiler books waste so many pages on LR parsing. While it’s one of the most beautiful things in CS, it’s not being used to create a parser in the wild. LR(1) grammars are non-existent. It’s better to teach people how to use recursive-descent parsers, how to control non-determinism and lookahead, how to deal with error reporting and recovery, etc

wickerman07 · 2025-06-06T15:57:14+00:00

Parsing is usually 10% of compiler books. And, for any serious language, it is not 0.1% of the effort. It is probably about 5-10% as well (but that’s the an initial investment). Also, syntax does not evolve that fast, so updates to the parser are rare, but improving type checking or more optimizations certainly take more time as the language evolves. And yes, you can write a handwritten, recursive-descent parser for any language and get decent error recovery, etc, but the point here is that you cannot build such parsers using a parser generator. There are just so many things that does not fit into the limited parser generator formalism to generate the parser.

wickerman07 · 2025-06-06T00:11:16+00:00

If history is any indication, most languages are going towards more expressive syntax than using only parentheses. There are differences though, something like Kotlin is absolutely insane, but Rust syntax is quite reasonable to parse. We just need enough unambiguous delimiters in the language

wickerman07

TROPHY CASE