haste-compiler
haste-compiler copied to clipboard
valderman
Aeson-compatible JSON module
Since Aeson is the de facto standard for doing JSON in Haskell, Haste should probably move in that direction for its JSON API.
What is the state of this now? I want to use geojson library, but it depends on aeson...
It will definitely be in 0.5, which is mainly held up by issues surrounding the GHC 7.10 port.
What is the state of this currently? I've been exploring the Haskell JS/Web ecosystem a bit, and while it looks like ghcjs might come out as the winner at some point, Haste kind of feels like the most usable solution overall. Ghcjs has practically no documentation, is insanely huge and hard to understand. I am currently in the process of writing a small hobby project using Haste, and the biggest pain here is not being able to share JSON serialization code between my backend and frontend(Haste) code.
I would definitely be interested in helping out with making Haste Aeson compatible, but I don't have a very good understanding of the Haste internals, where to start or even the underlying reasons for Haste not being compatible with Aeson.
It seems to be caused by Haste's broken template haskell support.
And I need more document of Haste's internal as well... I'm studying Haste's source and the comments do not seem to be enough to describe the whole architecture.
I'd really like to make this happen, but i fear my Haskell skills might be too lacking for this. If i understood it right, we first need to support Template Haskell in Haste. Is there something not very complex that I can start working on?
There are essentially two ways to do this: one is to patch aeson to not use TH (the quick and hacky way), or fix TH support in Haste once and for all. In both cases, some sort of patch to aeson would be desirable (using JSON.parse would be nice for performance reasons), and fixing Haste's internal CString representation is more or less necessary.
Currently, C strings are represented as JS strings, which is an insane design decision that never should have been made. Instead, the representation should be the same as for all other pointer-like types: typed arrays. When this is done, actual TH support should not be that hard to implement.
So, I'm afraid the least complex part of the pipeline in getting aeson working involves fiddling with Haste's internal pointer representation. It's not necessarily hard, but it does probably require spending some time getting familiar with the code base.