Skip to content
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

Racket/Hackett FFI + contract generation #31

Open
lexi-lambda opened this issue May 31, 2017 · 0 comments
Open

Racket/Hackett FFI + contract generation #31

lexi-lambda opened this issue May 31, 2017 · 0 comments
Labels

Comments

@lexi-lambda
Copy link
Owner

Like Typed Racket, Hackett should support safe interop with Racket, with boundaries protected with contracts. The interoperation story is more complicated with Hackett because it’s semantically more distant from Racket than Typed Racket is. For example:

  • Hackett is a lazy language, so values need to be forced when crossing from Hackett to Racket. In fact, they need to be recursively forced, so values that cross the boundary probably need to, at a bare minimum, implement a deepseq-style NFData typeclass.

  • Hackett functions are curried, which are unpleasant and unidiomatic to use from Racket.

  • Hackett has typeclasses, and typeclass resolution often can’t be done based on runtime values (for example, it can be based on the return type or even a phantom type with no runtime evidence), so it’s probably not possible to call typeclass-constrained functions from Racket.

  • Hackett is pure, so Racket code could potentially break invariants that Hackett code assumes. This is probably unavoidable, though, and Hackett users can technically use unsafe-run-io! themselves if they want, anyway.

It would be possible to create To-Racket and From-Racket typeclasses, or something like that, which have type signatures that include an entirely opaque Racket datatype, with some built-in instances for primitive datatypes. This way, conversions could only be defined in terms of the built-in conversions, and the typeclasses could be used to guide contract generation. The obvious downside of this is that crossing a boundary would be enormously expensive, so maybe there’s a way to do something similar using a typed representation of contracts (type-indexed contracts?) that would be more efficient.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant