Currently and and or must be used with both conditions and actions, resulting in code that reads somewhat strangely:

X == 1 or Y == 2 or False() => Z

I propose to separate the else keyword from else error on and allow it to be used on its own. It would behave the same as or but be right-associative, allowing the above code to be written as:

(X == 1 or Y == 2) else False() => Z

The error on construct would remain on its own, and can still be used in the same situations:

(X == 1 or Y == 2) else error "Error!" on Z

Or in new situations:

e@X() :-
where error "Error!" on e

I also propose to introduce a new keyword then which would be the complement to else. It would behave like and but be right-associative. The following code:

X == 1 and Y == 2 and True() => Z

Can then be written as:

(X == 1 and Y == 2) then True() => Z

Apart from improving readability, an added benefit is that this allows a construct that looks like an if-else:

(X == 1 and Y == 2) then True() => Z else False() => Z
Submitted by D. Pelsmaeker on 19 June 2014 at 12:33

On 19 June 2014 at 13:36 Eelco Visser commented:

Makes sense

Do you want to try adding these to TS yourself?

On 19 June 2014 at 13:37 Eelco Visser commented:

If then and else are indeed sugar for and and or, it should be easy to add to TS using just some desugaring transformations.

On 24 June 2014 at 11:55 D. Pelsmaeker commented:

I’ve attempted it, but it’s not really possible currently as all tasks are eagerly evaluated. A and B should not evaluate B if A fails, but currently it does. Equivalently, A or B should not evaluate task B if A doesn’t fail.

Therefore, if I split else from error on, then the error on task will always be evaluated and always display an error. (I could keep the else error on but then else doesn’t add any benefits.)

On 4 June 2015 at 01:09 Jeff Smits commented:

(I know this is a year old, but just FYI)

If the error on is the only reason you need lazy evaluation, you can work around it, though you won’t be able to do it with just desugaring.
Define A then B as not(A) or (A and B), and A else B as A or B where B depends on not(A). That last part cannot be defined in sugar I guess.

On 4 June 2015 at 01:11 Jeff Smits tagged !jeffsmits

Log in to post comments