I'm now writing a JSON parser in Koka.
-
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
-
@volpeon I have a CS degree and I'm ashamed I don't know what most of this means
@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
-
@volpeon I have a CS degree and I'm ashamed I don't know what most of this means
-
@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
@volpeon This language looks neat, thanks for mentioning it. -
Afterwards I'll do JSON-LD. Straight from baby mode to "oh god oh fuck, why am I doing this to myself"
@volpeon
JavaScript Object Notation for Linked Data
JavaScript Object Notation Low Density -
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.
-
@volpeon I have a CS degree and I'm ashamed I don't know what most of this means@sun @volpeon the only one that i'm not super clear what they mean is 'composable'
'composable'
https://en.wikipedia.org/wiki/Composability
stateless & self-contained apparently, though the wikipedia article needs love so it's probably a recent-ish term
and maybe 'ambient state'
'ambient state' seems pretty straightforward : just a background state
https://www.hp.com/us-en/shop/tech-takes/what-is-ambient-computing -
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.
@volpeon@icy.wyvern.rip BTW aber Vorsicht, mit zeitgemäßen Funktionen und einer anständigen App für iOS und Android könntest Du erfolgreicher sein als Mastodon.
-
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
@volpeon going down the next rabbit hole? -
@volpeon going down the next rabbit hole?
@stefan The grind never ends
-
Since Koka has no network stdlib yet, I'll have to implement URI and IRI handling first
Positive side effect compared to Haskell: I can unify the URI and IRI code because if there aren't any standards, I am the one making them :brdCool: In Haskell, they were in separate packages and it was kinda clunky
-
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 @volpeon@icy.wyvern.rip An absolut unit by birb
-
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 -
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. -
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.
-
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") -
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.
