"all of" block problem?

[dardoro]

@qw23

Or, a simpler version doing the same job:

But

[snapenilk]

The only things that can be called are reporters and predicates (also commands that have the report block).

[qw23]

I see.

[loucheman]

Good work!

Optimisation: I think all the parameters doesn't have to be evaluated... you can stop evaluating after you found the 1st false value

false,true,true,true,true,true,true,true,true,true,true,true,true,true,true,true,true,true,true,true,true,true
will be false: in this case, we know it when we evaluate the 1st parameter...

[dardoro]

@loucheman

Optimisation: I think all the parameters doesn't have to be evaluated... you can stop evaluating after you found the 1st false value

Yes has a short-circuit evaluation built-in "for free" so recursion stops early.

[qw23]

I think an interesting related question is why Snap rejects values when e.g. a reporter is expected (like in post 1: "expecting a ring but getting true"). What would go off the rails if values were accepted in these cases?

[bh]

@dardoro

so recursion stops early.

So recursion stops, period!

[bh]

@qw23

why Snap rejects values when e.g. a reporter is expected

It was a hard call, and in fact by coincidence we've been asking ourselves that question. But, in most cases, if a user gives a non-procedure value when a procedure is expected, it's a bug rather than a cleverness. (For example, the user is trying to write WHILE and doesn't get that a non-ringified value can't change each time through the loop.) And it's easy enough for the user to ringify the value.

[d4s_over_dt4]

Yeah,optimization isn't too early

[qw23]

@bh

… in most cases, if a user gives a non-procedure value when a procedure is expected, it's a bug rather than a cleverness

Speaking for myself, I choose to differ of opinion. Therefore, building on @dardoro’s example (post #19), I developed a more inclusive CALL-block:

A limitation is it can’t be augmented “WITH INPUTS” - in those cases Snap!’s CALL will need to be used.