Closed paf31 closed 8 years ago
That all looks sensible to me, I can't think of anything that has been missed. I have been using the code in https://github.com/bodil/pulp/pull/212/files (that is, my 0.9 compat PR) locally with code from 0.9 for the last couple of days and it seems ok. I'm going to wait for an 0.9.0 RC for the compiler and then test it more thoroughly then.
I'll definitely need to expand "name resolving" quite a bit to enumerate the various changes there. I'll post something here first then edit it in later :)
The way names are resolved has now been updated in a way that may result in some breakages. The short version is: now only names that have been imported into a module can be referenced, and you can only reference things exactly as you imported them.
Some examples:
Import statement | Exposed members |
---|---|
import X |
A , f |
import X as Y |
Y.A Y.f |
import X (A) |
A |
import X (A) as Y |
Y.A |
import X hiding (f) |
A |
import Y hiding (f) as Y |
Y.A |
Qualified references like Control.Monad.Eff.Console.log
will no longer resolve unless there is a corresponding import Control.Monad.Eff.Console as Control.Monad.Eff.Console
. Importing a module unqualified does not allow you to reference it with qualification, so import X
does not allow references to X.A
unless there is also an import X as X
.
Although the new scheme is stricter it should be easier to understand exactly what the effect of any given import statement is. The old resolution rules for qualified names were obscure and unexpected results could arise when locally-qualified module names overlapped with "actual" module names.
Module re-exports have also been tightened up as a result of these rules. Now if module X
is only imported as Y
, the re-export must list module Y
also. If a module is imported without being re-qualified then the original name is used.
I've tested PSCi with various core libraries, so I've checked that off.
I'm going to call the release notes done now. We can improve them still, but we have something pretty decent, I think.
I'll play a bit with psc-ide in a 0.9 project. I think there was one "The impossible happened" related to operators and maybe I can get that fixed today or tomorrow.
Actually, with the way the new operator aliases work, we have a regression inside psc-ide
. We currently cannot display type/kind information for operators/type operators.
Fixing this will be a little more involved, so for now I think it's best to display the name of the referenced function/type constructor as the type/kind, so the user can look that value up if he wants to.
@kRITZCREEK Could you create an issue for that please?
@garyb @hdgarrood @kRITZCREEK Is there anything preventing a release of 0.9.1 at this point?
Edit: perhaps we should come up with a list of immediate TODO items for after a release? Something like
I think the remaining items are lower priority, since we can mark 0.8.5 as the stable version or something like that, until we port enough of the contrib libraries over.
I think we're good to go :) I tested psc-ide
as well as I could, but it's currently impossible to find a "big" project that builds with 0.9.0.
So I think we should release 0.9.1, update all the libraries, document bugs or regressions, update the learning material and make 0.9.2 a bugfix release.
I've had good results with psc-ide on my project this weekend.
I added "Release on npm" to your immediate list, but nope, I think we're good to go.
Has anyone checked if everything with the core RCs compiles together currently?
Yes, everything works together, as of a couple of days ago at least.
Sent from my iPhone
On May 30, 2016, at 11:09 AM, Gary Burgess notifications@github.com wrote:
I added "Release on npm" to your immediate list, but nope, I think we're good to go.
Has anyone checked if everything with the core RCs compiles together currently?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
I'm double checking now :)
Ok, it's all good, just need to remember to add deprecation notes to:
purescript-arrows
(I think we're discontinuing this anyway? If not, it needs updates)purescript-coproducts
(now purescript-functor-coproducts
)purescript-functors
(now purescript-functor-products
)And I need to shake a leg on updating purescript-datetime
.
Does anything use arrows?
Sent from my iPhone
On May 30, 2016, at 11:30 AM, Gary Burgess notifications@github.com wrote:
Ok, it's all good, just need to remember to add deprecation notes to:
purescript-arrows (I think we're discontinuing this anyway? If not, it needs updates) purescript-coproducts (now purescript-functor-coproducts) purescript-functors (now purescript-functor-products) And I need to shake a leg on updating purescript-datetime.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
I think machines provides instances, and maybe some other things do, but I don't think anything uses it. The class is entirely subsumed by things profunctors offer anyway. It just has ArrowZero and ArrowPlus classes too, but no instances.
Since we have costrong now, I think we should deprecate it. We might want to deal with ArrowPlus at some point, but I'm not concerned about that right now.
Sent from my iPhone
On May 30, 2016, at 11:53 AM, Gary Burgess notifications@github.com wrote:
I think machines provides instances, and maybe some other things do, but I don't think anything uses it. The class is entirely subsumed by things profunctors offer anyway. It just has ArrowZero and ArrowPlus classes too, but no instances.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
I am not sure that Pulp should be checked off just yet, since I haven't managed to do a release yet (sorry). Also, I won't be able to do anything until this weekend, but that shouldn't really require delaying 0.9.1 as far as I can tell. So yeah, I think we're good to go.
As a note for webpack, I will follow-up the purescript 0.9.1 release with a compatible version. In terms of time-frame, may be closer to later in the week.
Thanks for the update @ethul!
@hdgarrood I'm not worried about Pulp, I've been using it since last week without any issues. It's more that it can be released. I think/hope users will start using 0.9.1 slowly, since it'll go out with a compatibility warning, so please don't feel rushed to get the release out.
@garyb Perhaps we should move deprecated libraries out into another organization? Bower should still resolve them, as long as we use GitHub to move them.
@paf31 I've made an org for that and invited you. Just moved the old purescript-monad-eff
over so far, as that already had a notice. I'll make PRs for notices for the others.
@paf31 Should we make a purescript-kleisli
for Kleisli
and Cokleisli
? They're in purescript-arrows
currently. Alternatively we could provide category instances for Star
and Costar
for the same behaviours, but I don't know if that's acceptable from a correctness point of view.
Should we make a purescript-kleisli for Kleisli and Cokleisli? They're in purescript-arrows currently. Alternatively we could provide category instances for Star and Costar for the same behaviours, but I don't know if that's acceptable from a correctness point of view.
I think we would be fine to add the Category
instances to profunctors
. I'm less sure about what to do with the Choice
instance for Cokleisli
since it uses Traversable
in place of Comonad
in Haskell's profunctors
. It is marked as "highly questionable", but I'm not sure if there is some distinction between (Co)Star
and (Co)Kleisli
that I'm missing.
cc @ekmett - what would you advise here?
@garyb I think we can tag a release today, when you're happy with the core libraries. Just let me know.
Now that 0.9.1 is out, contrib maintainers should please try to get their libraries up to date and released.
cc @cdepillabout @ethul @garyb @jasonzoladz @jdegoes @joneshf
Thanks!
Will take a look at what needs to happen tonight. Thanks for the heads up!
@paf31 Thanks for the heads up!
purescript-unicode is indirectly using purescript-aff
, so it's blocked by https://github.com/slamdata/purescript-aff/pull/55.
I'll update purescript-unicode
when purescript-aff
is updated for 0.9.1.
Is there a unified way to build libraries now? Much has changed since I was active.
@joneshf Generally, I'd say Pulp, but it's not been updated for 0.9.1 yet (should be this weekend hopefully).
For now, I'm using psc
directly, which is a bit simpler now:
psc 'bower_components/purescript-*/src/**/*.purs' 'src/**/*.purs'
Thanks!
If it's alright with you, I'd like to wait until pulp is up to date, and use modern build tools. Is there a timeframe for this issue to be finished?
I've heard it'll be done this weekend 🙂
@garyb I'll have time to work on purescript-dom
and purescript-react-dom
some more tonight or tomorrow. purescript-dom
depends on purescript-datetime
as well, so I can do that too while I'm at it.
I think I saw @garyb was working on datetime
so you might want to sync up with him.
Yeah, I'm nearly done with it I think. The JavaScript date type will be in a new library that is just a light wrapper around the native API, and then the existing datetime library will be more purescripty.
What do you think about having two libraries Node
and Browser
that implement node and browser APIs as close to specification as possible (the way purescript-dom
is implemented now) and everything else could be built upon them? Because if you think it is a good idea then I think now it is the best time for it :)
Sounds good, but I would like to build them using code generation from some IDL.
I don't think it's possible to do purely from IDL, they leave out lots of implementation details that need handling in PS. You could generate a skeleton, but it would need a lot of manual work still.
That's true, but I think there is still value there. These are low level libraries after all. It shouldn't matter if the types are coarser than they could be, since we expect other libraries to build on them anyway.
I just released pulp 9.0.0.
Lens is working with 0.9.1 now. I think that's the only contrib package I'm maintaining. Let me know if there are others.
Thanks @hdgarrood and thanks @joneshf !
That's a good point - do we have any way of getting a list of all the contrib packages that a particular person maintains?
Phil and Harry, thanks for all of your hard work. I'll update tomorrow.
On Saturday, June 4, 2016, Harry Garrood notifications@github.com wrote:
I just released pulp 9.0.0.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/purescript/purescript/issues/2151#issuecomment-223751677, or mute the thread https://github.com/notifications/unsubscribe/AIE1EDe0Swt9eqbIOEIpYUI6ULGcExQAks5qIWefgaJpZM4IkC6B .
I added a task to update Pursuit itself - we had "Update libraries" listed, but at the moment it's not possible to manually upload docs from 0.9.1 either.
purescript-unicode
has been updated to version 1.0.0 for PureScript 0.9.1.
Do other pursuit packages need to be updated to work with PureScript 0.9.1 (such as purescript-express)?
Yes, pretty much everything does.
Are we supposed to be releasing the libraries at 1.0.0+ now?
purescript-node
core-tests
psci
psc-ide-server
psc-publish
Did I miss anything? I suspect there are some tools which need to be added here, and it would be useful to create that list.
/cc @garyb @hdgarrood @ethul @kRITZCREEK