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

Alberto G. Corona agocorona at gmail.com
Tue Jun 9 21:52:55 UTC 2020


Thanks Chris. That is great news.

I just wanted to include the client-side of my own framework, axiom.

https://hackage.haskell.org/package/axiom

El mar., 9 jun. 2020 a las 22:19, Chris Smith (<cdsmith at gmail.com>)
escribió:

> Hi Alberto,
>
> The answer to your question has changed: yes, this now includes
> client-side JavaScript frameworks.  You can now find the reflex-dom
> tutorial from https://reflex-frp.org/tutorial running on CodeWorld at
> https://code.world/haskell#PahNrX2gsrB7SlSnvKvtMaw.
>
> Are there other client-side frameworks you're interested in?  The one
> restriction that remains is that the app must start with a blank page and
> build the UI dynamically.  The CodeWorld environment does not host assets
> like stylesheets and images, so if they are used, they must be either
> hosted elsewhere or delivered as a data-scheme URL.
>
> Hope that helps,
> Chris
>
> On Mon, Jun 8, 2020 at 5:42 PM Chris Smith <cdsmith at gmail.com> wrote:
>
>> (Sorry for the delay.  I overlooked this question.)
>>
>> > It is OK to include client-side Javascript frameworks?
>>
>> I was about to say no.  But now that you've got me thinking, perhaps I
>> could change this.  I described by thinking at
>> https://github.com/google/codeworld/issues/1362.  So my better answer is
>> "not yet".
>>
>> On Tue, Jun 2, 2020 at 7:41 AM Alberto G. Corona <agocorona at gmail.com>
>> wrote:
>>
>>> 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.
>>>
>>

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


More information about the Haskell-Cafe mailing list