The variable
i (in the block on the right above) can be dragged from the for block into the blocks used in its C-
shaped command slot.  Also, by clicking on the orange i, the user can change the name of the variable as seen in 
the calling script (although the name hasn’t changed inside the block’s definition).  This kind of variable is called 
an upvar for short, because it is passed upward from the custom block to the script that uses it. 
Prototype Hints 
We have noted three notations that can appear in an input slot in the prototype to remind you of what kind of 
input this is.  Here is the complete list of such notations: 
=    default value            …    multiple inputs       ↑    upvar 
λ    procedure types           ⫶    list                           ?    Boolean 
Title Text and Symbols 
Some primitive blocks have symbols as part of the block name: 
Custom blocks can use 
symbols too.  In the Block Editor, click the plus sign in the prototype at the point where you want to insert the 
symbol.  Then click the title text picture below the text box that’s expecting an input slot name.  The dialog 
will then change to look like this: 
The important part to notice is the arrowhead that has appeared at the right end of the text box.  Click it to see 
this menu: 
Choose one of the symbols.  The result will look kind of ugly in the prototype: 
but the actual block will have the symbol you want: 
The available symbols are, pretty much, the ones that are used in Snap! icons. 
But I’d like the arrow symbol bigger, and yellow, so I edit its name: 
This says to make the symbol 1.5 times as big as the letters in the block text, using a color 
with red-green-blue values of 255-255-150 (each between 0 and 255).  Here’s the result: 
Print pdf thumbnails - Draw thumbnail images for PDF in C#.net, ASP.NET, MVC, Ajax, WinForms, WPF
Support Thumbnail Generation with Various Options for Quick PDF Navigation
pdf thumbnail generator online; show pdf thumbnails in
Print pdf thumbnails - VB.NET PDF Thumbnail Create SDK: Draw thumbnail images for PDF in vb.net, ASP.NET, MVC, Ajax, WinForms, WPF
Support Thumbnail Generation with Various Options for Quick PDF Navigation
enable pdf thumbnails; no pdf thumbnails in
VI.   Procedures as Data 
A.   Call and Run 
In the for block example above, the input named action has been declared as type “Command (C-shaped)”; 
that’s why the finished block is C-shaped.  But how does the block actually tell Snap! to carry out the commands 
inside the C-slot?  Here is a simple version of the block script: 
This is simplified because it assumes, without checking, that the ending value is greater than the starting value; if 
not, the block should (depending on the designer’s purposes) either not run at all, or change the variable by −1 
instead of by 1.  (The for block in Snap!’s tool library works for ascending or descending values; you can read its 
script by right-clicking or control-clicking on it and selecting the Edit option.) 
The important part of this script is the run block near the end.  This is a Snap! built-in command block that 
takes a Command-type value (a script) as its input, and carries out its instructions.  (In this example, the value of 
the input 
is the script that the user puts in the C-slot of the for block.) There is a similar call reporter 
block for invoking a Reporter or Predicate block.  The call and run blocks are at the heart of Snap!’s first
procedure feature; they allow scripts and blocks to be used as data — in this example, as an input to a block — 
and eventually carried out under control of the user’s program. 
Here’s another example, this time using a Reporter-type input in a simplified map block (see page 22): 
Here we are calling the Reporter “multiply by 10” three times, once with each item of the given list as its input, 
and collecting the results as a list.  (The reported list will always be the same length as the input list.)  Note that 
the multiplication block has two inputs, but here we have specified a particular value for one of them (10), so the 
call block knows to use the input value given to it just to fill the other (empty) input slot in the multiplication 
block.  In the map definition, the input function is declared to be type Reporter, and data is of type List. 
Call/Run with inputs 
The call block (like the run block) has a right arrowhead at the end; clicking on it adds the phrase “with inputs” 
and then a slot into which an input can be inserted: 
C# HTML5 PDF Viewer SDK to view PDF document online in C#.NET
Export PDF in WPF. Print PDF in WPF. PDF Create. Create PDF from Word. Create PDF from Excel. File: Compress PDF. Page: Create Thumbnails. Page: Insert PDF Pages
pdf thumbnail creator; create thumbnail from pdf c#
VB.NET PDF- View PDF Online with VB.NET HTML5 PDF Viewer
View PDF in WPF. Annotate PDF in WPF. Export PDF in WPF. Print PDF in WPF. PDF Create. File: Compress PDF. Page: Create Thumbnails. Page: Insert PDF Pages. Page
how to view pdf thumbnails in; pdf thumbnails in
If the left arrowhead is used to remove the last input slot, the “with inputs” disappears also.  The right 
arrowhead can be clicked as many times as needed for the number of inputs required by the reporter block 
being called. 
If the number of inputs given to call (not counting the Reporter-type input that comes first) is the same as the 
number of empty input slots, then the empty slots are filled from left to right with the given input values.  If call 
is given exactly one input, then every empty input slot of the called block is filled with the same value: 
If the number of inputs provided is neither one nor the number of empty slots, then there is no automatic filling 
of empty slots.  (Instead you must use explicit parameters in the ring, as discussed in subsection C below.) 
An even more important thing to notice about these examples is the ring around the Reporter-type input slots 
in call and map above.  This notation indicates that the block itself, not the number or other value that the block 
would report when called, is the input.  If you want to use a block itself in a non-Reporter-type (e.g., Any-type) 
input slot, you can enclose it explicitly in a ring, found at the top of the Operators palette. 
As a shortcut, if you right-click or control-click on a block (such as the + block in this example), one of the 
choices in the menu that appears is “ringify” or “unringify.”  The ring indicating a Reporter-type or Predicate-
type input slot is essentially the same idea for reporters as the C-shaped input slot with which you’re already 
familiar; with a C-shaped slot, it’s the script you put in the slot that becomes the input to the C-shaped block. 
Variables in Ring Slots 
Note that the run block in the definition of the for block (page 32) doesn’t have a ring around its input variable 
action.  When you drag a variable into a ringed input slot, you generally do want to use the value of the variable, 
which will be the block or script you’re trying to run or call, rather than the orange variable reporter itself.  So 
Snap! automatically removes the ring in this case.  If you ever do want to use the variable block itself, rather than 
the value of the variable, as a Procedure-type input, you can drag the variable into the input slot, then control-
click or right-click it and choose “ringify” from the menu that appears.  (Similarly, if you ever want to call a 
function that will report a block to use as the input, you can choose “unringify” from the menu.  Almost all the 
time, though, Snap! does what you mean without help.) 
B.   Writing Higher Order Procedures 
A higher order procedure is one that takes another procedure as an input, or that reports a procedure.  In this 
document, the word “procedure” encompasses scripts, individual blocks, and nested reporters.  (Unless specified 
otherwise, “reporter” includes predicates.  When the word is capitalized inside a sentence, it means specifically 
oval-shaped blocks.  So, “nested reporters” includes predicates, but “a Reporter-type input” doesn’t.) 
Although an Any-type input slot (what you get if you use the small input-name dialog box) will accept a 
procedure input, it doesn’t automatically ring the input as described above.  So the declaration of Procedure-
type inputs makes the use of your custom higher order block much more convenient. 
C# PDF Convert to Jpeg SDK: Convert PDF to JPEG images in C#.net
Support of converting from any single one PDF page and multiple pages. Thumbnails can be created from PDF pages. Support for customizing image size.
how to create a thumbnail of a pdf document; view pdf thumbnails in
C# PDF Print Library: Print PDF documents in C#.net, ASP.NET
WPF Viewer & Editor. WPF: View PDF. WPF: Annotate PDF. WPF: Export PDF. WPF: Print PDF. File: Compress PDF. Page: Create Thumbnails. Page: Insert PDF Pages. Page
pdf preview thumbnail; disable pdf thumbnails
Why would you want a block to take a procedure as input?  This is actually not an obscure thing to do; the 
primitive conditional and looping blocks (the C-shaped ones in the Control palette) take a script as input.  Users 
just don’t usually think about it in those terms!  We could write the repeat
block as a custom block this way, if 
Snap! didn’t already have one: 
The lambda (λ) next to action
in the prototype indicates that this is a C-shaped block, and that the script 
enclosed by the C when the block is used is the input named action in the body of the script.  The only way to 
make sense of the variable action is to understand that its value is a script. 
To declare an input to be Procedure-type, open the input name dialog as usual, and click on the arrowhead: 
Then, in the long dialog, choose the appropriate Procedure type.  The third row of input types has a ring in the 
shape of each block type (jigsaw for Commands, oval for Reporters, and hexagonal for Predicates).  In practice, 
though, in the case of Commands it’s more common to choose the C-shaped slot on the fourth row, because this 
“container” for command scripts is familiar to Scratch users.  Technically the C-shaped slot is an unevaluated 
procedure type, something discussed in Section E below.  The two Command-related input types (inline and C-
shaped) are connected by the fact that if a variable, an item
[list] block, or a custom Reporter block is 
dropped onto a C-shaped slot, it turns into an inline slot, as in the repeater block’s recursive call above.  (Other 
built-in Reporters can’t report scripts, so they aren’t accepted in a C-shaped slot.) 
VB.NET PDF File Compress Library: Compress reduce PDF size in vb.
image resources: Since images are usually or large size, images size reducing can help to reduce PDF file size Embedded page thumbnails. Embedded print settings.
enable thumbnail preview for pdf files; print pdf thumbnails
VB.NET PDF Print Library: Print PDF documents in vb.net, ASP.NET
View PDF in WPF. Annotate PDF in WPF. Export PDF in WPF. Print PDF in WPF. PDF Create. File: Compress PDF. Page: Create Thumbnails. Page: Insert PDF Pages. Page
pdf thumbnail preview; can't view pdf thumbnails
Why would you ever choose an inline Command slot rather than a C shape?  Other than the run block 
discussed below, the only case I can think of is something like the C/C++/Java for loop, which actually has 
three command script inputs (and one predicate input), only one of which is the “featured” loop body: 
Okay, now that we have procedures as inputs to our blocks, how do we use them?  We use the blocks run (for 
commands) and call (for reporters).  The run block’s script input is an inline ring, not C-shaped, because we 
anticipate that it will be rare to use a specific, literal script as the input.  Instead, the input will generally be a 
variable whose value is a script.   
The run and call blocks have arrowheads at the end that can be used to open slots for inputs to the called 
procedures.  How does Snap! know where to use those inputs?  If the called procedure (block or script) has empty 
input slots, Snap! “does the right thing.”  This has several possible meanings: 
1. If the number of empty slots is exactly equal to the number of inputs provided, then Snap! fills the empty slots 
from left to right: 
2. If exactly one input is provided, Snap! will fill any number of empty slots with it: 
3. Otherwise, Snap! won’t fill any slots, because the user’s intention is unclear. 
If the user wants to override these rules, the solution is to use a ring with explicit input names that can be put 
into the given block or script to indicate how inputs are to be used.  This will be discussed more fully below.
Recursive Calls to Multiple-Input Blocks 
A relatively rare situation not yet considered here is the case of a recursive block that has a variable number of 
inputs.  Let’s say the user of your project calls your block with five inputs one time, and 87 inputs another time.  
How do you write the recursive call to your block when you don’t know how many inputs to give it?  The 
answer is that you collect the inputs in a list (recall that, when you declare an input name to represent a variable 
number of inputs, your block sees those inputs as a list of values in the first place), and then, in the recursive call, 
you drop that input list onto the arrowheads that indicate a variable-input slot, rather than onto the input slot: 
C# PDF File Compress Library: Compress reduce PDF size in C#.net
image resources: Since images are usually or large size, images size reducing can help to reduce PDF file size Embedded page thumbnails. Embedded print settings.
pdf thumbnail creator; create thumbnails from pdf files
VB.NET PDF - Print PDF with VB.NET WPF PDF Viewer
View PDF in WPF. Annotate PDF in WPF. Export PDF in WPF. Print PDF in WPF. PDF Create. File: Compress PDF. Page: Create Thumbnails. Page: Insert PDF Pages. Page
create pdf thumbnail image; pdf files thumbnail preview
Note that the halo you see while dragging onto the arrowheads is red instead of white, and covers the input slot 
as well as the arrowheads.  And when you drop the expression onto the arrowheads, the words “input list:” are 
added to the block text and the arrowheads disappear (in this invocation only) to remind you that the list 
represents all of the multiple inputs, not just a single input.  The items in the list are taken individually as inputs to 
the script.  Since numbers is a list of numbers, each individual item is a number, just what sizes wants.  This 
block will take any number of numbers as inputs, and will make the sprite grow and shrink accordingly:  
The user of this block calls it with any number of individual numbers as inputs.  But inside the definition of the 
block, all of those numbers form a list that has a single input name, numbers.  This recursive definition first
checks to make sure there are any inputs at all.  If so, it processes the first
input (item 1 of the list), then it wants 
to make a recursive call with all but the first
number.  But sizes doesn’t take a list as input; it takes numbers as 
inputs!  So this would be wrong: 
C.   Formal Parameters 
The rings around Procedure-type inputs have an arrowhead at the right.  Clicking the arrowhead allows you 
to give the inputs to a block or script explicit names, instead of using empty input slots as we’ve done until now. 
The names #1, #2, etc. are provided by default, but you can change a name by clicking on its orange oval in 
the input names list.  Be careful not to drag the oval when clicking; that’s how you use the input inside the ring. 
The names of the input variables are called the formal parameters of the encapsulated procedure. 
Here’s a simple but contrived example using explicit names to control which input goes where inside the ring: 
Here we just want to put one of the inputs into two different slots.  If we left all three slots empty, Snap! would 
not fill any of them, because the number of inputs provided (2) would not match the number of empty slots (3). 
Here is a more realistic, much more advanced example: 
This is the definition of a block that takes any number of lists, and reports the list of all possible combinations of 
one item from each list.  The important part for this discussion is that near the bottom there are two nested calls 
to map, the higher order function that applies an input function to each item of an input list. In the inner block, 
the function being mapped is in front of, and that block takes two inputs.  The second, the empty List-type slot, 
will get its value in each call from an item of the inner map’s list input.  But there is no way for the outer map to 
communicate values to empty slots of the in front of block.  We must give an explicit name, newitem, to the 
value that the outer map is giving to the inner one, then drag that variable into the in front of block. 
By the way, once the called block provides names for its inputs, Snap! will not automatically fill empty slots, on 
the theory that the user has taken control.  In fact, that’s another reason you might want to name the inputs 
explicitly: to stop Snap! from filling a slot that should really remain empty. 
D.   Procedures as Data 
Here’s an example of a situation in which a procedure must be explicitly marked as data by pulling a ring from 
the Operators palette and putting the procedure (block or script) inside it: 
Here, we are making a list of procedures.  But the list block accepts inputs of any type, so its input slots are not 
ringed.  We must say explicitly that we want the block itself as the input, rather than whatever value would result 
from evaluating the block. 
Besides the list block in the example above, other blocks into which you may want to put procedures are set 
(to set the value of a variable to a procedure), say and think (to display a procedure to the user), and report (for 
a reporter that reports a procedure): 
E.   Special Forms 
The primitive if
else block has two C-shaped command slots and chooses one or the other depending on a 
Boolean test.  Because Scratch doesn’t emphasize functional programming, it lacks a corresponding reporter 
block to choose between two expressions.  We could write one in Snap!: 
Our block works for these simple examples, but if we try to use it in writing a recursive operator, it’ll fail: 
The problem is that when any block is called, all of its inputs are computed (evaluated) before the block itself 
runs.  The block itself only knows the values of its inputs, not what expressions were used to compute them.  In 
particular, all of the inputs to our if
else block are evaluated first
thing.  That means that even in the base 
case, factorial will try to call itself recursively, causing an infinite loop.  We need our if
else block to be 
able to select only one of the two alternatives to be evaluated. 
We have a mechanism to allow that: declare the then and else inputs to be of type Reporter rather than type 
Any.  Then, when calling the block, those inputs will be enclosed in a ring so that the expressions themselves, 
rather than their values, become the inputs: 
In this version, the program works, with no infinite loop.  But we’ve paid a heavy price: this reporter-if is no 
longer as intuitively obvious as the Scratch command-if.  You have to know about procedures as data, about 
rings, and about a trick to get a constant value in a ringed slot. (The id block implements the identity function, 
which reports its input.  We need it because rings only take reporters as input, not numbers.)  What we’d like is a 
reporter-if that behaves like this one, delaying the evaluation of its inputs, but looks like our first
version, which was 
easy to use except that it didn’t work. 
Such blocks are indeed possible.  A block that seems to take a simple expression as input, but delays the 
evaluation of that input by wrapping an “invisible ring” around it (and, if necessary, an id-like transformation of 
constant data into constant functions) is called a special form.  To turn our if block into a special form, we edit the 
block’s prototype, declaring the inputs yes and no to be of type “Any (unevaluated)” instead of type Reporter.  
The script for the block is still that of the second version, including the use of call to evaluate either yes or no 
but not both.  But the slots appear as white Any-type rectangles, not Reporter-type rings, and the factorial 
block will look like our first
In a special form’s prototype, the unevaluated input slot(s) are indicated by a lambda (λ) next to the input 
name, just as if they were declared as Procedure type.  They are Procedure type, really; they’re just disguised to 
the user of the block. 
Special forms trade off implementor sophistication for user sophistication.  That is, you have to understand all 
about procedures as data to make sense of the special form implementation of if
else.  But any experienced 
Scratch programmer can use if
else without thinking at all about how it works internally. 
Special Forms in Scratch 
Special forms are actually not a new invention in Snap!.  Many of Scratch’s conditional and looping blocks are 
really special forms.  The hexagonal input slot in the if
block is a straightforward Boolean value, because the 
value can be computed once, before the if block makes its decision about whether or not to run its action input.  
But the forever
if, repeat
until, and wait
until blocks’ inputs can’t be Booleans; they have to be of type “Boolean 
(unevaluated),” so that Scratch can evaluate them over and over again.  Since Scratch doesn’t have custom 
blocks, it can afford to handwave away the distinction between evaluated and unevaluated Booleans, but Snap! 
can’t.  The pedagogic value of special forms is proven by the fact that no Scratcher ever notices that there’s 
anything strange about the way in which the hexagonal inputs in the Control blocks are evaluated. 
Also, the C-shaped slot familiar to Scratch users is an unevaluated procedure type; you don’t have to use a ring 
to keep the commands in the C-slot from being run before the C-shaped block is run.  Those commands 
themselves, not the result of running them, are the input to the C-shaped Control block.  (This is taken for 
granted by Scratch users, especially because Commands don’t report values, so it wouldn’t make sense to think 
of putting commands in the C-shaped slot as a composition of functions.)  This is why it makes sense that 
“C-shaped” is on the fourth row of types in the long form input dialog, with other unevaluated types. 
VII.     Object Oriented Programming 
Object oriented programming is a style based around the abstraction object: a collection of data and methods 
(procedures, which from our point of view are just more data) that you interact with by sending it a message (just 
a name, maybe in the form of a text string, and perhaps additional inputs).  The object responds to the message 
by carrying out a method, which may or may not report a value back to the asker.  Some people emphasize the 
data hiding aspect of OOP (because each object has local variables that other objects can access only by sending 
request messages to the owning object) while others emphasize the simulation aspect (in which each object 
abstractly represents something in the world, and the interactions of objects in the program model real 
interactions of real people or things).  Data hiding is important for large multi-programmer industrial projects, 
but for Snap! users it’s the simulation aspect that’s important.  Our approach is therefore less restrictive than that 
of some other OOP languages. 
Technically, object oriented programming rests on three legs: (1) Message passing: There is a notation by which 
any object can send a message to another object.  (2) Local state: Each object can remember the important past 
history of the computation it has performed.  (“Important” means that it need not remember every message it 
has handled, but only the lasting effects of those messages that will affect later computation.)  (3) Inheritance: It 
would be impractical if each individual object had to contain methods, many of them identical to those of other 
objects, for all of the messages it can accept.  Instead, we need a way to say that this new object is just like that 
old object except for a few differences, so that only those differences need be programmed explicitly. 
The idea of object oriented programming is often taught in a way that makes it seem as if a special object 
oriented programming language is necessary.  In fact, any language with first
class procedures allows objects to 
be implemented explicitly; this is a useful exercise to help demystify objects. 
The central idea of this implementation is that an object is represented as a dispatch procedure that takes a 
message as input and reports the corresponding method.  In this section we start with a stripped-down example 
to show how local state works, and build up to full implementations of class/instance and prototyping OOP. 
Documents you may be interested
Documents you may be interested