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