On Apr 26, 2010, at 09:33 , John Goerzen wrote:
It would, however, be nice if the language allowed you to override
default instances with the code in your own package.
Many other languages refer to this kind of thing as "monkey patching"
and warn against it because of the problems it causes
On 04/25/2010 03:47 PM, Ivan Lazar Miljenovic wrote:
So you recommend having packages specifically for instances?
My main problem with this is if you want a custom variant of that
instance. Let's take FGL graphs for example with instances for
QuickCheck's Arbitrary class. Maybe you want arbitr
On Mon, Apr 26, 2010 at 06:47:27AM +1000, Ivan Lazar Miljenovic wrote:
> My main problem with this is if you want a custom variant of that
> instance. Let's take FGL graphs for example with instances for
> QuickCheck's Arbitrary class. Maybe you want arbitrary graphs that are
> simple, or maybe m
Ivan Lazar Miljenovic schrieb:
> Henning Thielemann writes:
>> My conclusion was: Never define orphan instances privately. If an
>> instance cannot be added to the packages that provide the associated
>> type or the class, then discuss the orphan instance with the maintainers
>> of the type and th
Henning Thielemann writes:
> My conclusion was: Never define orphan instances privately. If an
> instance cannot be added to the packages that provide the associated
> type or the class, then discuss the orphan instance with the maintainers
> of the type and the class and setup a package that prov
John Goerzen schrieb:
> My second example was the addition of instances to time.
My conclusion was: Never define orphan instances privately. If an
instance cannot be added to the packages that provide the associated
type or the class, then discuss the orphan instance with the maintainers
of the t
On Sat, Apr 24, 2010 at 08:48:07PM +1000, Ivan Lazar Miljenovic wrote:
> Ross Paterson writes:
> > Same major version: any code using fully explicit imports that worked
> > with the old version will work with the new version, in the same way.
>
> By this you mean that additions have been made?
A
Ross Paterson writes:
> Same major version: any code using fully explicit imports that worked
> with the old version will work with the new version, in the same way.
By this you mean that additions have been made?
--
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
_
On Sat, Apr 24, 2010 at 08:21:04PM +1000, Ivan Lazar Miljenovic wrote:
> Mads Lindstrøm writes:
> > But that would be an API change. It is of cause a question of how strict
> > we want to be. I have seen several times that commercial software
> > developers denies changes bugs, as the fix would co
Mads Lindstrøm writes:
> But that would be an API change. It is of cause a question of how strict
> we want to be. I have seen several times that commercial software
> developers denies changes bugs, as the fix would constitute API changes.
> We obviously do not want to go there, but we could bump
Hi
On Sat, 2010-04-24 at 19:47 +1000, Ivan Lazar Miljenovic wrote:
> Mads Lindstrøm writes:
> > You could automatically generate QuickCheck tests for many pure
> > functions. It will not catch every API change, but it would catch some.
> > It would have caught the API change that John mentioned.
Roman Leshchinskiy writes:
> BTW, the versioning policy doesn't seem to even mention
> semantics. Perhaps we could add some text to the effect that it is a
> good idea to bump the version number if the semantics changes
> sufficiently even if the types don't?
Sounds like a good idea; at a guess I
On 24/04/2010, at 19:25, Ivan Lazar Miljenovic wrote:
> Roman Leshchinskiy writes:
>> John Goerzen gave one in the very first post of this thread: the fix
>> to old-locale which didn't change any types but apparently changed the
>> behaviour of a function quite drastically. Another example would
Mads Lindstrøm writes:
> You could automatically generate QuickCheck tests for many pure
> functions. It will not catch every API change, but it would catch some.
> It would have caught the API change that John mentioned.
As in comparing the old and the new functions?
> But automatically generat
Hi
On Sat, 2010-04-24 at 19:25 +1000, Ivan Lazar Miljenovic wrote:
> Roman Leshchinskiy writes:
> > John Goerzen gave one in the very first post of this thread: the fix
> > to old-locale which didn't change any types but apparently changed the
> > behaviour of a function quite drastically. Anothe
Roman Leshchinskiy writes:
> John Goerzen gave one in the very first post of this thread: the fix
> to old-locale which didn't change any types but apparently changed the
> behaviour of a function quite drastically. Another example would be a
> change to the Ord instances for Float and Double whic
On 24/04/2010, at 18:54, Ivan Lazar Miljenovic wrote:
> Roman Leshchinskiy writes:
>
>> On 24/04/2010, at 18:06, Ivan Lazar Miljenovic wrote:
>>> I would think that the API is all the
>>> functions/classes/datatypes/instances/etc. exported from the library in
>>> combination with their types.
>>
Roman Leshchinskiy writes:
> On 24/04/2010, at 18:06, Ivan Lazar Miljenovic wrote:
>> I would think that the API is all the
>> functions/classes/datatypes/instances/etc. exported from the library in
>> combination with their types.
>
> So the semantics of those functions doesn't matter at all?
W
On 24/04/2010, at 18:06, Ivan Lazar Miljenovic wrote:
> Roman Leshchinskiy writes:
>
>> On 24/04/2010, at 07:29, Don Stewart wrote:
>>
>>> Oh, the Platform has very strict standards about APIs,
>>
>> What is an API? The package versioning policy only seems to talk about
>> types and function s
Roman Leshchinskiy writes:
> On 24/04/2010, at 07:29, Don Stewart wrote:
>
>> Oh, the Platform has very strict standards about APIs,
>
> What is an API? The package versioning policy only seems to talk about
> types and function signatures. John's old-locale example shows that
> this is not enoug
On 24/04/2010, at 07:29, Don Stewart wrote:
> Oh, the Platform has very strict standards about APIs,
What is an API? The package versioning policy only seems to talk about types
and function signatures. John's old-locale example shows that this is not
enough.
Would it perhaps make sense for at
On 24/04/10 01:34, Ivan Lazar Miljenovic wrote:
> Keith Sheppard writes:
>> What Gwern said for 1) and 3)
>>
>>> 2) Not all head repositories are kept stable/buildable at all times.
>>>
>>
>> Isn't it bad practice to not have a buildable repo? In any case
>> package owners would be free to use or
jgoerzen:
> David Menendez wrote:
>> On Fri, Apr 23, 2010 at 10:11 PM, John Goerzen wrote:
>>> Don Stewart wrote:
Oh, the Platform has very strict standards about APIs,
When a package may be added:
http://trac.haskell.org/haskell-platform/wiki/AddingPackages
>>> That looks l
David Menendez wrote:
On Fri, Apr 23, 2010 at 10:11 PM, John Goerzen wrote:
Don Stewart wrote:
Oh, the Platform has very strict standards about APIs,
When a package may be added:
http://trac.haskell.org/haskell-platform/wiki/AddingPackages
That looks like a very solid document. Does it a
On Fri, Apr 23, 2010 at 10:11 PM, John Goerzen wrote:
> Don Stewart wrote:
>>
>> Oh, the Platform has very strict standards about APIs,
>>
>> When a package may be added:
>> http://trac.haskell.org/haskell-platform/wiki/AddingPackages
>
> That looks like a very solid document. Does it also app
Don Stewart wrote:
Oh, the Platform has very strict standards about APIs,
When a package may be added:
http://trac.haskell.org/haskell-platform/wiki/AddingPackages
That looks like a very solid document. Does it also apply when
considering upgrading a package already in the platfor
Ivan Lazar Miljenovic wrote:
I think the "release early, release often" slogan is an affect on this
as well: we encourage library writers to release once they have
something that _works_ rather than waiting until it is perfect. The
fact that we encourage smaller, more modular libraries over larg
David Leimbach wrote:
I think managers expect magic bullets and holy grails... sometimes they
just end up with "holy cow"'s (or other more interesting 4 letter words)
instead.
The good news for me, at least, is that *I* am the manager. (Yep, the
company is small enough for that.) Actually,
On Fri, Apr 23, 2010 at 12:17 PM, John Goerzen wrote:
> Don Stewart wrote:
>
>> I'll just quickly mention one factor that contributes:
>>
>>* In 2.5 years we've gone from 10 libraries on Hackage to 2023
>> (literally!)
>>
>> That is a massive API to try to manage, hence the continuing move to
Gwern Branwen writes:
> On Fri, Apr 23, 2010 at 7:17 PM, Ivan Lazar Miljenovic
> wrote:
>> 2) Not all head repositories are kept stable/buildable at all times.
>
> Perfect, meet better. Wait, no no - aw goddammit Perfect! Why do you
> do this every single time? *You* get to mop the floor this tim
Keith Sheppard writes:
> What Gwern said for 1) and 3)
>
>> 2) Not all head repositories are kept stable/buildable at all times.
>>
>
> Isn't it bad practice to not have a buildable repo? In any case
> package owners would be free to use or ignore the data as they like,
> but I'm pretty sure it wo
dagit:
> Hmm...But who would be willing to take on the hard, tedious, and time
> consuming
> work of maintaining the CI build system? I think for this build system effort
> to really take off a group of a few deadicated volunteers would be necessary.
>
CI for the HP would be really easy, and ex
On Fri, Apr 23, 2010 at 4:49 PM, Don Stewart wrote:
> ivan.miljenovic:
> > Don Stewart writes:
> >
> > > I'll just quickly mention one factor that contributes:
> > >
> > > * In 2.5 years we've gone from 10 libraries on Hackage to 2023
> (literally!)
> > >
> > > That is a massive API to try t
What Gwern said for 1) and 3)
> 2) Not all head repositories are kept stable/buildable at all times.
>
Isn't it bad practice to not have a buildable repo? In any case
package owners would be free to use or ignore the data as they like,
but I'm pretty sure it would be useful to many.
Best, Keith
stephen.tetley:
> On 23 April 2010 21:14, Jason Dagit wrote:
> [Snip]
> > We don't (yet), have a tool to help detect when
> > a change in version number is needed or what the next version should be. We
> > leave this up to humans and it turns out, humans make mistakes :)
>
> Hi All,
>
> Did any
On Fri, Apr 23, 2010 at 7:17 PM, Ivan Lazar Miljenovic
wrote:
> Keith Sheppard writes:
>> Set up a server to poll the "Source-Repository head" of every hackage
>> package that includes one in it's cabal file, then rerun the build any
>> time a change is detected. This may be a good excuse to impl
ivan.miljenovic:
> Don Stewart writes:
>
> > I'll just quickly mention one factor that contributes:
> >
> > * In 2.5 years we've gone from 10 libraries on Hackage to 2023
> > (literally!)
> >
> > That is a massive API to try to manage, hence the continuing move to
> > focus on automated QA o
Keith Sheppard writes:
> Set up a server to poll the "Source-Repository head" of every hackage
> package that includes one in it's cabal file, then rerun the build any
> time a change is detected. This may be a good excuse to implement a
> pluggable continuous integration server in haskell too alo
Sorry, "rerun the build" means rebuild my package and all of my
package's dependencies...
On Fri, Apr 23, 2010 at 7:11 PM, Keith Sheppard wrote:
>> 1) The buildbot will catch dependencies with compile errors, but only
>> after the package has been pushed, and there is no easy way for
>> packagers
> 1) The buildbot will catch dependencies with compile errors, but only
> after the package has been pushed, and there is no easy way for
> packagers to check that this won't happen
>
An alternate solution that can be done completely outside the hackage loop:
Set up a server to poll the "Source-R
Thomas Hartman writes:
> 1) The buildbot will catch dependencies with compile errors, but only
> after the package has been pushed, and there is no easy way for
> packagers to check that this won't happen
Don't forget, there are valid reasons why hackage will sometimes fail to
build a package: mi
Don Stewart writes:
> I'll just quickly mention one factor that contributes:
>
> * In 2.5 years we've gone from 10 libraries on Hackage to 2023
> (literally!)
>
> That is a massive API to try to manage, hence the continuing move to
> focus on automated QA on Hackage, and automated tools -- n
So the situation is
1) The buildbot will catch dependencies with compile errors, but only
after the package has been pushed, and there is no easy way for
packagers to check that this won't happen
2) There are many important packages that will pass a compile check
but not a runtime check.
Well, 2
Thomas Hartman wrote:
> 1) Folks, what exactly is the situation with buildbots?
If I'm not mistaken, the buildbots run *after* the package has been
pushed to hackage. Thats already too too late.
Erik
--
--
Erik de Castro Lopo
h
On 23 April 2010 21:14, Jason Dagit wrote:
[Snip]
> We don't (yet), have a tool to help detect when
> a change in version number is needed or what the next version should be. We
> leave this up to humans and it turns out, humans make mistakes :)
Hi All,
Did anyone sign up to work on this as a G
jgoerzen:
> Don Stewart wrote:
>> I'll just quickly mention one factor that contributes:
>>
>> * In 2.5 years we've gone from 10 libraries on Hackage to 2023
>> (literally!)
>>
>> That is a massive API to try to manage, hence the continuing move to
>> focus on automated QA on Hackage, and auto
Thomas Hartman wrote:
1) Folks, what exactly is the situation with buildbots?
If that's going to happen, then ideally we would have a way to run tests
as part of the hackage acceptance process. For instance, the change to
a time format string wouldn't break anything at compile time, but my
1) Folks, what exactly is the situation with buildbots?
2) Easily available images for installing virtualized environments
could also ameliorate the pain, no?
wrt 1) It seems to me that in an ideal world you could have a
candidate for uploading to hackage, but before uploading you could
push a mag
On Fri, Apr 23, 2010 at 11:34 AM, John Goerzen wrote:
>
> A one-character change. Harmless? No. It entirely changes what the
> function does. Virtually any existing user of that function will be
> entirely broken. Of particular note, it caused significant breakage in the
> date/time handling
On Fri, Apr 23, 2010 at 12:17 PM, John Goerzen wrote:
>
> Out of those 2023, there are certain libraries where small changes impact a
> lot of people (say base, time, etc.) I certainly don't expect all 2023 to
> be held to the same standard as base and time. We certainly need to have
> room in t
Don Stewart wrote:
I'll just quickly mention one factor that contributes:
* In 2.5 years we've gone from 10 libraries on Hackage to 2023 (literally!)
That is a massive API to try to manage, hence the continuing move to
focus on automated QA on Hackage, and automated tools -- no one wants
to
I'll just quickly mention one factor that contributes:
* In 2.5 years we've gone from 10 libraries on Hackage to 2023 (literally!)
That is a massive API to try to manage, hence the continuing move to
focus on automated QA on Hackage, and automated tools -- no one wants
to have to resolve thos
It is somewhat of a surprise to me that I'm making this post, given that
there was a day when I thought Haskell was moving too slow ;-)
My problem here is that it has become rather difficult to write software
in Haskell that will still work with newer compiler and library versions
in future ye
53 matches
Mail list logo