Unclear how to avoid redundant computation in 'repeat until' in a nice manner

Help with Snap!
#1

I would like to say

image
but I don't see a way to make the value of some costly computation the value of a local variable and use it inside the repeat until.

I seem to be forced to say something like this:

image
which I don't find as clear Nor do I want to define a new predicate for just this purpose.

I think what I want is to be able to say something like

repeat_until
    (let x some_expensive_computation()
     return x = 'a' || x = 'b') {
...
}
#2

λ(
[script var x=some_expensive_computation()]
[return x===a or x===b]
)

Also,you do not need readablilty as only you will like to see the code and you know what youre saying.

#3

You can set a local variable to the value of the computation beforehand, or use the "contains" predicate, but I agree that neither of these options are concise.

What I would do in this case is create a "let ... in ..." reporter that sets an upvar and then returns the result of the given expression, which would let you do this:

let in
let in896×150 13.8 KB

If you don't want to have to define a custom block for this purpose, you could instead use an anonymous procedure like this:

lambda let

#4

I just said it!!!

#5

We both came up with our own solutions, and that's okay.

#6

Thanks both.

I should have made it clear that this is a project I expect students to enhance so it does matter how readable/understandable it is.

I thought of the let command but it can't be used in a repeat until, but a let reporter may well be my way forward. Thanks.

#7

The let variable be value in body reporter works well in my project. Though I avoided the equal sign since it is used only for testing equality in Snap!. But I needed to make body a reporter: E.g.

image

#8

You can set body to be an unevaluated input (look for the input shape called "Any (unevaluated)"). It will look like a normal input from the outside, but the procedure receives an anonymous function that it can call to evaluate the input expression when it's needed.

#9

Thanks. Using any (unevaluated) looks nicer now.

#10

Totally not true :slight_smile:
The number of times I have tried to read someone else's awful unreadable code...

#11

... the number of times I have tried to read my own unreadable code three months later

#12

ikr that happens to me all the time.

Like, all the time