[ANN] random-shuffle package

older
Using cabal to build an exportable...

Manlio Perillo

19 Mar 2009 19 Mar '09

10:41 a.m.

I'm pleased to announce the availability of random-shuffle package. The cabalized package is available at http://haskell.mperillo.ath.cx/random-shuffle-0.0.2.tar.gz The code is based on http://okmij.org/ftp/Haskell/perfect-shuffle.txt Thanks to Oleg Kiselyov for sharing this! I have made some changes to Oleg code: - changed coding style to what seems to be a more common Haskell coding style - Used Int, instead of Integer, for the index type - Forced some strict evaluation. It was a trial and error effort (I'm not an expert), but results are very impressive. Example program and timings/memory usage, are on: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=2600 NOTE: I don't plan to upload the package to Hackage, for the near future. I'm thinking to add some other functions that operate on lists, like Python random module (random.choice, random.sample), and the partitioning function I have posted the other day (although I'm not sure this is a generic useful function). However, in this case, the package name should be changed. I'm not sure it is a good idea to release a package that implements only one function (but I may be wrong). Feedbacks (on current random-shuffle and future additions) are welcomed. Regards Manlio Perillo

Show replies by date

Max Rabkin

19 Mar 19 Mar

11:31 a.m.

On Thu, Mar 19, 2009 at 4:41 PM, Manlio Perillo wrote:

...

However, in this case, the package name should be changed. I'm not sure it is a good idea to release a package that implements only one function (but I may be wrong).

Personally, I think that there is little harm in releasing a package if it does something useful in a not-totally-broken way. Especially if you plan to extend it. I wrote the hmm package, which is basically only two functions, but that's all one needs to work with hidden Markov models, so that's all there is (I *am* busy expanding its functionality that's needed in a program I'm writing, but the basics are already there). I also uploaded the kmeans package, which exports a single function -- a friend of mine had the code, and it was useful to me, so it might be useful for others. And what does a clustering package need besides a cluster function? --Max

Manlio Perillo

12:21 p.m.

Max Rabkin ha scritto:

...

On Thu, Mar 19, 2009 at 4:41 PM, Manlio Perillo wrote:

...
However, in this case, the package name should be changed. I'm not sure it is a good idea to release a package that implements only one function (but I may be wrong).

Personally, I think that there is little harm in releasing a package if it does something useful in a not-totally-broken way. Especially if you plan to extend it.

Ok, I will add the package on Hackage, thanks. One last thing. Yitzchak Gale kindly posted an example with the implementation of my `partition` function: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=2485 using shuffle'. Now, I would like to implement a `sample` function, like the one in the Python random module: http://docs.python.org/library/random.html#random.sample Is an implementation based on shuffle good? Or a more efficient implementation is possible? How should be the interface of this sample function? Should it return the sampled list *and* the original list without the sampled elements? Or it is better to just return the sampled list? If both partition and sample functions can be implemented efficiently using shuffle', then it may be appropriate to add these two functions inside the random-shuffle package. Thanks Manlio

Colin Paul Adams

12:30 p.m.

New subject: Checking in packages to Hackage early in development cycle?

...

...
...
...
...
"Max" == Max Rabkin writes:

Max> On Thu, Mar 19, 2009 at 4:41 PM, Manlio Perillo Max> wrote: Max> Personally, I think that there is little harm in releasing a Max> package if it does something useful in a not-totally-broken Max> way. Especially if you plan to extend it. Suppose you intend to extend it, and are not sure yet if the interface will change as a result? -- Colin Adams Preston Lancashire

John Van Enk

12:32 p.m.

New subject: Checking in packages to Hackage early in development cycle?

Generally, I mark my stuff as Experimental, and make note of it in my announcements. /jve On Thu, Mar 19, 2009 at 12:30 PM, Colin Paul Adams

...

wrote:

...

...
...
...
...
...
"Max" == Max Rabkin writes:

Max> On Thu, Mar 19, 2009 at 4:41 PM, Manlio Perillo Max> wrote:

Max> Personally, I think that there is little harm in releasing a Max> package if it does something useful in a not-totally-broken Max> way. Especially if you plan to extend it.

Suppose you intend to extend it, and are not sure yet if the interface will change as a result? -- Colin Adams Preston Lancashire _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Brandon S. Allbery KF8NH

12:39 p.m.

New subject: Checking in packages to Hackage early in development cycle?

On 2009 Mar 19, at 12:30, Colin Paul Adams wrote:

...

...
...
...
...
...
"Max" == Max Rabkin writes:

Max> On Thu, Mar 19, 2009 at 4:41 PM, Manlio Perillo Max> wrote:

Max> Personally, I think that there is little harm in releasing a Max> package if it does something useful in a not-totally-broken Max> way. Especially if you plan to extend it.

Suppose you intend to extend it, and are not sure yet if the interface will change as a result?

Generally you indicate this by changing the minor version: 0.3.0, 0.3.1, etc. have compatible APIs, but 0.4.0 has an incompatible API. And with major version 0, API breakage is expected in new releases. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Brandon S. Allbery KF8NH

12:56 p.m.

New subject: Checking in packages to Hackage early in development cycle?

On 2009 Mar 19, at 12:39, Brandon S. Allbery KF8NH wrote:

...

On 2009 Mar 19, at 12:30, Colin Paul Adams wrote:

...
...
...
...
...
> "Max" == Max Rabkin writes:

Max> On Thu, Mar 19, 2009 at 4:41 PM, Manlio Perillo Max> wrote:

Max> Personally, I think that there is little harm in releasing a Max> package if it does something useful in a not-totally-broken Max> way. Especially if you plan to extend it.

Suppose you intend to extend it, and are not sure yet if the interface will change as a result?

Generally you indicate this by changing the minor version: 0.3.0, 0.3.1, etc. have compatible APIs, but 0.4.0 has an incompatible API. And with major version 0, API breakage is expected in new releases.

Oh, and to address your question more directly: it's by getting your package out there where people will find it (i.e. on hackage, since that's where people look) that you get more eyes on it and hopefully more ideas as to how to evolve it. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Duncan Coutts

