Am I the only one who likes the current SDL (well, most of it)?  I think 
I've changed my opinion on this over time, as I used to be all for a 
brand new SDL with all kinds of programming features and blah blah blah...

Now, I'm at the point that I love the current SDL's simplicity, as well 
as its imperative nature.  I would just want some cleaning up done with 
it, mainly:

1) Any and every # statement needs to be thrown out, and a new 
consistent system implemented.  This includes declarations, control 
structures, object identifiers, file i/o, and output streams.

2) As a result of 1) above, macros would be re-engineered.  Yay!

3) We need some way of examining and modifying previously declared objects.

We could implement the above while keeping the majority of SDL identical 
to what it currently is, though.

-- 
...Chambers
www.pacificwebguy.com

Post a reply to this message

Chambers wrote:
> Am I the only one who likes the current SDL (well, most of it)?  I think

	Likely the others who like it are unlikely to be reading this newsgroup.


-- 
"Now we all know map companies hire guys who specialize in making map
folding a physical impossibility" - Adult Kevin Arnold in "Wonder Years"


                    /\  /\               /\  /
                   /  \/  \ u e e n     /  \/  a w a z
                       >>>>>>mue### [at] nawazorg<<<<<<
                                   anl

Post a reply to this message

Chambers <ben### [at] pacificwebguycom> wrote:
> Am I the only one who likes the current SDL (well, most of it)?  I think
> I've changed my opinion on this over time, as I used to be all for a
> brand new SDL with all kinds of programming features and blah blah blah...

Overall... no.  you're not the only one.  It's not perfect, but more often that
not, the things I come up with are limited by me rather than by the language.
A little more namespace rigor might make it easier to create macro libraries,
but that may also be my fault for not trying a little harder.

> 3) We need some way of examining and modifying previously declared objects.

Just curious--why?  Can you do it right in the first place?

 - Ricky

Post a reply to this message

Chambers <ben### [at] pacificwebguycom> wrote:
> Am I the only one who likes the current SDL (well, most of it)?  I think
> I've changed my opinion on this over time, as I used to be all for a
> brand new SDL with all kinds of programming features and blah blah blah...
>
> Now, I'm at the point that I love the current SDL's simplicity, as well
> as its imperative nature.  I would just want some cleaning up done with
> it, mainly:
>
> 1) Any and every # statement needs to be thrown out, and a new
> consistent system implemented.  This includes declarations, control
> structures, object identifiers, file i/o, and output streams.
>
> 2) As a result of 1) above, macros would be re-engineered.  Yay!
>
> 3) We need some way of examining and modifying previously declared objects.
>
> We could implement the above while keeping the majority of SDL identical
> to what it currently is, though.

So, um... with 1) to 3) done to the SDL, what exactly would *remain* of the
existing one?

I see primarily one thing: The particular attributes that objects have, and a
few basics about how they are set to particular values.

My goal for a 4.0 SDL *is* to keep these two fairly familiar.

Not perfectly, granted - but that's a concession to getting the whole language
consistent.

At the moment, basically, each and every object keyword acts as a full-fledged
SDL statement - with its own little parser module, i.e. defining its own little
language inside it.

Getting a formalism into these parsing rules, so that all objects can be handled
by a single lightweight parser module, is one of the key issues I think a 4.0
SDL should address.

For instance, what is the "reflection" statement in the "finish" block? Is it a
property of the finish? Is it a sub-object? Well, to the current SDL the answer
is quite simple: It is the "reflection" keyword followed by an opening brace, a
couple of values and more keywords, and the closing brace. But I don't think
this approach is suitable to serve as the basis for a 4.0 SDL - whether it be a
new one or an overhauled 3.6 SDL.

To me, it's not *too* much about "how should the language look like", but mostly
"how can a generalized scripting language be formalized to 'carry' a look & feel
remniscient of the current one"; this, and adding some sugar I keep missing in
the current SDL.

But as we're on it, I think it is also worth pondering whether we might use some
more equations signs here and there, or maybe some semicolons, if it helps the
formalizing of the language, like:

  radiosity {
    count = 50;
    recursion_limit = 2;
  }

instead of

  radiosity {
    count 50
    recursion_limit 2
  }

I don't think this would do much harm to the language as a general. And it *may*
help to come up with an easy formalism for it all.

Post a reply to this message

On 4/20/2009 10:14 PM, triple_r wrote:
> Chambers<ben### [at] pacificwebguycom>  wrote:
>> 3) We need some way of examining and modifying previously declared objects.
>
> Just curious--why?  Can you do it right in the first place?

Because this allows things like a macro-implementation of the MechSim 
patch without the need to actually patch the library, for one.  There 
are many other uses, too.

-- 
...Chambers
www.pacificwebguy.com

Post a reply to this message

On 4/21/2009 12:45 AM, clipka wrote:
> So, um... with 1) to 3) done to the SDL, what exactly would *remain* of the
> existing one?

The imperative nature, plus the current syntax for object (and 
texture/pattern/et al) creation.

Ie, we DON'T need

new SDL.Object.Sphere {
  Radius: 4.0f;
  Center: new SDL.Unit.Vector3(4.5f,1.5,3.0f);
  Texture: new SDL.Pattern.Texture {
   Pigment: new SDL.Pattern.Pigment {
    Pattern: SDL.Pattern.Predefined.Solid;
    Color: new SDL.Unit.Vector3(1.0f,0.5f,0.0f);
   }
  }
}

when we can do

sphere {<4.5,1.5,3>, 4 pigment {color rgb <1,.5,0>}]

