THANK you all for your contributions. My favorite is the recursive version. This version doesn't smell iterative anymore like the map with 1 arg.
Don't you mean report (join (CHAR) (recur...)) in the last line?
its there... 
While I doubt the majority would be happy with prefix syntax it does have the wonderful advantage that + can be variadic. I doubt I'm not the only one who is annoyed when needing to add 3 or 4 things that I'm forced to nesting + expressions instead of (+ 2 3 4 5)
Haven't seen it but I do like this JavaScript version which makes some sense given Scheme's influence on the design of JavaScript and its closures. And it is trivially interactive when read in a browser due to the native JavaScript support.
Already available in variadic reporters library
Sure, but the original idea was to dig into functional programming. And there seems to be some value when having the operator always as the first argument of a list and the arguments as the CDR, resp. behind the first element of the list. Abstract structure of a list as an element of a list followed by the rest of the list, which is recursive in itself, the thinking in terms of functions as an operator applied to arguments and the pure syntax of putting atoms/elements together. All of this together in a single form of syntax have some educational value. Its a small price to pay that (+ 3 4) looks a bit unfamiliar at first sight.
I agree (being part of the "minority"). Another good argument for prefix is how it simplifies constructing meta-interpreters.
But there remains the difference between
(+ 3 4)
and
+(3 4) or +(3, 4)
The later is broader appeal and many of the same advantages.
I think this discussion is switching between a discussion of prefix/infix, s-expression/function+arguments, and suitability for meta-programming/simple-mental-models-of-execution.
All important issues but we should keep them separate.
Good point. Maybe I'll starting using them. What about adding subtraction and division?
The combine function only works with associative dyladic functions.
sum and product are implemented recursively as could difference and quotient. Admittedly, difference and quotient aren't as intuitive with more than two arguments but Lisp has had them for over 50 years. E.g. Emacs Lisp documentation:
Function: - &optional number-or-marker &rest more-numbers-or-markers
The - function serves two purposes: negation and subtraction. When - has a single argument, the value is the negative of the argument. When there are multiple arguments, - subtracts each of the more-numbers-or-markers from number-or-marker, cumulatively. If there are no arguments, the result is 0.
(- 10 1 2 3 4)
⇒ 0
(- 10)
⇒ -10
(-)
⇒ 0
I find the 're-mixed' @dardoro 's solution really elegant and am thanking you for sharing it, @helicoptur
I wonder what were the reasoning steps leading to your idea that those ('call' and 'id OF...') blocks maybe are after all not really necessary for the solution to work? And, on the other hand, I equally wonder about the steps that have led you, dardoro, to the original idea with those blocks in the first place?
Maybe you can start both books at the same time by first putting together the easiest (beginners) topics (paragraphs) to make the easy book first, and subsequently adding the harder ones to make the harder book later?
Maybe.
I'm kind of dreading the whole idea. My book-writing process is that I spend nine months or so pacing the floor, not writing a word, and hating myself. Then I spend two months writing, and another month on the stupid formatting issues. So it's not a lot of fun.
I would hope that starting with a book I've already written might reduce the time for that first part, although I'd have to think through all these questions about blocks not being prefix and all that.
It's true that that's a way Snap! is different from Scheme. The variadicness of - and / has always seemed kludgy to me. I bet 90% of the time Lispians write (- 0 a b c), if they use >2 inputs at all. And the other 10% they really mean (+ foo (- 0 a b c)) but they've learned to write that in the less intelligible form.
The real problem is that subtraction and negation are done with the same procedure name. With positional notation we could have two separate blocks (- x) and (x - y). I keep trying to persuade Jens that that would be a huge improvement, and finally he invented "neg" as one of the options in the SQRT block. But that's not discoverable. The two - blocks should be right next to each other in the palette.
Since I want macros, I have to be able to translate between Snap! surface syntax and a more Lisp-like one in which each block becomes a list with the entire blockspec as the car and the argument expressions as the cdr. Luckily @pumpkinhead has written a library for that, so I just have to get off my butt (figuratively speaking; in reality it's more like getting on my butt) and write the rest of it.
I looked into the book for an hour and it looks really interesting. I will start next weekend to look into i and build SNAP blocks while reading.
But I think there are 2 options: Using standard existing SNAP Blocks, but then the book has to be rewritten in a lot of areas.. I have seen chapters, in which the scheme code does not match to any standard SNAP blocks. Or following the story line of the book. But then custom SNAP blocks will be needed. And the superficial reader of the book who only wants to build quickly a game and is not interested in functional programming, will ask why he should follow such outdated nerdy scheme syntax
I will report in a week or so.
But, if you think about it as "I am letting my creative subconscious do the preparations behind the scenes", then you will have no reason to give yourself a hard time, would you?
It made me happy when I've first noticed the "neg" option was introduced so the multiplication block (with '-1' as one of its inputs) was not needed anymore when all I wanted was just a negation.
I agree it would be better to have it next to other arithmetic blocks in the blocks pallette.
Yeah, that's what I tell myself, but it doesn't persuade me while I'm experiencing it.
Yeah, we used to have this problem in Logo. For a long time, there were 40 million different Logo books, all of which did square-triangle-house, and there wasn't anything to read next. Until finally I broke the ice with Computer Science Logo Style and that started a flood. So, in the case of Snap!, all the millions of Scratch books are pretty much also Snap! books, and to the extent that there are small differences, it's those authors' job to convert their books for Snap!. My job is the book you read second.