Make a new release to Hackage

[pepeiborra]

The version in Hackage is >2 years old, doesn't build with ghc 8 and doesn't come with a stack yaml file either.

[tim-m89]

Hi pepeiborra,

This package is somewhat deprecated in favour of major re-write which is on gitlab. I wrote some notes about why the re-write here.

If you want to experiment with the other project, clone each of the following repos into a common directory since the stack.yaml files used there assume relative paths:

https://gitlab.com/tim-m89/clr
https://gitlab.com/tim-m89/clr-host
https://gitlab.com/tim-m89/clr-bindings
https://gitlab.com/tim-m89/clr-test-app

Then build and run the test app. If you're using windows, you'll probably have to have a custom linker invocation due to ghc issue #12186

[pepeiborra]

Hi Tim, I work for a Haskell team at Barclays Capital, and we are looking for an interoperabilty solution to call .Net from Haskell, so this is great news. And it works ! I already ran the example app in my Mac Os laptop. Can you let me know: - What is the overall status of the rewrite (the issue tracker in gitlab is empty) ? - Would you have any reservations about us using it in production ? What are your thoughts on the inline-c/java/r approach ? I think it’s quite appealing from a usage point of view, but more importantly the implementation is surprisingly concise. After going through the Salsa thesis I have to say there is a lot of complexity going on at the type level, which the inline-java approach successfully avoids with: 1. A low level binding: this would correspond to your clr-host with explicit String-y invocations and zero/minimal conversions 2. A mid level binding, using the type system to guide the method selection but no subtyping/narrowing/coercing. 3. A quasi quoter, leveraging the ability to embed bytecodes in the Haskell binary using static pointer magic. Because the heavy lifting (overloading resolution, implicit coercions, etc) is left to the host compiler, the Haskell implementation is much lighter. This article is a brilliant summary: http://blog.tweag.io/posts/2016-10-17-inline-java.html Thanks and let me know your thoughts, Pepe

…

On 3 Feb 2017, at 20:24, Tim Matthews ***@***.***> wrote: Hi pepeiborra, This package is somewhat deprecated in favour of major re-write which is on gitlab. I wrote some notes about why the re-write here <https://gitlab.com/tim-m89/clr/blob/master/README.txt>. If you want to experiment with the other project, clone each of the following repos into a common directory since the stack.yaml files used there assume relative paths: https://gitlab.com/tim-m89/clr <https://gitlab.com/tim-m89/clr> https://gitlab.com/tim-m89/clr-host <https://gitlab.com/tim-m89/clr-host> https://gitlab.com/tim-m89/clr-bindings <https://gitlab.com/tim-m89/clr-bindings> https://gitlab.com/tim-m89/clr-test-app <https://gitlab.com/tim-m89/clr-test-app> Then build and run the test app. If you're using windows, you'll probably have to have a custom linker invocation due to ghc issue #12186 <https://ghc.haskell.org/trac/ghc/ticket/12186> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABoAjxyE2voz9O8bhC6eS0V4nxvnMY_ks5rY4zxgaJpZM4L2dWU>.

[tim-m89]

As for the different approaches of how to achieve this, I first experimented with a unique quasi quoted syntax that was using just mono's embedding API. I didn't take me long to come to the same consensus as everyone else on over using TH.

I liked the Salsa approach as it was a make the most of the type system effort, building on a solid foundation. Haskell's type system can encode anything from an OO type system (probably not formally proven but I'm sure of it).

I've been asked about the inline approach before, I think it's great, but perhaps a bit niche use case? There's still a problem of how to get data into and out of each eco system, so that's why I feel like it's best to focus on the building the bridge first, then perhaps add on the inline feature at a later date.

I sent you an email containing this^.

As for the original issue, my opinion is that there's not that much point in further maintenance on this package specifically. The 'clr' project is a direct continuation of this with no intention of undoing the features/goal of Salsa. There's still parts of code here that need to be dropped into the rewrite for a few things though.