Re: Some syntax sugar for logic programming

From: <>
Date: Fri, 31 Oct 2014 08:16:19 +0300

Thank you for the answer, Michael!

> 28 окт. 2014 г., в 19:17, Michael Hanus <> написал(а):
> On 10/27/2014 05:36 AM, 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».

Actually, an infix disjunction is what interests me more, less is where it resides. Is there such in Curry?
Though there is a problem with infix one, that you should not forget to set braces, where needed.

>> 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:
> 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
> your programming tasks, I guess.
> 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

The idea is cool, but isn’t it a case where some people will forget to use solve() resulting in performance degradation of their programs?

> 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)

No, i’ve used this in a pure logic context. Isn’t it possible to extend unification to support such syntax, or i miss something?
Though thanks for reminding about &> operator, i think it’s useful for usage of constraints in functional context.

> Best regards,
> Michael
> _______________________________________________
> curry mailing list
> curry_at_lists.RWTH-Aachen.DE
> http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry

curry mailing list
Received on Fr Okt 31 2014 - 15:49:09 CET

This archive was generated by hypermail 2.3.0 : Sa Dez 09 2023 - 07:15:13 CET