Thank you for the answer, Michael!
> 28 окт. 2014 г., в 19:17, Michael Hanus <mh_at_informatik.uni-kiel.de> написал(а):
>
> 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».
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:
>
> 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
> 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
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Fr Okt 31 2014 - 15:49:09 CET