Re: Some syntax sugar for logic programming

From: Michael Hanus <mh_at_informatik.uni-kiel.de>
Date: Tue, 28 Oct 2014 17:17:13 +0100

On 10/27/2014 05:36 AM, lausgans_at_gmail.com wrote:
> I’m interesting whether some syntax extensions are planned, exactly:
>
> 1. habitual disjunction, i.e. orC in Prelude in form of Cond1 orC Cond2 orC … instead of orC [Cond1, Cond2,...] resided in Constraint

I think this is a matter of taste. The prelude is already a big thing
and should contain frequently used operations, e.g., those which are
often used in the interactive top-level loop.
In programs, I think it is not a big effort to write
"import Constraint".

> 2. fromBoolToSuccess (and vise versa?) and not operator for writing things like notC (fromBoolToSuccess (null lst)) instead of explicit null lst =:= False

Here you bring up an interesting point which should be discussed on
this list. Some people are not happy with the distinction of the
types "Success" and "Bool". Actually, I see these problems every time
I teach Curry to new students...

Sergio and I recently wrote a paper where it is proposed to drop
the type "Success" from Curry:

http://www.informatik.uni-kiel.de/~mh/papers/WFLP14_Success.html

Historically, Success was introduced as the Prolog-equivalent to
express unification, whereas Bool was taken from Haskell to express
sequential case distinctions. We think the language design of Curry
could be simplified by dropping the type Success and having only
one kind of equality (==) in the language. This would also simplify

The only tricky issue is to retain unification, if possible.
For instance, in the initial expression

x==[1,2] where x free

one would like to bind x to the list [1,2] instead of instantiating
x to all integer lists and produce False for all lists except [1,2].
However, this could be easily expressed by

solve (x==[1,2]) where x free

where "solve" is defined by

solve True = True

Due to this definition, the "False" results need not be computed
so that x could be bound [1,2]. This means that the old (=:=)
could be redefined by

x =:= y = solve (x == y)

As a consequence, no code duplication (like orC, andC,...) is necessary
for the Success type.

In order to play with this proposal, the recent (development) releases
of PAKCS and KiCS2 offer the operation solve (but still provide
the type Success and =:= for backward compatibility).

> 3. matching of whole pattern and part of it in one construction, like in functional counterpart, i.e. (Var1_at_(SubVar1,SubVar2),Var2) =:= somefunction

This would mean that one uses pattern syntax also in expressions.
I think this could be confusing, in particular, since functional
patterns might have a different meaning. On the other hand,
it is not a big deal to transform this into a standard expression, e.g.,

(Var1,Var2) =:= somefunction &> Var1 =:= (SubVar1,SubVar2)

Best regards,

Michael
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Di Okt 28 2014 - 17:17:59 CET

This archive was generated by hypermail 2.3.0 : Do Jun 20 2024 - 07:15:12 CEST