As part of building a Scratch Player in Flash, I produced a quick textual 'dump' format to be able to confirm the object & language reader was working properly. As a quick extension to that, I tried to make the dump format be parseable again. What resulted was a python-esque language that very closely mirrors Scratch visual layout. It could conceivable express a whole project assuming media were 'included' from external files, but the example is just the major entities (stage and sprites) and the code itself.
This topic may have come up many times before and I know about the BLOCK format (see below), but I thought this particular example might be interesting. Maybe replacing the placeholder ('%b') markers with parentheses of the arguments like done in the BLOCK format would be an alternative to get it to be more vertically compressed, so I put that example in as well. Or just writing it here (see below), it is basically similar to the BLOCK format without the extra brackets and where indentation is meaningful.
The longer writeup and some comments are at:
http://chimu.wordpress.com/2008/09/17/scratch-textual-language/
when I receive (find-next-disk)
set next-disk to (0)
broadcast (propose-next-disk) and wait
repeat until ((next-disk) > (0))
set potential-disk to (0)
if (not ( (potential-disk) = (previous-moved-disk)) )
set next-disk to (potential-disk)
broadcast (move-next-disk) and waitSemi-translated into BLOCK notation form (which was actually quite hard to get right :-( )
[blocks]
<when I receive[ find-next-disk
<set{ next-disk }to( 0
<broadcast[ propose-next-disk ]and wait c>
<repeat until><(<{ next-disk >}><>>0)>
...
<end>
[/blocks]
<when I receive[ find-next-disk
<set{ next-disk }to( 0
<broadcast[ propose-next-disk ]and wait c>
<repeat until><(<{ next-disk >}><>>0)>
...
<end>Offline
Hi, parseroo.
I looked at your blog entry about this. Very interesting! I think having a text form of Scratch blocks could be very useful as a transition from Scratch to text-based languages, and I agree with your set of design principles.
Scratch already has a way to dump a text description of a project, including all the scripts. Shift-click on the "Extra" button and select "write project summary" from the menu. We created that feature to help us analyze projects as part of a research study (that's why it is a "hidden" feature), but it is sometimes be a "aha!" for people to see that their Scratch code can be represented textually. The format of the code was meant for human interpretation, not reading by a computer, but I don't think it would take much to change the format so it could be easily parsed by a computer and converted back into blocks, perhaps using conventions similar to your first code snippet above.
Please keep me posted about your project!
-- John
Offline
Hi, again.
Your syntax could be made even easier to read and type by omitting parentheses around arguments that are either literal constant values (strings or numbers) or varaible names. The parser would only need to be a little be more clever. For example:
when I receive "find-next-disk"
set next-disk to 0
broadcast "propose-next-disk" and wait
repeat until (next-disk > 0)
set potential-disk to 0
if (not (potential-disk = previous-moved-disk))
set next-disk to potential-disk
broadcast "move-next-disk" and waitNote that expressions would still have parenthesis around them.
A final refinement would be to allow assignment statements using "=" rather than the "set _ to _" form:
when I receive "find-next-disk"
next-disk = 0
broadcast "propose-next-disk" and wait
repeat until (next-disk > 0)
potential-disk = 0
if (not (potential-disk = previous-moved-disk))
next-disk = potential-disk
broadcast "move-next-disk" and waitWhat do you think?
-- John
Offline
The quotes around the event names definitely makes more sense than parentheses -- (find-next-disk) or (foo) would appear to return the value of 'foo' [which could be "move-next-disk"] not be equal to the string "foo". So I just had that wrong :-)
I also agree that bare numbers shouldn't need parentheses (as long as block names can't include bare numbers).
Regarding the '=', I was not trying to change anything about the language between the visual format and the textual one -- both because the language exists and also because of the potential benefit for human-language translation.
Certainly having a short assignment is nice but typing "set ... to" is pretty short and exactly matches the block wording. And starting with a word makes the lines very readable in 'natural language'.
I guess there is an ambiguity issue though. Statements like 'set size to 5' is ambiguous and might require extra quotes to be a variable setting 'set "size" to 5' is different from 'set size to 5'. So maybe that is a benefit to making assignment a bit different from this common pattern of other 'set foo to'. Or people would have to get used to typing extra quotes.
Personally, I don't like '=' being assignment (however used to it I am) and I especially don't like it if it depends on context:
failure = (potential-disk = previous-moved-disk)
And introducing '==' for the equality comparison seems a shame.
Personally I do like ':=', ':-', '<-', and any similar kind of arrow-looking thing (without stealing the '_' key :-) ). I think ':=' is the most normal of these, but ':-' should be the easiest to to type.
Offline