Am 14.07.2021 um 20:15 schrieb ingo:

> Lets go wild then. I don't like it. I like how the current SDL is
> sufficient. Fit for use. Although there's a lot I would leave out.
> #declare, #local be gone! Proper, simple, understandable namespaces and
> scoping with maybe a (exportable) global.

So there _is_ something you would add: Namespaces.

Also, for something that is "fit for use", there's quite a lot you would 
seem to change ;)

> All the #'s be gone. What's
> left then is quite clean.

But is it though?

Trim the `#` from the `#version` statement, and it clashes with the 
pseudo-variable `version`, for example. Trim the `#` from the `#local` 
statement, and it clashes with the `local` pseudo-dictionary.

You're asking for namespaces - you can look at `#` as the namespace for 
control statements.


(There's also one particular property the use of `#` has, that is 
invaluable at least for the current parser:

It helps a lot in speeding up the parsing of some control structures. 
For example, after encountering `#if()` with an expression that is 
false, the parser can simply skip from `#` to `#` in search for the 
matching `#else` or `#end`, because anything else is guaranteed to not 
natter. Likewise, after encountering `#macro(...)`, the parser can 
simply skip from `#` to `#` in search for the matching `#end`, because 
it will only parse the macro body once it is invoked.

Of course that may be less of an issue once we change the parsing 
strategy to scan and tokenize the file only once, and then work on the 
"pre-digested" token sequence.)


> Oh ';' out, out out. Squiggels is enough and
> (),[],<>. Vectors are great.
> 
> Then there's a few little gripes "for (I, 0, dimension_size(ArrayX, 1)-
> 1)" for example. I know the dimension_... comes from the multidimensional
> arrays, but are they still needed when we have arrays of arrays? "for (I,
> 0, size(ArrayX)-1)" or "for (I, 0, size(ArrayX[5])-1)".

Genuine multidimensional arrays are easier to set up:

     #declare Foo = array[10][10];

as opposed to:

     #declare Foo = array[10];
     #for (I, 0, 9)
         #declare Foo[I] = array[10];
     #end

Also, they guarantee that the size of the second dimension is constant, 
whereas arrays of arrays might have different sizes in the second dimension.

They are also more memory-efficient, especially if the last dimension is 
comparatively small.

And I guess they are also more efficient in terms of performance, 
although that might not show much in comparison to the general slowness 
of the current parser.


> So, no brand new syntax for me, but a cleaned up version as close as
> possible in functionality as the current one.

> No OOP.

I hope you'll be fine with structured data aggregates at the very least 
(think POV-Ray v3.8's dictionaries).

And since dictionary entries can be functions (or at least should be 
able to; not 100% if that currently works), and I'm determined to make 
functions more powerful (wouldn't you want to be able to write tiny 
little programs in functions, if only to more easily work with interim 
results?), OOP will probably enter the scene as a side effect.

If it weren't for the special syntax of macros (`#macro Foo() ... #end` 
instead of `#declare Foo = macro() ... #end`)

Also, my goal is to formalize the object, pattern and whatnot syntax 
more, which will feature OOP at least under the hood. And wouldn't it be 
nice to implement custom objects that look and feel just like the 
inbuilt ones, syntax-wise?

> Would iterators,
> generators make sense? I doubt it.

I'm not quite so sure. Unless we provide a goot set of container-style 
inbuilt data structures (which _are_ useful after all), people will 
start to use structured data aggregates to roll their own, and end up 
with the desire to use them in a nice elegant `for myElement in myArray` 
(or alike) loop. That'll be difficult to implement generically without 
the concept of an iterator.

The good news is that iterators are just a matter of proper 
implementation, once you provide OOP basics.

> No async.

Sure? It would allow users to leverage multiple CPUs even during parsing.

> Minimal to no functional
> stuff.

If you mean syntax to support functional programming, I agree. I can't 
wrap my head around that paradigm anyway, so I doubt I could design or 
even implement a language to support it properly.

If you mean powerful syntax for functions, I disagree. I do want at 
least the ability to easily compute interim results in functions.

> Also something that relative easily can be converted from old to
> new (probably impossible given how the SDL can be 'abused').

You're probably right there: It would be a pain to write a converter. 
Because it is a pain to write a parser for the current SDL in the first 
place.

> Under the hood? I would like to have more access to all kind of variables
> POV-Ray calculates so we can create 'things' (textures) depending on
> those results.

Ooooh... so maybe some OOP features after all?

Also: Can you be a _little_ bit more specific?

There's a lot of stuff POV-Ray calculates under the hood, but only a 
fraction thereof can reasonably accessed from SDL.

> Ok, now for the crazy one: Wasm. https://webassembly.org/
> I like how the compiled functions in math.inc work through an include
> file. I like the ideas of adding more of those.
> I even more like the idea if we could write dynamic linked libraries,
> call them from POV-Ray using a compagnion include file. (something
> simmilar is done in SuperCollider c++ for the audio server and a *.sc
> file for the scripting side).
> Now, what if these wasm's can be used as 'dll's'. It would make them
> platform independent plug-in's. Reduction of maintenance. There are a lot
> of languages that can be compiled this way, proper toolchains et al.

I don't think that will happen, at least not anytime soon. Allowing for 
arbitrary binaries to be plugged in can open up quite a can of worms, 
security issues being only one of them.

Also, I'm sure such plug-ins _will_ create intersections with the world 
of OOP.

> Or, the other way around. Could it be made possible to convert a parsed
> file into 3D printer data more easily, with checks for holes we don't
> need when tracing? OGL visualisations?

Possibly, eventually. Long road there. But that's less of a parser 
matter, and more of a render pipeline thing. We need to pull that apart 
in order to more easily provide SDL-level access to its elements.

Post a reply to this message