On 22 February 2006 17:27, Malcolm Wallace wrote:
However, I would be equally happy to combine type/newtype/data into a single keyword for exports.
for the record, I am in favour of tagging export specifiers with 'class' or 'type' (using 'type' for all type constructors, in light of yours and John's points). I'm not in favour of adding type signatures to export lists. It's a half way solution to specifying interfaces, and I'd rather design it properly from scratch. If modules are to contain interfaces, I don't think extending the export list is the way to do it. I'd rather do something like: -------------------------------------- modules M exports class Eq a where (==) :: a -> a -> Bool data T :: * -> * f :: T -> Int mkT :: Int -> T where -- implementation below here data T a = C a Int f = ... -------------------------------------- Not a proposal by any means, and I don't think that Haskell' should tackle this, but this seems the right direction to me. Cheers, Simon
I lost track of what is the issue being tackled here. What's broken with the current way of specifying exported entities? Imho it's the best system that I've seen (across all languages I know). A lot of language chose to separate interface from implementation in source files. (eg. Ada) I find this annoying because to change a single thing you have very often to edit two files. The counter-argument is that the user of a module wants to see only the interface. However, with modern tools like haddock, one doesn't look at the source code any more to understand the interface of a module, but some specifically processed version of the sources, so this argument is void. So, again, please keep implemenation and interface as close as possible. Public modifiers permit this adequately, but they don't fit with haskell syntax style very well. The current export list being 1. very light 2. optional and 3. allowing to re-order presentation in haddock (or such a similar tool) makes it the very best solution for haskell, imho. Cheers, JP. On 2/23/06, Simon Marlow <simonmar@microsoft.com> wrote:
On 22 February 2006 17:27, Malcolm Wallace wrote:
However, I would be equally happy to combine type/newtype/data into a single keyword for exports.
for the record, I am in favour of tagging export specifiers with 'class' or 'type' (using 'type' for all type constructors, in light of yours and John's points).
I'm not in favour of adding type signatures to export lists. It's a half way solution to specifying interfaces, and I'd rather design it properly from scratch. If modules are to contain interfaces, I don't think extending the export list is the way to do it. I'd rather do something like:
-------------------------------------- modules M exports
class Eq a where (==) :: a -> a -> Bool
data T :: * -> * f :: T -> Int mkT :: Int -> T
where -- implementation below here
data T a = C a Int f = ... --------------------------------------
Not a proposal by any means, and I don't think that Haskell' should tackle this, but this seems the right direction to me.
Cheers, Simon _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
"Simon Marlow" <simonmar@microsoft.com> wrote:
However, I would be equally happy to combine type/newtype/data into a single keyword for exports.
for the record, I am in favour of tagging export specifiers with 'class' or 'type' (using 'type' for all type constructors, in light of yours and John's points).
For the sake of avoiding confusion, perhaps we should choose a keyword (or better, a reserved identifier with no meaning outside of the export/import list) that is none of "type", "data", or "newtype"? How about "datatype", "tycon", or the like? Then it would be clearer that there is no relationship between the way the type is defined, and how its namespace is notated in the export list.
If modules are to contain interfaces, I don't think extending the export list is the way to do it. I'd rather do something like: -------------------------------------- modules M exports
class Eq a where (==) :: a -> a -> Bool
data T :: * -> * f :: T -> Int mkT :: Int -> T
where -- implementation below here --------------------------------------
But, apart from adding fuller signatures than I proposed, that is exactly the same as an export list, modulo some very minor syntactic differences!
Not a proposal by any means, and I don't think that Haskell' should tackle this, but this seems the right direction to me.
I agree that full interface specs are beyond Haskell'. JPBernardy's argument that tools (Haddock, compilers) can already extract the interface automatically is quite persuasive too. Regards, Malcolm
participants (3)
-
Jean-Philippe Bernardy -
Malcolm Wallace -
Simon Marlow