Updates for psc 0.7

[hdgarrood]

I still need to test the ordArray instance, it's not immediately clear how to do that (since if you try to install purescript-console, you get another version of purescript-prelude in your bower_components...)

[paf31]

I ran into the same issues when I tried to implement this. I landed on using Int as the return type (-1, 0, 1), which isn't ideal, but I think it's better than paying the price of four extra function arguments. I'd also rather avoid the impure callback.

[paf31]

See the version in tests/prelude.purs in the compiler repo. It uses Number, but you get the gist.

[garyb]

Wouldn't the extra arguments be simpler? That doesn't impose any cost on using the function as they're curried in at instance-definition-time.

[paf31]

I guess that's true. I maintain my stance on the impure bit though :)

[garyb]

Agreed! I'm playing around with an alternative implementation now.

[garyb]

There's a bug in the prelude version by the way, both inner functions accept ys.

[garyb]

Also i is never incremented!

[paf31]

Oops :) I guess it's not used then.

[paf31]

D'oh. I actually put it in there to make things compile, then forgot about it. I meant to go back and fix it up.

[hdgarrood]

The ordArray instance is broken - compare [] [0] gives EQ. I'm working on tests now.

[paf31]

Looks nice thanks. For the testing, I usually delete the extra Prelude from bower_components. I was thinking we would add a separate directory with its own bower.json for tests anyway.

[hdgarrood]

There's a new ordArray instance in here now, which seems to work. It's based on the one in the compiler currently.

You can run the tests by doing:

$ psc test/Main.purs src/**/*.purs bower_components/*/src/**/*.purs --main | node

I'm not good enough with gulp to work out how to make this into gulp test.

[garyb]

I did something similar in purescript-arrays: https://github.com/purescript/purescript-arrays/blob/master/gulpfile.js#L44-L49

[paf31]

Looks good to me. I was thinking that for tests, we could eventually work on a separate test suite project for each core library. We could even use quickcheck that way.

@garyb Looks good, merge?

[garyb]

Maybe we should break out a purescript-assert or something that provides zero-dependency assertions so we can use it across any of the projects above quickcheck in the dependency hierarchy.

[garyb]

Yep,

[paf31]

👍 for purescript-assert, but not for the reason you said necessarily. I would rather have the option of using quickcheck, but separate the project out so we don't get circular dependencies.

[garyb]

My only concern about that is the thing we have with the core-tests library currently - nobody knows it exists, and we don't check those tests when making updates or add new cases for new features. That's not unfixable, we just have to make sure whatever it is is integrated into the travis build for the corresponding libraries.