paulyoung / purescript-corefn

A library for working with the PureScript functional core.
Apache License 2.0
23 stars 7 forks source link

Ready to publish? #44

Open joneshf opened 6 years ago

joneshf commented 6 years ago

Heya! This package looks great! Any interest in publishing it for others to use?

paulyoung commented 6 years ago

Yeah, I've been thinking about it now that #42 has been merged and I've validated that it works as expected so far in PureSwift.

The only thing is that it's now only compatible with the corefn output of 0.12 so I was wondering if I should wait for that to be released.

What do you think?

joneshf commented 6 years ago

Gotcha.

Since the commit history looks pretty clean, how do you feel about publishing a version compatible with 0.11.7?

Looks like https://github.com/paulyoung/purescript-corefn/commit/646c996ac179b3f60f5abe40aa32ca005809e2c0 is the last commit to master before #42 got merged and there were no other commits to master in the meantime.

Did #42 contain fixes along with the conversion, or was it just conversion?

joneshf commented 6 years ago

Actually, that's maybe a big ask. Dunno what kind of maintenance you want to do on this library. Anyone can follow suit like you did on PureSwift and reference a commit.

paulyoung commented 6 years ago

42 was pretty much a straight port from Haskell and is fully featured whereas the work before that which was compatible with 0.11 only just about supported lambda calculus from what I remember.

The big motivation for switching to the 0.12 corefn output is that it's the only way (so far as I could tell) to support FFI in alternative backends. This issue I opened explains it a little bit: https://github.com/purescript/purescript/issues/3162

That, along with the hope that 0.12 might be released soon means I wasn't planning on supporting the 0.11 output.

FWIW, the branch of PureSwift that's using the new format is paulyoung/psw.

joneshf commented 6 years ago

Gotcha. Yeah, I tried that commit and it didn't parse anything :sweat_smile:.

Guess I'll hold out for the next version.

joneshf commented 6 years ago

Sorry, I know I said I would hold out, but I kinda just went ahead and did it since I don't know when 0.12 is coming out: https://github.com/paulyoung/purescript-corefn/compare/646c996ac179b3f60f5abe40aa32ca005809e2c0...joneshf:master. If you'd like to support 0.11.7, I can open a PR if you make a branch at 646c996ac179b3f60f5abe40aa32ca005809e2c0.

As far as finding FFI files, that's unfortunate. Seems like there's two common cases (as you pointed out): bower and psc-package. Probably can support those two cases explicitly and call it a day.

paulyoung commented 6 years ago

I just created a 0.11 branch 🙂

paulyoung commented 6 years ago

I think there’s still an issue with FFI in that you know the module name but not the package name.

paulyoung commented 6 years ago

For example, you have Control.Monad.Eff.Console but don’t know that it belongs to purescript-console

joneshf commented 6 years ago

Oh right. Hmm, that is unfortunate.

joneshf commented 6 years ago

Wait, could you do some processing to figure it out?

Again, assuming the two package managers, dip into the respective directories (bower_components or .psc-package) and map modules to packages. Anything that's not in that mapping has to be from the local source. Once you have a module, look it up in the mapping and fallback to the local source if it doesn't exist.

paulyoung commented 6 years ago

That sounds like it could work!

paulyoung commented 6 years ago

Should I make a release for the 0.11 stuff?

joneshf commented 6 years ago

Lemme throw in a functor instance, then yes!

paulyoung commented 6 years ago

I’m not sure how to approach versioning here. For example, if I make a v1.0.0 release for 0.11 output and then later make a v2.0.0 release for 0.12 output, what would happen when the 0.11 branch needs to make a breaking change?

joneshf commented 6 years ago

3.0.0? It's a breaking change for both 1.0.0 and 2.0.0.

I dunno, I'm pretty up in the air about versions. I'm probably not the best person to ask for advice :). Also, I'm fine with using a commit SHA for now if you don't want to think about it.

paulyoung commented 6 years ago

A somewhat radical proposal might be to have something like CoreFn.0.11.Module and CoreFn.0.12.Module 😯

joneshf commented 6 years ago

That works as well.