Re: Narrowing: yes or no? [was Re: Narrowing vs. rewriting]
Manuel Chakravarty wrote:
> Yes, this is a good point. As I think that especially the outer frame
> of a typical application does not make any use of nondeterminism (but
> usually mainly consists of IO-monad expressions etc.) it is too be
> expected that nondeterminism will only occur in some inner
> computations -- probably strongly localized.
This is also my intention. Therefore, we are currently working
on a concept to encapsulate nondeterminism, and I'll add it to
the Curry proposal if it is stable enough.
> It should be as easy as possible to control the determinism of
> function definitions. To be honest, I am not yet convinced that the
> evaluation annotations are optimal in this respect. Like the
> definitional trees, they may be nice to define a semantics or as an
> intermediate representation in a compiler, but are probably to verbose
> for a programmer. Maybe it would be interesting to see whether
> something like the determinism declarations of Mercury are feasible
> for Curry.
I agree that the current annotations are not convenient for
programmers. Therefore, I moved the syntax of them to a less prominent
place (appendix). However, I think they should be in the language
since one intention for Curry is to provide a platform into which
existing approaches can be compiled. Moreover, one can "play"
with different evaluation annotations. But I am open to alternative
suggestions. I think in most cases it is sufficient to specify
whether a function is rigid or flexible rather than specifying
the entire tree. Thus, I propose to provide annotations like
f eval rigid
p eval flex
specifying that all branches in f are rigid or all branches in p
are flex (suggestions for other keywords than "rigid" or "flex" are
welcome). Such annotations would be sufficient for all my example
programs and they correspond to the mode/determinism
annotations of Mercury somehow. Any comments?
Best regards,
Michael
Received on Mo Jul 14 1997 - 14:09:00 CEST
This archive was generated by hypermail 2.3.0
: Do Jun 20 2024 - 07:15:05 CEST