I think that Peter misunderstood the behavior of my work in PR#4478. 
(Unless he's done a lot more than I did.)  That makes most of your
comments not be relevant, because they apply to something that isn't
happening.

However, one clarification...

On 8/22/2025 11:06 PM, vulcan_--- via Discuss wrote:

No.  In any given scope, assignments are evaluated before modules.

OEP8 module references cannot be called in expressions per se.

OEP8 geometry values can be evaluated in expressions, and can contain
arbitrary OpenSCAD syntax, including evaluations of ordinary modules and
module references.

Nobody is currently working on geometry values.

Hyper-quick summary of OEP8 / PR#4478  geometry values, to make it
clearer what the difference is...

g = {{ cube(); }};

"g" will get the result of evaluating the enclosed arbitrary OpenSCAD
statements.

Geometry values are values and you can do anything value-like with
them:  assign them, pass them to or return them from functions, put them
in lists and objects, et cetera.

You can do two new things with geometry values:

g;    or maybe  import(g);

(no final-ish decision on which) would add the geometry value to the model.

o = render(g);

This is the really interesting one.  It runs the full rendering process
on the geometry value, and returns a list of vertexes and faces (for 3D
objects) or points and paths (for 2D objects), and some metadata.  This
allows you to create things like bend/wrap operations, along with
simpler operations like "center anything".

But again, beyond the implementation in PR#4478, which more or less
worked at the time but was before the Manifold transition, nobody is
working on geometry values.

I think they're orthogonal to objects and module references, and
strongly recommend keeping them separate.  I tried to bring in all three
at the same time, because I wanted to verify that they could all
peacefully coexist, but that stalled because it was too big for people
to review.  Things are too complicated right now as it stands; I would
leave geometry values for after we've closed on several of the other items.

[ Subject change to broaden the topic ]

On 8/22/2025 7:42 PM, Jon Bondy via Discuss wrote:

Probably only in my head, and then that replicated imperfectly into
other people's heads.

I would say:

  Objects

• Provide a name-value pair data type.

• Creation, access, and iteration syntax should be crisp and minimal.

• Should support both statically-named and dynamically-named keys,
  including arbitrary strings as keys.

• Should be clearly extensible to support future OO-related features:
  methods, inheritance, maybe more.

• (Maybe) Should support "comprehension" akin to list comprehension.

  Module references

• Provide a data type that is a reference to a module, akin to the
  existing function references.

• Provide a syntax for defining a module, that yields a module reference.

• Module references should be invoked like ordinary modules, akin to
  how function references are invoked like ordinary functions.

  Geometry values

• Provide a data type that can represent a CSG tree.

• Provide a syntax for generating these values in an expression, using
  ordinary OpenSCAD syntax.

• Provide a way to add one of these values to the model under
  construction.

• Provide a way to render one of these values into vertexes and faces
  (for 3D) or points and paths (for 2D), and return that rendered data
  to the user program.

What do you mean by a syntax to define a module that yields a module
reference? Do you mean you want something like a lambda for function
that creates a new module?

On 8/24/25 07:52, Jordan Brown via Discuss wrote:

On 8/23/25 19:52, Jordan Brown via Discuss wrote:

That may be the most succinct statements made yet in all the recent
hullabaloo on this list.  But let me try to explain. I've spent nearly
75 years chasing electrons for a living, quitting school to go fix them
things we now call TV's right after VJ day.  Tested at 147 on the Iowa
test in the 7nth grade, so most of you have at least 8 more years of
math education than I do.  Tried to get Korea out of  the way by having
the draft board draw my name about a year early, but made a 98 on the
AFQT in '52, which got me 4F'd forever and ineligible for the GI Bill.
Helped make the TV cameras on the Trieste when it went down in the
mohole in Feb '59. Got a 1st phone in 62, and switched to broadcast
engineering shortly after.  1st person in about 6 years to actually pass
the CET  test, at Norfolk Community College, just by walking in the
profs door with a spare $20 bill in '72.  Spent the last 18.75 years of
my working life as a CE who fixed 99% of it at WDTV-5 here in WV.  So
mathematically, you folks impress the heck out of me. And at 90 I am
still productive with the bare bones OpenSCAD monthly builds.  Never
could get to 1st base with FreeCAD.  So basically I'm not qualified to
have "an opinion" simply because I don't have the education to
understand the arguments. Not your fault, mine.

What I do see, is the authors of what I consider great software,
endlessly arguing over the best color for M&M's Peanuts.  And I see this
as discouraging to new users witnessing the discussion. OTOH I only know
of one other list where the authors actually answer questions.  Believe
me that is refreshing, please never change that. . .

The only thing I'd like to see, is a center keyword that if left out,
defaults to true, not false.

Cheers, Gene Heskett, CET.

"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.

• Louis D. Brandeis

On Sat, 2025-08-23 at 23:32 -0400, gene heskett via Discuss wrote:

YES!

On 8/24/25 01:42, larry via Discuss wrote:

I can't make it happen. But at least a dozen of you guys could. In 4 or
5 years
I cannot remember not having to use it where it was applicable. It would
sure save me a bunch of typing making long lines even longer forcing a
shrinkage
to my viewport window on a 1920*1024 screen. Or a font so small I can't
see my
typu's on it.

Cheers, Gene Heskett, CET.

"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.

• Louis D. Brandeis

They will never flip the default on the center keyword, because it would
break tons of models.  But we got this right in BOSL2:  objects appear
centered by default.  :)

On Sun, Aug 24, 2025 at 1:42 AM larry via Discuss <
discuss@lists.openscad.org> wrote:

On 8/23/2025 11:32 PM, gene heskett wrote:

That would break an awful lot of existing code.

One can always create aliased versions of things like cube() (called,
perhaps, MyCube()) where the defaults are different. There is no need
for this to be an issue for anyone, and one need not change the
language.  Just define what you want and then use your versions of the
modules.

On 8/24/2025 7:30 AM, Adrian Mariano via Discuss wrote:

--
This email has been checked for viruses by AVG antivirus software.
www.avg.com

On 8/24/25 07:31, Adrian Mariano via Discuss wrote:

Then make it possible to set that ",center=true;" in a single global
scope line at the top of the file.
The endless repeat typing of a typu prone 11 chars would come to an end.

Cheers, Gene Heskett, CET.

"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.

• Louis D. Brandeis