Simply Scheme in SNAP

[kimmie46]

There was the idea in a previous discussion to update an existing book with SNAP blocks.

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

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 boo…

There is a book called Simple Scheme written by famous people:
https://people.eecs.berkeley.edu/~bh/ss-toc2.html

i went through the first 100 pages and created some SNAP blocks along the ride/reading. You can take a look here:

Snap! Build Your Own Blocks

The first 6 chapters of Simply scheme explain programming in general, but with a focus on introductory scheme/LISP. It is focused on explaining scheme keywords and their usage on a prompt/command line. That is useful, if you want to learn scheme, but does not fit into nowadays Scratch/SNAP books, which help you quickly to build an application (mostly w/o understanding the CS behind it)
Simply scheme is more like BJC for grandparents, who still want to use a command line.

Here are my 2 points when going through the book.

1. Expectation in SNAP is that any Block on the screen can be executed and it returns a result
   in Scheme you expect that from the command prompt inside round brackets ()

So I created the blocks with prefix notation, which feels already "schemish".
But the main syntax of scheme if left out, so I build a "scheme list SNAP block", which uses the first element as a function and applies it to the next elements as arguments.
(func parameter parameter .... )

So there are 2 types of blocks for the authentic scheme feeling. The rebuild SNAP blocks for the primitives and a generic Scheme brackets simulation SNAP block, which mimics the command line a bit better.

This scheme block fails so far to deal with quoted strings, which occur in CHAPTER 5 ff.
There is no quote in SNAP (besides ringify) as far as I understand it.

So the mimicry of scheme is not complete, and I am not sure yet, if there is some value in building a complete scheme keywords implementation in SNAP. Maybe it would help to grasp the very simple syntax and the concepts of scheme/Lisp. It probably also helps to get deeper into functional thinking.

2. Converting the book Simply Scheme into a SNAP book
   The whole discussion was about creating a SNAP book. If the scope of the book was an introduction into Scheme with SNAP, the book could stay like it is and we would need only to enhance the book with SNAP blocks, which imitate scheme.
   (A SNAP program built with Scheme Blocks could be used to create executable scheme code. )
   BUT: such a book would be useful only for advanced students interested in functional programming and Scheme, NOT for SNAP beginners. And this is where the discussion started.
   I would contribute to such a book, but I am not sure, if there really is a demand for that.

I think, "Simply scheme" cannot make it to become a real SNAP starter book. That would mean it needs to be rewritten completely in my humble view.

This discussion was started with my interest in functional programming. I only started with the first chapters, but will continue with Functions as Data. Now its finally getting interesting.

[cymplecy]

Great stuff

I think I prefer to make Scheme ( ) explicit e.g

[kimmie46]

Correct. If it turns out to enhance the full book with SNAP code and codification to create real scheme oden, then the brackets would explicitly be there. I just dont know yet, if this turns to a real project/book.

[bh]

Thanks, guys. I wasn't really thinking about trying to mimic Scheme syntax, though. More trying to explain the same concepts in more or less the same order, with more or less equivalent projects. If anything, I'd encourage readers who know a Lisp dialect to think of the rounded ends of reporter blocks as being the parentheses!

What would make the Snap! version recognizable as related to the Scheme version is that I'd give readers an environment with the Words and Sentences library loaded.

As in the Scheme version, I'm not trying to teach the language; I'm trying to use the language to teach computer science.

But this project has to wait a little until I'm out from under BJC revisions.

[kimmie46]

@bh

More trying to explain the same concepts in more or less the same order, with more or less equivalent projects.

Yeah, but that seems a totally new book to me. (I would buy that book right away!!)

I'm trying to use the language to teach computer science.

Sure, but it feels to me that there is lots of basic explanation in the first 100 pages, which is just explaining on how to use keywords, how to create a function and so on, which is so much easier now with SNAP. Maybe, additionally, I am lacking patience.

One of the benefits of mimic scheme syntax could be that you could generate scheme code and can run it immediate. Another benefit is to understand the beautiful simplicity of scheme syntax and its link to functional paradigm. I dont know, how you can get to understand functional programming w/o brackets f(x) and the greek letter lambda.

[bh]

@kimmie46

I dont know, how you can get to understand functional programming w/o brackets f(x) and the greek letter lambda.

Another project currently on hold is to implement Church numerals as a possible student project, not for BJC, but for more advanced students. The goal is to use pretty much exact lambda calculus notation:

Unfortunately it doesn't quite work, because of how Snap! handles upvars (which is how the lambda parameters are implemented). The use of LAUNCH in the code pictured here is a partial workaround, but it doesn't fix everything. And yes, I'm cheating by allowing two parameters in a lambda expression instead of Currying it. I'm working with Jens to develop a solution to my problem here, but that won't be immediate.

Anyway, the point is, I think there's a place for strict functional notation, and a place for Snap! notation. I'll try to put some time into Simply Snap! soonish. (Title tentative...)