How does multiply of a character and a number work with HOF like map, filter...?

I am obsessed with codification from SNAP to Python.
Now I came along on multiplying a character c with a number n, which is possible in Python.
It returns in python just n times the concatenation of this character with itself.
So "4 * a" results in a string "aaaa".
(This is helpful, when printing something on the command line.)

So I tried to produce the same result in SNAP and came up with 2 solution.
1 with repeating an assignment and another with adding the character to a list.

image

But I find both versions ugly and - i admit - imperative.
So my question to the gurus is:

  1. How can I concatenate a character with itself n times without using assignments and repeat.

  2. How can I concatenate a character with itself n times by a adding a character to a list without a repeat statement, but with map, combine, ...

NOT important and NOT urgent at all.
I just want to excel in functional programming before I die.

Here's one way:


The first JOIN, with "a" in it, isn't actually joining anything; it's used only to satisfy MAP, which wants a function in that slot. The gray ring has an explicit formal parameter to prevent the substitution of a list item into the empty slot. It's the second JOIN that actually does the joining.

If you think mapping a constant function over NUMBERS FROM is ugly, you might like the APL library, with which you can do it this way:

Alternatively, I would consider this an improper breaking of the abstraction barrier provided by COMBINE, but this works:


It's improper because you have to know that the first input to the combining function (here, the JOIN in the gray ring) is the accumulated result so far, while the second input is one new item from the input list. And you have to have an "a" in front of the input list because the very first time COMBINE calls JOIN, it's with the first two list items as the inputs.

But pro Common Lisp programmers do things like this; instead of a COMBINE function they have two, FOLDL and FOLDR, that combine the list items left-to-right or right-to-left, and they're allowed to take advantage of knowing that. Whereas we say the combining function has to be associative, so it doesn't matter which order COMBINE uses, and that's none of the user's business.

@helicoptur: Doing it recursively is fine also!

THANK YOU SO MUCH!!!

I just tried to understand it and realized that you can also use the join statement to map over the list resulting from a join statement with only 1 argument (see block at bottom)
image

It feels to me like a misuse of the map statement. I am used to map with a function with 2 args, where 1 is left blank.

I wish there was a detailed guide to the functional programming novice.

There is! Structure and Interpretation of Computer Programs, the best computer science book ever written!

But, duh, I don't know why it didn't occur to me to just click the left arrowhead to get rid of the empty input. I guess I developed the habit from the original JOIN, which wasn't variadic.

I can see why it feels weird to you to call an arity-zero constant function in a MAP. It is a little strange, but it's a convention of functional programming. Would you feel better if it were


? That would be a one-arity function, the usual thing for MAP, but it still ends up not really using its input.

Oh, I forgot to answer this part. The usual case is a function expecting one input. That can be an arity-two function with one input filled in (that maneuver is called Currying in the literature), but it can also be

Sure, but the examples of SICP are use hard math stuff like Newton's method for approximations to the zeroes of a function, so me and my students struggle more with the examples than the real content of SICP. I am also not so highly motivated to dig into all the brackets of scheme again. There is a SICP version with all the code in python, which I find more tasty (composingprograms.com/).

I thought about a project of putting the SICP text online and rewriting all the code of SNAP. But even that would be a very advanced course due to the hard math examples.
What I am looking for - and I think its not out there - is more a DIY self help guide with lots of examples and less theoretical stuff like lambda calculus any sophomore can understand. SICP for teenies or SICP for the advance Scratch User.

Oh don't get me started...

Maybe what you want is a Snap! version of Simply Scheme. I've thought about that...

I would love to use that book in my classes. Any way the community can help you writing it?

Other version
untitled script pic (45)

As for "combine" with declared initial accumulator value, it's enough to start with ""
untitled script pic (47)

Good time to ask; I've just finished watching Ratatouille, the TikTok Musical, the result of a huge online collaboration/crowdsourcing: https://www.todaytix.com/x/nyc/shows/22803-ratatouille-the-tiktok-musical. So that puts me more in the mood to think it might be possible to crowdsource Simply Snap!. Here are some of the obstacles:

  1. First I have to talk MIT Press, and co-author Matt Wright, into blessing the project. I think sales of the Scheme version have gone down enough to make that possible, but we'll see.

  2. At least in the beginning, contributors have to speak TeX pretty well. We have massive amounts of custom TeX code in the book, including code that automatically scans the Scheme programs and generates index entries for the procedures being defined. (I was very proud of getting that to work!) The pictures in the book are imported as EPS files, so either we continue to change pictures to EPS or I learn how people import PNGs and JPEGs into TeX these days.

  3. We have to first decide what the result of the process should be. The easy thing to do would be to just post the chapters as HTML with no page formatting. But arguably it would help Snap! get taken seriously if it became a real book, on dead trees (and/or some ebook format), which involves careful layout of every page.

  4. And, umm, besides being good for Snap!, it might be good for me personally (and Matt too) to make a little money off this, in which case we might have to impose restrictions on licensing of the product, which might cool people's ardor to contribute. (Maybe not; O'Reilly publishes books that are also online and CC-BY-SA, and Gary Stager is bugging me to write a Snap! book that he can publish, and is willing to do it on a CC-BY-SA or maybe CC-BY-NC-SA basis. Although I think he wants one a little easier than Simply Scheme is.)

For the first one, you don't need to use the call or ID blocks:

Snap*!* version of Simply Scheme.

That sounds like a very interesting project. I didn't know this book which is due to my low education.

SNAP doesn't use a command line, but a canvas to move drag blocks into slots of other blocks.
This seems to me to have lots of implications when learning a language and understanding the patterns behind the language.

Syntax in scheme is always parenthesized lists in which a prefix operator is followed by its arguments. Like (+ (+ 2 3) (+ 4 5)). So this functional thinking of (func arg1 agr2 arg3) sneaks into your blood and brain after writing lots of scheme functions.
We don't have this in SNAP, so I wonder how some of the pages could be transformed to a SNAP context.

Maybe it would be a good idea to invent some Scheme-syntax-like SNAP Blocks, so you get this functional syntax pattern into your blood? Otherwise there are several pages in the book, which wouldn't make a lot of sense in a SNAP context. There are also features like reading files which don't exist in SNAP. But this is only premature brainstorming

image

Unfortunately there are so many interesting projects out there, so I am not sure, if have enough time to contribute a lot to this project.

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.

image

Don't you mean report (join (CHAR) (recur...)) in the last line?

its there... :slight_smile:

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.