Hey all,<br><br>I'm going to get on a soapbox here. Sorry in advance for sounding like a hot air bag.<br><br><soapbox><br><br>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.<br>
<br>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. <br><br><a href="http://github.com/heuermh/lick">http://github.com/heuermh/lick</a><br>
<br>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.<br>
<br>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.<br>
<br>Points:<br><br>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.<br>
<br>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.<br>
<br>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... <br>
<br>lambda(int y)<br>{<br> return y + 1;<br>} @=> fun int x;<br><br><<< x(4) >>>; // prints 5<br><br>// obviously, that's fraught with issues... function pointers could work like this:<br><br>
fun int f(int g)<br>{<br> return g+1;<br>}<br><br>f @=> function x;<br><br><<< x(4) >>>; // prints 5<br><<< x(4.4) >>>; // error<br><br><br>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.<br>
<br>Constructors -- we've been flirting with that idea for a long time. We need those. Interfaces... yes.<br><br>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. <br>
<br></soapbox><br><br>Just some ideas.<br><br>Mike<br><br><br>