Running (or Calling) functions defined with upvar (implementing Python in Snap!)

[stirlingstout]

Hello. I started doing this in BYOB but I've come across the same problem in Snap! (but with a different outcome).

Background: As an experiment sparked by Stefano Federici's languages in BYOB/Snap!/BloP I've started implementing languages in BYOB. So far I've got ARM assembly language and a reasonable subset of Python, but the definition of functions is very clunky.

In Snap! the equivalent of what I want to (be able) to do is shown in the attached images below.

I define the function using the def [] ( [] , [] , [] ) block (there are a number of these depending on how many parameters there are, the example uses 3). This uses one parameter for the name of the function and 3 defined as upvars, so the user can use them in the function definition.

Calling the function is done with the [] ( [] , [] , [] ) block (again there are a number of these depending on how many parameters there are).

On my BYOB version the calling works, but every variable has the value 0 (I think I'm homing in on the error (though I may be way off) and I don't mind writing a new image for this use). On Snap! I get the error message Inside: Error. Expecting 0 input(s) but getting 3.

Is what I'm doing impossible? Should it work? It certainly looks reasonable to me.

I want to make the process of writing Python in Snap!/BYOB as like writing Python as possible to allow a project like this to help with the students in the UK who have to have experience of (at least) one graphical and one text based language for GCSE. Anecdotally there are a fair number of students who find the leap very difficult and it would be interesting to do some research on whether this helps.

Thanks.

John Stout

[jmoenig]

Hmmm, I'll investigate (but I've got a few days off, so it might take me a week).

On a side note: Has anybody seen this work: http://dataspace.princeton.edu/jspui/handle/88435/dsp017w62f8405

It's behind a registration wall, but I'd be interested in this, as it seems to cover common ground...

[jmoenig]

Aha, found it here: https://github.com/Sktank/SnapPy

[jmoenig]

Okay, at some point we need to talk about sentences like this one (in SnapPy):

blocks are merely a high level abstraction of underlying textual code

He's gotten it all backwards! Text is an abstraction of the mechanics of a program. The "mechanics" happen to be the AST and that maps directly to blocks. Therefore blocks are way closer to the metal than any text.

Grrrr.

[stirlingstout]

Jens

Thanks for looking into it.

I thought this was an interesting statement from the SnapPy author as well:

the semantics of blocks in graphical programming languages can be easily inferred without any prior coding knowledge

John

[haritop]

Try this

[stirlingstout]

Hi. I've just tried this and I get the same error. I think I've got the block correctly built (a, b, and c are still upvars aren't they?). Calling the defined function should be the same shouldn't it, i.e., [run (item [1] of (item [2] of [functions])) with inputs [par1], [par2], [par3]]

I couldn't do it in Chrome since I just couldn't manage to get the drop down in the set blocks to work, so this is in Internet Explorer. I'll try and export the project and see if I can run it that way.

Thanks for the help. I presume what this does is set up an enclosing scope/closure for block that can feed the parameters into block.

John

[haritop]

Hello John, I've tested this on Firefox, Chrome and IE and it runs OK. You're right on everything you mentionted. You just change the "def" block, and the rest should stay as they were. You're also right about the idea behind this. I can't figure out what causes the problem(When I tested your initial code I had the same error like you, but not now). Did you update the "functions" list, before calling the defined function?

[stirlingstout]

Ah, I've just looked at the error properly. It now says Inside: TypeError. Object doesn't support property or method 'at'.

Yes, I've updated the functions list.

Sorry, my stupid mistake: I'd put (item (1) of (item (2) of [functions]) rather than the other way around. It's now working OK. Thanks very much.

Now, can I do the same in BYOB? I'll have a go but if you've any ideas I'd be very grateful.

John

[stirlingstout]

Many, many thanks. A simple [the script] block around the sets and the block and it's working in BYOB (after fixing some stupid errors on my part).

Do you think the original should have worked? Jens doesn't seem to think it obviously shouldn't which gives me some hope. I was trying to debug the problem (if it is a problem) in BYOB but I don't think I was getting very far (though I learnt a lot more about the way it works).

Thanks again.

John

[jmoenig]

John, I just didn't get around to checking your original solution because of the holidays (and my vacation this week), but my general inclination is that any attempt at creating anything that's called "function" without using a full Lambda construct is bound to fail :-)

Now, I see that you're assigning the "blocks" as the function itself, and that that is a lambda, but you're not binding the parameters (the upvars). Therefore the function is missing a crucial part and I'd expect it not to work most of the time.

I'm glad that there seems to be a working solution now, but I'd actually love to have a discussion about the merits of the whole approach, I can't deny that I'm very skeptical about it. Anyway, give me another week or so, then I promise I'll look into all of this and maybe come up with another suggestion or two how to transition from blocks to text (shudder...)

[cycomachead]

This is definitely interesting. I've been experimenting with a similar idea around custom blocks, though I'm trying to match the AP spec syntax... I'd love to hear what comes out of this.