>    radiosity {
>      count = 50;
>      recursion_limit = 2;
>    }
>
> instead of
>
>    radiosity {
>      count 50
>      recursion_limit 2
>    }

It depends if you see those values as parameters or variables.

-- 
...Chambers
www.pacificwebguy.com

Post a reply to this message

Chambers <ben### [at] pacificwebguycom> wrote:
> > So, um... with 1) to 3) done to the SDL, what exactly would *remain* of the
> > existing one?
>
> The imperative nature, plus the current syntax for object (and
> texture/pattern/et al) creation.
>
> Ie, we DON'T need
>
> new SDL.Object.Sphere {
>   Radius: 4.0f;
>   Center: new SDL.Unit.Vector3(4.5f,1.5,3.0f);
>   Texture: new SDL.Pattern.Texture {
>    Pigment: new SDL.Pattern.Pigment {
>     Pattern: SDL.Pattern.Predefined.Solid;
>     Color: new SDL.Unit.Vector3(1.0f,0.5f,0.0f);
>    }
>   }
> }

I take it as understood that we do *NOT* want any such syntax in a POV 4 SDL.
Yes, indeed, I'd rather stick to the current SDL than use such a monster.

That's why I kept lamenting about the shortcomings of Lua and the like in this
particular respect.

Post a reply to this message

Chambers escreveu:
> On 4/20/2009 10:14 PM, triple_r wrote:
>> Chambers<ben### [at] pacificwebguycom>  wrote:
>>> 3) We need some way of examining and modifying previously declared 
>>> objects.
>>
>> Just curious--why?  Can you do it right in the first place?
> 
> Because this allows things like a macro-implementation of the MechSim 
> patch without the need to actually patch the library, for one.  There 
> are many other uses, too.

I like to position objects in relation to each other.  That is, I put a 
table on the floor, then place objects onto the table by using the 
table's relative position.  Sure, you can imagine there are quite a few 
annoyingly named local variables around to carry out the task of 
tracking the current positions etc.  Being able to do

sphere { position(table) 1 }
or
sphere { table.position 1 }

without resorting to hacks in the form of slow parsed macros would be 
quite nice.

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

clipka wrote:
> Chambers <ben### [at] pacificwebguycom> wrote:
>>> So, um... with 1) to 3) done to the SDL, what exactly would *remain* of the
>>> existing one?
>> The imperative nature, plus the current syntax for object (and
>> texture/pattern/et al) creation.
>>
>> Ie, we DON'T need
>>
>> new SDL.Object.Sphere {
>>   Radius: 4.0f;
>>   Center: new SDL.Unit.Vector3(4.5f,1.5,3.0f);
>>   Texture: new SDL.Pattern.Texture {
>>    Pigment: new SDL.Pattern.Pigment {
>>     Pattern: SDL.Pattern.Predefined.Solid;
>>     Color: new SDL.Unit.Vector3(1.0f,0.5f,0.0f);
>>    }
>>   }
>> }
> 
> I take it as understood that we do *NOT* want any such syntax in a POV 4 SDL.
> Yes, indeed, I'd rather stick to the current SDL than use such a monster.
> 
> That's why I kept lamenting about the shortcomings of Lua and the like in this
> particular respect.
> 
> 
lol

Was thinking about this a bit. One could get the same syntax as now, 
mostly, or almost, and still get "access" the sorts of things above, but 
it requires some compromising on what is possible, and how. As well as 
maybe some minor changes to existing code. Here is how:

You have explicit or implicit declaration of objects by name. Explicit 
would be something like:

declare my_object as sphere;
declare my_object2 as box;
//Set attributes.
...

Implicit would be something like:

parse(
   sphere {...}
   box {...}
)

In other words, the "existing" SDL get parsed exactly as it does now, 
and all you have to do is either enclose the code in a "parse" command, 
or use something like 'parse_file("existing.pov");'. From the standpoint 
of people using the SDL that already exists, the result is entirely 
transparent.

Now, in the '//Set attributes' part of the first example, you get 
basically two things:

sphere.parse_table(list my_table);

and attributes like:

sphere.translation
sphere.rotation
sphere.scale
sphere.{everything else}

The parse_table is the list of things "done to" the object, is 
indexable, and you can add to it, and it parses "existing" SDL commands. 
The . parts are the "current" result of the matrix operations that took 
place in that table. One could have command to "re-run" the table, add 
to it, delete things from it, etc. And, from the perspective of 
something "coding" SDL, again, functions would exist to "add to" that 
table, as though they where using the existing SDL.

This means a tiny bit more overhead in the parse stage, since it has to 
build the tables for each object, and track them. But, it also means 
that the existing SDL remains basically the same in construct, even if 
its used a tad differently, you can nearly add to and change things the 
same way, **but** the actual "language" level can work more like a true 
program, without the complicated and confusing macro system now used to 
do most things, and with animation and other things handled, optionally 
as part of the "code" executing, and not via some reparse of the SDL.

Similar tricks would likely be possible for handling textures and other 
things. In effect, you get access to the SDL level if you need it, 
otherwise, you declare all your "static" objects, either SDL control any 
animation, or when possible, do that via the "language" level of the 
code. And, there is no conflict between what was **basically** a markup 
language, and what is program. Similar to how HTML is "clearly" 
distinct, for the same reason, from PHP, Java, or anything else that is 
used to "change it" dynamically. In a lot of ways, what little looping 
other other functions we do have in the SDL are shoehorned on. That 
really isn't going to change, unless you divorce the SDL *from* the flow 
control somehow imho.

-- 
void main () {

     if version = "Vista" {
       call slow_by_half();
       call DRM_everything();
     }
     call functional_code();
   }
   else
     call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models, 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message