[chuck-users] FLOSS (user editable) manual for ChucK

[Kassen]

Rob;

Your comments underscore the need to create a ChucK _reference manual_, even
> before creating a _programmers guide_ .  By definition, most ChucK users are
> already programmers for whom explanations of object oriented programming,
> inheritance and type casting is superfluous.  On the other hand, being able
> to quickly learn the syntax for oo, inheritance and type casting is
> important.
>

I respectfully disagree. I think there is a significant audience for ChucK
that knows about music, knows (something) about sound yet has never used
text as a interface to controlling these and wants to try it's hand at that.
Not everybody has the luxury of attending classes at Princeton or Stanford
and yet these people still need a place to get started.

There is no conflict here though, as the current initiative covers both
introductory tutorials and a attempt at creating a exhaustive reference to
all object types, methods, operations and keywords.


>
> Give me a decent ChucK reference manual (i.e. what the heck does the
> reserved "pure" keyword do?), and I'll be happy to write a few tutorials for
> beginners.
>
>
Great! I'm in the process of writing these references and will include
"pure". I'm also looking over the tutorials that are up already as I found
some bits in there that I have serious doubts about. You can start adding
tutorials on any topic you find lacking whenever you have the time and
inclination.

"pure", to explain from memory, is a keyword to mark member functions for a
mother class that is just meant to be extended and not meant to be
instantiated on it's own (hence this function wouldn't be called). Ge once
explained that he mainly wanted to be able to write "pure fun", as in (my
example) "pure fun void cheerfulAbyss()". I can't -off hand- think of a
occasion where it will actually affect anything.

Still, it will be documented. As will the "--poop" commandline flag, which
is about as useful and as frequently used, but it exists and so it needs to
be in there. I can think of even more obscure features, but I'll have to
re-find the exact syntax.

These things aren't either/or matters, in fact we found that some files
needed to be split up because only a single user can work on a file at a
time so working on more things at the same time will help make the most of
the hands and eyes that we have.

Yours,
Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20091217/5b7d1c87/attachment.htm>