Proposal: change flexible/rigid default in Curry

From: Michael Hanus <mh_at_informatik.uni-kiel.de>
Date: Mon, 26 Aug 2002 19:01:52 +0200

Dear Colleagues,

after some discussion about programming in Curry with Sergio,
we want to propose to change the flexible/rigid default in Curry.

Current definition:
===================
Only defined functions with result type "Success" (i.e., constraints)
are flexible; all others are rigid.

New proposed definition:
========================
All defined functions are flexible (if not explicitly declared as
"rigid"); external functions (including if-then-else) are still rigid.

Rationale:
==========
Originally, all non-constraint functions were rigid by default.
The reason was to avoid the enumeration of possibly infinite
search spaces if somebody has accidentally used a logical variable
(e.g., by a typo) in a rule. However, in the meantime all logical variables
must be explicitly declared (in contrast to Prolog or Toy) so
that this case rarely happens.

On the other hand, if one wants to use a rigid function for search
(like concatenation "++"), one must define the same function again
with eval annotation "flex" (e.g., "(+++) eval flex") which is
boring and causes difficulties if one teaches Curry. Thus, if all
defined functions are flexible by default, teaching functional logic
programming with Curry becomes simpler and needs not so many code
changes. Furthermore, the "eval flex" annotation as well as
the "pragma" annotation can be omitted from the language definition
(which simplifies the language which is always a good point).

Finally, the cases where one explicitly needs rigid (instead of
flexible) defined functions are rare. One example are concurrent
objects (for which one currently also needs a "eval rigid"
annotation). As a test, I have implemented the new proposal
and recompiled all examples and application programs and everything
worked as before. Therefore, we think that the new proposal
does not cause any problem. If anybody sees a problem with this
proposal, please react! Otherwise, I'll change the language
definition according to this proposal due to its advantages.

Best regards,

Michael
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Mo Aug 26 2002 - 19:03:55 CEST

This archive was generated by hypermail 2.3.0 : Do Feb 01 2024 - 07:15:05 CET