redefining a module()
I’m vaguely surprised this kind of functional conflict hasn’t happened already.
Perhaps an indelicate question: at what point does a 3rd-party library (or a largish chunk of its features) become so useful/ubiquitous that it becomes a de facto standard of its own?
I for one consider BOSL2 as nearing that point, as I find myself including it by default in pretty much everything. The other libraries I use are rather more specialized.
Or was there a conscious decision made early on to keep specific BOSL2 features out of the “base” functionality?
From: Jordan Brown via Discuss discuss@lists.openscad.org
Sent: Thursday, June 11, 2026 11:04 AM
To: Adrian Mariano avm4@cornell.edu
Cc: OpenSCAD general discussion Mailing-list discuss@lists.openscad.org; Jordan Brown openscad@jordan.maileater.net
Subject: [OpenSCAD] Re: redefining a module()
Eh, sort of. Yes, when a library introduces a "broad" feature, a behavior that it presents as ubiquitous, and OpenSCAD evolves to have a similar-but-different feature, that's a conflict of sorts, a disharmony. However, one can still draw a line around the OpenSCAD components and the library components, and say that different rules apply to each.
And in fact you do that: OpenSCAD constructs extend into +Z by default (and +XY for cube and square), while BOSL2 constructs are centered by default. OpenSCAD cube() and BOSL2 cuboid(), and OpenSCAD cylinder() and BOSL2 cyl(), do very similar things but have different origin points.
But drawing that kind of line isn't possible when the library has augmented the builtins, because those augmented builtins are then inside both circles, and they might (in the future) conflict.
To be clear: I'm not saying that BOSL2's overrides of the builtins are wrong. There's a tradeoff: cleaner overall API, versus future compatibility risk. There are arguments on both sides. Personally, I probably wouldn't have done it, because you already felt the need for cuboid() and cyl(); once you are saying "here's the better way" it's not much of a leap to "we recommend not using the old way". You chose differently, and that's OK.
On 6/11/26 11:37 AM, Lee DeRaud via Discuss wrote:
I’m vaguely surprised this kind of functional conflict hasn’t happened
already.
The rate of enhancement in the base OpenSCAD library has slowed to a
crawl, so it's unlikely to happen. The basic argument seems to be "if
you can do it somehow without changing the builtins, then that's how you
should do it".
The focus has been on speed/performance improvements (Manifold), things
which make libraries easier to write (i.e. Objects), UI, and I/O (i.e.
exporting better to 3mf). The maintainers have decided no breaking
changes (even to "incorrect" code) shall be made without a high bar. And
so if center="right" made things centered, you can't make that now put
the origin at the left side of the cube, because someone could have a
model that now works differently.
But there is some freedom in that: you can use BOSL2 and a given version
of BOSL2 will be extremely unlikely to work differently on different
versions of OpenSCAD.
But it's really unfortunate the version of OpenSCAD you get from the
website is 1. so outdated and 2. doesn't include BOSL2, but there's
already discussions on those points.
Cory
On 6/11/2026 11:37 AM, Lee DeRaud via Discuss wrote:
I’m vaguely surprised this kind of functional conflict hasn’t happened
already.
If you stay away from overriding, the major place that can happen is in
module/function names. Has there ever been a library that started using
some name X, and then later OpenSCAD started using that same name? No
idea. Or, similarly, a conflict between a main program and a library,
or a main program and OpenSCAD? (That possibility is one of the things
that I'd like to fix in a hypothetical future replacement for "use".)
OpenSCAD evolves very slowly in that area, so there are very few
opportunities for conflict - and, mostly, since the library
implementation will "win", there will only be a conflict if somebody's
trying to use the new built-in feature.
Perhaps an indelicate question: at what point does a 3^rd -party
library (or a largish chunk of its features) become so
useful/ubiquitous that it becomes a de facto standard of its own?
I for one consider BOSL2 as nearing that point, as I find myself
including it by default in pretty much everything. The other
libraries I use are rather more specialized.
Any library sets its own standard, so that's already happened. The
question that I think you're asking is whether there's a point at which
OpenSCAD would change its course, away from the course we might
otherwise select, to align with some library or to avoid a conflict with
some library. I think that will always be handled on a case-by-case basis.
Or was there a conscious decision made early on to keep specific BOSL2
features out of the “base” functionality?
There are two levels of "base" functionality.
You can have stuff that's built into the program itself and implemented
in C++, like cube(), that you get without any "include <>" or "use <>".
There's been a pretty conscious decision to minimize those things,
adding them only when they simply can't be implemented in
OpenSCAD-language, or when there's a major performance difference
between a C++ implementation and an OpenSCAD-language implementation.
There are two reasons for that decision: (1) writing C++ is harder and
riskier than writing OpenSCAD-language, and (2) once it's in the C++,
it's very difficult to change it or take it out with making somebody
unhappy. If it's in OpenSCAD-language, and you get to it using "include
<BOSL2.scad/std.scad>", tomorrow you can introduce BOSL3 and consumers
can "include <BOSL3/std.scad>", without causing any problems for
BOSL2-based programs. We have lots of stuff today that's implemented in
C++ that could be implemented in OpenSCAD-language; if we were starting
with a blank slate I wouldn't be surprised if the list of builtin
modules and functions was much smaller, with the remainder supplied by a
bundled library.
There can be libraries that are bundled with OpenSCAD, that are
installed by default. You access them with "include <>" or "use <>",
just as for an unbundled library. MCAD is bundled with OpenSCAD. BOSL2
could be bundled with OpenSCAD. Why isn't it? Because the BOSL2
authors have decided they don't want it to be. (I don't think the
question has come up yet whether OpenSCAD would accept it.) Why don't
they want it to be? I haven't talked to them deeply about it, but I
think the answers are roughly wanting to be the masters of their own
destiny, and not wanting to be bound up with the OpenSCAD release schedule.
I think the high-level and never-quite-accomplished goal is for OpenSCAD
to get a package manager, so that installing a library is just a matter
of selecting it and saying "install", rather than needing to pick which
libraries to bundle.
BOSL2 is extremely important to how I code in OpenSCAD. Were OpenSCAD
to create a release that made it incompatible with BOSL2, or screwed up
BOSL2 for no universally agreed reason, I would question the wisdom of
the changes in that release. It may not be a question of the tail
wagging the dog, but perhaps the shoulders wagging the hips. I see the
two as inexorably bound together, already.
Jon
On 6/11/2026 2:37 PM, Lee DeRaud via Discuss wrote:
Perhaps an indelicate question: at what point does a 3^rd -party
library (or a largish chunk of its features) become so
useful/ubiquitous that it becomes a de facto standard of its own?
I for one consider BOSL2 as nearing that point, as I find myself
including it by default in pretty much everything. The other
libraries I use are rather more specialized.
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
We have never had any conversation with the OpenSCAD devs about how the
BOSL2 feature set interacts with the "base" functionality. The devs do,
however, have a general mindset that if you can do it in userspace they
should not add it to core OpenSCAD. This appears to apply even when the
OpenSCAD implementation is fragile, difficult, and orders of magnitude
slower. I'll also note that OpenSCAD seems to have had its first release
in 2010 and BOSL2 development looks like it commenced sometime around 2018,
so OpenSCAD development was well underway when BOSL2 got its start.
River tried to get polygon operations (the clipper library) exposed as user
functions, for example, with a working PR. The implementation he wrote in
userspace is probably 1000x slower at least than the native version. But
that didn't fly. Another questionable situation: I implemented solutions
to linear systems of equations in OpenSCAD. In recent tests I realized my
code was 100,000 times slower than native code would be (e.g. by comparing
to Octave). Rock solid and highly optimized implementations of linear
algebra exist in packages like eigen or lapack, so why am I wasting my time
trying to figure out why my code is 10^5 times slower than the reference?
I did discover a way to rewrite the code to make it faster---it involved
doing all the operations on transposed matrices, basically doing everything
turned sideways from how all the algorithms appear in the textbooks. I've
forgotten the exact timings but I think it's now "only" 100-1000 times
slower than native. I don't generally see much point in trying to get
stuff like this added to core OpenSCAD because it doesn't seem to actually
happen.
Jordan, yes, you can draw a line around OpenSCAD and the library and say
that different rules apply. The problem is, the users will be confused and
won't get it, and we'll get a ton of bug reports. This gets back to the
reason for the overrides, which is that it avoids us having a list of
"these 11 modules you must never use". It's not all the core modules,
just some of them. And it actually changed when I added descriptions and
had to override translate, rotate and multmatrix. So if OpenSCAD added a
core anchor feature that conflicted with the BOSL2 anchor feature we'd be
in that situation but it would probably be even more confusing when users
mistakenly used the forbidden modules. So while yes, technically BOSL2
could coexist with this imagined new feature, in practice it would probably
result in the rise of BOSL3 with a different API to reduce confusion.
Another observation is that sure, you can say "only use the BOSL2 functions
in BOSL2" but what if you need to use other code from some other non-BOSL2
source? You have to translate it to BOSL2 before you can use it?
Cory said, "The rate of enhancement in the base OpenSCAD library has slowed
to a crawl". That's an interesting perspective. I'd say it's always been
at a crawl--or slower. When I first started using OpenSCAD the situation
was much the same: the "stable" version was years old and missing useful
features I found I needed. And this connects to the issue of BOSL2 being
bundled with OpenSCAD. Would you want to be stuck with the 2021 version of
BOSL2? I'll admit that if OpenSCAD errs on the side of excessive
stability, BOSL2 errs in the other direction---tying releases to an every
5+ years schedule definitely doesn't suit us.
On Thu, Jun 11, 2026 at 2:37 PM Lee DeRaud via Discuss <
discuss@lists.openscad.org> wrote:
I’m vaguely surprised this kind of functional conflict hasn’t happened
already.
Perhaps an indelicate question: at what point does a 3rd-party library
(or a largish chunk of its features) become so useful/ubiquitous that it
becomes a de facto standard of its own?
I for one consider BOSL2 as nearing that point, as I find myself including
it by default in pretty much everything. The other libraries I use
are rather more specialized.
Or was there a conscious decision made early on to keep specific BOSL2
features out of the “base” functionality?
From: Jordan Brown via Discuss discuss@lists.openscad.org
Sent: Thursday, June 11, 2026 11:04 AM
To: Adrian Mariano avm4@cornell.edu
Cc: OpenSCAD general discussion Mailing-list discuss@lists.openscad.org;
Jordan Brown openscad@jordan.maileater.net
Subject: [OpenSCAD] Re: redefining a module()
Eh, sort of. Yes, when a library introduces a "broad" feature, a behavior
that it presents as ubiquitous, and OpenSCAD evolves to have a
similar-but-different feature, that's a conflict of sorts, a disharmony.
However, one can still draw a line around the OpenSCAD components and the
library components, and say that different rules apply to each.
And in fact you do that: OpenSCAD constructs extend into +Z by default
(and +XY for cube and square), while BOSL2 constructs are centered by
default. OpenSCAD cube() and BOSL2 cuboid(), and OpenSCAD cylinder() and
BOSL2 cyl(), do very similar things but have different origin points.
But drawing that kind of line isn't possible when the library has
augmented the builtins, because those augmented builtins are then inside
both circles, and they might (in the future) conflict.
To be clear: I'm not saying that BOSL2's overrides of the builtins are
wrong. There's a tradeoff: cleaner overall API, versus future
compatibility risk. There are arguments on both sides. Personally, I
probably wouldn't have done it, because you already felt the need for
cuboid() and cyl(); once you are saying "here's the better way" it's not
much of a leap to "we recommend not using the old way". You chose
differently, and that's OK.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
On Jun 11, 2026, at 12:26 PM, Jordan Brown via Discuss discuss@lists.openscad.org wrote:
If you stay away from overriding, the major place that can happen is in module/function names. Has there ever been a library that started using some name X, and then later OpenSCAD started using that same name?
Not really… OpenSCAD changes so glacially that it never really happens in practice. It took three years for object() to be added, and the module literals it was supposed to come with still haven’t appeared. I HAVE tried suggesting ways to fix the broken use<> in a way that would provide namespaces, though.
lib = use<lib.scad>;
foo = lib.func(blah);
On the other hand, OpenSCAD DID change the rules for allowed function and module names to exclude starting with numbers, so that numbers in 0xDEADBEEF hex notation could be added. That messed badly with nopSCADlib, as I recall, since it had modules named for various electrical parts whose names started with numbers.
I admit that starting module names with numbers is kinda sketchy. But so is taking advantage of having separate namespaces for modules, functions, and variables. I ended up leaning heavily on that myself, so I can’t blame nophead much. What isn’t forbidden is allowed.
-Revar
On Jun 11, 2026, at 5:05 PM, Adrian Mariano via Discuss discuss@lists.openscad.org wrote:
And this connects to the issue of BOSL2 being bundled with OpenSCAD. Would you want to be stuck with the 2021 version of BOSL2? I'll admit that if OpenSCAD errs on the side of excessive stability, BOSL2 errs in the other direction---tying releases to an every 5+ years schedule definitely doesn't suit us.
I wouldn’t mind if OpenSCAD shipped with snapshots of BOSL2, but I’m not tying BOSL2’s development schedule to it.
-Revar
If OpenSCAD shipped with BOSL2 snapshots then this would make whatever
BOSL2 release shipped with the "stable" OpenSCAD into the de facto official
BOSL2 release.
On Thu, Jun 11, 2026 at 8:41 PM Revar Desmera via Discuss <
discuss@lists.openscad.org> wrote:
On Jun 11, 2026, at 5:05 PM, Adrian Mariano via Discuss <
discuss@lists.openscad.org> wrote:
And this connects to the issue of BOSL2 being bundled with OpenSCAD.
Would you want to be stuck with the 2021 version of BOSL2? I'll admit that
if OpenSCAD errs on the side of excessive stability, BOSL2 errs in the
other direction---tying releases to an every 5+ years schedule definitely
doesn't suit us.
I wouldn’t mind if OpenSCAD shipped with snapshots of BOSL2, but I’m not
tying BOSL2’s development schedule to it.
-Revar
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
"What isn’t forbidden is allowed."
What isn't forbidden becomes commonplace?
:)
On 6/11/2026 8:36 PM, Revar Desmera via Discuss wrote:
On Jun 11, 2026, at 12:26 PM, Jordan Brown via Discussdiscuss@lists.openscad.org wrote:
If you stay away from overriding, the major place that can happen is in module/function names. Has there ever been a library that started using some name X, and then later OpenSCAD started using that same name?
Not really… OpenSCAD changes so glacially that it never really happens in practice. It took three years for object() to be added, and the module literals it was supposed to come with still haven’t appeared. I HAVE tried suggesting ways to fix the broken use<> in a way that would provide namespaces, though.
lib = use<https://urldefense.proofpoint.com/v2/url?u=http-3A__lib.scad&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AsrE-c7ZR7B2Kyr3qgfvvppkCEBVsNmwEMndcrRSuOI&m=3O9cXf1mCOYbzwutjyUBxd3vIki8pvNkYpfg2y6cyxc79Cbz7s-as1svUirbW9A8&s=j-7A0Gj52pW03eTpg92gy0v5jyikEtoSorbu_JmHk8A&e=>;
foo = lib.func(blah);
On the other hand, OpenSCAD DID change the rules for allowed function and module names to exclude starting with numbers, so that numbers in 0xDEADBEEF hex notation could be added. That messed badly with nopSCADlib, as I recall, since it had modules named for various electrical parts whose names started with numbers.
I admit that starting module names with numbers is kinda sketchy. But so is taking advantage of having separate namespaces for modules, functions, and variables. I ended up leaning heavily on that myself, so I can’t blame nophead much. What isn’t forbidden is allowed.
-Revar
OpenSCAD mailing list
To unsubscribe send an email todiscuss-leave@lists.openscad.org
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
On Jun 11, 2026, at 5:51 PM, Adrian Mariano via Discuss discuss@lists.openscad.org wrote:
If OpenSCAD shipped with BOSL2 snapshots then this would make whatever BOSL2 release shipped with the "stable" OpenSCAD into the de facto official BOSL2 release.
So, BOSL5 then.
-Revar