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

[Alberto G. Corona]

It is OK to include client-side Javascript frameworks?

El mar., 2 jun. 2020 a las 1:09, Chris Smith (<cdsmith at gmail.com>) escribió:

> 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.
>
> _______________________________________________
> 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.



-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200602/8f38235c/attachment.html>