Wolfgang Lux wrote:
> looking more carefully at the changes in the report, I've found
> two (more or less) problematic issues.
>
> The first is that an implicit module header
> module M where
> is added to file M.curry when it does not have an explicit header.
> This does not mix well with hierarchical modules (at least when the
> module hierarchy is mapped onto the file system). For instance, if
> a compiler is invoked for file
> A/B/C/D/M.curry
> which header should be used for M if it does not have an explicit
> header?
> module M where
> or
> module A.B.C.D.M where
> In the former case, one cannot omit module headers for nested modules,
> in the latter case one can only compile the file or load it into the
> interpreter from the correct parent directory. At least to me, the
> latter
> seems overly restrictive.
So, I think that introducing the unqualified header "module M where"
is the most reasonable solution. Headers with nested module names
are good to distinguish identical unqualified module names
in different directories, which, I suppose, occur only
in "finished" projects where one usually puts module headers.
I can make this point clearer by adding "in a directory" to
the corresponding sentence in Section 6 so that it reads:
"If a module stored in a directory in file M.curry does not contain
a module head, the standard module head "module M where" is
implicitly inserted."
This should make it clear that M is a name without directory
prefixes. Ok?
> The other, more important issue is the definition of committed
> choice. Looking at the definition of tryone in the report
> tryone g = commit [let x free in (g x,x)]
> I notice that this definition will never work in MCC because of
> the restriction that a committed choice must not bind variables
> which are not local to a constraint/expression pair. Unfortunately,
> the variable x in the above is just as non-local as it would be in
> tryone g = let x free in commit [(g x,x)]
>
> I see two options here. One is to introduce special syntax for
> committed choice, e.g., a choice expression as in early versions
> of the report:
> choice { constraint_1 -> expression_1 [where LocalDefs_1];
> ...
> constraint_n -> expression_n [where LocalDefs_n] }
> so that tryone would be defined as follows:
> tryone g = choice { g x -> x where x free }
> The other option is to acknowledge the fact that currently no
> implementation supports committed choice and leave out any concrete
> syntax for committed choice from the report. Instead the report
> could say something like "committed choice is under consideration
> for inclusion in a future version of the report" until someone
> comes up with a working implementation of committed choice.
I am in favor to the latter option and omit any description
of committed choice in the current report, or refer to the
use of ports as a way to obtain the effect of a committed choice.
Best regards,
Michael
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Mo Mär 27 2006 - 12:59:09 CEST