@sun The documentation explains everything in more detail. I found it easy to understand, but I also worked with Haskell before and that permanently rewires your brain

Afterwards I'll do JSON-LD. Straight from baby mode to "oh god oh fuck, why am I doing this to myself" ​​

Long term plan is an ActivityPub server which implements my ideas to fix microblogging (see my recent posts). If nobody picks them up, I'll just do it myself. Either it turns out they're bad and it was simply a fun little experiment, or they're good and maybe this prompts other servers to follow suit

Long term plan is an ActivityPub server which implements my ideas to fix microblogging (see my recent posts). If nobody picks them up, I'll just do it myself. Either it turns out they're bad and it was simply a fun little experiment, or they're good and maybe this prompts other servers to follow suit

@volpeon@icy.wyvern.rip Exactly.

Afterwards I'll do JSON-LD. Straight from baby mode to "oh god oh fuck, why am I doing this to myself" ​​

Since Koka has no network stdlib yet, I'll have to implement URI and IRI handling first ​​

Since Koka has no network stdlib yet, I'll have to implement URI and IRI handling first ​​

Since Koka has no network stdlib yet, I'll have to implement URI and IRI handling first ​​

Well, guess what
I need to write a module for unit testing, too ​​

Well, guess what
I need to write a module for unit testing, too ​​

Well, guess what
The community stdlib has one and it's good, so they spared me the effort ​​

I was about to add unit tests for the IRI parser and found a nice JSON file with lots of test cases. I have JSON parsing, so that's good. What I don't have is a nice way to decode the generic json type to a specific type presentation, like with Aeson's FromJSON. I could still get all the test cases from the JSON file without it, but the rest of the application needs to handle JSON as well and then a decoder abstraction would be really good to have. So writing a decoder module is next ​:brdFlat:​

edit: Never mind again. I keep missing stuff because I keep looking for Haskell-like solutions, but Koka is simply different.

The application crashes when the JSON is too large. I bet it's because Koka's parser combinator library makes every single step backtrackable.

It's actually not too difficult to avoid backtracking if you make the subparsers smarter. I just didn't do it because it also makes them less readable, but oh well.
So right now I parse booleans like this, for instance: string("true") || string("false"), which means it tries the first parser, and on failure the second one (and therefore the consumed input must get "un-consumed").
The smarter solution is to pick the right branch directly so there is no "un-consuming" necessary. Like this:

val c = one-of("tf")
if c == 't' then
  string("rue")
else
  string("alse")

I removed all backtracking and it can handle larger JSON files now, but I still need to remove a very large chunk of the tests file to avoid the crash. ​​

I removed all backtracking and it can handle larger JSON files now, but I still need to remove a very large chunk of the tests file to avoid the crash. ​​

Looks like it's a known issue with ctl effects (which parsers use): github.com/koka-lang/koka/issues/279
There's one more idea I want to try, but otherwise I'll just accept it for now