Hello Michael!
> Proposal 1:
> "as", "hiding", and "qualified" are not keywords and can be used
> as ordinary identifiers.
This looks perfectly reasonable to me.
>
>
> Furthermore, there is a problem with qualified names and the
> function composition operator. Consider the definition
>
> f i = [i..]
>
> The right-hand side can be interpreted in two ways:
>
> - an arithmetic sequence (i.e., (enumFrom i)), or
>
> - the list consisting of the operator "." imported from module "i"
>
> To avoid this ambiguity, I propose the first alternative
> since this is often used in existing programs.
> This alternative can be enforced by the following
>
> Poroposal 2:
> Qualifications of the operator "." are syntactically not allowed.
I must admit that it dislike this kind of special hacks. In fact,
this ``fix'' seems to have some more consequences. For instance, in
Haskell and in the Muenster Curry compiler it is possible to use the
following declaration in order to make only the qualified names of all
prelude entities visible:
import qualified prelude
I tend to make use of this in order to check for prelude dependencies
in my programs and also to test/write replacements for prelude
functions. As it stands, your proposal will make the operator .
inaccessible after this import declaration. (It is possible, but not
always reasonable, to add a declaration import prelude((.)) to the
program; e.g., if you want to provide a prelude replacement which
implements some kind of tracing, or whatever, on top of the prelude
functions.)
Also note that there are other places where a space is needed in order
to avoid the interpretation as qualified name, e.g. you cannot write
putStr.show
to denote the expression which is equivalent to the print function, but
have to add (at least) one space either before or after the dot.
BTW, in Haskell this problem is leveraged by the fact that module names
have to start with an upper case letter. If we were going to adopt this
convention, the problem would go away -- at least as long as you use
lower case variable names. Furthermore, putStr.show becomes valid (for
people who prefer it), but not Just.id.
Regards
Wolfgang
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Mo Sep 01 2003 - 09:01:32 CEST