Warp wrote:
Warp, thanks for the well thought out and measured set of suggestions.
   If nothing else you put the discussion on a more organized plane with 
a good marriage
of abstract concepts and specific examples




> 
> #macro M(a, b)
>   , a, b>
> #end
> 
> sphere { <1 M(2, 3), 4 }
> 
>   This just doesn't fit in for byte-compiled code (at least not with very,
> very ugly hacks which would only burden and slow down the VM interpreting
> the bytecode).
>   The vast majority of #macros out there already work as pure functions,
> though, so only the "ugliest" ones would break.

I gotta laugh, naturally *I* do those sorts of ugly things all the time. 
  But hey, I wince when I do it.  Guess I could live with a little more 
enforced rigor.
( I usually find I reach for the #macro command and get into that kind 
of trouble when I am looking for some way to introduce rand() into the 
works. But I digress)




> 
> * Existing data containers, namely arrays and strings (which are special
> arrays of characters), should be enhanced and new data containers introduced.

> For example the current array could be internally implemented as a C++ deque,
> which would make it work like the current one plus you can freely resize it
> (larger or smaller), append elements at the beginning and at the end, and
> you can still access any element fast, and none of these operations will be
> slow (eg. resizing does not require copying/moving any existing elements).
> Even inserting or removing elements from the middle of the array would be
> possible, although it would not be a constant-time operation.
>   Strings could also be internally implemented as C++ strings. This would
> also allow easy resizing and appending. Also any byte values should be
> supported so that strings could also be used as raw byte arrays (for example
> for reading and writing files in binary mode). More operators and functions
> for accessing and manipulating strings should be added.

That would be *Wonderful!*




> 
>   Some syntactical technique should be introduced which would allow handling
> and accessing other types of data containers as well, such as lists and
> sets (balanced binary trees). Using the same idea as with C++ iterators for
> this could be one possibility. This would allow offering the C++ data
> containers at the SDL level.

Over my head but still sounds great.  What I like about Python, what 
ever its weaknesses, is the easy string handling.


> 
> * The language should be enhanced in such a way that you can create your
> own (efficient) data containers. For this it may be necessary to introduce
> the concept of modules (ie. classes without inheritance) or classes (with
> perhaps a simple inheritance support) and references. These modules or
> classes could have member variables and perhaps even member functions.
> Accessing the elements could be done with the dot operator.

Over my head, but if it would keep the heavy tech boys interested, I'm 
all for it.  We need to keep you guys interested.


> 
> * Many of the existing features of the current SDL, such as the camera,
> global_settings, etc, could be enhanced to behave like such modules/classes.
> For example, I envision this kind of code being possible:
> 
> #if(global_settings.max_trace_level < 10)
>   global_settings { max_trace_level 10 }
>   // or alternatively: global_settings.max_trace_level = 10
> #end
> 
> #declare CameraAngle = camera.angle;
> 
>   Perhaps even objects could behave like modules/classes like this, so
> you could do something like:
> 
> #declare S = sphere { 0, 1 };
> #declare R = S.radius;
> 
>   This could be especially useful for writing SDL libraries which modify
> triangle meshes (eg. subdivision, smoothing...)

This would be great.


> 
> * There should be support for binary reading and writing of files (into
> strings, which have been enhanced to support raw byte data). Maybe other
> methods of reading and writing files could be introduced as well (in order
> to make it easier to write file format parsers).
> 
> * If possible, introduce alternative ways of handling identifiers/variables
> so that all of these lines are valid:
> 
> #declare Var = Var + 1;
> Var = Var + 1;
> #declare Var += 1;
> Var += 1;

Could make for a debugging nightmare... Gestalt psychology, training the 
'eye' and all that. Your eye is used to C++ so naturally you would like 
to gravitate there.  I find the limited, though admittedly cumbersome, 
POV look reassuring when I am about to tackle reams of code looking for 
my one typo. But then again, most of us shift between languages where 
that other syntax is supported so it may be a lame concern on my part.


> 
> * The most difficult thing of all: Some kind of shader language, and deciding
> if this will be a completely separate language from the SDL (in the same
> way as current user-defined functions are) or if it will be the same.
> Perhaps a limited set of the SDL itself could be used as a shader language
> (for example a shader would be a macro/function which takes certain
> parameters and only uses a subset of the whole SDL, and which has access
> to certain special functions not accessible normally; the parser would check
> that this is so).
>   Ideally such shader function could do things like trace additional rays,
> read information from objects, textures, etc.
> 

Since we are undertaking the conversation.  I would enjoy having you 
sketch this out a little more.   I hit a bump, conceptually, when I see 
the term 'shader language'.  I am not really sure what it means in 
relation to the texturing that POV uses.  You are usually pretty good at 
sorting out these kind of semantic/conceptual tangles for us that are 
less technical.  For instance I thought that 'shader language' went 
along with 'scanline rendering'


-Jim

Post a reply to this message