rounded/beveled raised text
On 11/22/25 13:14, Jon Bondy via Discuss wrote:
If those working in functional programming choose to call immutable
values "variables", that is unfathomable and incorrect, but I don't
think we need to adopt or encourage that misleading nomenclature.
Are you going to do that for all Math books took?
ciao,
Torsten.
Another observation here is that the value of "x" in an OpenSCAD program
does in fact vary. It's not the same in every program, nor in every scope
of a single program. Also you have the option of running your program with
"x" set to a different value, so its value does in fact potentially vary
from program invocation to program invocation. In contrast, you don't
generally change the value of PI. In mathematics the term "variable" is
used for values that do not change during a particular analysis or
calculation. It's considered bad practice in a mathematical paper to
reassign a variable to a different value. We still call them variables.
The term constant is generally reserved for values like pi that
fundamentally do not change.
That said, I don't know what the implications are for the best
documentation. There's also the question of how you would get new people
to actually read the documentation section that goes over this topic. I'd
think that is really the question. If you have a documentation heading
like "You can't (usually) write x=x+1" that might attract people's
attention, for example. Most users are not going to read this
documentation; they'll just try to write x=x+1 and get confused with it
doesn't behave as expected.
But if you lean too hard into the "constant" idea then code like:
module foo(x)
{
x=abs(x);
....
}
becomes kind of puzzling. I write code with this form all the time while
handling arguments.
There's also
function foo(x) =
let(x=2x)
let(x=2x)
let(x=2*x)
x;
in which 4 values of x exist. So is x an immutable constant? Looks kind
of variable to me. You have to get very technical about scopes and build
up this idea that there are 4 different "x" values with the same label that
are somehow still different objects in order to preserve the concept of
immutability. That's technically correct, but that's not how I think about
code like this intuitively, nor do I feel that the full technical
conception has much advantage over the simpler intuitive one.
On Sat, Nov 22, 2025 at 7:14 AM Jon Bondy via Discuss <
discuss@lists.openscad.org> wrote:
If those working in functional programming choose to call immutable values
"variables", that is unfathomable and incorrect, but I don't think we need
to adopt or encourage that misleading nomenclature.
I agree that SOME of the named values that we use are actually variables,
while most of them are immutable. This, of course, only adds to the
confusion. We could attempt to manage this in the documentation by
specifically calling THOSE values "variables", and noting the difference.
I assume that none of the proposed language changes will create actual
variables, but I could be wrong.
The term "named constant", however awkward, seems to capture how OpenSCAD
works, and does not require a knowledge of C or Pascal or Modula2, all of
which have "const"s.
If we keep writing documentation referring to named constants as if they
were variables, then we should not be surprised by on ongoing confusion by
new adapters, and perhaps by some who give up on OpenSCAD because of their
confusion and frustration. If that is an acceptable penalty to pay for the
simplicity of the term "variable", then let's proceed with no change
Jon
On 11/22/2025 1:33 AM, Jordan Brown via Discuss wrote:
On 11/21/2025 6:40 PM, Father Horton via Discuss wrote:
In functional programming, they’re called variables, despite their
immutability. I think we are stuck with the term.
Perhaps more importantly, different runs through the same snippet of the
program may have different values for the same name.
for (i = [0:10]) echo(i);
function inc(j) = j + 1;
module kube(k) cube(k);
Are i, j, and k variables or constants?
(OpenSCAD behavior actually aligns with the C/C++ "const" modifier, but I
think that expecting OpenSCAD users to be familiar with C or C++ is a
stretch.)
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient
Virus-free.www.avg.com
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient
<#m_-6465873517671051256_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD is an ... unusual ... language. I am only concerned about
clarity when we describe the language. I don't need to fix all of the
mistakes (IMHO) made over the ages.
:)
On 11/22/2025 7:46 AM, Torsten Paul via Discuss wrote:
On 11/22/25 13:14, Jon Bondy via Discuss wrote:
If those working in functional programming choose to call immutable
values "variables", that is unfathomable and incorrect, but I don't
think we need to adopt or encourage that misleading nomenclature.
Are you going to do that for all Math books took?
ciao,
Torsten.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
Thanks, Adrian, for focusing us on "the implications ... for the best
documentation". That is the real issue.
Jon
On 11/22/2025 7:58 AM, Adrian Mariano via Discuss wrote:
Another observation here is that the value of "x" in an OpenSCAD
program does in fact vary. It's not the same in every program, nor in
every scope of a single program. Also you have the option of running
your program with "x" set to a different value, so its value does in
fact potentially vary from program invocation to program invocation.
In contrast, you don't generally change the value of PI. In
mathematics the term "variable" is used for values that do not change
during a particular analysis or calculation. It's considered bad
practice in a mathematical paper to reassign a variable to a different
value. We still call them variables. The term constant is generally
reserved for values like pi that fundamentally do not change.
That said, I don't know what the implications are for the best
documentation. There's also the question of how you would get new
people to actually read the documentation section that goes over this
topic. I'd think that is really the question. If you have a
documentation heading like "You can't (usually) write x=x+1" that
might attract people's attention, for example. Most users are not
going to read this documentation; they'll just try to write x=x+1 and
get confused with it doesn't behave as expected.
But if you lean too hard into the "constant" idea then code like:
module foo(x)
{
x=abs(x);
....
}
becomes kind of puzzling. I write code with this form all the time
while handling arguments.
There's also
function foo(x) =
let(x=2x)
let(x=2x)
let(x=2*x)
x;
in which 4 values of x exist. So is x an immutable constant? Looks
kind of variable to me. You have to get very technical about scopes
and build up this idea that there are 4 different "x" values with the
same label that are somehow still different objects in order to
preserve the concept of immutability. That's technically correct, but
that's not how I think about code like this intuitively, nor do I feel
that the full technical conception has much advantage over the simpler
intuitive one.
On Sat, Nov 22, 2025 at 7:14 AM Jon Bondy via Discuss
discuss@lists.openscad.org wrote:
If those working in functional programming choose to call
immutable values "variables", that is unfathomable and incorrect,
but I don't think we need to adopt or encourage that misleading
nomenclature.
I agree that SOME of the named values that we use are actually
variables, while most of them are immutable. This, of course, only
adds to the confusion. We could attempt to manage this in the
documentation by specifically calling THOSE values "variables",
and noting the difference. I assume that none of the proposed
language changes will create actual variables, but I could be wrong.
The term "named constant", however awkward, seems to capture how
OpenSCAD works, and does not require a knowledge of C or Pascal or
Modula2, all of which have "const"s.
If we keep writing documentation referring to named constants as
if they were variables, then we should not be surprised by on
ongoing confusion by new adapters, and perhaps by some who give up
on OpenSCAD because of their confusion and frustration. If that
is an acceptable penalty to pay for the simplicity of the term
"variable", then let's proceed with no change
Jon
On 11/22/2025 1:33 AM, Jordan Brown via Discuss wrote:
On 11/21/2025 6:40 PM, Father Horton via Discuss wrote:
In functional programming, they’re called variables, despite
their immutability. I think we are stuck with the term.
Perhaps more importantly, different runs through the same snippet
of the program may have different values for the same name.
for (i = [0:10]) echo(i);
function inc(j) = j + 1;
module kube(k) cube(k);
Are i, j, and k variables or constants?
(OpenSCAD behavior actually aligns with the C/C++ "const"
modifier, but I think that expecting OpenSCAD users to be
familiar with C or C++ is a stretch.)
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email todiscuss-leave@lists.openscad.org
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.avg.com_email-2Dsignature-3Futm-5Fmedium-3Demail-26utm-5Fsource-3Dlink-26utm-5Fcampaign-3Dsig-2Demail-26utm-5Fcontent-3Demailclient&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AsrE-c7ZR7B2Kyr3qgfvvppkCEBVsNmwEMndcrRSuOI&m=7Es_itF8F35-KWxHbywi_4jhSL1wi2AQpDFPPnpoYSDm-drZncSy1YtGuFqmjhpL&s=71UdSAODPG3GxlM_3ePp24VbxETGYb4LeK4KFdQPQgQ&e=>
Virus-free.www.avg.com
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.avg.com_email-2Dsignature-3Futm-5Fmedium-3Demail-26utm-5Fsource-3Dlink-26utm-5Fcampaign-3Dsig-2Demail-26utm-5Fcontent-3Demailclient&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AsrE-c7ZR7B2Kyr3qgfvvppkCEBVsNmwEMndcrRSuOI&m=7Es_itF8F35-KWxHbywi_4jhSL1wi2AQpDFPPnpoYSDm-drZncSy1YtGuFqmjhpL&s=71UdSAODPG3GxlM_3ePp24VbxETGYb4LeK4KFdQPQgQ&e=>
<#m_-6465873517671051256_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
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
My understanding of the problem is that what is needed is a term which means
"Reference handle which the user may assign a value to, possibly multiple times, and the last instance is the one applied for a given run of a program."
Arguably, "handle" is the correct term, but it goes against the grain of the history of algebra/math terminology, and is sufficiently arcane that switching folks to it would be a tough row to hoe.
I think just explaining the above early on, and then noting that "variable" will be used as a shortcut for "OpenSCAD handle/variable" is probably the most expedient option.
That said, if there is a term in computer science or some natural language which succinctly and efficiently conveys the above meaning, I'd be glad to know of it, and I think a powerful argument could be made for using it in this context.
William
--
Sphinx of black quartz, judge my vow.
https://designinto3d.com/
While agreeing with all that has been said, the issue that concerns me
is when someone is pointed to a particular piece of documentation (as I
was when I did not understand roof()), and they see "variable", without
the required explanation. it could lead to confusion.
On 11/22/2025 8:22 AM, William F. Adams wrote:
My understanding of the problem is that what is needed is a term which means
"Reference handle which the user may assign a value to, possibly multiple times, and the last instance is the one applied for a given run of a program."
Arguably, "handle" is the correct term, but it goes against the grain of the history of algebra/math terminology, and is sufficiently arcane that switching folks to it would be a tough row to hoe.
I think just explaining the above early on, and then noting that "variable" will be used as a shortcut for "OpenSCAD handle/variable" is probably the most expedient option.
That said, if there is a term in computer science or some natural language which succinctly and efficiently conveys the above meaning, I'd be glad to know of it, and I think a powerful argument could be made for using it in this context.
William
That said, if there is a term in computer science or some natural language
which succinctly and efficiently conveys the above meaning, I'd be glad to
know of it, and I think a powerful argument could be made for using it in
this context.
There is. That term is "variable".
OpenSCAD is basically a functional language, so it thinks in terms of
functions. If I have a function f(x), what is “x”? It’s a variable — it can
take different values each time the function is called. Yes, at the global
level OpenSCAD treats things differently, but if we start calling “x” one
thing in global scope and something else in a function, even though we use
it the same way in expressions, that just makes the terminology more
confusing, not less.
In most (all?) languages that use functions/subroutines/modules/whatever, the ‘x’ in ‘f(x)’ is emphatically NOT a “variable”: it’s an “argument”.
Even in OpenSCAD, there’s a profound difference.
From: Father Horton via Discuss discuss@lists.openscad.org
Sent: Saturday, November 22, 2025 6:48 AM
To: OpenSCAD general discussion Mailing-list discuss@lists.openscad.org
Cc: Father Horton fatherhorton@gmail.com
Subject: [OpenSCAD] Re: The term "variables"
That said, if there is a term in computer science or some natural language which succinctly and efficiently conveys the above meaning, I'd be glad to know of it, and I think a powerful argument could be made for using it in this context.
There is. That term is "variable".
OpenSCAD is basically a functional language, so it thinks in terms of functions. If I have a function f(x), what is “x”? It’s a variable — it can take different values each time the function is called. Yes, at the global level OpenSCAD treats things differently, but if we start calling “x” one thing in global scope and something else in a function, even though we use it the same way in expressions, that just makes the terminology more confusing, not less.
On Sat, Nov 22, 2025 at 10:24 AM Lee DeRaud via Discuss <
discuss@lists.openscad.org> wrote:
In most (all?) languages that use functions/subroutines/modules/whatever,
the ‘x’ in ‘f(x)’ is emphatically NOT a “variable”: it’s an “argument”.
Even in OpenSCAD, there’s a profound difference.
It's been a minute, but I think I recall that in a function definition some
of my classes referred to the x in f(x) as a parameter, and then when
the function was actually called, the stuff betwixt the parenthesis was an
argument. Not that I'm looking to get into one. 😉 I'm okay with calling it
an argument all the time -- though once inside the body of a function, I
don't recall if we still referred to it as an argument when accessed.
As for "it's a functional language" or "Ph.D. mathematicians say...", I
wish there were two layers of documentation: Not everyone who wants to
design 3D objects has a higher degree in mathematics or computer science.
For the purists doing deep dives, the arcane, occult philosophical
mysteries may be fun and relevant enough to determine to several decimal
places how many angels can dance on the head of a pin. To the non-techie
and / or lazy, who just want to draw simple objects with code rather than
try to stretch objects with a mouse a la Blender, the arcana may be less
relevant. Thus user manuals and reference manuals.
Agree, although I’m not over-fond of “parameter” in this context, as we tend to use “parameter” (and “parametric”) when describing the named-(semi-)constants that started this discussion.
And having said that, maybe “parameter” is the word we’re looking for to replace “variable”.
From: Kevin Cole dc.loco@gmail.com
Sent: Saturday, November 22, 2025 8:02 AM
To: OpenSCAD general discussion Mailing-list discuss@lists.openscad.org
Cc: Father Horton fatherhorton@gmail.com; lee.deraud@roadrunner.com
Subject: Re: [OpenSCAD] Re: The term "variables"
On Sat, Nov 22, 2025 at 10:24 AM Lee DeRaud via Discuss <discuss@lists.openscad.org mailto:discuss@lists.openscad.org > wrote:
In most (all?) languages that use functions/subroutines/modules/whatever, the ‘x’ in ‘f(x)’ is emphatically NOT a “variable”: it’s an “argument”.
Even in OpenSCAD, there’s a profound difference.
It's been a minute, but I think I recall that in a function definition some of my classes referred to the x in f(x) as a parameter, and then when the function was actually called, the stuff betwixt the parenthesis was an argument. Not that I'm looking to get into one. 😉 I'm okay with calling it an argument all the time -- though once inside the body of a function, I don't recall if we still referred to it as an argument when accessed.
As for "it's a functional language" or "Ph.D. mathematicians say...", I wish there were two layers of documentation: Not everyone who wants to design 3D objects has a higher degree in mathematics or computer science. For the purists doing deep dives, the arcane, occult philosophical mysteries may be fun and relevant enough to determine to several decimal places how many angels can dance on the head of a pin. To the non-techie and / or lazy, who just want to draw simple objects with code rather than try to stretch objects with a mouse a la Blender, the arcana may be less relevant. Thus user manuals and reference manuals.