[Haskell-cafe] Library maintainers: Include your library in CodeWorld web-based Haskell environment

[Chris Smith]

Thanks for the questions.

1. Yes, network I/O is excluded.  The only real exceptions here are
stdin/err/out, and code that's specifically written to work in GHCJS, such
as JavaScript.Web.XMLHttpRequest and JavaScript.Web.WebSocket modules in
ghcjs-base.

2. Depending on bytestring is fine, because it has a shim that makes it
work with GHCJS.  I believe
https://github.com/ghcjs/ghcjs/tree/ghc-8.6/lib/boot/shims is a list of
shimmed libraries that you don't need to worry about depending on.

3. Exporting inessential TH features is fine.  It's just that people
attempting to use your library via CodeWorld won't be able to use
them, since CodeWorld's web interface will refuse to build anything that
enables Template Haskell.

It looks like your project is completely excluded only because of the
network I/O.  If the network I/O is not necessary and you could exclude the
dependency using a combination of "#ifdef ghcjs_HOST_OS" in source and "if
impl(ghcjs)" in the cabal file, then it could still work.  But, of course,
of the network I/O is the whole point, then it's not going to work out.
JavaScript

On Mon, Jun 1, 2020 at 2:30 PM Viktor Dukhovni <ietf-dane at dukhovni.org>
wrote:

> On Mon, Jun 01, 2020 at 11:37:12AM -0400, Chris Smith wrote:
>
> >
> https://github.com/google/codeworld/blob/master/codeworld-available-pkgs/codeworld-available-pkgs.cabal
> >
> > Packages that fit here are:
> >
> > 1. No I/O, except for stdin/out/err.  Since CodeWorld runs code in a web
> > browser, there is no filesystem, for example.
>
> I assume this also precludes network I/O?
>
> > 2. Do not rely on native libraries, or have dependencies that do.  This
> all
> > depends on the library building with GHCJS.
>
> I guess this also excludes `bytestring`, which uses memcpy(), memchr(),
> and writes directly allocated memory?
>
>     -- | Wrapper of 'mallocForeignPtrBytes' with faster implementation for
> GHC
>     --
>     mallocByteString :: Int -> IO (ForeignPtr a)
>     mallocByteString = mallocPlainForeignPtrBytes
>
> and all of its dependencies?
>
> > 3. Do not require use of Template Haskell by clients.  It's okay if your
> > package needs template Haskell to build, but people using your library
> via
> > CodeWorld cannot yet use TH themselves.
>
> Is it that Template Haskell features in modules are not available to
> users, or that modules that export even "inessential" TH features are
> precluded.
>
> For example, can the platform support a module that exports a
> convenience TH "splice", if the same can be done slightly less
> conveniently (e.g. run-time, rather than compile-time error checks) at
> runtime via alternative functions?
>
> [ My current project does network I/O, uses `bytestring`, and provides
>   TH-splices for two types of compile-time validated literals, so I
>   would assume is a non-starter on all three counts. ]
>
> --
>     Viktor.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200601/3b9fdbfa/attachment.html>