Re: Proposal for syntax changes in Curry

From: Sven Panne <Sven.Panne_at_informatik.uni-muenchen.de>
Date: Fri, 23 Oct 1998 12:05:25 +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.

Neither me.

> [...]
> With your new proposal things get really bad, however, because now
> there is no syntactic distinction between the two cases. E.g. consider:
>
> f x = x <= 2
> g x = x == 1
> h x | f x = 1
> | g x = 2
>
> The result of the reduction h 1 will always be 1. Now if I change the
> definition of g to
> g x = x =:= 1
> (and this might be in a completly different part of the program) I now
> get as result of h 1 the disjunction 1 | 2. (With the old syntax I
> would have got a type error telling me that g x is not of type Bool.)

IMHO, that's not a problem. Another solution would be to change the
typing rule for guards to:

   To type
      l | g1 = r1
        | ...
        | gn = rn
   type each gi separately, yielding ti. After that, all ti must be
   unifiable to either
      a) Constraint (default).
      b) Bool. In this case, transform the gi = ri to
             i) nested ifs (if i>1), or
            ii) g1 =:= True = r1 (if i=1)

The report does not state the semantics for the case a) with multiple
guarded rhs yet, but I guess it should be:

      l = g1 => r1
      l = ...
      l = gn => rn

Hmmm, another quite different reading could be

      l = choice g1 -> r1
                 ...
                 gn -> rn

but I didn't think about the consequences of this reading very long...
 
> 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.

No! Please nuke the {...} syntax. I've never really understood the
difference between c and {c}, where c::Constraint. I recommend every
language designer to implement the scanner/parser for him-/herself...

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

OK, now from level 0.5 of "WADLER'S LAW OF LANGUAGE DESIGN" back to
level 2... :-)

-- 
Sven Panne                                        Tel.: +49/89/2178-2235
LMU, Institut fuer Informatik                     FAX : +49/89/2178-2211
LFE Programmier- und Modellierungssprachen              Oettingenstr. 67
mailto:sven.panne_at_informatik.uni-muenchen.de            D-80538 Muenchen
nhttp://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne
Received on Fri Oct 23 1998 - 13:09:00 CEST

This archive was generated by hypermail 2.3.0 : Fri Sep 20 2019 - 07:15:04 CEST