RE: Infix expressions
| The second header line shows categories, whereas the links in the grey | boxes are to articles. The idioms category collects together articles | that are about idioms. | | We could have an idioms or programming techniques article as well, | of course. It only needs to be written. Interesting. I thought there would be a rationale! But my point is this: I didn't even know that there is a concept of a category on the Haskell web site. And I visit it regularly. An innocent visitor certainly won't. Now I know that there is such a concept, but I have no idea what it might mean, or how I might use it. My suggestion: by all means have categories, whatever they are. But can we arrange the home page of Haskell.org so that a new and ignorant visitor can simply look on the visible page (without prior knowledge) and know where to go? And can there be some information readily accessible that explains what categories are, and how to use them and add to them? Sorry to be stupid about this. Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Infix expressions
In article [EMAIL PROTECTED] ft.com, Simon Peyton-Jones [EMAIL PROTECTED] wrote: But can we arrange the home page of Haskell.org so that a new and ignorant visitor can simply look on the visible page (without prior knowledge) and know where to go? Yes, yes, go ahead and change the page as you like. Getting it just right is harder than it seems, though. Meanwhile I shall admonish contributors to bear in mind that our first audience is those expecting a web-site on Haskell and not necessarily interested in this wiki thing. And can there be some information readily accessible that explains what categories are, and how to use them and add to them? I'm hoping readers will just click on a category page and see a little index of relevant articles, and understand what it's about. I can edit the structure of category pages if necessary. Nevertheless it may be appropriate to make it clearer on the front page whether or not a link is a page with actual content or merely one of these indexy-things. Editing the website, on the other hand, takes us in MediaWiki territory. More prominent links to editing help on Wikipedia might be appropriate; strictly speaking I can't just copy it across for copyright reasons. -- Ashley Yakeley, Seattle WA WWED? http://www.cs.utexas.edu/users/EWD/ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Ranges and the Enum class
Sometime back on one of the other Haskell lists, there was a proposal to not have the floating types instances of Enum and instead have some other class to which [a, b..c] desugars. That is, rename enumFromThen and friends and put them in another class. Put simply, Float and Double should not support succ and pred (unless, perhaps, they map to the next greater/lesser representable number, which would also be confusing). I can even see an argument for not allowing Float or Double to be used for ranges either, as the steps may not be exact, which in practice turns out to be very confusing. This is a wart I would really like to see get fixed. -- Aaron Denney -- ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Ranges and the Enum class
On Fri, Mar 17, 2006 at 04:48:52PM +, Aaron Denney wrote: Sometime back on one of the other Haskell lists, there was a proposal to not have the floating types instances of Enum and instead have some other class to which [a, b..c] desugars. That is, rename enumFromThen and friends and put them in another class. Put simply, Float and Double should not support succ and pred (unless, perhaps, they map to the next greater/lesser representable number, which would also be confusing). I can even see an argument for not allowing Float or Double to be used for ranges either, as the steps may not be exact, which in practice turns out to be very confusing. Speaking of confusing, try [0, 0.3 .. 2]::[Rational] Also, toEnum and fromEnum would make more sense mapping from and to Integer. It seems that succ and pred are unused. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Ranges and the Enum class
On 2006-03-17, Ross Paterson wrote: Speaking of confusing, try [0, 0.3 .. 2]::[Rational] Right. I had forgotten that -- Rational is exact, yet has the weird closest endpoint behavior of Float and Double. Also, toEnum and fromEnum would make more sense mapping from and to Integer. It seems that succ and pred are unused. So, I think I'll put together a proposal, well two. Okay, three. First, change toEnum and fromEnum to Integer. Then there is a choice between: (1): Remove Double, Float, and Rational from Enum. They're no longer usable in arithmetic sequences. Pro: Very easy to do. Sequences can still be constructed by starting with integers, and scaling to convert. Con: Loses some functionality (though it's questionable functionality given rounding). (2): Split Enum into the classes Enum and ArithmeticSequence and change what the various [..] desugars to. class Enum a where succ, pred :: a - a toEnum :: Integer - a fromEnum :: a - Integer I believe succ and pred aren't used directly by anything else, but I do like having them. instance Integer, Int Rational _could_ be added here by the diagonal representation, but probably sohuldn't. class ArithmeticSequence a where stepFrom :: a - [a]-- [n..] stepFromBy:: a - a - [a] -- [n,n'..] stepFromTo:: a - a - [a] -- [n..m] stepFromByTo :: a - a - a - [a] -- [n,n'..m] instance Int, Integer, Float, Double, Rational. (a) Make all of them have the closest endpoint behavior. (b) Make all of them have strict no more than behavior. Pros: Clearly divides two seperate uses, while keeping functionality. Can re-introduce relationship between Ix and Enum? Cons: Yet another typeclass. Slightly misleading name, as non-arithmetic structures _should_ be supported. Also a bit long. But doing so automatically is tricky, as toEnum and fromEnum are no longer accessible Keeps questionable functionality of non-exact arithmetic sequences. Personally, I'm for 2(a), but I think even (1) is an improvement. It's a pity we can't make Enum a subclass of ArithmeticSequence that provides the methods of its superclass. Would it be possible to have data ... (deriving ArithmeticSequence) check if (Num a, Ord a) is defined and use (+), else if Enum a is defined, use fromEnum/toEnum to go through Integer, else fail. Where I suppose defined must mean defined in this module. Hmm. That's kind of ugly. I can see why these were combined, but it's still really ugly. Steppable might be a better name. Comments anyone? -- Aaron Denney -- ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
