Re: Literate comments
RFC-822-HEADERS: Original-Via: == We seem to be converging here. I prefer Simon's suggestion of an appendix to Paul's suggestion of a Section 1.6, but am not too bothered either way. Will also try to work in Simon's note about file extensions. I am happy to leave the question of how to format the Prelude in Joe's lap. I'll go ahead and draft the required page. Cheers, -- P
The class Ix
RFC-822-HEADERS: Original-Via: == Folks, I have realised that the class Ix is under-documented in the Haskell Report. I propose to add the following: New section 6.9.1 "The Class Ix". (Renumber subsections in 6.9). ~ Arrays may be subscripted by any type in the class @Ix@, which is defined as follows (definition repeated from Section 4.3.2) class (Ord a) => Ix a where range :: (a,a) -> a index :: (a,a) -> a -> Int inRange :: (a,a) -> a -> Bool The @index@ operation maps the upper and lower bounds of the array, and a subscript, to an integer. Typically, this integer is used to index a linear representation of the array. The @range@ operation enumerates all subscripts, and the @inRange@ operation tells whether a particular subscript lies in the domain of the array. An implementation is entitled to assume the following laws about these operations: and [ index (l,u) l <= index (l,u) s && index (l,u) s <= index (l,u) u | s <- range (l,u) ] inRange (l,u) i == i `elem` range (l,u) The first law states that the index of any in-range subscript falls between the index of the first subscript and that of the last. The law is required so that the implementation can allocate a suitably-sized array representation given only the array bounds. The second law is an obvious consistency condition on @inRange@. = End of proposed text. It would be possible to be a bit more draconian on the first law. For example the following is simpler but more restrictive: range (l,u) !! index (l,u) i == i Simon
Re: Literate comments
I'd be happy with this, as an appendix, but I'd rather not change any of the report's presentation. To do so consistently would be difficult, and it adds little to the Prelude appendices which are basically all code anyway. Now, for Joe and Paul's tutorial, yes! I wonder if you could also work in the convention that we all (I think) use of .hs suffices for Haskell files, and .lhs for literate ones? Simon | To be precise: I propose an additional chapter of the report, labeled | `Literate comments' and no more than one page long, that states a | convention for providing literate comments, notes that it is NOT part | of Haskell but is supported by existing implementations, and mentions | that the Prelude is presented with this convention in the report. I | volunteer to draft the page.
Literate comments
To be precise: I propose an additional chapter of the report, labeled `Literate comments' and no more than one page long, that states a convention for providing literate comments, notes that it is NOT part of Haskell but is supported by existing implementations, and mentions that the Prelude is presented with this convention in the report. I volunteer to draft the page. Paul, as syntax honcho you should rule on this. Cheers, -- P OK, here's a counter proposal: add a subsection 1.6 (1.5 is on layout) which describes the suggested convention on literate programming, one page max. But, DON'T re-do the Prelude; I don't believe it will improve the presentation much (in this case, anyway), and I would really rather that we leave this as a suggested convention rather than committing to using it in any substantive way. -Paul