20 Mar 20 Mar

6:30 a.m.

New subject: Checking in packages to Hackage early in development cycle?

On Thu, 2009-03-19 at 12:56 -0400, Brandon S. Allbery KF8NH wrote:

...

On 2009 Mar 19, at 12:39, Brandon S. Allbery KF8NH wrote:

...
On 2009 Mar 19, at 12:30, Colin Paul Adams wrote:

...
...
...
...
>> "Max" == Max Rabkin writes:

Max> On Thu, Mar 19, 2009 at 4:41 PM, Manlio Perillo Max> wrote:

Max> Personally, I think that there is little harm in releasing a Max> package if it does something useful in a not-totally-broken Max> way. Especially if you plan to extend it.

Suppose you intend to extend it, and are not sure yet if the interface will change as a result?

Generally you indicate this by changing the minor version: 0.3.0, 0.3.1, etc. have compatible APIs, but 0.4.0 has an incompatible API. And with major version 0, API breakage is expected in new releases.

We call it the Package versioning policy (PVP) http://www.haskell.org/haskellwiki/Package_versioning_policy Package authors are encouraged but not required to follow it. In the not too distant future you will be able to explicitly opt-in, in which case we will try to check that the package does indeed follow the policy and advising authors of dependent packages about the kind of version constraints they should use.

...

Oh, and to address your question more directly: it's by getting your package out there where people will find it (i.e. on hackage, since that's where people look) that you get more eyes on it and hopefully more ideas as to how to evolve it.

Yes, early feedback from users is invaluable in API design. Duncan

Colin Paul Adams

6:39 a.m.

New subject: Checking in packages to Hackage early in development cycle?

...

...
...
...
...
"Duncan" == Duncan Coutts writes:

Duncan> On Thu, 2009-03-19 at 12:56 -0400, Brandon S. Allbery KF8NH wrote: >> On 2009 Mar 19, at 12:39, Brandon S. Allbery KF8NH wrote:

...

...
On 2009 Mar 19, at 12:30, Colin Paul Adams wrote:

...
...
...
...
>> "Max" == Max Rabkin writes: >> >> >> >> Max> On Thu, Mar 19, 2009 at 4:41 PM, Manlio Perillo >> >> Max> wrote: >> >> >> >> Max> Personally, I think that there is little harm in >> releasing a >> Max> package if it does something useful in a >> not-totally-broken >> Max> way. Especially if you plan to >> extend it. >> >> >> >> Suppose you intend to extend it, and are not sure yet if the >> >> interface >> will change as a result? >> > >> > Generally you indicate this by changing the minor version: >> 0.3.0, > 0.3.1, etc. have compatible APIs, but 0.4.0 has an >> incompatible > API. And with major version 0, API breakage is >> expected in new > releases.

