kwikius

> However, I consider it highly undesirable to have two overlapping object-literal syntaxes, and the one-and-only syntax, whichever that is, should use the `{...}` markers. (...} But there can be...

For associative arrays the syntax in https://github.com/openscad/openscad/issues/4203 works ( in your version of the parser without modifying your other syntaxes), if you change ':' to '=' to avoid ambiguity with...

The "geometry literal" has many similarities to a module_literal. Semantic change is pre-eveluation of expressions. You could for example decorate the module_literal syntax to get the same effect with very...

``` 1 $fn = 3; 2 x = [module] { circle(10); }; 3 m = module() { circle(10); }; 4 translate([0,0,0]) x; // adds a triangle 5 translate([20,0,0]) m(); //...

> You injected the word "module", which means "a block of source that will be evaluated later", into an expression that is evaluated _now_, not _later_. No. I use the...

The expression ```x = {{ circle(10); }}; ``` doesnt mean anything in current OpenSCAD It's a syntax error; > You injected the word "module", which means "a block of source...

The type of the result of a calculation on two quantities Q op Q where the result is dimensionless should merely be the type of(v1() op v2()). No conversion required....

> > The type of the result of a calculation on two quantities Q op Q where the result is dimensionless should merely be the type of(v1() op v2()). No...

> > In fact the claim in mp-units to be able to represent different systems is not upheld in practise. It provides one system and uses that as the basis...

> The same operation (e.g., division) should always return the same interface no matter which system you use. I can't follow what you are trying to say there. What do...