News for hackers. Stuff that matters.
Re:Pratt parsing is a black box by vinipsmaker on Tuesday November 03, 2026 @04:01PM (#50358134)
Author here.

I was using Pratt parsing for almost a year in a macro-heavy language that I've been developing before finally sitting down on my chair to write my thoughts on Pratt parsing. Code is closed right now because I don't want LLMs training on my code before 0.1, but I'll open source it again later.

Happy to answer questions.

Re:Pratt parsing is a black box by p1necone on Tuesday November 03, 2026 @05:03PM (#50358883)
Tangential - on the 'use [] instead of <>' advice that you referenced in the post, I wish more languages would experiment with making types first class values that just get passed in regular () braces instead.

With erased static types, you can do arbitrary operations on types-as-values at compile time and just compile the static result into the runtime code, so it doesn't even cost anything at runtime to do this. Generic functions just turn into curried functions with the type params as their first param set.

Re:Pratt parsing is a black box by convolvatron on Tuesday November 03, 2026 @05:45PM (#50359313)
in logic programming you can just use normal predicates for arbitrary types also.

my understanding is that this makes certain typing decisions undecidable? I agree though the the special parallel type language is a huge amount of added complexity and source of pain.

Re:Pratt parsing is a black box by p1necone on Tuesday November 03, 2026 @05:54PM (#50359385)
> special parallel type language is a huge amount of added complexity and source of pain

This was exactly what initially motivated me to write my own language. I was spending a bunch of time writing complex types in typescript (for SQL query builder type stuff - essentially data schema -> TS type transformation) as what was essentially just a bunch of regular boolean logic and iteration that would be simple, but because the 'type' world uses a completely different syntax to the 'value' world it gets unreadable really fast.

My language was originally basically "what if Typescript had types as first class values and wasn't permanently tied to the unsound foundation of Javascript", but I've been finding various other rabbit holes to fall into along the way.

Re:Pratt parsing is a black box by tyromaniac on Tuesday November 03, 2026 @08:11PM (#50360388)
I believe zig does this
Re:Pratt parsing is a black box by p1necone on Wednesday November 04, 2026 @04:23PM (#50371757)
Yeah zig was definitely a big inspiration - implementing type system stuff as comptime code execution gives you a bunch for free that would otherwise be pretty tricky to implement.
Re:Pratt parsing is a black box by vinipsmaker on Tuesday November 03, 2026 @09:51PM (#50360992)
My own language doesn't try to unify both worlds (values from "type" world and values elsewhere), but my macros can be configured to happen in the type world. From a macro for the type world, you can run normal code to return whatever type you want. It's not the same thing you're talking about, but it's another interesting thing you can do.
Re:Pratt parsing is a black box by ogogmad on Wednesday November 04, 2026 @01:08PM (#50369308)
Wondering how that compares to dependent types.
Re:Pratt parsing is a black box by p1necone on Wednesday November 04, 2026 @04:21PM (#50371734)
I think they are essentially dependent types, I'm just coming at it from the "idiot with a laptop who hasn't read up on type theory" direction, and trying to fit everything into the "but what if it was just another place the user can write regular code" hole.