New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Port ghcjs-base.GHCJS.Foreign.Callback as base.GHC.JS.Foreign.Callback for the GHC JavaScript Backend #150
Comments
I'm not CLC and this is a fairly naive question so feel free to ignore it, but shouldn't this live under the |
I think you're right that that's one correct place for it to live, but IMO since it's more about defining functions as a JavaScript "primitive" type, it's good for it to live near |
@JoshMeredith Could you provide motivation for this change? Currently the proposal doesn't mention why you need to move this module to In the context of the current discussion about the If there're any technical challenges that require to move this module to |
While I personally agree with such split-base proposals, the upsteaming began previous to these, and as such we already have a significant proportion of |
I agree that the base split shouldn't be a blocker for this. This should be voted on as per the status quo. |
This also seems orthogonal to me, based on my understanding of the other proposal. |
Yeah this is just an example of the issue that a Agreed for now just carry on ignoring splitting base, but remember this thing as motivation for split base thereafter.
|
Yes, I think that the JavaScript modules being conditionally compiled in |
AFAIU we are upstreaming a stable, battle-tested module from |
This is the kind of thing that's on the edge for me. Should it go in Is there no other place to put this code in the GHC source tree? |
It's critical for Haskell programs. GHC's JavaScript backend doesn't require any of the functionality implemented by this module. Rather, it is an entirely user-facing module that provides users with a way to interact with the browser (and JavaScript libraries in general - given the prevalence of callbacks). To not supply this functionality in The examples provided in the description are demonstrations of usage in user code. |
@JoshMeredith Thanks for clarifying the motivation behind this change and confirming that this module is indeed for I'm +1 on this. In general, it's an interesting design challenge. I would love to have But since the transition was already made with |
I assume the new module is to be guarded by |
Dear CLC members, any more non-binding opinions on this? |
+1 |
1 similar comment
+1 |
The |
This is indeed the case in the linked merge request. |
Dear CLC members, let's vote on the proposal to port @tomjaguarpaw @chshersh @mixphix @hasufell @angerman @parsonsmatt +1 from me. |
+1 |
4 similar comments
+1 |
+1 |
+1 |
+1 |
Thanks all, 6 votes in favour out of 7 are enough, approved. |
Code available at https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10128
Introduction
GHCJS previously implemented a
Callback a
data type, which is currently missing from GHC's JavaScript backend. This type represents functions passable in the FFI that use a more standard JavaScript calling convention - rather than the calling conventions used in the JS generated code.GHCJS supported functions up to 3 arity, and it supported various synchronicities of callbacks. Arguments are passed as an untyped
JSVal
- essentially a representation of a plain JavaScript value.Usage
To construct callbacks, the following functions are used depending on synchronisation and the existence (or lack thereof) of a return value:
Only the 1-arity signatures are demonstrated here, but sizes up to 3 - including 0 - are available.
These are expected to be used as a way to call into Haskell-generated code from regular JavaScript, via FFI imports. A simple example demonstrating this is as follows:
Callbacks as FFI "exports"
Callbacks enable a form of FFI "exports", through setting global variables:
Then, if our generated Haskell-main is called in the HTML head,
globalF
will be available as a callback for e.g. HTML buttons.Implementation
The
GHCJS.Foreign.Callback
module from theghcjs-base
package ports with minimal changes to the module and without changes to the current JavaScript backend (except for a few bugfixes that have already been merged).The text was updated successfully, but these errors were encountered: