So
[scratchblocks] (add[d]to (list[a][b][c]@delInput @addInput::list)::list)//a, b, c, d [/scratchblocks]
[scratchblocks] (delete[1]of (list[a][b][c]@delInput @addInput::list)::list)// b, c [/scratchblocks]
And likewise.
Why not, or at least add it to relabel.
That would be convinent for when I'm testing list stuff and seeing the output of, for example, this:
[scratchblocks] script variables ( (list ) :: grey ) :: grey set [list v] to (list [1] [2] @delInput @addInput :: list) add [3] to (list) report (list) :: control cap [/scratchblocks]
if they were reporters i would be able to instead write simply this:[scratchblocks] (add [d] to (list [a] [b] [c] @delInput @addInput :: list) :: list) [/scratchblocks]
How do you get the arrows (on, lets say [scratchblocks] (list[a][b]::list) [/scratchblocks] ) with scratchblocks?
Just tag @addInput and @delInput.
oh well they will be angry to see people tag them just for fun
those people do not exist evident by the inability to click on their names and them not having a background.
and also @silver_star you need to wrap the scratchblocks in the html <p> tag so discourse doesn't break it
<p>[scratchblocks]
...
[/scratchblocks]</p>
and @addInput and @delInput will be converted to their respective symbols
will do that job nicely
I was just using that as an example, but what about for delete and insert at?
They are more complex to make 
But generically - to convert one of the list command blocks into a reporter use this construct
I like this idea, but in most text-based languages (that I know of) deleting items fron lists returns the items that were deleted - I think it would make more sense to go with that.
What about list watchers? You would have to do
[scratchblocks]set [my var v] to (add [] to [my var v]::list)[/scratchblocks]
and the watcher would reset its size every time.
When people use those blocks it's because they're trying to build a script, a sequence of instructions. You can't do that with reporters, so this would make it harder for people who only know about programs as a sequence of steps. They'd have to use IGNORE all the time.
People who know about reporters shouldn't mutate lists as side effects of computing a function. You make a new list (which might or might not share storage with the old one, depending on how you make it).
If I were designing Snap! from, uh, nothing, I'd have just one block shape, so you could use the same block as an input to another block and as a toplevel block in a sequence. They'd look kinda like those Darwin bumper stickers. But I'd still encourage people to program functionally, without side effects.
No, [scratchblocks] (addto(list)::list) [/scratchblocks] would just be an option on relabel.
The original [scratchblocks] addto(list)::list [/scratchblocks] would still be there.
I think that is a very good idea.
it looks gross in ur quote
yeah scratchblocks don't quote very well
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.