ghcjs support

[imalsogreg]

It would be nice if we could parse yaml from code compiled by ghcjs. This should be possible by binding a .js yaml parsing library instead of the c lib-yaml library here in the yaml package and choosing between them using CPP macros.

It may be difficult to get the same level of error reporting from the available javascript libraries. I'm not sure. The most popular js yaml parser seems to be js-yaml

Have you thought about anything around the issue of ghcjs? What conditions would you want to see met if you would take a PR for this kind of thing?

[snoyberg]

I'm open to the idea, but this is the first time I've tried something like this. It would probably make more sense to put the GHCJS-specific bindings in a separate package and conditionally depend on it.

[imalsogreg]

The trouble is that one of my application's dependencies (groundhog) parses YAML, rather than me depending on yaml directly myself - if it were the latter case I would just depend on a separate package as you suggest. groundhog's maintainer suggested I look into patching yaml.

Option 1 would be for me to patch your yaml package and add a two modules like Data.Yaml.Lite, which would only export things that both libyaml and js-yaml are capable of (no streaming), choosing between which one to actually export through CPP. Then I'd ask groundhog to depend on Data.Yaml.Lite.

If you're not into that (I understand - it dirties up yaml), then Option 2 is just to see if groundhog is willing to take the CPP and conditionally bring in a different package for the little yaml parsing it does.

The deciding factor is probably whether or not there are other commonly used libraries that do yaml parsing and may want to be ghcjs compatible. If so, then it may make most sense to put the CPP here in yaml, along with my promise to stay on top of any bugs that introduces.

[snoyberg]

To clarify: I was saying that there should be a separate package the binds to a Javascript YAML library, and then this yaml package could use it conditionally, depending on whether the implementation is ghc or ghcjs.

[imalsogreg]

Ah, I didn't realize that you meant this. That sound fine to me. The only thing really required to make everything transparent for downstream users is that yaml would provide a module with the same name and similar set of exported functions under both compilers, so that groundhog doesn't need to consider what compiler is used during its build.

[snoyberg]

Yup. We already have a good approach to this I think: Text.Libyaml is very much about the C library, so we'd probably hide that for GHCJS, and then expose the same Data.Yaml for both compilers.

[imalsogreg]

Thanks. I'll see if I can get a patch together for this.

[snoyberg]

Closing since there's no progress here.