"jr" <cre### [at] gmailcom> wrote:
> one feature we're all (I think) keen to see would be
> a means to find out a variable's type.

I think this would best be illustrated by a .pov file trying to #read from a
data file of some sort.

This thread will quickly become a collection of disparate ideas that will need
to be sorted and prioritized.

I'd suggest creating a document (or better, a spreadsheet - for reasons I can
expand on) to append and annotate, thus keeping everything in one place.

Author, feature type (object, attribute [texture, pigment pattern], flow
control, introspective keyword, syntactical sugar, etc.), priority (core,
wanted, maybe-nice-to-have)

The more granular we make it, the easier it will be to deal with everything, and
make appropriate recommendations and changes.

Examples from existing languages would help easily illustrate syntax and usage
without having to write everything out from the outset.

Approaching this from a "unix-style" way of thinking: everything has a single
purpose, and the result is achieved by assembling the functional parts into a
cohesive whole.  This way, any time something has to be fixed/updated, the input
and the output remain unchanged, and it's only how things are handled internally
that changes.  Old versions ought to be deprecated and fully retained with
commentary, so as not to lose ideas and historical explanations about WHY things
were done.  Every keyword/feature ought to have a version number, and the last
working version ought to be retained in full (perhaps as keyword_lw so that the
newer version of the full software can still be used without rollbacks).

- BW

Post a reply to this message