Support GHC JS backend #135
Conversation
|
Should we remove callbacks? That module has been upstreamed into |
| @@ -1064,15 +1063,6 @@ realFloatToJSON d | |||
| | otherwise = doubleValue (realToFrac d) | |||
| {-# INLINE realFloatToJSON #-} | |||
|
|
|||
| scientificToNumber :: Scientific -> Number | |||
There was a problem hiding this comment.
I don't remember this too well. I see that it was used in an instance that's commented out, and it's not exported - so I'd guess that I removed it because of an unused function warning.
| @@ -2,7 +2,8 @@ | |||
| ForeignFunctionInterface, JavaScriptFFI, EmptyDataDecls, | |||
| TypeFamilies, DataKinds, ScopedTypeVariables, | |||
| FlexibleContexts, FlexibleInstances, TypeSynonymInstances, | |||
| LambdaCase, MultiParamTypeClasses, DeriveGeneric #-} | |||
| LambdaCase, MultiParamTypeClasses, DeriveGeneric, | |||
| TypeOperators #-} | |||
There was a problem hiding this comment.
TypeOperators are not used in the diff, is this a GHC API induced change?
There was a problem hiding this comment.
I'm hazy on this too, but IIRC there was a warning for it. It might have been allowed in earlier versions of GHC without warning.
ghcjs-base.cabal
Outdated
| @@ -1,6 +1,6 @@ | |||
| cabal-version: 3.0 | |||
| name: ghcjs-base | |||
| version: 0.2.1.0 | |||
| version: 1.0.0.0 | |||
There was a problem hiding this comment.
What's the reasoning for a 1.0 release? Are we promising something stable? I would think we should bump a major version, for sure, but a 1.0 seems is too much, especially because I envision we'll have to make our own ghcjs-internal and ghcjs-base split.
There was a problem hiding this comment.
@hamishmack suggested this on slack a while ago as a way to break version bounds with projects using GHCJS. IMO, there's also the possibility of releasing with a new name, but I don't think it's necessary.
There was a problem hiding this comment.
I think the problem with a new name is that they should be mutually exclusive. If we keep the same name there is no way anyone will wind up with both in their build plan.
I wonder if we should use 0.8 or something to avoid confusion. It seems unlikely we will want to release any more non arch(javascript) versions.
| if (i >= 0) { | ||
| v += x.u1[i].toString(16); | ||
| i--; |
There was a problem hiding this comment.
this feels like it could be inlined into the previous while loop, probably not a worthwhile optimization without profiling though. Just wanted to mention it.
| for (; i >= 0; i--) { | ||
| v += x.u1[i].toString(16).padStart(4, '0'); |
There was a problem hiding this comment.
same here, this screams for some loop fusion, but best left for another time.
| } | ||
| } | ||
| return s + String.fromCharCode.apply(this, a); | ||
| return new TextDecoder().decode(arr.u8.subarray(off, off+len)); |
|
I had a quick read already, but will do a proper review at the end of today |
Co-authored-by: Jeffrey Young <jeffrey.young@iohk.io>
- Fixed some issues with the JS backend syntax translation introduced by ghcjs#135.
No description provided.