I don’t get it. What does it achieve?
I think that @qw23 wanted to show how you could remove the ($+((condition ?)) $+ then $+ ((true case λ))$+::control) part of your block because it could be covered by the (((else pairs...))::control) part of your block.
Yeah, that’s my ideal solution.
Granted.
First of all, it’s not always about execution speed. Ease of use, or elegance, counts too.
Secondly, the official library’s let block is rather slow. Replace it with a faster let, or use var followed by set, and execution time will be about halved.
Thirdly, further optimisation of the Snap! definition code may be doable.
And finally, if a variadic-if is ever going to be implemented by a primitive function, it will probably become even faster.
ok, but then why have a new definition?
mine uses extra inputs because it makes more sense to look at - which is why the primitive is like that, probably.
Sorry, I didn't mean to offend you... I agree with you...
I thought recursion would be a very good solution in this specific case and I still don't understand why it isn't...
My problem with this whole approach is that the "if" is vertically centered on the two condition-result pairs, and then the "else" appears at the left margin rather than lined up horizontally with those pairs. It takes me a big mental effort even to see the "false then a" part.
I don't really have a suggestion to fix it. If we were doing math, there'd be a huge open brace following the IF, tall enough to encompass all the rest, including the ELSE clause. I'm fantasizing about a Snap! that allowed TeX math expressions in with the title text and parameters in a block prototype. But no. :~)
I was actually referring to the “outside” (= function, or use), not the “inside” (= implementation, or “definition” as it is called in Snap!) of the variadic-if block. Meaning: if a block is easy-to-use (or more elegant), it may not matter that its execution is somewhat slower than the alternative.
Your code is superior to mine, or @mark4sisb’s, in both size and speed (which is what I hinted at when I wrote “further optimisation of the Snap! definition code may be doable”). Even so, it’s still (perhaps acceptably, see the above explanation) slower than the alternative, i.e. a composition of vanilla reporter-ifs:
yeah, thats why I asked for this. it's also sad that the recursive method is usually slower than looping :(
Execution speed isn’t everything. E.g. clarity / elegance, and ease of development / maintenance are often at least as important, perhaps even more so in prototype systems, teaching languages, etc. Once a program works correctly, one may want to subsequently optimise its runtime, most of which is usually determined by just a few pieces of its code.
IMAO the chief merit of recursion within code is its simplicity (admittedly: where applicable). One needs to answer just two questions:
- (how) can the solution of a case belonging to a group of problems be formulated in terms of (a) simpler case(s) within the same group, assuming - this is the “leap of faith” - solutions to those simpler cases are known?
- which base case(s) exist(s), i.e. (a) case(s) with a trivial solution, to which all reductions (as constructed according to the answer of question 1) ultimately lead?
However, different programming constructs may be equally simple to use and understand, depending on the problem at hand.
this is something I'm really bad at.
while I understand what you're saying, I feel like a beginner will most likely look at most of the code of this thread, be confused, and only understand dardoro's.
but I think the other options check all those boxes! that's why
I believe it is also a skill that can be learned by trying again and again - until it eventually becomes like swimming, or riding a bike.
I agree, in this case (dardoro’s code is superior by far).
BTW as for the code proposed in my first post (#17) I would have preferred to recurse to the very if … (if-then-pairs) else (default) function, thus avoiding introduction of a process inner function - however that can’t be done because of Snap!’s unevaluated type input handling.
Using a side-effect of the variadic unevaluated ('default') it may be simplified to
For the real life application even
I just realized that all of the "if-else" reporters are way overengineered. Here is a far faster and more elegant way to create it:
However, the down side is that the predicates are all evaluated right away, even though the output options aren't. To compare speeds, here are some of the options already suggested in this thread compared to mine:
Mine:
qw23's
Original:
PS: This also made me realize that the definition for the "if else if..." primitive command was also way overengineered. Here is my simplified definition:
Actually, with the current primitive definition, this is also the case. See for yourself!
I know, and that's the problem with that primitive definition.
