Re: [Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK
On Jul 18, 2009, at 9:26 PM, Wolfgang Jeltsch wrote: I don’t think, it’s a good idea to have German identifiers, since Haskell’s keywords are English. Put it this way: if Haskell's keywords were in German, do you suppose I would write my Haskell code in anything but English? Does the fact that 'data' is a Latin word mean that some fraction of our Haskell identifiers should be in Latin? Some say ita, some say minime. On the other hand, I strongly argue that a library about Bézier curves uses the identifier Bézier, not Bezier. So non- ASCII identifiers are useful even if identifiers are in English. Indeed, you need non-ASCII letters to write English well. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK
Am Sonntag, 19. Juli 2009 23:42 schrieben Sie: On Jul 18, 2009, at 9:26 PM, Wolfgang Jeltsch wrote: I don’t think, it’s a good idea to have German identifiers, since Haskell’s keywords are English. Put it this way: if Haskell's keywords were in German, do you suppose I would write my Haskell code in anything but English? At least, many people all over the world write their code in something other than their native language. :-) Does the fact that 'data' is a Latin word mean that some fraction of our Haskell identifiers should be in Latin? data is also an English word nowadays. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK
Am Samstag, 18. Juli 2009 06:31 schrieben Sie: On Jul 18, 2009, at 2:35 AM, Wolfgang Jeltsch wrote: So I should upload a package with German identifiers to Hackage? Sure, why not? The fact that I can't read it is my loss, not your fault, and there will be plenty of other German-reading Haskellers to benefit from it. I've happily worked with programs in French (not large ones (:-)). I don’t think, it’s a good idea to have German identifiers, since Haskell’s keywords are English. On the other hand, I strongly argue that a library about Bézier curves uses the identifier Bézier, not Bezier. So non-ASCII identifiers are useful even if identifiers are in English. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK
On 18 Jul 2009, at 13:26, Wolfgang Jeltsch wrote: Am Samstag, 18. Juli 2009 06:31 schrieben Sie: On Jul 18, 2009, at 2:35 AM, Wolfgang Jeltsch wrote: So I should upload a package with German identifiers to Hackage? Sure, why not? The fact that I can't read it is my loss, not your fault, and there will be plenty of other German-reading Haskellers to benefit from it. I've happily worked with programs in French (not large ones (:-)). I don’t think, it’s a good idea to have German identifiers, since Haskell’s keywords are English. On the other hand, I strongly argue that a library about Bézier curves uses the identifier Bézier, not Bezier. So non- ASCII identifiers are useful even if identifiers are in English.\ And I think that a library about Dynkin diagrams should use the identifier Dynkin, not Дынкин.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK
Am Dienstag, 7. Juli 2009 14:42 schrieb Robin Green: On Fri, 10 Jul 2009 10:44:51 +0200 Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: PASCAL uses “program”, not “programme”, The word program (as in computer program) is spelled program in both British and American English. Probably just because British English took it from American English. It’s similar to the “German” word “Computer”. It’s not native. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK
Am Mittwoch, 15. Juli 2009 05:27 schrieben Sie: On Jul 10, 2009, at 8:44 PM, Wolfgang Jeltsch wrote: Why do we use English for identifiers? Because English is the language of computer science. What English should we use? It’s tempting to say, we should use the original English, which is British English. But we should ask again what is the language of computer science. And the language of computer science is American English. It was possible to adopt such an attitude in the 20th century. But this is the 21st century. We have globalisation, internationalisation, localisation. We have Unicode, so that people are no longer limited to the set of characters that technicians from the USA found tolerable back in 1967. So I should upload a package with German identifiers to Hackage? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK
Wolfgang Jeltsch schrieb: Am Mittwoch, 15. Juli 2009 05:27 schrieben Sie: On Jul 10, 2009, at 8:44 PM, Wolfgang Jeltsch wrote: Why do we use English for identifiers? Because English is the language of computer science. What English should we use? It’s tempting to say, we should use the original English, which is British English. But we should ask again what is the language of computer science. And the language of computer science is American English. It was possible to adopt such an attitude in the 20th century. But this is the 21st century. We have globalisation, internationalisation, localisation. We have Unicode, so that people are no longer limited to the set of characters that technicians from the USA found tolerable back in 1967. So I should upload a package with German identifiers to Hackage? I most like identifiers like getZahl. :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK
On Jul 18, 2009, at 2:27 AM, Wolfgang Jeltsch wrote: Probably just because British English took it from American English. It’s similar to the “German” word “Computer”. It’s not native. The spelling program goes back to 1633 at least; it cannot then have referred to computers, and is not likely to have been an American import. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK
On Jul 18, 2009, at 2:35 AM, Wolfgang Jeltsch wrote: So I should upload a package with German identifiers to Hackage? Sure, why not? The fact that I can't read it is my loss, not your fault, and there will be plenty of other German- reading Haskellers to benefit from it. I've happily worked with programs in French (not large ones (:-)). Mind you, I was specifically speaking of alternative *dialects* (English, Scots, American, Strine), not alternative *languages*. The library at this University contains books in a wide range of languages and is all the better for it; it would be as churlish as it would be foolish to say English books only! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK
On Jul 10, 2009, at 8:44 PM, Wolfgang Jeltsch wrote: Am Freitag, 10. Juli 2009 05:26 schrieb rocon...@theorem.ca: I find it amazing that you independently chose to spell colour with a `u'. It makes me feel better about my choice. I have to admit that it makes me unhappy. :-( Why do we use English for identifiers? Because English is the language of computer science. What English should we use? It’s tempting to say, we should use the original English, which is British English. But we should ask again what is the language of computer science. And the language of computer science is American English. It was possible to adopt such an attitude in the 20th century. But this is the 21st century. We have globalisation, internationalisation, localisation. We have Unicode, so that people are no longer limited to the set of characters that technicians from the USA found tolerable back in 1967. (Note that Americans includes French Canadians and lost of people who mainly speak Spanish.) Let's face it, by this argument we'd have to abandon the metric system when writing computer programs. There are good reasons to adopt American speling for a term or English spelling. They include the language that the author is most familiar with, the language the paying customers are most familiar with, the language of the laws that the program has to conform to, any number of things. But there is a way above this issue. Why can't we have BOTH Colour AND Color? What changes, if any, would it take for Haskell to support bidialectal naming practices (whether it is English -vs- American, insular/Brazilian Portuguese, Norwegian, Arabic dialects, or whatever)? We can create an alias for a type easily enough. We can create an alias for a defined function easily enough. We cannot create an alias for a constructor; there is no way to say data X = A | B Int constructor C = B so that C can be used for pattern matching just like B. We cannot create an alias for a module name; while we can create a module that re-exports everything from some module, there is no way to make them act the same as far as inheritance of dotted names is concerned. SML has similar limitations, but not quite the same. It lets us create alias for types and defined functions. It also lets us create aliases for modules, its structures and functors (more or less). But even SML doesn't allow the definition of aliases for constructors. To my knowledge, most early developments in computer science had their roots in the US. One consequence of this is that reserved words of programming languages are typically in American English. PASCAL uses “program”, not “programme”, and BASIC uses “COLOR”, not “COLOUR”. So, in my opinion, Haskell color packages should use the identifier Color, not Colour. By the way, I also write my papers and documentation in American English. Best wishes, Wolfgang (who is neither British nor American) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK
It’s tempting to say, we should use the original English, which is British English. Some suggest the original English remained in Britain when the North American colonies were founded; others claim it was brought to the Americas by the British settlers, leaving a pale imitation back in Britain. The truth is much stranger: the original English was actually smuggled out of Britain to the West Indies in a wardrobe belonging to General Sir Ralph Abercromby, where it ended up on the island of Trinidad after Sir Ralph took possession of that territory in the name of the British Crown. It came to be used and modified freely by the various immigrants to Trinidad (and later Tobago) and their descendants (largely African, Indian, British, Portuguese, German, Spanish, and Chinese). Many of these peoples then emigrated, bringing the original English to North America and back to Britain. A copy of it has fallen into my hands, and so I can, without bias, make the following call: both color and colour shall be acceptable in Haskell programming. 'Kerb' and 'gaol' are right out, however. Cheers, Robert (who's grandfather is from London and grandmother from Trinidad; but is nevertheless American) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK
Am Freitag, 10. Juli 2009 05:26 schrieb rocon...@theorem.ca: I find it amazing that you independently chose to spell colour with a `u'. It makes me feel better about my choice. I have to admit that it makes me unhappy. :-( Why do we use English for identifiers? Because English is the language of computer science. What English should we use? It’s tempting to say, we should use the original English, which is British English. But we should ask again what is the language of computer science. And the language of computer science is American English. To my knowledge, most early developments in computer science had their roots in the US. One consequence of this is that reserved words of programming languages are typically in American English. PASCAL uses “program”, not “programme”, and BASIC uses “COLOR”, not “COLOUR”. So, in my opinion, Haskell color packages should use the identifier Color, not Colour. By the way, I also write my papers and documentation in American English. Best wishes, Wolfgang (who is neither British nor American) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK
On Fri, 10 Jul 2009 10:44:51 +0200 Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: PASCAL uses “program”, not “programme”, The word program (as in computer program) is spelled program in both British and American English. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK
Max Rabkin wrote: On Sat, Jul 4, 2009 at 8:38 PM, Andrew Coppinandrewcoppin 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. 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? I find it amazing that you independently chose to spell colour with a `u'. It makes me feel better about my choice. 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. ;-) You can use by lib without worrying about the CIE. You can use my library without ever importing or using the word CIE. However, the CIE stuff is there for those who need it. Perhaps I (maybe with some help) need to make a tutorial on the haskell wiki to try to make it less intimidating. 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? Linear blending is done by the affineCombo function. I think the darken function will do what you mean by multiplication Colour subtraction can be done by adding (using mappend) a colour that has been darkend by a factor of (-1). I don't believe there is any demand for a colour subtraction fuction, so I don't have a name for it. I suppose these sorts of questions can be put nicely into a short tutorial on the wiki. 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.] Certainly speed is an issue that I haven't tackled yet since I don't know too much about how to optimized Haskell code. I was thinking of sprinkling in some SPECIALIZE pragmas and maybe adding some RULES to make operations more effecient. For example we could have a rule to rewrite floor to some sort of GHC specific fast floor function. (Although that rule probably deserves to be in some sort of more general location). Any help in this direction would be appricated (perferably while keeping things as portable as possible). This all being said, the major problem my code solves is doing blending in a linear colour space. This necessarily make converting to non-linear sRGB for output much slower. So for people who want speed over proper blending, then probably AC-Colour is the package they need to reach for. Essentially the two packages do fill different niches! BTW, the EasyRaster package looks useful. I haven't looked at EasyRaster yet, but I got excited when I saw it announced. :) -- Russell O'Connor http://r6.ca/ ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK
OK, so having released AC-HalfInteger, I got slightly carried away and released three other small packages. These are packages that many programs I write all end up using. I'm forever copying these files, so I made them into actual bonafide packages. http://hackage.haskell.org/package/AC-Vector-1.1.1 This provides two types, Vector2 and Vector3, which are unboxed vectors of Doubles, with arithmetic, dot product and cross product, and a few other useful items. http://hackage.haskell.org/package/AC-Colour-1.1.1 This provides two types, Colour and Colour8. Both implement simple RGB colour types with arithmetic. Colour has unboxed Double fields, and Colour8 has unboxed Word8 fields. My usual workflow is to do all the image generation with Colour, and to convert to Colour8 just before the data hits the I/O channels. You can, however, do arithmetic directly on Colour8. (I haven't extensively tested that it works properly though...) http://hackage.haskell.org/package/AC-EasyRaster-GTK-1.1.1 This is a layer over Gtk2hs. As you all probably know, Gtk2hs provides a Cairo binding that makes vector graphics wonderfully easy. However, *bitmapped* graphics is darned tricky. I basically had to sit in the #haskell channel with Duncan for a few hours trying to figure out how the hell to do it. This knowledge is now codified in the above package. Load it up and you don't need to know a thing about GTK; you can just create an ImageBuffer, write some pixels to it (efficiently!), save it to disk or display it on screen. (But you *can* access the underlying GTK+ resources if you wish...) In other news, it appears that the batch job to generate the documentation just ran, so you can view it all online. :-D Comments, suggestions, random flames, etc... [I'm particularly curios to know what Duncan will make of the GTK thing...] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK
On Sat, Jul 04, 2009 at 06:56:44PM +0100, Andrew Coppin wrote: http://hackage.haskell.org/package/AC-Colour-1.1.1 Why don't you use colour[1]? [1] http://hackage.haskell.org/package/colour -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK
Felipe Lessa wrote: On Sat, Jul 04, 2009 at 06:56:44PM +0100, Andrew Coppin wrote: http://hackage.haskell.org/package/AC-Colour-1.1.1 Why don't you use colour[1]? [1] http://hackage.haskell.org/package/colour A few reasons: 1. I never knew it existed. ;-) 2. It's mind-blowingly complex. 3. It doesn't appear to provide arithmetic over colours. 4. It's parameterised over the component type; my library is hard-coded to specific types for speed. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK
On Sat, Jul 4, 2009 at 8:38 PM, Andrew Coppinandrewcop...@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. 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? 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 :) 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. 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? BTW, the EasyRaster package looks useful. --Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK
Max Rabkin wrote: On Sat, Jul 4, 2009 at 8:38 PM, Andrew Coppinandrewcop...@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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK
On Sat, Jul 4, 2009 at 9:18 PM, Andrew Coppinandrewcop...@btinternet.com wrote: 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. The sRGB function makes a Colour from RGB (actually sRGB, which is a standardised RGB -- basically RGB where the exact frequency and power of each channel is specified -- but you can pretend your monitor's RGB is sRGB. So mappend gives you colour addition [with the perplexing comments about gamut, presumably some kind of small mammal?] The gamut of a device is the range of representable colours (a monitor's gamut looks something like a parabola with a flat base in XYZ space, whereas a printer's is much more complex and variable). This makes sense. If you double a monitor's brightest white, you don't get a colour twice as bright: you get the same colour. but there's no subtraction? No multiplication? No linear blending? affineCombo can do subtraction, again with the gamut warning. darken does scalar multiplication; it probably doesn't do componentwise multiplication, which doesn't make much sense if you're trying to work in a coordinate-independent setting, though I admit RGB-multiplication can be handy. 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.] Fair enough. Can your implementation not be turned into a patch? BTW, I'm also working on Haskell fractals. You might be interested in looking at my fractal package (though it's currently undocumented, and has no GUI). --Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK
Paul Johnson wrote: Andrew Coppin wrote: 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. ;-) Your display may not be calibrated, but those used for graphic design certainly are. Indeed. And if you're in any kind of position where you *care* about such things, you should be using color, not AC-Colour. If, however, you just want to throw together pretty pictures, AC-Colour is simpler and easier. Different libraries for slightly different tasks. ;-) On the package naming front: I appreciate your wish to avoid just having another colour library. But AC_Colour doesn't help much. Simple_colour might be better. Mmm, yeah. Naming everything with AC precludes name clashes and doesn't require too much thinking. Coming up with a better name requires thinking about what actually makes your package unique. And, of course, if another package comes along, that analysis may change. (E.g., I seem to recall there's a newbinary package which has actually been long since superceeded - so not so new any more!) If I name my package simple-colour, and then somebody else makes an even simpler one... the name becomes kind of meaningless. (Admitedly there's not too much danger of this happening...) I just like the idea of having definitely unique, distinctive package names. Otherwise I'd have to come up with stuff like geovector and trivicolour and so on... Arguably EasyRaster-GTK should have been a sufficiently unique name by itself though. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK
On Jul 4, 2009, at 15:01 , Max Rabkin wrote: On Sat, Jul 4, 2009 at 8:38 PM, Andrew Coppinandrewcop...@btinternet.com wrote: 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. I don't see a good meaning for signum offhand, but fromInteger could take an X11-encoded RGB value and abs could produce grayscale brightness. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
