Wolfgang Lux wrote:
> Only if you ignore literate source files (which means that the source of
> module M should be stored in M.lcurry, see Sect. 10) and hierarchical
> module
> names. An implementation could assume thae module A.B.C is stored in
> file
> A.B.C.curry, but also in A/B/C.curry. Unless the report is going to make
> one of the two schemes mandatory, you should refine the proposal to say
>
> a module named M, where M contains no dots, should be stored in a
> file
> M.curry.
Ok, thanks for the hint.
> - Inside module M, it is always possible to refer to an entity x defined
> at the top-level of the module with the qualified name M.x.
This is reasonable. Good for documentation (but not strictly necessary
since these names are always accessible).
> - This allows making the description more concise of what is exported
> when module M occurs in the export list of a module: Module M in this
> context is simply an abbreviation for the list of all entities whose
> unqualified name x is in scope and whose qualified name M.x is in
> scope.
> Note that the unqualified name x could be ambiguous.
Ok.
> - 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.
> - A hiding clause acts on both the unqualified and the qualified name.
I don't understand why the hiding of the qualified name is
useful. Usually, there should be no ambiguities with the
qualified name, and if one wants to import the qualified name
but hides the unqualified one, a further import declaration
seems necessary.
> - As-patterns. They are far too convenient when you have to spell out a
> pattern in order to avoid overlapping left hand sides in a
> declaration,
> but you are not really interested in the pattern's components
> (because
> they are handled elsewhere). The prototypical example is in the
> definition of a simple depth first search strategy:
>
> dfs g = all (try g)
> where all [] = []
> all [g] = [g]
> all gs_at_(_:_:_) = concatMap dfs gs
>
> According to the current version of the Curry report, one would have
> to write all (g1:g2:gs) = concatMap dfs (g1:g2:gs) for the last
> equation.
Ok, I already have been asked for this several times...
> - 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?
> - The ability to define and use new data constructor symbols, e.g.
>
> infix 4 :=
> data Assoc a b = a := b
> flipAssoc (x := y) = y := x
>
> is also convenient, but I do not consider it as important as
> the preceding two items.
So let's postpone it since one can often obtain a similar effect
by introducing defined functions.
> - Finally, one big plea: Can we please rename the prelude into
> Prelude. I find it really annoying that I have to change
> import Prelude hiding(...)
> into
> import prelude hiding(...)
> when switching from Haskell to Curry and vice versa. Besides,
> PAKCS and MCC already use capitalized names for the modules in
> their standard libraries, so why should there be an exception
> for the prelude? In fact, I'd really like to see Curry adopt
> Haskell's capitalization conventions, but I guess Michael is
> opposed to this ...
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...
Best regards,
Michael
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Mi Feb 01 2006 - 07:58:55 CET