[Edu-sig] CTL: Computer Thinking Language

[David MacQuigg]

At 08:09 PM 3/3/2009 -0800, michel paul wrote:
>On Tue, Mar 3, 2009 at 2:27 PM, David MacQuigg <<mailto:macquigg at ece.arizona.edu>macquigg at ece.arizona.edu> wrote:
>>
>>>>Before I discovered Python a couple of years ago I was experimenting with a pseudo-code approach for expressing math concepts.  I had this kind of stuff in mind:
>>>>
>>>>factorial(n):
>>>>    if n < 2 ---> 1
>>>>    else ---> n*factorial(n-1)
>>
>>>I like the feeling of action in --->, but I also like the self-explanatory "return".  Any other suggestions?  Strong preferences?
>
>Oh no, not at all.  My only point in even bringing this up was that I had been trying to formulate something like a CTL awhile ago, and then I discovered Python.  Wow!  What I found so delightful is that the kind of pseudo-code I was contemplating looked a whole lot like Python!  I thought that was a really good sign.  Yeah, Python is pseudo-code that runs!  It already is a CTL.
>
>I think the most useful CTL for integration in math education should be as close to ordinary algebra as possible.  That's what I had been trying to get at.  Kids in algebra classes initially get confused by this 'return'.  It doesn't look like what they usually see in math.  So I thought an arrow might correspond to mapping notation for functions:  f: x ---> y vs. Euler notation: f(x) = y.  So that's why I originally opted for the arrow.  However, once they've had even a little experience, the use of 'return' isn't all that strange to them.  And then, the other day when I had them create generators for their HW assignment on sequences, wow!  I was really pleased that they got the idea that 'yield' just meant that the function was on hold until called again.  They seemed OK with that.

OK, let's stick with 'return' unless someone comes up with a better word or symbol.  At least it is a common keyword in all the languages that students are likely to move up to.  Nothing to unlearn.

>>It would be nice to avoid in CTL the complexities of precedence and associativity rules (very non-fundamental knowledge).  How about we just do all operations in the order they occur, unless you force a different order with parens.
>
>In terms of integration into math classes, I think it would be better to maintain the traditional order of operations.  (I realize here that I'm emphasizing math/CS fusion at a secondary level, and you're talking about CS0.)  But using parentheses to clarify order - definitely!  And then from there, it's easy to create functional compositions.  Now, I wouldn't emphasize functional composition for ALL simple arithmetic expressions - that would just be silly.  But I think doing that is an excellent kind of exercise.  And then beyond that - turn the functional compositions into binary expression trees!  I've had kids do that in math classes as exercises in order of operations.  Take a typical arithmetic expression that has several things going on and turn it into a binary expression tree.

You are right.  There is a "traditional order" of operations.  The precedence rules for arithmetic operators are not just Python.  Maybe we can get away from having to teach these rules by requiring parens in *all* multi-operator expressions.  This would be equivalent to breaking a complex expression into a binary tree, if I understand your last example correctly.

a + b * c ** d   ==>   a + (b * (c ** d)))

Anything more complex than this is probably beyond CS0.

a + b + c + d    ==>   (((a + b) + c) + d)

Well, maybe we should make an exception, and not require parens when all the operators are the same.


At 11:59 PM 3/3/2009 +0100, Laura Creighton wrote:

>In a message of Tue, 03 Mar 2009 15:27:28 MST, David MacQuigg writes:
>>At 10:00 AM 3/2/2009 -0800, michel paul wrote:
>>
>>>Before I discovered Python a couple of years ago I was experimenting wit
>>h a pseudo-code approach for expressing math concepts.  I had this kind o
>>f stuff in mind:
>>>
>>>factorial(n):
>>>    if n < 2 ---> 1
>>>    else ---> n*factorial(n-1)
>>
>>I like the feeling of action in --->, but I also like the self-explanator
>>y "return".  Any other suggestions?  Strong preferences?
>>
>>We could use a symbol other than = for assignment, just to avoid confusio
>>n with the comparison operator and to introduce the idea of variables as 
>>labels, not containers.  How about:
>>
>>a2 --> a**2
>>a --> b --> c --> 0
>
>Datapoint: the children I was teaching how to write games have all had
>terrible problems with arrows.  Whenever I tried to use them to indicate
>anything there was this large mental thud.  So my suspicion is that this
>will make things harder, rather than easier.
>
>In explaining things I found that words worked best.
>
>and the words that worked were:
>
>'is bound to'

How about :=

a2 := a**2
a := b := c := 0

This could be read as "bound to", "assigned to", or my preference "applied to", as in a label applied to an object.

Should we put a definite "end" at the end of every function, like in Ruby?  For me, it adds nothing, but a lot of folks must think it has value, or Ruby wouldn't have added it in their efforts to improve on Python.

Some other suggestions from Ruby that might be appropriate for CTL:
http://www.ruby-lang.org/en/documentation/ruby-from-other-languages/to-ruby-from-python/

true and false instead of True and False (and nil instead of None)

elsif instead of elif

require instead of import

parentheses for function calls are optional

:>) Ruby lurkers, speak up.  I promise you will be treated with respect.  I think 'elif' is kinda cute, like a baby elifant, but then I don't really know how kids think. :>)

if a<b,(a, b-a); elif a>b,(a-b, b); else (a, b)

-- Dave