Wolfgang Lux wrote:
> > Using default rules and Jaime's proposal of auxiliary
> > functions, I would rewrite this as
> >
> > foo A _ = 0
> > foo B _ = 1
> > default foo x y = foo_ x y
> > where foo_ _ A = 0
> > foo_ _ B = 1
> > default foo_ _ _ = 2
>
> But this is wrong because now foo B A returns 1 while it should
> return 0. In order to get the intended semantics of foo you have
> to use a few more default rules (like Jaime's translation does).
Right, but I assumed that returning 0 for (foo B A) is not
intended if there is a rule like "foo B _ = 1". This is also
the reason why I think a sequential reading for different
rules gives not very clear code.
> [Proposal for default rules deleted.]
> I do not object to this addition. But still I would like to have some
> more syntactic sugar for the definition of functionslike foo. Taking
> up a suggestion of Mario, we could introduce case expressions to
> perform such "top-down" pattern-matching. Using the default rules
> extension an obvious translation for case expressions into the Kernel
> of Curry which performs this pattern matching would be as follows:
>
> case e of {} => failed
> case e of { t -> e'; alts } =>
> let f t = e'
> default f x = case x of { alts }
> in f e
>
> where f and x are fresh names which do not occur in e, e', t, and alts.
> The extension to guarded patterns and local definitions in case
> alternative should be obvious.
>
> Thus my foo example could now be written as
>
> foo x y =
> case (x,y) of
> (A,_) -> 0
> (_,A) -> 0
> (B,_) -> 1
> (_,B) -> 1
> (_,_) -> 2
This is an excellent idea! Having a sequential reading for
case expressions is fine and also conform with the use of case
expressions in other programming languages. In contrast to
a sequential reading of pattern matching in different rules,
here it is ok since a case is ONE expression. Furthermore,
this seems to satisfy all standard requirements for default rules without
an extension of the kernel language implemented by the different
backends. If nobody objects, I'll include these extensions
(i.e., simple default rules and case expressions of the form
above) in the next version of the Curry report.
> P.S.: I just noticed that the failed function is no longer in the
> standard prelude. Is there any reason for that?
As far as I remember, it was never in the standard prelude
but only in the prelude of our PAKCS implementation.
But maybe it is good to fix the name of this function
and include it in the standard prelude as defined by
-- failed is a non-reducible polymorphic function
failed :: _
failed | 1=:=2 = x where x free
Best regards,
Michael
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Do Okt 26 2000 - 15:28:46 CEST