Duncan> We call it the Package versioning policy (PVP) Duncan> http://www.haskell.org/haskellwiki/Package_versioning_policy Duncan> Package authors are encouraged but not required to follow Duncan> it. In the not too distant future you will be able to Duncan> explicitly opt-in, in which case we will try to check that Duncan> the package does indeed follow the policy and advising Duncan> authors of dependent packages about the kind of version Duncan> constraints they should use. I missed the upper bounds on dependencies. How am I supposed to know what the upper bound is? >> Oh, and to address your question more directly: it's by getting >> your package out there where people will find it (i.e. on >> hackage, since that's where people look) that you get more eyes >> on it and hopefully more ideas as to how to evolve it. Duncan> Yes, early feedback from users is invaluable in API Duncan> design. So I announced my library this morning (long before I was intending to, but you guys are persuasive). This is my first released Haskell code, so full code reviews will be welcome. -- Colin Adams Preston Lancashire

minh thu

6:46 a.m.

New subject: Checking in packages to Hackage early in development cycle?

2009/3/20 Colin Paul Adams :

...

...
...
...
...
...
"Duncan" == Duncan Coutts writes:

Duncan> On Thu, 2009-03-19 at 12:56 -0400, Brandon S. Allbery KF8NH wrote:

...
...
On 2009 Mar 19, at 12:39, Brandon S. Allbery KF8NH wrote: On 2009 Mar 19, at 12:30, Colin Paul Adams wrote:

...
...
...
>>> "Max" == Max Rabkin writes:

Max> On Thu, Mar 19, 2009 at 4:41 PM, Manlio Perillo Max> wrote:

Max> Personally, I think that there is little harm in releasing a >> Max> package if it does something useful in a not-totally-broken >> Max> way. Especially if you plan to extend it.

Suppose you intend to extend it, and are not sure yet if the interface >> will change as a result?

Generally you indicate this by changing the minor version: 0.3.0, > 0.3.1, etc. have compatible APIs, but 0.4.0 has an incompatible > API. And with major version 0, API breakage is expected in new > releases.

Duncan> We call it the Package versioning policy (PVP)

Duncan> http://www.haskell.org/haskellwiki/Package_versioning_policy

Duncan> Package authors are encouraged but not required to follow Duncan> it. In the not too distant future you will be able to Duncan> explicitly opt-in, in which case we will try to check that Duncan> the package does indeed follow the policy and advising Duncan> authors of dependent packages about the kind of version Duncan> constraints they should use.

I missed the upper bounds on dependencies. How am I supposed to know what the upper bound is?

I don't know what is the consensus, but I always thought that dependencies should simply state what versions work. So the upper bound would be the current version. If a new version appears, just bump the version too, even if nothing changed in the code. Makes sense ? Thu

Duncan Coutts

7:07 a.m.

New subject: Checking in packages to Hackage early in development cycle?

On Fri, 2009-03-20 at 10:39 +0000, Colin Paul Adams wrote:

...

Duncan> We call it the Package versioning policy (PVP)

Duncan> http://www.haskell.org/haskellwiki/Package_versioning_policy

Duncan> Package authors are encouraged but not required to follow Duncan> it. In the not too distant future you will be able to Duncan> explicitly opt-in, in which case we will try to check that Duncan> the package does indeed follow the policy and advising Duncan> authors of dependent packages about the kind of version Duncan> constraints they should use.

I missed the upper bounds on dependencies. How am I supposed to know what the upper bound is?

If your packages depends on a package that follows the PVP then the upper bound is +0.1 than the latest version you know your package works with. For example suppose you need the zlib package. Suppose the minimum version you need is 0.4. Suppose that you tested it with version 0.5 and you were lucky at the bits of the API that changed were not the bits you were using. Then you would say: build-depends: zlib >= 0.4 && < 0.6 It's < 0.6 because that is the next breaking API version. If the next zlib release is compatible then it'd be something like 0.5.1.0 or 0.5.0.1. However zlib-0.6 would be a new version that breaks existing APIs. Since you have no idea which APIs I'm going to break when I release zlib-0.6 then you should play it safe and require any 0.5.x version but not 0.6. Make sense? This is why we need the PVP. Without it (or something similar) we cannot know what the right upper bound is. Putting in sensible upper bounds will make hackage much more reliable and less prone to breakage as new packages are released. It is definitely something we're trying to encourage (and something that needs tool support). Duncan

5907

Age (days ago)

5908

Last active (days ago)

List overview

Download

10 comments

7 participants

participants (7)

Brandon S. Allbery KF8NH
Colin Paul Adams
Duncan Coutts
John Van Enk
Manlio Perillo
Max Rabkin
minh thu