This document is a work in progress.

Learn to Program using Alice

Appendix E

Restrictions, Limitations, and Bugs for Alice 2.0

Published:  October 25, 2007
By Richard G. Baldwin

Alice Programming Notes # 920


Part of a series

This document serves as an appendix to a series of programming tutorial lessons that are designed to teach you how to program using the Alice programming environment under the assumption that you have no prior programming knowledge or experience.


This appendix is intended primarily for instructors.  While students are invited to study the material in this appendix, it is written at a level that beginning programming students probably won't understand.

The purpose of this appendix is to compile known restrictions, limitations, and unpublished bugs of Alice 2.0, (as compared to other programming environments such as Java, C++, and C#), as guidance to instructors who are preparing lesson plans for a programming course that uses Alice.

Sending email to Dick Baldwin
Send your email message to and include the word Alice surrounded by spaces in the subject line to cause the message to bypass my spam blocker.  (Note that if the spammers catch onto this, I will modify these instructions later.)
I plan to add to this appendix as I learn more about such restrictions, limitations, and bugs.  Therefore, you should view this document as a continuing work in progress.  If you know of restrictions and limitations that are not included here, I would like to hear about them.

Unpublished bugs

The web page at describes bugs that were known by the folks on the Alice Development team as the last update of that page.  That page is no longer being kept up to date.  As of this writing in April of 2007, the latest update to that page was 04/05/2005.

There is a bug reporting page that is accessible from the main Alice website (see Resources) but as of this writing that page is no longer functional.

Unfortunately, this leaves instructors who are teaching courses using Alice high and dry with very little help when problems occur.  In some cases, it may be possible to get help by visiting the Alice Community page, but finding relevant information there can be a long and tedious process.

I don't know how long I will be able to keep it up, but for the present at least I plan to describe major unpublished bugs in this appendix for the benefit of students and instructors alike.  The bugs won't get fixed, but at least a student or an instructor having a problem can quickly check this page to see if their problem is listed here.

Viewing tip

I recommend that you open another copy of this document in a separate browser window and use the following links to easily find and view the figures and listings while you are reading about them.



Supplementary material

Once you have mastered Alice, I recommend that you also study the other lessons in my extensive collection of online programming tutorials.  You will find a consolidated index at

Restriction and Limitations

Alice is not an object-oriented programming language

Alice is object based

While Alice is an outstanding product for teaching object-based programming, in my opinion Alice is not an object-oriented programming (OOP) language.

A true OOP language must make the following features available to the programmer:

Alice supports encapsulation reasonably well.  However, Alice does not enforce encapsulation, so it is quite easy for your students to write programs using a very poor programming style that breaks encapsulation.

Alice makes a reasonable gesture towards making inheritance available to the programmer.  It is possible to create an object from the gallery of classes, add methods, functions, and properties to the object, and then save a new class that represents the object in its expanded form.  (See restrictions regarding the cast operator later in this document.)  Having saved that class, it is possible to create new objects from it later in the same program, or in other programs.

However, there is no semblance of support for polymorphism.

In addition, there are numerous detailed features (such at type casting) that are expected from a true OOP language that apparently are not available in Alice.

Makes writing 3D graphics a breeze

However, the Alice program makes it possible for a student to learn in a few months how to write object-based 3D animation programs that would probably require the student to study for years if he were programming in hard-core Java 3D instead of using a Java program to write his programs in Alice.

While Alice is not a fully object-oriented programming environment, it is object-based and therefore is very suitable for getting a student started down the road towards object-oriented programming.

Limitations related to the lack of a cast operator

A workaround
See this link for a workaround for this limitation.

Alice does not have a cast operator.  Therefore, as near as I have been able to determine, it is not possible to cast an object from the generic type Object to the true type of the object.  Therefore, when you allow a specialized object, such an object created from the gallery class named Penguin to be treated as type Object, you lose access to the custom methods belonging to that object.

Custom methods of a Penguin object

For example, a Penguin object has the following methods in addition to the standard primitive methods (see Appendix A for information regarding primitive methods).

  1. wing_flap
  2. jumping
  3. turn_head_right
  4. turn_head_left
  5. glide
  6. jump
  7. walk
  8. walking

The Transformable type
I have yet to figure out how to use the Transformable type, so it is possible that its use could be the solution to this restriction.

Passing a Penguin object to a method

If you pass a Penguin object to a method, you can pass it either as type Object or as type Transformable.  If you pass it as type Object and the code in the method continues to treat it as type Object (remember there is no cast operator that can be used to cast it to type Penguin), then the following methods can be called on the object in addition to a subset of sixteen of the twenty standard primitive methods:

  1. set value
  2. set(color,<value>)
  3. set(opacity,<value>)
  4. set(vehicle,<value>)
  5. set(skin texture,<value>)
  6. set(fillingStyle,<value>)

Custom methods are not included

As you can see, this doesn't include any of the eight custom methods belonging to a penguin.  The last five methods in the above list are used simply to set the values of properties.  Therefore, it appears that we have lost access to the methods that cause a penguin to be a penguin and differentiate it from an ice skater.

While it may be possible to use the set value method to eliminate this restriction and cause the custom methods to become accessible, I haven't been able to figure out how to do that if it is possible.

A workaround in the textbooks

Some of the textbooks provide a workaround to this restriction, but it looks to me like that workaround breaks encapsulation.  That is not something that I would want to teach a beginning programming student to do.

Please tell me that I am wrong

Because this is a fairly serious restriction, which greatly reduces the benefit of modularization through methods and probably also reduces the benefits of using lists and arrays, I continue to hope that someone will tell me that I am mistaken on this and will show me a way to gain full access to all of the methods belonging to the object without breaking encapsulation.  Unfortunately, that hasn't happened so far.  If you have a solution that provides full access to all of the methods belonging to the object and preserves encapsulation, I would really like to hear about it.

Limitations regarding string processing

The world provides the following two string processing function:

Curiously (for Java programmers anyway) you can compare two strings for equality using the == and != operators.

And, that is the sum total of the string processing capability that I have identified in Alice so far.  For example, I haven't found a way to decompose a string into its characters (there is no char type in Alice) or even a way to decompose it into a set of one-character strings that represent the characters in the original string.

This is another area where I would like to hear from you if you know of interesting ways to process strings that preserve encapsulation.


Errors in while events

Note:  This section applies to while events and not to simple while statements.

Event types in Alice

Alice supports the event types shown in Figure 1.  (See the lesson titled "Events and Interactive Programming" in Resources.)

Figure 1. Event types in Alice.
Event types in Alice
  1. *When the world starts
  2. While the world is running
  3. *When a key is typed
  4. While  a key is pressed
  5. *When the mouse is clicked on something
  6. While the mouse is pressed on something
  7. *While something is true
  8. When something becomes true
  9. When a variable changes
  10. Let the mouse move <objects>
  11. Let the arrow keys move <subject>
  12. Let the mouse move the camera
  13. Let the mouse orient the camera

Note:  Event types in boldface are illustrated by sample code in this lesson.


Experience shows that the event types identified by items 4, 6, and 7 in Figure 1 often experience runtime errors when the conditional item on which the while behavior is based goes to false.  That probably also happens for item 2 as well, but by the time the error occurs the program will have terminated and you won't see the error.

An unpredictable error

Whether or not an error will occur seems to be unpredictable, depending on the code in the event handler.  Some code results in an error and other code does not.

Regardless of the fact that some code seems to run okay, these three event types (items 4, 6, and 7) are unreliable.  Unless I learn something to the contrary in the future, my recommendation is for you to avoid using them.  Since the failure mode seems to be restricted to the point where the conditional clause goes false, the event type in item 2 is probably marginally okay to use.  If an error occurs, you will never see it because the program will have terminated by that time.

Alice0920-01c, A program that consistently fails

Listing 1 shows the source code for a simple program that consistently fails on my computer.

Listing 1. Alice0920-01c, A program that consistently fails.

Alice0920-01c's Code

Created by: Dick Baldwin



While A is pressed
Begin: <None>
ground.handleEvent ( );
End: <None>



  public void handleEvent ( ) {
       // Copyright 2007, R.G.Baldwin
  // Demonstrates Alice failure mode involving while event.
  // Program fails when key is released.
  doTogether {
       for (int index = 0 ; index< 5 times ; index += 1 ){
       ground .say( ( index .toString() ) );

Intended behavior

The intended behavior of this program is to perform a given processing task while the A-key is pressed and to terminate that process when the A-key is released.  The behavior up until the point where the A-key is released is to repetitively count from 0.0 through 4.0 and to display the count in a say-bubble.  This is the correct behavior.  However, the program fails when the A-key is released.

Unintended behavior

It is easy to show that when an event handler is registered on the During clause as in the Events section of Listing 1, and the key is released, the event handler method is forced to terminate almost immediately rather than being allowed to terminate in a controlled manner and clean up after itself on the way out.  Although I can't be certain, my guess is that effectively the Java thread on which the event handler is running is sent a thread.stop message.  If so, this is completely at odds with Sun's recommendations regarding multi-threaded programming.

An idea for a workaround

Each of the while events contains the following three clauses:

You can register an event handler on each of the clauses.  Originally I had hoped that it would be possible to

With this scheme, the event handler would continue to execute the desired process as the body of the while loop until the flag is set to false by the End clause.  At that time, the event handler would terminate properly and return.

This idea doesn't work

Unfortunately, I discovered that the End clause doesn't fire its event until either the event handler method returns or the key is released, whichever occurs later.  Therefore, the End clause cannot be used to set the flag to notify the event handler method that it is time to terminate properly and return because the End clause doesn't fire its event until the method returns.

I was unable to come up with a scheme that would emulate the key-pressed behavior that would be provided by this event type if it worked properly.

A workaround that provides the same counting behavior

Listing 2 shows the source code for a workaround that provides the counting behavior described above.  However, this program requires two keystrokes , one on each of two different keys to accomplish the same counting behavior.

Listing 2. Source code for the program named Alice0920-01d.

Alice0920-01d's Code

Created by: Dick Baldwin



When A is typed
ground.handleEvent ( );

When S is typed
ground.runFlag .set( value , false );



  public void handleEvent ( ) {
       // Copyright 2007, R.G.Baldwin
  // Workaround for problem in Alice0920-01c
  // Requires two keystrokes on different keys, A and S
  // Process starts on A and ends on S
  ground.runFlag .set( value , true );
  while ( ground.runFlag ) {
       doTogether {
       for (int index = 0 ; index< 5 times ; index += 1 ){
       ground .say( ( index .toString() ) );
  if ( ( ground.runFlag != true ) ) {
       index .set( value , 5 );
  } else {
  Do Nothing

When the A-key (upper or lower case) is pressed and released, the event handler is called and the counting process begins.  The counting process continues until the S-key is pressed and released, at which time the counting process ends and the event handler terminates properly.  (In both cases, the action happens on the up-stroke of the key.)

Note that it is necessary to declare a new property of type Boolean named runFlag on the properties tab of the ground during the manual setup for this program.

This workaround is not very compatible with the original insofar as keyboard activity (while a single key is pressed) is concerned.  However, it is the best that I was able to come up with.

This is a workaround for item 4 in Figure 1.  It may be possible to develop similar workarounds for items 6 and 7 as well.

Visibility of the Transformable type

Whenever you declare a variable and select the Other button, one of the types that appears in the pull down list is Transformable.  When I inquired about this type I was told:

"Transformable is an internal data type that is not intended to be
directly manipulated by end users. If you have managed to see the word
'transformable,' that probably indicates that you've gotten the system to cough up some internal information."

Bottom line, just ignore the Transformable data type.  Apparently you can't use it.

Avoiding setValue problems with arrays

Under various circumstances, Alice allows you to call setValue on an array to set the value of one array to a different array of a different type and/or size.  When I inquired as to the behavior that should be expected from doing this, I was told:

"... the SetValue method probably shouldn't allow you to drag in arrays of different sizes or types, so that also appears to be unintended (and undefined) functionality that we would discourage anyone for attempting to use."

Bottom line, don't set the value of one array to another array of a different type and/or size.

Dealing with array size problems

The lesson titled "Lists" (see Resources) describes a problem that sometimes occurs when attempting to use the drag and drop programming paradigm to determine the size of an array.  When I inquired about this problem, this is what I was told:

"... if you have a place in your code that 'accepts' an integer being dragged to it, if you drag the array, you will get a menu that offers you two choices: 'ith item from array' and 'size of array'."

Unfortunately, that answer wasn't very helpful.  It describes what should happen, but does not describe what does happen in some cases.

I also describe a fairly complicated workaround for this problem in the lesson titled "Lists" (see Resources).

Template material

This section consists solely of template material that I am saving to use when adding material to this document at a later date.

Begin sidebar template material

Sidebar template
This is the text that is contained in the sidebar.

Sidebar template material

Sidebar template material

End sidebar template material

Figure 1. This is a template for future expansion.
This is a template for future expansion.


Figure 2. This is a template for future expansion.
This is a template for future expansion.


Figure 3. This is a template for future expansion.
This is a template for future expansion.


Figure 4. This is a template for future expansion.
This is a template for future expansion.


Figure 5. This is a template for future expansion.
This is a template for future expansion.


Figure zz. This is a template for future expansion.
This is a template for future expansion.


Listing 3. This is a template for future expansion.
This is a template for future expansion.


Listing 4. This is a template for future expansion.
This is a template for future expansion.


Listing 5. This is a template for future expansion.
This is a template for future expansion.


Listing zz. This is a template for future expansion.
This is a template for future expansion.



General resources

Resources from lessons in the series titled "Learn to Program using Alice"


Complete program listings

Complete listings of some of the programs discussed in this appendix are shown below.  Other listings are embedded in the text where they are discussed.

Listing zz. This is a template for future expansion.
Template for future expansion


Copyright 2007, Richard G. Baldwin.  Faculty and staff of public and private non-profit educational institutions are granted a license to reproduce and to use this material for purposes consistent with the teaching process.  This license does not extend to commercial ventures.  Otherwise, reproduction in whole or in part in any form or medium without express written permission from Richard Baldwin is prohibited.

About the author

Richard Baldwin is a college professor (at Austin Community College in Austin, TX) and private consultant whose primary focus is a combination of Java, C#, and XML. In addition to the many platform and/or language independent benefits of Java and C# applications, he believes that a combination of Java, C#, and XML will become the primary driving force in the delivery of structured information on the Web.

Richard has participated in numerous consulting projects and he frequently provides onsite training at the high-tech companies located in and around Austin, Texas.  He is the author of Baldwin's Programming Tutorials, which have gained a worldwide following among experienced and aspiring programmers. He has also published articles in JavaPro magazine.

In addition to his programming expertise, Richard has many years of practical experience in Digital Signal Processing (DSP).  His first job after he earned his Bachelor's degree was doing DSP in the Seismic Research Department of Texas Instruments.  (TI is still a world leader in DSP.)  In the following years, he applied his programming and DSP expertise to other interesting areas including sonar and underwater acoustics.

Richard holds an MSEE degree from Southern Methodist University and has many years of experience in the application of computer technology to real-world problems.