Re: Proposal for syntax changes in Curry

From: Michael Hanus <hanus_at_informatik.rwth-aachen.de>
Date: Fri, 23 Oct 1998 12:22:44 +0200

Wolfgang Lux wrote:
> First I do not see the reason why you want to restrict the expression
> inside a
>
> let ... free in exp
>
> to the type of constraint.

This restriction is due to semantical reasons. Since "let...free"
corresponds to existential quantification, it is natural to
have it in constraints, but I do not know what is the semantics
of a term like "there exists an x such that x+2".

> Second I am very unhappy about your proposal concerning conditional
> expressions. I had liked the idea of interpreting conditional
> expressions with only boolean guards as an abbreviation for nested if
> expressions on the rhs very much, esp. as this interpretation is also
> compatible with Haskell. However there was a clear syntactic criterion
> when this interpretation applied.
> ...
> So I would suggest either dropping the change in semantics for (only)
> boolean guards in a conditional expression or still use braces around a
> constraint expression the guard of a conditional expression. The latter
> will not conflict with Haskell, as a record can never appear in a guard
> expression.

I must admit that I also preferred the idea of a syntactic distinction
between Boolean guards and constraints rather than a distinction
(and transformation) based on the type structure. But Herbert
argued for a unique syntax for constraints and thus dropping
the curly brackets also in the guard of a rule. But I am still
open for discussion. I have no problem to enclose constraints
in guards (and only there or maybe also in the guards of a choice)
to have a clear syntactic distinction.
I am interested to get other opinions.

> P.S.: Just out of curiosity. What is the reason for replacing /\ by &?
> I've just got accustomed to typing /\ :-)

I have never used /\ but the comma notation instead of this.
Therefore, I looked for a short replacement of the comma to drop
the curly brackets. You can also justify it by a comparison to C.
There, you have && as the sequential conjunction (I suppose
this is the reason why it is also taken in Haskell) and & as
the bitwise conjunction which evaluates, in contrast to &&,
both arguments. Thus, one can see && as the sequential and
& as the parallel (or concurrent) conjunction. Finally,
I've also seen & in some other proposals for parallel conjunction.

Best regards,

Michael
Received on Fr Okt 23 1998 - 13:27:00 CEST