Hello,
Jan> Your thought would destroy equational reasoning! For example
Jan> you would be able to define different equalties on the same
Jan> data structure. So Red==Black could be False in one place
Jan> and True in another place. Does that make any sense?
Ralf> Of course, it does. You neglect the fact that definitions have
Ralf> scope. You can already define two functions both called say
Ralf> `eq' such that `eq Red Black' yields False in one place and
Ralf> True in another place.
in fact, one has to be very careful in using equational reasoning.
Consider the do-notation:
do x <- ...
let y = x
x <- ..
return (y==x)
It is false to assume that the value True is returned. Each line of
the do opens a new scope. In my opinion, avoid the use of x
twice in such cases.
Let me give you my opinion about the idea of Johannes.
Johannes> just a thought .. why is it that some declarations (data,
Johannes> type, newtype, class, instance) are only allowed at the
Johannes> (module) top level? in some cases i'd like to have more
Johannes> locality, and less namespace pollution.
I think the module is the right instance to make type definitions
like the function is the right instance to define values, in
general. You could also have a lot of nested let-expressions, e.g.,
but they complicate the comprehension of the functions, see the
scope discussion above.
What you suggest may be good for a very special purpose,
--- I'm interesting in what you have in mind ---
but not for most applications. What you can do is to
define your types in an indirect way using algebraic data
types.
If your problem arised just as a consequence that your modules
are very large, I suggest to use smaller modules.
As it is beneficial to have small function definitions, it also
is to have small modules. In that case, what one would like to
have is NESTED MODULES and that seems to be implementable more
easily.
Sincerely
-------------------------------------------------------------------------------
Christoph Herrmann
E-mail: [EMAIL PROTECTED]
WWW: http://brahms.fmi.uni-passau.de/cl/staff/herrmann.html
