Re: Name discussion for new primtive

From: German Vidal <gvidal_at_dsic.upv.es>
Date: Thu, 11 Nov 2004 13:42:51 +0100 (CET)

On Thu, 11 Nov 2004, Michael Hanus wrote:

> Bernd Brassel wrote:
> > > Nevertheless, I still prefer simply 'eval' (it would be more
> > > conservative for people from lazy functional programming), we
> > > just need to clearly state in the report that it evaluates its
> > > argument to a non-variable value, i.e., a constructor-rooted term.
> >
> > I think the idea to call it something like eval is good. evalC, however,
> > could imply, like ground, that the value does not contain any logical
> > variables at all. But evalC [X] should not suspend.
> > Can we express this easily as well or do you think there will be no
> > misunderstandings?
>
> I don't think so. Since the evaluation primitive "seq" is well known,
> "eval" seems very similar to "seq" and the difference is not reflected
> in the name. Moreover, we usually say that, at the top-level, an
> input expression is "evaluated" to a normal form. For instance,
> the expression "id X" is evaluated to "X". Therefore, it might
> be very confusing if "eval (id X)" cannot be evaluated but suspends.

Ok, I agree with you. However, as you already mentioned, a name
like 'nonVar' sounds like a Boolean test (as in Prolog). So I'd prefer
a name where the fact that the argument should be evaluated to
something is made clearer.

What about 'eval2nonVar'? (for 'evaluation' to a non-variable value,
being clear that a value in our context is either a logical variable
or a constructor-rooted term). It's a bit too long, but I think
it describes well what we want..

German


_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Thu Nov 11 2004 - 14:16:06 CET

This archive was generated by hypermail 2.3.0 : Thu Sep 19 2019 - 07:15:06 CEST