• Object-oriented programming, message passing, encapsulation and inheritance with first-class objects:
  

  define make a dog (name)
  report ({
    if <(message :: custom-arg) = [name]> then
      report (name) :: custom cap
    end
    if <(message :: custom-arg) = [bark]> then
      say [Woof woof!] for (2) secs
    end
  } input names: (message :: custom-arg) @delInput @addInput :: grey ring) :: custom cap
  
  define ask (object) for (message)
  report (call (object) with inputs (message) @delInput @addInput :: control) :: custom cap
  
  define tell (object) to (message)
  run (object) with inputs (message) @delInput @addInput :: control

  
  
• Local variables (lexical scoping)
  (For convenience, Scratch should probably have an easier way to make local variables, but it's possible do it with lambda.)
  
  
• Very versatile procedures (higher order procedures)
  
  
• Callbacks
  
  
• Data-directed programming, a very powerful additive dispatch thing
  
  
• …and much, much more!
  

Chibi-Matoran wrote:

Another possibility:

(function (x::custom) -> {report(x)::control}::custom) //id

You would be able to add and delete parameters by right-clicking the block, which is truer to Scratch's “custom blocks.”

Chibi-Matoran wrote:

I think the official terminology is too confusing.

(instruction {} with variables +-::ring grey)
(do instruction (instruction{} with variables +-::ring grey) with variable values +-::control)

Jonathan50 wrote:

Chibi-Matoran wrote:

I think the official terminology is too confusing.

...

I don't think it should say ‘variables’ though:
http://i.cubeupload.com/PVxCsB.png

adespotist wrote:

How about this?

the script {move (10) steps}::operators reporter

Obviously because of the limitations of scratchblocks2 I can't do multiple lines of scripts in there but in the real Scratch it would work.

kvackkvack wrote:

This feature is not complicated at all if designed and explained properly.
I'd suggest something like

set [my lambda v] to (the script { move (10) steps } :: operators)
(result of running (my lambda) :: control)
run (my lambda) :: control

I might make a long post trying to explain it after school.

BookOwl wrote:

I like

(the blocks ({report [Hi!] :: custom} ::extension ring ) :: custom)

for lambdas, and

(call (script :: variable) with args [1] [2] :: custom)
run (script :: variable) with args [1] [2] :: custom

for running them

Owengren wrote:

(report script {move (10) steps}::custom-arg ring)
(report reporter (size)::custom-arg ring)
(report boolean <touching [ v]?>::custom-arg ring)

-Io- wrote:

We could always make it a reporter with a c mouth if the ring block is too confusing

Jonathan50 wrote:

Something like

(make procedure {
  foo :: grey
  bar :: grey
  baz :: grey
}:: custom)
(make procedure [] :: custom)

? perhaps there could just be the first variant?

Something like this bad mockup

?

(function (x::custom) -> {report(x)::control}::custom) //id

Chibi-Matoran wrote:

I support the addition of lambdas, because then we could implement many features by ourselves. However, I feel like your examples are too close to Snap!; perhaps we should develop ways that flow better with Scratch's designs? For example, the arrow inputs are very Snap!-ish. I don't want Scratch to start copying Snap!'s designs.

I support overall, but want lambdas to be presented differently, so they are easier to understand. We should brainstorm possibilities.

(λ (x :: custom-arg) (y :: custom-arg) -> ((x) + (y)) :: custom)
(λ (x :: custom-arg) (y :: custom-arg) → ((x) + (y)) :: custom)
(procedure (x :: custom-arg) (y :: custom-arg) → ((x) + (y)) :: custom)
(function (x :: custom-arg) (y :: custom-arg) → ((x) + (y)) :: custom)

set [lambda v] to {define (x)(y)(z)}

Chibi-Matoran wrote:

One flaw with Snap! is that it differentiates between named functions and lambdas, even though they are the same. In an ideal world, custom blocks and rings should be called the same way.

Chibi-Matoran wrote:

EDIT: Jonathan50, I don't think we should use the lambda symbol. “Procedure” isn't the correct word for something that returns a value.

define my procedure
change [global variable v] by (20) // Side-effect! This is not a function, despite returning a value.
say [Hello!] for (2) secs // More side-effects.
report [foo] :: control cap

define my function
report [bar] :: control cap // As this has no side-effects and returns a value, it is a function *and* a procedure.

define ignore (input) // Despite having no side-effects, this block does not return a value and is therefore not a function.
define my other procedure
ignore (my function :: custom) // Ditto

-Io- wrote:

Support!

I very much prefer the ring like blocks
I think the worded blocks are more adequate for Scratch's design. And “function” might be better too.

(function {say [hi]} :: grey ring) // Lies! This isn't a function

(instruction {} with variables +-::ring grey)
(do instruction (instruction{} with variables +-::ring grey) with variable values +-::control)

Chibi-Matoran wrote:

I think the official terminology is too confusing.

(instruction {} with variables +-::ring grey)
(do instruction (instruction{} with variables +-::ring grey) with variable values +-::control)

Jonathan50 wrote:

-Io- wrote:

Support!

I very much prefer the ring like blocks
I think the worded blocks are more adequate for Scratch's design. And “function” might be better too.

…But

(function {say [hi]} :: grey ring) // Lies! This isn't a function

-Io- wrote:

Hmm you're right.

Though, is there any other terminology that will not confuse a bit, or isn't too long?

Jonathan50 wrote:

-Io- wrote:

Hmm you're right.

Though, is there any other terminology that will not confuse a bit, or isn't too long?

Procedure? Often abbreviated to “proc” but “proc” is less self-explanatory and Scratch typically doesn't use abbreviations.

iamunknown2 wrote:

Not very good at complex data structures, but is there a difference between a function and a procedure?

Also, what are the advantages of lambdas (in the round block version)? It seems that the main use of lambdas is so that creating a function is unnecessary for parameters expecting a function.

-Io- wrote:

Support!

I very much prefer the ring like blocks
I think the worded blocks are more adequate for Scratch's design. And “function” might be better too.

the script {move (10) steps}::operators reporter