Codification Improvements

[cycomachead]

Would it be possible to make any of the following improvements to codification? I'm happy to help with some if I get a bit of direction for what to do. We're going to be using Python in a few weeks in CS10 so I'm going to be working creating a more robust codification project for Python, with the goal of being 2.6+ and 3.3+ compatible! :)

• Would it be possible to make a generic header mapping so custom blocks don't individually need to be translated? So I could say: Map [procedure definition] to XXX. And in python this would be: ` def (, ): `
• When a code mapping doesn't exist, the code of block currently skips the Snap! Block. Would it be possible to have this output some default string about the snap! Block? Of course it'd be syntactically incorrect, but so is a blank space that's left right now. (At least in most cases.)

I'll post more as I work on this! :)

[cycomachead]

How might I ringify a ring?

I'd like to map rings to create proper lambdas in Python which should be totally possible, but I don't see anyway to actually ringify and empty ring.

EDIT: D'oh: Dragging a ring in a ring actually works, you just can't do it with a context menu.

[jmoenig]

isn't the "header mapping" menu option, which is the same as the MAP TO HEADER block variant what you need?

[brianharvey]

Dragging a ring in a ring actually works, you just can't do it with a context menu.

We're going to fix that. It's on the list.

[cycomachead]

The header mapping works ok, but it has to be specified for each custom block. It would be nice if there was a 'meta' header header so I could specific the same setup for every custom block to be automatically converted.

[studej]

Remapping headers and codes of all blocks I agree with @cycomachead This is current problem: 1) Map some blocks to 1st language 2) Map some blocks to 2nd language which has limited syntax (recognizes only a few blocks) Now when you start mapping script -- you can have mixed result, because mapped blocks from 1st language weren't overmapped by 2nd language.

It will be nice to have block which will remap all primitives and custom blocks (also delimiters etc.) in project. I would like to use custom strings (e.g. "//Unsupported").

What about comments? Will it be possible to remap comments of script? If yes, then we need map String to code %input with enumeration String/comment

[brianharvey]

First a minor point: You can now double-ring from the context menu.

As to the big issues: First the meta-issue. Jens's idea about codification is not that it translates all of Snap! into some other language. It was inspired by the need of PiE for a way for hs kids to program their robots in simulation and then download Arduino code to the actual robot, and so the goal is to codify only the handful of blocks that are actually relevant to the application. Hence it doesn't have every possible feature.

Having said that, I think it would be great if we could use codification to build a Snap! compiler, not to make standalone executables but to essentially turn custom blocks into primitive blocks when speed is important. So for me it's Javascript, not Python, that is the truly important target language.

So, about some of the specific issues above:

Yes to supporting comments. And that eliminates the need for a special case for unsupported blocks; you can just turn them into comments of the target language.

I'm unsympathetic to complicated solutions to problems that arise when putting two target languages in the same project. I know Jens's demo project does that, but in real cases a project will import a particular target language library.

Yes yes yes to supporting rings! They're our best feature and we should be eager to show off how programs that ought to work when translated to Python actually don't. :-)

I think this is a good Michael-size project. Keep it simple.