Michael Hanus wrote:
> Wolfgang Lux wrote:
>> [...]
>> - Definitions at the top-level do not shadow definitions imported
>> from
>> another module, instead the defined entity's name is ambiguous
>> and one
>> must use a qualified name in order to disambiguate it in the
>> right hand
>> side of a declaration.
>
> I don't like this restriction on top-level entities which are defined
> in the local module because this means that I have to change the code
> of my local module when I import another module containing entities
> with the same name. I think that the top-level declarations of
> my local module should be always visible without qualification.
I admit that it is a bit inconvenient that you have to change the
local module. However, keep in mind that you only have to add an
appropriate hiding clause to the import declaration (or specify the
entities, which you want to import, explicitly).
On the other hand, Haskell's policy of reporting an error in case
of name conflicts between top-level declarations and imported entities
becomes really a bonus when you want to import a library function, but
there accidentally happens to exist a definition with the same name
in the module. If the compiler silently chooses the local definition,
this may lead either to somewhat confusing error messages from the
type checker (confusing because you will likely have troubles to match
the types in the error message with the type of the imported function)
or, even worse, to very hard to track down runtime bugs. IMHO,
preventing such errors is really worth the "inconvenience" of having
to use hiding clauses.
> [...]
>> - Guards and local declarations in the alternatives of case
>> expressions
>> with a fall-through semantics as in Haskell, e.g.
>>
>> case x of
>> Left y | y >= 0 -> -1
>> Right y | y >= 0 -> 1
>> _ -> 0
>>
>> This expression would reduce to the number 0 if x is bound to
>> Left (-1).
>> Rewriting a case expression using boolean guards into one
>> without can
>> lead to a lot of code duplication or the introduction of a lot of
>> auxiliary functions -- in particular for more complex matches
>> as the
>> example above -- which may obscure the intended meaning of a
>> program.
>
> This is a good argument for guards, but local declarations?
If you have guards in the alternatives of a case expression you
sooner or
later want to have local declarations that scope over all guards and
where
the pattern's arguments are in scope, e.g.
case x of
(y,z)
| prod > 0 -> 1
| prod < 0 -> -1
| otherwise -> 0
where prod = y * z
> [...]
> In the case of the prelude, I have no objections to capitalize
> the name. However, as you already guessed, I don't like to put
> more restrictions on the names. I think that colorings are
> more useful than cases...
I assume that you refer to syntax aware highlighting as, e.g.,
performed by the Haskell mode for Emacs. AFAIR, the Haskell mode
(on which your Curry mode for Emacs is based) uses the case of
identifiers in order to distinguish variables/functions and
constructors. In fact, without reading the definitions of module
A, how would you tell whether A.x is a function or a constructor
and colorize it correctly?
Regards
Wolfgang
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Do Feb 02 2006 - 09:04:43 CET