Scratch

joefarebrother wrote:

but if the add block copied the list instead of adding a reference, but it added it AFTER copying not before, there will be no infinite loops

Well, for our purposes, sometimes the user wants a self-referential data structure.  Also, even if not, the user usually wants a later change in a sublist to be reflected in the list-of-lists.  So copying isn't a good option; the user can make a copy explicitly if desired.

Maybe Scratch could do lists of lists with copying.  It would be weird,  I think.

Hardmath123 wrote:

bring your own milkshake?

   Maybe if you rotate the second B 90 degrees counterclockwise.

Is there any way on byob 3.1.1 to test if a value is 'nil', the value reported when a script doesn't report anything? Because right now i am trying to make a switch block that allows you to jump between cases using a report block, but the test script has to look like this: (you need antidote to see it)

Those report blocks allow you to jump between cases so you can stockpile actions (also if you report <false> it will do the default AND the case) but you need a report <true> block to end the script, which looks ugly. If there was a way to compare values to nil, i could solve this problem. (the = boolean doesn't work) Here is my implementation:

Last edited by joefarebrother (2012-03-21 17:56:04)

joefarebrother wrote:

Is there any way on byob 3.1.1 to test if a value is 'nil', the value reported when a script doesn't report anything?

Scratch (and therefore BYOB) makes a strong distinction between commands and reporters.  It's an error to CALL (rather than RUN) a block that doesn't report a value.  I just tried putting a STOP BLOCK in a custom reporter in 3.1.1 and it seems to cause an infinite loop when CALLed.

If your domain doesn't include Booleans, you could write a reporter version of SWITCH and have each case report a new value or False.  Then I'd use CASCADE to keep trying until the reported value is False.

Hardmath123 wrote:

I'm thinking about writing a Lisp interpreter in Scratch.

You're a masochist!  It's (pretty) easy to write a Lisp interpreter in a language that gives you recursive procedures, but you're going to have to maintain a stack of tasks in an explicit list to simulate procedure calls.  And you don't even have lists of lists in Scratch, so you have to encode everything as text.

Doing a pure functional Lisp by substitution, as you suggest, should work fine.  If you'd like to see another way, one that even lets you implement mutation, look at the Explicit Control Evaluator in Chapter 5 of SICP.  The evaluator comes pretty late in the chapter, but you have to read all of it, because they start by essentially inventing a machine language and you have to understand that first.  The payoff is that the evaluator does tail call elimination, not to mention that you can have DEFINE.

P.S.  It's awesome that you're into Lisp.  I'm still working on convincing Jens that we should compile Snap! procedures into Lisp. 

roijac_test wrote:

won't it be faster to compile it to JS?

Well, it'll be more useful to compile to JS, in terms of getting Snap! projects to run fast, and we'll do that too.  But I don't really want to show the user the resulting JS, because it's not going to look like idiomatic JS code; it'll be all procedure calls, basically.  Whereas the result of compiling into Lisp will look like idiomatic Lisp code, because (1) Snap! is really just Scheme in disguise, and (2) all programming languages are really Lisp once you get past the surface syntax -- this is why the first thing a modern compiler does is to turn the program into a "parse tree," a/k/a a Lisp program.

roijac wrote:

wait, why not just show em the snap! blocks?

We're already doing that.  The question is whether also to have some format that's easier to write programs about.  The alternative would be to make a parse tree in list-of-blocks form, which we should do also.

bharvey wrote:

joefarebrother wrote:

Is there any way on byob 3.1.1 to test if a value is 'nil', the value reported when a script doesn't report anything?

Scratch (and therefore BYOB) makes a strong distinction between commands and reporters.  It's an error to CALL (rather than RUN) a block that doesn't report a value.  I just tried putting a STOP BLOCK in a custom reporter in 3.1.1 and it seems to cause an infinite loop when CALLed.

well sometimes it reports 'nil' which always returns false in the equals boolean (even with another nil value) and causes an error if you try to check it's type with the <Is () a ()> block, and other times it loops forever trying to report something.

joefarebrother wrote:

I thought of a mechanism to solve this: encode your "list" as a php string

Oh, yeah, it's possible; you just spend half your time encoding and decoding instead of doing the interesting work of evaluating expressions.

You could even encode it as strings of zeros and ones!   

bharvey wrote:

joefarebrother wrote:

well sometimes it reports 'nil' which always returns false in the equals boolean (even with another nil value)

Nil isn't a value; it's a very terse error message.  When we have time for details of the user interface, we'll improve error reporting.

also (atribute [parent v]) of something that has no parent is nil

bharvey wrote:

joefarebrother wrote:

also (atribute [parent v]) of something that has no parent is nil

I'm going to talk Jens into having a root object that's its own parent, so every object will have a parent and this won't arise.  (But the parent of a toplevel sprite will be the Sprite object, whose parent will be Corral (with Stage as its other child); Corral's parent will be Object.  Or something like that.  Other children of Object will be Costume and Sound.

But I don't think I've talked him into it quite yet. 

Couldn't you then recurse infinitely if you were trying to find the toplevel parent through repeated calls to parent? Wait, maybe not...

bharvey wrote:

joefarebrother wrote:

also (atribute [parent v]) of something that has no parent is nil

I'm going to talk Jens into having a root object that's its own parent, so every object will have a parent and this won't arise.  (But the parent of a toplevel sprite will be the Sprite object, whose parent will be Corral (with Stage as its other child); Corral's parent will be Object.  Or something like that.  Other children of Object will be Costume and Sound.

But I don't think I've talked him into it quite yet. 

maybe any toplevel sprite is the parent of itself?