Short-circuit evaluation for (&&)

[nyuichi]

The current implementation of the conjunction binary operator (&&) does not short-circuit arguments:

let-mutable x <- 0
let _ = false && (let () = x <- 1 in true)
!x  %=> 1

Is this behavior intentional?

[gfngfn]

This behavior is intended. && is just an ordinary function of type bool -> bool -> bool.

[nyuichi]

Is there a plan to add a new operator that performs short-circuit evaluation?

2019/07/11 0:49、T. Suwa notifications@github.comのメール:

This behavior is intended. && is just an ordinary function of type bool -> bool -> bool.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gfngfn/SATySFi/issues/186?email_source=notifications&email_token=AAED34E26N37JH4AEL6IZ2DP6YAINA5CNFSM4H7IJ67KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZT4ZMA#issuecomment-510119088, or mute the thread https://github.com/notifications/unsubscribe-auth/AAED34HIFPHQWPQ3LB674A3P6YAINANCNFSM4H7IJ67A.

[gfngfn]

Is there a plan to add a new operator that performs short-circuit evaluation?

No, at least for now. Do you have a strong reason for adding short-circuit variant of &&? IMHO it seems sufficient to just use (&&-) : bool -> (unit -> bool) -> bool defined as follows:

let (&&-) b k = if b then k () else false

[nyuichi]

I am writing a lexer/parser library for satysfi and making heavy use of an idiom like if i < string-length s && some-pred (string-sub s i 1) then …. Without short-circuit it evaluates the second condition before the array index validation is performed and simply raises a runtime error. I don’t think this is a rare case. The same could happen if I was writing another library that uses Array or hashtable.

2019/07/11 16:30、T. Suwa notifications@github.comのメール:

Do you have a strong reason for adding short-circuit variant of &&? IMHO it seems sufficient to just use (&&-) : bool -> (unit -> bool) -> bool defined as follows:

let (&&-) b k = if b then true else k () I think one big goal of satysfi is typesetting without super programming techniques’’, which of course TeX fails to accomplish. I do not think restricting expressive power contributes to this aim. It can rather triggersuper satysfi programming techniques.''

If you are not willing to stop treating binary operators all uniformly, what about introducing keywords like and and or as in python? Or, is it possible to use the new metaprogramming framework to define such a metalevel function instead?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gfngfn/SATySFi/issues/186?email_source=notifications&email_token=AAED34GKE3TKGIK2FTFZ6Z3P63OTDA5CNFSM4H7IJ67KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZVZDRQ#issuecomment-510366150, or mute the thread https://github.com/notifications/unsubscribe-auth/AAED34B5JV6COLXQPRBC6PDP63OTDANCNFSM4H7IJ67A.

[elpinal]

Or, is it possible to use the new metaprogramming framework to define such a metalevel function instead?

a.satyh:

@stage: 0

let (&&&) b1 b2 = &(if ~b1 then ~b2 else false)

b.satyh:

@import: a

let-mutable x <- 0
let _ = ~(&false &&& &(let () = x <- 1 in true))
let z = !x   %=> 0

A bit cumbersome, though.

[nyuichi]

2019/07/11 20:52、El Pin Al notifications@github.comのメール:

Or, is it possible to use the new metaprogramming framework to define such a metalevel function instead?

a.satyh:

@stage: 0

let (&&&) b1 b2 = &(if ~b1 then ~b2 else false) b.satyh:

@import: a

let-mutable x <- 0 let _ = ~(&false &&& &(let () = x <- 1 in true)) let z = !x %=> 0 A bit cumbersome, though.

That’s very helpful. And that’s not that cumbersome I think, at least for my purpose. Thanks a lot!

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gfngfn/SATySFi/issues/186?email_source=notifications&email_token=AAED34HNL3OD3BS62XNZU3LP64NGRA5CNFSM4H7IJ67KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZWOQUQ#issuecomment-510453842, or mute the thread https://github.com/notifications/unsubscribe-auth/AAED34H2N2OMDB2EAE5XFYTP64NGRANCNFSM4H7IJ67A.