zero-fill shift right operator doesn't exist about purescript-native HOT 11 CLOSED

Funny, I just ran into this one when testing my C++ changes. In C++ and golang they need to be unsigned for the shift to zero fill. So that will need to be addressed.

from purescript-native.

Ah that makes sense. I already found a situation like this when reading a file in another module. It would be nice to have an backend independent file library. I would think the js foreign design makes that difficult since it enforces providing the foreign file in the same repo at build time. That probably needs compiler and build tool support: Dune added a feature called virtual modules that allows deferring an implementation https://dune.readthedocs.io/en/stable/variants.html. On the Haskell side, I think backpack provides similar features.

Otherwise, the libraries could be designed to make the bits that use node pluggable via a Monad or a taking things like argv as parameters. I was able to get the arg parser to work, but had to copy a lot of the module over and replace calls to argv, exit, etc.

I think that's enough to close this ticket, as this module no longer causes compilation errors.

from purescript-native.

FYI, I'll likely just remove this from the inliner (both backends), and it will have to be handled in the appropriate FFI library

from purescript-native.

Ok, so a zshr function would need to be added here https://github.com/andyarvanitis/purescript-native-go-ffi/blob/master/purescript-integers/Data_Int.go? It seems like something that go and c++ should be able to inline anyway.

from purescript-native.

Yup, that's the place.

It would be messy, since you need to convert to unsigned, then shift, then convert back to signed. And you probably want to do some error checking along the way.

from purescript-native.

I'm trying to validate the changes to the compiler and seeing what looks like it might be an incorrect definition in effect for bindE

panic: interface conversion: interface {} is func(interface {}) interface {}, not func() interface {}

goroutine 1 [running]:
github.com/purescript-native/go-runtime.Run(...)
	/Users/josephprice/go/pkg/mod/github.com/purescript-native/[email protected]/debug.go:15
github.com/purescript-native/go-ffi/purescript-effect.init.0.func2.1.1(0x13ea7a0, 0xc0001c6cc0)
	/Users/josephprice/go/pkg/mod/github.com/purescript-native/[email protected]/purescript-effect/Effect.go:19 +0x11f

I don't see anything wrong with the definition here https://github.com/purescript-native/go-ffi/blob/master/purescript-effect/Effect.go#L16

from purescript-native.

I can have a look. Are you able to share the code that exhibits the problem?

from purescript-native.

Yea I'll create a repo to demonstrate these issues.

from purescript-native.

Here's the repo https://github.com/joprice/purescript-native-test. I took an existing test repo I have with a bunch of examples and slimmed it down so it's in a bit of an odd shape. The failing example is in the "main" folder. This spago.dhall still has an experiment where I was building all the dependencies in the package set to see what built with the psgo compiler. I plan on going over each module and extracting a single function from each module so that it imports the go and builds it as a simple way to fuzz out some issues.

from purescript-native.

I just pushed a commit to minimize it a bit further, to reduce the number of dependencies and functions.

from purescript-native.

Thanks for the code, it definitely helped me find the issue.

Looks like it's not a bug. It's from a call to this from Node.Process:

argv :: Effect (Array String)
argv = mkEffect \_ -> process.argv

Which in turn comes from this (in same module):

mkEffect :: forall a. (Unit -> a) -> Effect a
mkEffect = unsafeCoerce

Which won't work with golang (javascript doesn't care).

Under other circumstances I'd call that a leaky abstraction, but the Node.Process module is specifically for Node.js, so I'd say it's fair enough.

from purescript-native.