Implementing FFI for external packages

[purescript-python]

Implementing FFI for external packages

[mikesol]

Sounds good.

Just FYI, quickcheck works just fine with a basic example using the port you made!

module Main where

import Prelude

import Effect (Effect)
import Effect.Console (log)
import Test.QuickCheck (quickCheck)

main :: Effect Unit
main = do
  quickCheck \n -> n + 1 == 1 + n

[thautwarm]

Thanks for your interest!
For example, to support purescript-enum, we write a git(it can be bitbucket/gitlab hosted one) project:
purescript-enums.py

Check its project structure and the correspondence between it(the FFI project) and purescript-enum

Then you can register it here: ffi index mirror

We solve FFI issues by using an FFI index mirror, and you can also fork it to make your own one, if you want you can ask us more details, and if not just make a PR to ffi index mirror

[thautwarm]

Besides, so far it seems that you cannot implement purescript-quickcheck because it seems quickcheck used the internal representation of chars and strings.

We now map purescript strings to python strings, but in python, a string is an array of chars, and can be randomly indexed, while in languages "correctly implemented unicode strings", a char in a string can be 1 or 3 byte(s), where a string is essentially an array of uint8 and cannot be randomly indexed.

[thautwarm]

@mikesol we now working on purescript-quickcheck

[mikesol]

Great! I just saw it on your github. So if I understand correctly, the blocker is their use of the String type? While I still need to dig deeper into this project, it seems that it would be useful to have interop between purescript String and python-purescript, as lots of purescript projects use String. I agree that native support for unicode strings would be really nice, as it is a feature needed by most apps that treat client data like names and addresses.

If you could write up a separate issue for this problem, I can take a look at it and see if I can dive in!

[thautwarm]

@mikesol
Hello!

So if I understand correctly, the blocker is their use of the String type?

You're right.

I agree that native support for unicode strings would be really nice, as it is a feature needed by most apps that treat client data like names and addresses.

We now map purescript String to Python str, which does have native unicode support. The problem here is, python's string representation is different from JS ones, that Python cannot expose string's internal code units to users.

Python strings are aligned strings(this can be memory inefficient), hence can be randomly accessed. Each character in a Python string is not fixed length, unlike a code unit.

We may use python bytes for purescript String, which have code units, but it will make things harder to support EFFICIENT native unicode. This issue has some details, if you want we can talk.

I received your email and I'm glad to have a chat with people from your company. However recently my research is very very urgent.. If possible I want to postpone it for a few days..

[thautwarm]

@mikesol I don't remember if I've told you some particular things about FFI implementation, but I'd add it here:

1. null in JavaScript maps to None in Python, Unit in PureScript maps to () in Python.
2. A JavaScript function function f(x) { ... } should be written def f(x = None): ... in python.

The list might be extended in the future, which is for being compatible because some purescript libraries do use some JS-specific behaviors.