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