Am 12.07.2021 um 15:01 schrieb Mr:

> So my question to the experts is, could end of line statement still be
> compatible with the proposed json paradigm / standard ? maybe in the worse case,
> breaking away from the standard but by chosing a subset of it... or whatever
> shift...?

One of the key features of the proposed language would be that any valid 
JSON file would automatically qualify as valid POV-Ray SDL file 
(provided the "document object model", aka "schema", matches, i.e. the 
hierarchy of how and what stuff is nested where).

Allowing for line endings to terminate statements might break that 
compatibility, because the JSON standard allows line endings anywhere it 
allows for whitespace.


I used JSON as a starting point for the proposed SDL format not only to 
start _somewhere_ but specifically because being 100% compatible with 
JSON would have the advantage that there are tools and libraries galore 
out there to generate that format.

JSON is one of just a handful of probably the top most popular formats 
for storage and exhange of structured data:

- XML
- JSON
- YAML

XML is painfully verbose, and therefore not an option. YAML is very 
concise, but assigns semantics not only to line endings but also to 
indentation, and that is something I'm anything but a fan of.

Which leaves us with JSON as the next most obvious choice - which 
happens to be similar to POV-Ray's current SDL both in terms of 
verbosity and overall look & feel (thanks to both ultimately being 
inspired by C).


Also, categorically making any line ending end a statement has the big 
drawback that any statement must be written on a single line. To work 
around this, the statement-ending semantics of line endings would have 
to be weakened depending on context, which in turn would add more 
complexity to the parser, and moreover to the language itself, 
potentially making it difficult for users to grasp how the line-ending 
rules work.

An alternative would be to make some of the commas optional, but at 
least as soon as we add certain of our own features we'd run into 
similar problems to avoid ambiguities.


> (I only asked because it would seem that we would be at leat two in favour of
> such a feature, but I for one would gladly give the request up after being
> explained a reason, such as performance gain etc...)

Compatibility with the base format, keeping the format free from 
ambigiuties, and keeping the format reasonably easy for users to grasp. 
That's pretty much all the reason there is to not assign special 
semantics to line endings.

In terms of performance, it probably wouldn't make much of a difference.

Post a reply to this message