I spend all my time with Arc working on the forum, so JSON is more important to me than it might be to someone else who primarily focuses on the language.
I was working on the data export feature, which before just dumped a user's posts and comments as a printed statement, but I wanted it to export JSON because that's more portable. Racket has a really nice JSON parser, unfortunately all the forum data is templated, so I can't just pass it to Racket because it doesn't understand the type. There may be a way to get it to work at that level but I don't know what it is.
So I had to get an old JSON parser for Arc and rewrite a bit of it to be able to generate JSON from forum data. I think it was zck's parser but I'm not entirely sure ATM. It works, but it's an awkward workaround. Any data coming from the forum has to go through one parser, and any other data, such as from a remote API would be going through another (Racket's.)
>Is making it work just a matter of calling the Racket primitive on `rep.template` instead of `template`?
Yes, I had to hunt around to even know that existed, because it's not in the docs.
You can get to it from the "Type operations" link in the table of contents. Of course, you might've been drawn to the "Templates" page instead.
And unfortunately, that documentation describes Anarki's stable branch. Making documentation of similar quality for Anarki's master branch might be quite a bit more work. So even if you were familiar with tagged types already, the knowledge that template instances were a tagged type on Anarki master might be hard to discover.
I suppose a more ideal form of the documentation would describe on the "Templates" page that template instances were a tagged type with a certain representation. It could describe the direct implications of that, but it would also have a link to the "Type operations" page for more background.
>I suppose a more ideal form of the documentation would describe on the "Templates" page that template instances were a tagged type with a certain representation. It could describe the direct implications of that, but it would also have a link to the "Type operations" page for more background.
That would have been tremendously helpful, can we do that? Who actually maintains the documentation, can it be updated?
Perhaps we should maintain the docs only in plain-text and only within the repo, just because of the operational overheads of managing multiple branches. At least that way they won't seem to lie to a newcomer. I'm curious to hear what others think.