Breaking down the operations when auto-casting gets complex So, take a Java statement like this one, given some int n:

if ((n+"").length() == (((n+1)+"").length())) {


Or perhaps this one, given some double, temperature, and some method that returns a boolean, unHatched():

while (temperature &lt; 100 &amp;&amp; unHatched())


In both of these cases, multiple auto-casts are made during the evaluation of the statement, and in both cases, the final determination is a boolean that is passed into some sort of control structure.

In my work with gifted students, the most that I have ever had to do to help someone understand statements like these is to do a simple trace.  We write the statement down, mark each item by its type, and then cross off areas of the statement (and write down the new types) as we walk through the evaluation.  This method has worked pretty consistently with my students at my day-job.

However, lately I have begun tutoring an adult student who is having a great deal of trouble, and I have been struggling to break apart statements like the above examples in ways that he can parse and keep straight.

He is at the right point, curricularly-speaking, to be examining them, but I am really struggling to help him trace and understand such statements.  (Ironically enough, because he can guess and modify a statement repeatedly, he can actually write statements like these with a fair amount of success, though when he is finished, he no longer fully understands them.)

For various reasons, learning a small concept usually takes him 3-5 weeks.  This timescale is fine, it is simply the speed at which he operates.  However, this adds a constraint for me: approaches that I take to the material must lend themselves to a fair amount of repetition with only very minor variations, or they won't be effective. 

I am really having trouble finding a good approach here.  How can I give him the tools to break down statements with complex data type transformations?
I suspect that you handle such situations by informally building the parse tree of the expression in your mind. Maybe not all at once, but a bit at a time, perhaps. I'm not a cognition expert, of course, but it might help him if you teach him to do it explicitly on paper. He needs a table of operator precedence, of course and needs to be able to deal with parentheses, but otherwise it is just a mechanical process. Put the lowest precedence operator at the root of a tree and then work on the operands. The interior nodes are operators and the leaves are operands. 

Can't promise it will work, but it would be my next step. With time, he may learn to rely less on the paper. Or, he might learn how to build a tool to do it automatically. That might be nice to have.