[haritop]

@stirlingstout : I'm glad it help you out. @jmoenig : Just a notice(I don't know if it's important, so I won't open a new issue for it). Check this code: This works, and the last say, prints 0. That is: upvars behave like temporary variables. Is this normal? Note that, this doesn't work in BYOB.

[jmoenig]

@haritop yes, in Snap upvars are script variables. You can use upvars to build your own (temporary) variable definition block. This did not work in BYOB.

[stirlingstout]

Not really relevant but one strange thing that's come out of this (but it is in BYOB, I haven't checked with Snap!) is that I can't save the project if the function list variable has any contents. I get Unknown class: CArgSlotMorph error. Clearing the functions variable before I save stops the problem. I've tracked this down to missing entries in ObjStream class>>userClasses but when I 'fixed' this I got the same error with MultiArgMorph. I fixed that and now I'm getting another error on UTF32['2']!

@jmoenig: I'm also not sure about the approach, but with a bit of luck I can get some teachers in our Computing at School organisation to do some research on it (Mandi Banks at Manchester University's Institute of Education is also interested). Anecdotally there is a problem, but whether this will help I don't know. I think a lot of it is the "Oh no, I've got a blank page in front of me! Where on earth do I start?"

I wondered about some sort of halfway house where you would drop text, rather than blocks.

[jmoenig]

I know and i'm sorry! BYOB has stretched the Scratch source code more than was sustainable, that's why I've reimplemented it as Snap. There are many, many issues with BYOB, and I'm more than just a little scared that it's still so popular 4 years after I've stopped supporting it... (I do understand that some teachers love BYOB's prototypal inheritance features, and you might have noticed that I'm just now adding those to Snap as well).

This whole blocks-to-text-transitioning debate makes me very nervous. It's my impression that this "problem" is mostly raised by teenagers wanting to "code like real men" (gender-bias intended) and by policy makers who don't know any better, i.e. who have no computer science background themselves. Too many people believe that computers are somehow driven by text. This is clearly untrue to the point of having become a superstition, same as a violin is not played by sheet-music. Nobody would seriously claim that when they strum a guitar their actions are converted to an "underlying" written score that gets magically applied to the strings achieving a chord. Yet, with computers that seems to be the prevailing misconception.

TRL;DR: It's okay to teach writing skills in grammar school. Programming a computer is not a form of writing but of building. Just because we've been harassing students with Latin so long doesn't justify turning everything into Latin.

That said, are you aware of Snap's "codification" capabilities? Snap lets you map any block and its inputs to any textual expression. Then you can actually transcompile Snap scripts to any textual language. Did you know that?

here's a demo project that lets you encode some simple algorithms from Snap to Python, JavaScript, Smalltalk and even C:

http://snap.berkeley.edu/snapsource/snap.html#present:Username=jens&ProjectName=Codification

This can be applied to any other textual programming language, I've just provided a few simple examples of ones that I'm more familiar with (at some point I need to document this better, I know).

So, you see, the point of this demo is that once you have blocks, turning them into text is really trivial, it's just pretty printing, nothing more! The whole point of programming is learning to think in terms of structural elements (statements, expressions, functions, objects etc.) and not in terms of words and letters. You are a programmer if you can see and think in the underlying structure. That's what blocks are about.

That's also the reason why I've included Elements in BYOB (you're probably aware of this, right?). With Elements you can see the "underlying blocks" behind Squeak Smalltalk, you can see that the whole system is nothing but blocks all the way down. You don't ever need text for a big system, it's just plain not true.

So, let me slip another half-secret here: At the moment we (John Maloney, Yoshikiki Ohshima and moi) are creating (yet) another general-purpose blocks-based programming language, which, like Elements is built with blocks all the way down. We'll start presenting it and looking for early testers at this summer's Scratch conference in Amsterdam. Are you going to be there? I'd love to discuss this more with you in person, John!

But I'm aware of your evangelization efforts, and that I'm preaching to the choir here. Therefore, if you feel that it would be helpful to create a form of hybrid language combining blocks with text, I'm all for that (and I do have a couple of ideas how to implement this in Snap). Let me come up with a proposal sometime next week!

[stirlingstout]

I was really looking forward to coming to Amsterdam but my partner and I are driving down to Croatia in our VW camper when it's on. I really like Elements, and have used it as a quick introduction to the 'stuff' underlying BYOB.

I'll have a look at your Codification project as soon as I can (I'm away at the moment). One of the main reasons I've stuck with BYOB is the Files category I've added which means that schools can use it for GCSE projects, and that I can use Smalltalk. I've never really taken to Javascript but I think I'll have to start.

I'm quite happy to play around with BYOB to try solving the problems so absolutely no need to apologise.

Your new system sounds really exciting. Even though I'm not going to be there I'd love to be involved as an early tester.

John

[bb010g]

An Elements-style system could probably be made for JS too.