Scheme Blocks

[Mark Friedman]

I have just finished teaching a course based on SICP ("Structure and Interpretation of Computer Programs") using JavaScript and ironically, though perhaps not surprisingly, it has furthered my interest in developing a visual blocks language version of Scheme.  So, I am starting a new personal project to do just that and am interested in any feedback that this group might have.

My basic, high-level plan is:

1. Take the great work that Lyn Turbak (and presumably others) did on local variables in App Inventor and create a Blockly plugin.  Independent of App Inventor or Scheme, this would, I think, be of some benefit to the Blockly community.
2. Create a design for representing 1st class procedures in Blockly.  Snap! is obviously one source of ideas for this, but if anyone has any other ideas or references they would be welcome.  Note that it's not just the procedure block(s) themselves, but some other things, like how they would fit with built-in primitive functions, which you might want in a Blockly Toolbox but might get dynamically reassigned.
3. Build a Scheme language plugin for Blockly's core language.  This would be like any of the other core Blockly languages.  This would probably not be super useful for anyone, but it's still probably worth doing, I think.
4. Build a "reasonable" Scheme language plugin for Blockly.  This would incorporate a significant subset of the standard Scheme r7rs-small.  I'm open to suggestions on what, exactly, this should include.
5. Design and build a blocks-based Scheme IDE, using Blockly and some existing Scheme interpreter.
6. Build a version of App Inventor that uses Scheme blocks.  This would reuse as much of the existing App Inventor code base as possible.  Note, though, that it will probably not be possible to import/convert existing App Inventor projects to Scheme. This could be viewed as a bug or a feature ;-)

As I said, I welcome comments, questions and ideas.  I also welcome collaborators on any of this!  Let me know if you're interested.

-Mark

[Coda Highland]

You might consider looking at Berkeley Snap! for inspiration.

https://snap.berkeley.edu/research

> Snap! was developed by Jens Mönig and Brian Harvey under the umbrella of the University of California at Berkeley, with the objective of bringing the power of the Scheme programming language and its computer science concepts into a Scratch-like environment.

I'm not entirely sure Snap's approach is the best way to do it, and there's definitely value in a Blockly implementation of it, but given that it's been done before... might be worth taking a look!

/s/ Adam

--
You received this message because you are subscribed to the Google Groups "Blockly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blockly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/blockly/CAOk7GcQE4xGKs90d5ea80uRAWan81wOpaQnBY%3Dq4B1vf%3DVPWdg%40mail.gmail.com.

[Mark Friedman]

Thanks, Adam!  I mentioned Snap! in my item 2 but I'm sure that folks will appreciate the additional context. 

-Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/blockly/CAFE_sBEYdv_A5EiK1zKAfOWYwd458otQJBv9Ykj6T8zYot6JBQ%40mail.gmail.com.

[Coda Highland]

Oh, whoops, I totally missed that! But yeah, hopefully those articles will help shed some light on the motivation.

/s/ Adam

To view this discussion on the web visit https://groups.google.com/d/msgid/blockly/CAOk7GcRPqNp-WJdxzPVCfwbmk_wmic%3DyWcUWgRQzvKqUhSCiPg%40mail.gmail.com.

[Mark Friedman]

BTW, for some reason that page doesn't list the paper "Lambda in blocks languages: Lessons learned".  That paper might be the most salient article about Snap! for the purpose of informing a design for a procedure block.  

-Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/blockly/CAFE_sBGo7wSF3977Wo7d4ApWa2fq3pR459MnbQjFMXTy-P81Fw%40mail.gmail.com.

[Beka Westberg]

Hi Mark!

Thank you for posting about this :D It sounds like such a fun project. Gahhh I wish I had time to contribute right now, but I'll have to satisfy myself with following your progress =)

If you want to create a third-party plugin for the scoping (or anything else) that would be awesome! Scoping is something we've wanted for a long time, and I'm sure other people want it as well. The core team is happy to answer any questions, provide input, and even do code reviews if that's helpful =) We want to facilitate a healthy plugin ecosystem so we're happy to help where we can!

And to get started on that, we do have some docs on plugins, and adding a plugin (although that mostly applies to first-party plugins). We also have a codelab for building your own language-generator, and docs on operator precedence (which I find to be particularly confusing).

Oh and with regard to first-class functions, I remember Lyn's GRASP language having an interesting way of doing that (although that wasn't a blocks language, so it may not apply). I'll see if I can find that later this evening (once I'm on my other computer) and post back.

Best of luck on your project :D Once you have a github/bitbucket repo for it, definitely feel free to share here so I (and other people) can check it out! I can't wait to see how it goes :D

Best wishes,

Beka

To view this discussion on the web visit https://groups.google.com/d/msgid/blockly/CAOk7GcR0NEgx1Xg7DD27uw7Ze-ZPSgzxgj%3D-L0pZPEG47dH9rQ%40mail.gmail.com.

[Beka Westberg]

> Oh and with regard to first-class functions, I remember Lyn's GRASP language having an interesting way of doing that (although that wasn't a blocks language, so it may not apply). I'll see if I can find that later this evening (once I'm on my other computer) and post back.

Ok, I've dug up Lyn's master's thesis on Grasp, because I don't really like the way Snap! handles first class procedures (ie the grey ring). In my view, with Snap! you're basically wrapping an instance of a procedure activation in a special construct to get a reference to the procedure definition the activation references, which is super weird.

The Grasp language has a much clearer separation between procedure activations (aka procedure calls, procedure invocations) and procedure definitions. When you start learning Grasp, you only have access to procedure activations (called "machines" in Grasp). Then as you advance you start to create procedure definitions (called "blueprints"). These blueprints can then be activated by an "abstract machine" which is equivalent to Scheme's `apply` procedure. (5.4.1 and 5.4.6 in Lyn's thesis)

I think having the separate notions of procedure activation and procedure definition with different visual representations is very important when you're trying to make this advanced concept intuitive. Otherwise it's hard to understand the difference between a definition and an activiation. IE how the former is a first-class data type and the latter is not.

As Lyn notes in his thesis (7.1.2):

"A problem with text-based languages such as Scheme is that syntactic patterns do not necessarily indicate a semantic relationship. This is the basis for the "procedure as pattern" bug in which the programmer attaches undue importance to the syntactic similarities between the forms for defining a procedure and for invoking it. Since the visual representations in the Grasp system are intentionally chosen to convey the structure of the computational elements, reasoning based on visual similarities is valid in Grasp."

I think Snap! has fallen into a similar "procedure as pattern" trap by creating syntactic symilarities between their procedure activations and references to procedure definitions.

I think some clearer notations would be:

• Having to "apply" every instance of a procedure definition,  instead of referencing activations directly (but this would get quite verbose).
• Having separate blocks for procedure activations and references to procedure definitions (but this expands your number of blocks).

But then again, maybe the design of Grasp doesn't really apply to blocks-based programming. And afaik Grasp was never tested with students either, so it may not be the best place to look for wisdom hehe.

If anyone has thoughts on this I'd love to discuss more :D It was super fun to dig up this old research hehe.

Best wishes,

Beka

[Mark Friedman]

Wow!  Thanks Beka!  I appreciate your advice and I look forward to reading Lyn's thesis (or maybe even re-reading, since it's quite possible that I read this years ago and have forgotten).

-Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/blockly/8ab5459d-1806-41cc-b8c8-224267a2ecffn%40googlegroups.com.