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 wrote:

On Mon, Jun 01, 2020 at 11:37:12AM -0400, Chris Smith wrote:

...

https://github.com/google/codeworld/blob/master/codeworld-available-pkgs/cod...

...

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.

(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 wrote:

It is OK to include client-side Javascript frameworks?

El mar., 2 jun. 2020 a las 1:09, Chris Smith () 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 wrote:

...

On Mon, Jun 01, 2020 at 11:37:12AM -0400, Chris Smith wrote:

...

https://github.com/google/codeworld/blob/master/codeworld-available-pkgs/cod...

...

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.

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 () 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 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 wrote:

...

It is OK to include client-side Javascript frameworks?

El mar., 2 jun. 2020 a las 1:09, Chris Smith () 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 wrote:

...

On Mon, Jun 01, 2020 at 11:37:12AM -0400, Chris Smith wrote:

...

https://github.com/google/codeworld/blob/master/codeworld-available-pkgs/cod...

...

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.