[chuck-users] wishlist for the new year

[Hans Aberg]

On 3 Jan 2010, at 16:47, Kassen wrote:

>> If we're serious about changing the ChucK language, I'd put in my  
>> vote
>> for a Ruby-style approach.
>
> Personally I'm more interested in looking what issues those other
> languages solve, how those related to our concerns, then finally
> figuring out how to solve those things in a ChucKist way.

I think so, too. All computer languages have quirks, or "gotchas" as  
they are called here:
   http://en.wikipedia.org/wiki/Gotcha_(programming)

In addition, languages tend to be well designed for a certain type of  
issues, and using them in other circumstances can be rather cumbersome.

> If you are really interested in mixing ChucK and Ruby you may want to
> look at what's on Tom's cocktail menu; http://github.com/alltom/ruck

This link describes some peculiarities of Ruby, of which some are not  
so good:
   http://en.wikipedia.org/wiki/Ruby_(programming_language)#Deviations_from_behaviour_elsewhere

For example, imposing extra conditions on identifiers is not good - I  
use Haskell, in which variables can only start with lower case (those  
that start with uppercase are reserved fro types), and when one  
accidentally is doing wrong, one gets mysterious compiler errors. A  
declarative language, I think is best, which is essentially what is  
used in math - the road that ChucK is on.

Another problem of languages is having too few precedence levels -  
some investigated math, and found that there are a lot more than in  
typical computer languages. Here, Ruby inherits the problem of Pascal  
for logical operators. A language benefits readability if one can  
eliminate the need of parenthesizes.

Also, Ruby treats a line ending as an end of statement, which  
generally is bad if one needs to write something that takes up more  
than one line. This idea comes from scripting languages, like shell,  
which are good for writing simple things, but known to be problematic  
for outright programs (steeps learning curve, and hard to read and  
debug).

Haskell uses an alternative called layout syntax: in addition to  
normal bracketing to environments one can drop them and use  
indentation instead. For example,
   -- Leading term in monomial order.
   lead :: Polynomial -> Term
   lead p = last xs
     where
     Xs xs = normalize p
Here, the indentation of "where" says that the stuff that follows on  
the same indentation level belongs to the block. The problem is that  
the compiler tends to give strange error messages "possibly due to  
wrong layout" and one may have to guess if it is a layout problem or  
not. (Also, it sets a tab equal to 8 spaces when computing layouts,  
which has fallen out of use.)

Haskell has the problem that the function name must be repeated often  
when defining a new function. Another quirk is the lazy evaluation,  
which is wholly incompatible with imperative structures, which leads  
to the introduction of the complicated concept of monads (an import  
from math category theory).

Getting back to Ruby, it treats various objects as Boolean, which is a  
bad idea, inviting errors. The gotcha link mentions the classical C  
mistake, confusing the two
   if (a = b) then ...
   if (a == b) then ...
The first is an assignment, and the second a test of equality - it is  
common to do mistakes on this one.

But the problem could have largely been circumvented if types did not  
implicitly convert to Boolean types. Then the first one would have  
generated a compiler error, except when programming specifically  
Boolean types, but that does not happen so often.

In general, it is a bad to have implicit type conversions to types  
which loose information. That is a C-quirk.

Anyway, just examples on what one might have to think about when  
moving along. If people try out what works and not works and discusses  
it here, that may give the developers feedback.

   Hans