Scratch

Then why is there two slots in BYOB for these Boolean/predicate blocks?

Or does the Boolean one CARE about the input? (if so, can you explain it a little?)

Edit: Btw, yay new page.

Last edited by DigiTechs (2013-04-10 06:55:01)

@Jens Do you know which one(s?  ) of my proposals got accepted to the Barcelona conference? And do I have to pay to get in, even though ill be presenting?

monadic, dyadic and variadic indicate the arity of a function, i.e. the number of inputs it expects (derived from Greek):

   monadic: single input (e.g. sqrt)
   dyadic: two inputs (e.g. x + y)
   variadic: arbitrary number of inputs (e.g. JOIN in Snap!)

Sometimes you can also see their Latin counterparts (e.g. in Smalltalk):

   unary: single input (e.g. Smalltalk's #fact method)
   binary: two inputs (e.g. Smalltalk's #@ constructor)
   ternary: three inputs (e.g. JavaScripts  ? :  expression)
   n-ary (hence the name "arity"

so, when we're saying "variadic" inputs we're referring to the "Multiple inputs" radio button in Snap's long form slot type dialog.

Does this help? Otherwise Brian can explain these things much better.

Last edited by Jens (2013-04-10 11:16:02)

blob8108 wrote:

technoboy10 wrote:

And do I have to pay to get in, even though ill be presenting?

I wondered that. I think you do...

That's too bad. 

@blob

You might want to add some way to indicate where watchers should go and not store it in the Watcher object (see Scratch's watcher positioning bug)

And in kurt.CostumeFromFile(name, fp, image_format=None), you know that 'fp' means file-path, right? 

And, why [removed by moderator - please keep it polite] would you make Actors hard-reference the project? o.O
The memo-leak in kurt itself is bad enough (I just write a patch for M30W to open projects in another process...), you can use weakref.proxy, you know 

Last edited by Paddle2See (2013-04-10 12:34:16)

Jens wrote:

when we're saying "variadic" inputs we're referring to the "Multiple inputs" radio button in Snap's long form slot type dialog.

Ah, yes. Like the "(list [] < >)" block.

roijac wrote:

You might want to add some way to indicate where watchers should go and not store it in the Watcher object (see Scratch's watcher positioning bug)

This might make sense, yes. But Scratch doesn't store the information anyway, afaict, so I don't see the point.

in kurt.CostumeFromFile(name, fp, image_format=None), you know that 'fp' means file-path, right?

Dang, good point. I was going for "file-pointer" ("file" is a builtin, ofc). Any suggestions?

And, why [removed by moderator - please keep it polite] would you make Actors hard-reference the project?

Certain things need access to data from the rest of the project — for example, Blocks sometimes need to look up a sprite by its name from a block argument.

If your objection is to having to pass a Project to the Stage/Sprite constructors, I could have the Scriptable.project instance variable be magically set by Project, when you add a Sprite to the "sprites" attribute, for example. (This is what I'm planning for Blocks and Scripts, and Kurt 1.4 has partially.)

I don't know what you mean about memory leaks. Python has built-in GC. Kurt might use a lot of memory if you open lots of images, but that's not a memory leak.

And I don't want weak references. 

Thanks for the feedback!

(BTW, you realise the API m30w currently uses is going to be completely broken, right?  )

Last edited by Paddle2See (2013-04-10 12:36:18)

Lua has built in GC, but you can still get memory leaks if you define too many useless variables.

Hardmath123 wrote:

DigiTechs wrote:

Then why is there two slots in BYOB for these Boolean/predicate blocks?

As far as I know (not… giving… in… to… AFAIK…), one of them returns a lambda that you need to run, for short-circuit evaluation, and the other evaluates the condition that you can use directly.

Do you mean something like an anonymous function in Lua?

Example of Anonymous function:

    function newCounter ()
      local i = 0
      return function ()   -- anonymous function
               i = i + 1
               return i
             end
    end
    
    c1 = newCounter()
    print(c1())  --> 1
    print(c1())  --> 2

roijac wrote:

Look at the new 2.0 JSON format, pretty sure they added it

Seems they did — though it seems broken in practice for lists.

Added, anyhow!

EDIT: readthedocs is cool. I love the post-commit hooks!

(PS: anyone else ever clicked "quote" instead of "edit"?  )

I was going for "file-pointer" ("file" is a builtin, ofc). Any suggestions?

stream?

Hmm, not sure. Maybe I'll just use "file_".

I get 69MB of RAM stolen from my PC

Blame the object table format. 

(BTW, you realise the API m30w currently uses is going to be completely broken, right?  )

Well... I certainly want the ability to change my classes without upstream changes - it's really unlikely that I'm going to use kurt as more than a backend.

I was just suggesting you update your requirements/setup.py to specify kurt<2 

Last edited by blob8108 (2013-04-10 11:47:45)

No, but multiple variables can reference the same value (e.g. list), and display editable watchers on it.

Okay, but you do realize that a list can have multiple watchers, right?

@DigiTechs:  Like most non-purely-functional programming languages, Snap! uses applicative order evaluation, which means that when you run a block, Snap! evaluates whatever expressions provide the inputs to the block before running the block itself.  To take a simple example, SAY (2+3) computes the value 5 and gives that to SAY as its input; SAY never knows how that 5 was computed.

So, with that in the back of your mind:  An input of type Boolean means that the block expects a true-or-false value as the input.  Whatever expression you put in that input slot (e.g., <(x) = 7>) is evaluated before the block is run.  An input of type Predicate means that the block expects a block as its input value -- specifically, a hexagonal predicate block.  The block itself is the input, not the result of running the block.  This is useful, for example, to write something like REPEAT UNTIL that will want to evaluate the predicate block repeatedly.

Now the fun part:  An input of type "Boolean (unevaluated)" looks like a Boolean input (a hexagonal slot), but behaves like a Predicate input (i.e., doesn't evaluate the expression in the slot before calling the outer block).  The Scratch built-in REPEAT UNTIL block has, in reality, a Boolean (unevaluated) input slot.  (Whereas IF uses a plain old Boolean input slot because that expression only has to be evaluated once.)  The purpose of unevaluated input types is to allow system-builders to use procedures as inputs (predicate procedures, in this case) without the system users having to understand first class procedures.

A procedure with unevaluated inputs is historically called a "special form."  In programming language theory, special forms are understood as a way to have islands of normal order evaluation (meaning that procedures see the actual input expressions, rather than the values of those expressions) in an otherwise applicative order language.  In particular, recursive procedures will never terminate if the IF/ELSE used inside them isn't a special form (thinking now not about the Boolean input, but about the two "legs" of the IF/ELSE that say what to do in each case).  If IF/ELSE followed applicative order, the recursive call would be evaluated even in the base case!

In Scratch and all its children, the script in a C-shaped slot is always an unevaluated input.  That is, all C-shaped (or E-shaped) blocks are special forms.  The fact that Scratch users don't have to think about normal vs. applicative order shows the value of unevaluated input types in user interface design.

I hope this answers the question... 

Last edited by bharvey (2013-04-10 12:33:39)