[chuck-users] wishlist for the new year

[mike clemow]

Hey all,

I'm going to get on a soapbox here.  Sorry in advance for sounding like a
hot air bag.

<soapbox>

It's hard to change the C-like nature of Chuck from the grammar side.  And
there are a lot of reasons not to attempt to change the grammar.  Speed,
ease of learning, etc.

Now, some attempts have been made to bring a higher-level of programming to
Chuck, most notably in Michael Heuer's LiCK library, which I encourage
everyone to take a look at.

http://github.com/heuermh/lick

You have Lists here, ArrayLists, functors, which allow for a verbose kind of
functional programming, etc.  It's hard to approach at the moment, but if
you use it, you might forget you're programming Chuck.

I think it's important to stay within the confines that our dev's have set
out for Chuck.  I think it's important to keep Chuck lean, fast, and easy to
learn (i.e. C-like).  But it's also important for Chuck to allow the kind of
thing that Michael's trying to build--because it's more like Ruby, Python,
the nice parts of Java 6, Haskell, etc. -- all those things we want out of a
good scripting language.

Points:

It would be great if it was easier to approach LiCK (and other libraries).
Only documentation can help that.  There is none.  It's hard to make.
Therefore, we need a system to generate documentation.

It would be great if LiCK (and other libraries) were easier to use.  We need
to be able to import them.  Chuck needs a proper preprocessor, an import
system, something.  Graham Coleman wrote a Chuck preprocessor/shell in Perl,
which I've used in the past.  It's really a nice thing to have.

It would be great is LiCK could be be less verbose.  There's no reason that
functions shouldn't be objects by default.  There ought to be a function
type.  Then we wouldn't need functors to do functional programming.  Perhaps
even a lambda keyword.  "fun int" could define a type...

lambda(int y)
{
    return y + 1;
} @=> fun int x;

<<< x(4) >>>;  // prints 5

// obviously, that's fraught with issues...  function pointers could work
like this:

fun int f(int g)
{
    return g+1;
}

f @=> function x;

<<< x(4) >>>;  // prints 5
<<< x(4.4) >>>;  // error


This is going to be a huge thing to implement.  First, we should be able to
continue to better do these things using the built-in object system using
functors.  Okay, but we need to be able to determine the class of an object
at runtime (I've experimented with this already--so has Graham Coleman, who
had a patch for an instanceOf method).  This requires introspection.  We
should have that.

Constructors -- we've been flirting with that idea for a long time.  We need
those.  Interfaces...  yes.

These things would really allow us to create easy to use libraries for chuck
IN CHUCK that allow for multiple paradigms (functional, OO, imperative,
etc).  We can make Chuck feel like Ruby.  We can make Chuck feel like LISP.
We can make Chuck feel like Java, or C++, or whatever.  But only when we
have these things.

</soapbox>

Just some ideas.

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20100103/baa16265/attachment.html>