I've decided to shelve my ideas about parallel parsing until a 2.0 release because I haven't been working on that at all, though it's still the plan. Since I had to update party for gleam 1.0, I decided I'd just push what's been very handy for my PL projects, as a regular parser combinator library, and make it the 1.0 release since it's already so useful. See the CHANGELOG.md for the changes I made. The project is also licensed finally.
#Party 1.0 released!
1 messages · Page 1 of 1 (latest)
Party time
i think the competition for the most "html templating" and "parser combinator" libraries is very close 😂 gleamlins love exactly two things, it seems
I must be the odd gleamlin out.
I just enjoy writing parser combinator libraries lol, I knew full well there was no demand (:
its a good one ^.^ maybe my favourite
cant wait to come last
my real trick with nibble is i made the api so awkward to consume that nobody would be bothered to benchmark it vs the others
You like it more than nibble?
That's quite nice to hear lol
I've been under the assumption that anyone would be smarter to use nibble and I only use party because it's mine
I doubt party is faster
i like nibble's names for the combinators a little more than party, but thats just a gleamy/elmy thing and i think you have some that i didnt think about
i think i was on to an interesting idea with the whole lexer step first but no one has managed to work out how to use it other than me so im not sure i can call the library a success ^.^
the lexer is a cool idea but ironically often these days when i want to reach for a parser i just want the combinators 😅 rarely am i doing something big enough to warrant that whole extra step
Yeah my names come from the fact that I use a lot of haskell's Parsec library for parsing, so it's familiar to me
This does sound cool. I've thought for a while that I'll have options for more advanced combinators that can be much more performant; a lexing step sounds like it'd be a great fit for the sort of stuff I had in mind. I do think that being restricted to that approach doesn't sound super ergonomic though
I often think "damn I forgot an obvious important parser" and then still forget to add it. But I hope with my recent additions it's pretty complete now. And I don't worry too much about this because I have satisfy for those who need more
i do like that nibble comes with a pratt parser, you should steal that
Alright, good to know for things I might add in the future
But I will say that my making this 1.0 is kind of a declaration to myself and others that I'm not really planning on touching it for a while lmao
yeah thats exactly what i did 😂
@scarlet elk you mentioned supporting a separate lexer step, and someone on github convinced me to support arbitrary token types (they found a backwards-compatible way with type synonyms that I think is pretty neat) so I figured I'd show you. I don't think this api is too tough to consume, but I did add a bunch of docs notes telling people to use the older types and functions wherever possible lol https://github.com/RyanBrewer317/party/tree/RyanBrewer317/generalized-token-type
The pratt parser thing still feels like too big an undertaking for right now but we'll see
I would loooove a pratt parser API in party but totally understand if its too much. It's just really nice to get away from writing precedence rules by hand
you could peek (heh) nibble's source and port it to party pretty trivially
some of the combinators might have slightly different names but thats about it
call it pratt_party and publish it
Pratty
@junior drum thank you for those new combinators! They've been published in Party 1.0.5 now.