[Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK

Andrew Coppin andrewcoppin at btinternet.com
Sat Jul 4 15:18:53 EDT 2009

Max Rabkin wrote:
> On Sat, Jul 4, 2009 at 8:38 PM, Andrew
> Coppin<andrewcoppin at btinternet.com> wrote:
>> A few reasons:
>> 1. I never knew it existed. ;-)
> A good reason. However, it's good to do a quick search over Hackage
> before uploading (or before writing) so you know what's out there.

Fair enough. ;-)

> Also, if you hadn't used an "AC-" prefix, you'd have had a name
> collision. Is there a particular reason why you want your name in the
> package name rather than just the author field?

Well, for example, there's seemingly half a dozen unrelated packages all 
called "binary", which is just confusing. I wanted to make sure my 
packages had unique names. (I mean, so do the existing binary packages, 
just not very useful ones...)

>> 2. It's mind-blowingly complex.
> Colour *is* complex. Which is why I'm so glad Russell O'Connor did all
> the hard work for me :)

Well, no, because now I'm going to have to spend a few hours trying to 
find out what CIE is before I can even use that library.

I think really it's just aimed at a different problem. It looks like 
it's trying to specify actual real-world colours. [It's news to me that 
this isn't fundamentally impossible...] I'm only trying to specify 
colours on a computer screen. And as we all know, computer screens 
aren't calibrated in any way, and the same RGB value looks different on 
each display. But then, I'm only trying to write a fractal generator, so 
CIE specifications are somewhat overkill here. ;-)

>> 3. It doesn't appear to provide arithmetic over colours.
> It provides darken, blend and addition (though addition is called
> mappend rather than (+)). signum, abs and fromInteger don't make a
> huge amount of sense for colours.

Yeah, I implemented signum and so forth for colours and vectors, but 
they're not particularly meaningful... [Insert remark here about 
Haskell's numeric class hierachy.]

So mappend gives you colour addition [with the perplexing comments about 
"gamut", presumably some kind of small mammal?], but there's no 
subtraction? No multiplication? No linear blending?

>> 4. It's parameterised over the component type; my library is hard-coded to
>> specific types for speed.
> My feeling would be to trust the specializer until it lets me down.
> Has it let you down in the past?

Heh, my colour library includes a custom floor implementation that talks 
to the GHC primops directly because calling floor is too slow...

[In case that sounds like idle talk, I had a program go from 10 seconds 
to less than 1 second just by using this function. There's a few tickets 
about it on the GHC Trac.]

> BTW, the EasyRaster package looks useful.

Well, I'd like to think so... It doesn't do anything you couldn't do 
yourself if you spend a day or two trying to grok the GTK complexity. 
But it's much easier to just import some code somebody else has already 
written. ;-) Certainly when I'm in the middle of trying to build a 
complicated bit of software, figuring out how to just write a few pixels 
onto the screen is a low priority.

More information about the Haskell-Cafe mailing list