andrel <a_l### [at] hotmailcom> wrote:
> http://members.chello.nl/a.c.linnenbank/newsdlforpov.html

  Here are some ideas of mine, if the new SDL is created as an enhancement
of the current SDL (instead of creating a completely separate new scripting
language):

* Even if it's based on the current SDL, it should still be byte-compilable
(and even JIT-compilable to native machine code if so needed), which means
that at least some backwards-compatibility must be broken and there's no
way around it. One example is that #macros can no longer be used in the
same ways as current ones, but instead they must work as pure functions.
For example, current macros can be used for "ugly" tricks like this:

#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.

* 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.

  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.

* 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.

* 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...)

* 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;

* 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.

* Likewise some way of post-processing the rendered image with the SDL should
be possible. This could also be, for example, a special macro/function which
takes certain parameters and which has access to certain functions.
  Ideally the post-processing step is not completely separate from the
rendering step. For It may be cool if the post-processing function could,
for example, trace new rays if it wants to.

-- 
                                                          - Warp

Post a reply to this message