Add new scripts

Feature Requests
1

Please fill out these questions for all feature requests and bug reports. If you're requesting a feature, please let us know why this feature is important or useful, not just what it should do.
Thanks!

  1. What browsers show this problem? All browsers (this is a feature request, the code has never been written.)
  2. Please share an example project (if possible). N/A
  3. Describes the steps to reproduce this issue. Open snap.
  4. What does Snap! currently do? There are no blocks to add scripts to the scripts area
  5. What should Snap! do instead? There should be one block to add a script that has an option for the hat block and the script, and returns a number that can be used to delete the script using the other block.
    Is this bug a security concern? If so, please do not post security concerns directly to the forum. Please email us at contact@snap.berkeley.edu. Thank you!
2

Yes.

This is part of a bigger piece of work we have to do. The thing is, it's not so very useful to add one canned script to the scripting area; you could just put it there the usual way. (I know, not if you're a library. Still, only useful in a narrow situation.) The bigger project is to be able to look inside a script and assemble a script out of pieces with variations. For example, in Logo I can do this:

to ordinals :index :names
if emptyp :names [stop]
define first :names `[[data] output item ,:index :data]
ordinals :index+1 butfirst :names
end

ordinals 2 [second third fourth fifth sixth seventh eighth ninth tenth]

and that gives me a bunch of procedures like

to fourth :data
output item 4 :data
end

We can do that in Logo because programs are text, and so the language facilities for manipulating text automatically also work to manipulate programs. But in Snap! we are up against what I think is the big weakness of block programming: programs aren't text.

My current thinking about this is that we provide two primitives to convert back and forth between Snap! code and Lisp code. A Lisp program is a list of lists. So we'd convert
untitled script pic (1)
to something like
[[BLOCK untitled script pic (3)] [[BLOCK untitled script pic (2)] 2 3] 5]
where [...] represents a list, and [BLOCK ...] is a data structure from which you can extract the block's picture, its name, its spec, its arity, etc. So that's the translation of an expression or instruction into list form. The translation of a script would be [BEGIN (instruction) (instruction) ...]. The translation of a procedure definition would be [(MOTION|LOOKS|SOUND|...) (COMMAND|REPORTER|PREDICATE) (name) (spec) [(input name) (input name) ...] (body)] where body is a script as above. Name is redundant with spec, but provides a canonical name for a block with title text distributed among input slots -- is the block called ITEM or ITEM OF? The name field could, special case, be LAMBDA, in which case the translation is a ring rather than a definition. If there's a name, though, the text version could be input to (DEFINE (proc)), which would cause a definition to exist. (TEXT (ringed block)) would be the reverse translation.

(MAKE-SCRIPT (script)) could then do what you're asking for. And, you're right, hat blocks have to be treated specially.

Anyway, this is a huge undertaking, and I think we're huge-undertakinged out for the moment. But it's high on both our lists.