Assignment semantics

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Assignment semantics

Oskar
The sequential assignment semantics of the proposed let() should ideally be aligned with the future idea of having scoped variables, and I am interested in what the intention is here. The current behavior is (as has been discussed before) not ideal, and there may be a few different options of how to change that. Considering the following two cases (and their current behavior in the comment)

    a=1; b=a; a=2;  // b == 2
    d=c; c=2; // WARNING: Ignoring unknown variable 'c', d == undef

The options I see are:

1. Introduce sequential assignment with reassignment. This will silently change b to 1 in the example above, which will cause silent breakage.

2. Introduce sequential assignment without allowing reassignment (i.e. make it an error). This will probably break some few cases of existing code, but not silently and with an easy way to fix.

3. Introduce recursive assignment disallowing reassignment. -> This will change d to 2 in the example above which theoretically could silently break some existing code, but quite unlikely.

4. Of course: Do nothing.

So: 1 -> silent breakage. 2 -> less breakage but not silent. 3 -> low risk of silent breakage. From an implementation point of view, 1 and 2 are quite a bit simpler to implement.

My suggestion would be to do 2, but start with a depreciation warning. That is also in line with the current let-syntax (especially if we disallow reassignment).

The use case of supplying variables on the command line with them just being appended to the current file could be handled in a special way to keep that support.

The following case is interesting too:

    i = 1;
    module foo() {
        function f() = i;
        echo(f());
        a = f();
        echo(a);
        i = 2;
        echo(f());
        b = f();
        echo(b);
    }
    foo();

Before testing, can you guess what it outputs? Should module calls be interleaved with expression evaluation?
Reply | Threaded
Open this post in threaded view
|

Re: Assignment semantics

kintel
Administrator
Hi Oskar,

I’d really like to clean this up properly. It will break stuff, but if we make a clean break together with other language features, perhaps it would make sense to create a V2 of the scad language.

On May 15, 2014, at 13:40 PM, Oskar <[hidden email]> wrote:

> The following case is interesting too:
>
>    i = 1;
>    module foo() {
>        function f() = i;
>        echo(f());
>        a = f();
>        echo(a);
>        i = 2;
>        echo(f());
>        b = f();
>        echo(b);
>    }
>    foo();
>
> Before testing, can you guess what it outputs? Should module calls be
> interleaved with expression evaluation?
>
I’ll comment on the other stuff later, but in the meantime, consider some similar Javascript code, which is not obvious either, unless you’re into Javascript:

var i = 1;
function foo() {
  function f() { return i; }
  console.log(f());
  var a = f();
  console.log(a);
  var i = 2;
  console.log(f());
  var b = f();
  console.log(b);  
}
foo();

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Assignment semantics

Oskar
kintel wrote
I’d really like to clean this up properly. It will break stuff, but if we make a clean break together with other language features, perhaps it would make sense to create a V2 of the scad language.
Do you have any other changes in mind that wouldn't be backwards compatible? One potential that comes to mind is unification of the function and variable namespaces to avoid having to have a separate syntax for calling closures / function variables (and would simplify stack/contexts and name lookups).

kintel wrote
I’ll comment on the other stuff later, but in the meantime, consider some similar Javascript code, which is not obvious either, unless you’re into Javascript:

var i = 1;
function foo() {
  function f() { return i; }
  console.log(f());
  var a = f();
  console.log(a);
  var i = 2;
  console.log(f());
  var b = f();
  console.log(b);  
}
foo();
That is interesting. I didn’t know the scoping rules of javascript, so I had to look them up. I think the javascript behavior is a bit more logical than the scad example, but ”1 1 2 2” would also have made sense.

Regards,

Oskar
Reply | Threaded
Open this post in threaded view
|

Re: Assignment semantics

kintel
Administrator
On May 15, 2014, at 16:59 PM, Oskar <[hidden email]> wrote:

> Do you have any other changes in mind that wouldn't be backwards compatible?
> One potential that comes to mind is unification of the function and variable
> namespaces to avoid having to have a separate syntax for calling closures /
> function variables (and would simplify stack/contexts and name lookups).
>
I’m looking into implicit unions: https://github.com/openscad/openscad/issues/350
The idea is to a lazy evaluation of implicit unions and allow multiple top-level objects.
As a start, I’m looking at for loops and the top level and the children() module, but I feel that a number of nodes should pass their children upwards (transforms, assign, if-else, color).

This will definitely break existing models.

I think we could also benefit from doing a general workover to make default parameters, parameter names a bit more unified, but the best way forward might be to introduce new keywords for some of those (in the same spirit as the let() expression).

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Assignment semantics

kintel
Administrator
In reply to this post by Oskar
Hi Oskar,

I’m not very happy with the current assignment strategy. This stems from the first version of OpenSCAD being released in a very early phase and it being too late to change once we reached a certain momentum.

Out of your 4 suggestions, I think I agree that sequential assignment makes sense.
The main questions is whether or not to allow reassignment. As long as we do sequential assignment, I don’t think reassignment poses any danger, except for (as you point out) potential silent breakage of existing models.

At some point, I think silent breakage will be hard to avoid if we want to be able to improve OpenSCAD. One way around that is to introduce versioning of OpenSCAD models and have a good way of managing backwards compatibility or upgrading. This needs significant thought.

In terms of supplying variables on the cmd-line, this is an important feature, but the way it works today is a bit of a hack. If we’re already breaking stuff, it could make sense to redefine how to pass parameters to scripts.

..so to go further we need to evaluate whether or not reassignment of immutable variables is important or not.

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Assignment semantics

G. Wade Johnson
On Sat, 17 May 2014 13:56:32 -0400
Marius Kintel <[hidden email]> wrote:

> Hi Oskar,
>
> I’m not very happy with the current assignment strategy. This stems
> from the first version of OpenSCAD being released in a very early
> phase and it being too late to change once we reached a certain
> momentum.
>
> Out of your 4 suggestions, I think I agree that sequential assignment
> makes sense. The main questions is whether or not to allow
> reassignment. As long as we do sequential assignment, I don’t think
> reassignment poses any danger, except for (as you point out)
> potential silent breakage of existing models.
>
> At some point, I think silent breakage will be hard to avoid if we
> want to be able to improve OpenSCAD. One way around that is to
> introduce versioning of OpenSCAD models and have a good way of
> managing backwards compatibility or upgrading. This needs significant
> thought.
>
> In terms of supplying variables on the cmd-line, this is an important
> feature, but the way it works today is a bit of a hack. If we’re
> already breaking stuff, it could make sense to redefine how to pass
> parameters to scripts.
>
> ..so to go further we need to evaluate whether or not reassignment of
> immutable variables is important or not.

For me, I would prefer not to allow reassignment, provided I can supply
parameters on the command line and have a default in the script if not
defined. Without any reassignment, I can imagine the following dance
(in pseudo code):

  actual_foo = defined cmdline_foo ? cmdline_foo : default_value;

If we are considering breaking changes, it might be a good idea to
change the terminology from "immutable variable" to "constant". This
might reduce confusion from new users to OpenSCAD.

Thanks for all of the work that has gone into OpenSCAD. I wouldn't do
nearly as much 3D design without it.

G. Wade
--
In theory, there is no difference between theory and practice. But, in
practice, there is.                   -- Jan L.A. van de Snepscheut
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Assignment semantics

MichaelAtOz
Administrator
When reexamining assignment and discussion immutable v's constants v's reassignment etc, must then introduce scope (which was mentioned above), and if we are talking of breaking things, then there are other areas which need breaking.

I'm doing a bit of reading first and will jump in later with other things.

But one area is use<> and it's scoping and ways of overriding default values. Also how multiple include<> / use<> work together. (further into namespaces etc...)

OpenSCAD Admin - email* me if you need anything, or if I've done something stupid...
* on the Forum, click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain;
to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work.
Obviously inclusion of works of previous authors is not included in the above.
Reply | Threaded
Open this post in threaded view
|

Re: Assignment semantics

kintel
Administrator
On May 17, 2014, at 18:54 PM, MichaelAtOz <[hidden email]> wrote:

> But one area is use<> and it's scoping and ways of overriding default
> values. Also how multiple include<> / use<> work together. (further into
> namespaces etc…)
>
Thanks for reminding me! Namespaces would be a very sought after addition to OpenSCAD, especially in terms of being able to use external libraries without polluting the global namespace.
There was some discussion about this here: https://github.com/openscad/openscad/issues/522

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Assignment semantics

kintel
Administrator
In reply to this post by Oskar
On May 15, 2014, at 16:59 PM, Oskar <[hidden email]> wrote:
>
> Do you have any other changes in mind that wouldn't be backwards compatible?

I started on a wiki page to keep track of this:
https://github.com/openscad/openscad/wiki/File-Format-Versioning

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Assignment semantics

Oskar
kintel wrote
I started on a wiki page to keep track of this:
https://github.com/openscad/openscad/wiki/File-Format-Versioning
I like that suggestion. One of the most important aspects of a versioning system would be how to avoid having to keep maintaining depreciated code and behaviors. Your suggestion to offer to automatically upgrade old syntax seem like an excellent (and very feasible) way do to it.

/Oskar
Reply | Threaded
Open this post in threaded view
|

Re: Assignment semantics

Oskar
In reply to this post by G. Wade Johnson
G. Wade Johnson wrote
On Sat, 17 May 2014 13:56:32 -0400
Marius Kintel <[hidden email]> wrote:

> ..so to go further we need to evaluate whether or not reassignment of
> immutable variables is important or not.

For me, I would prefer not to allow reassignment, provided I can supply
parameters on the command line and have a default in the script if not
defined.
Disallowing reassignments feels like the cleanest solution, but they are quite handy sometimes. Here is an example of a function in my own code where I used reassignments a few times:

// Compute the circumcenter of a triangle on a sphere
function circumcentre(points, triangle) = let(
        p0 = points[triangle[0]],
        p1 = points[triangle[1]],
        p2 = points[triangle[2]],
        n  = cross(p2-p0, p1-p0),
        m2 = 1 / (n*n),
        m  = sqrt(m2),

        radius = asin(.5 * m * norm(p0 - p1) * norm(p1 - p2) * norm(p2 - p0)),
       
        // centre in barycentric coordinates
        a = .5 * m2 * norm_sq((p1 - p2)) * ((p0 - p1) * (p0 - p2)),
        b = .5 * m2 * norm_sq((p0 - p2)) * ((p1 - p0) * (p1 - p2)),
        c = .5 * m2 * norm_sq((p0 - p1)) * ((p2 - p0) * (p2 - p1)),
        center = a*p0 + b*p1 + c*p2,
        center = norm(center) > epsilon ? unit(center) : unit(n),

        behind = distance(plane(points, triangle[0], triangle[1], triangle[2]), center) < 0,
        center = behind ? -center : center,
        radius = behind ? 180 - radius : radius
) [center, radius, behind];

This can of course be rewritten to avoid it. The mechanical rewrite would mean just appending a suffix to each reassignment (and use that in the following code). I.e.:

        center0 = a*p0 + b*p1 + c*p2,
        center1 = norm(center0) > epsilon ? unit(center0) : unit(n),
        behind = distance(plane(points, triangle[0], triangle[1], triangle[2]), center1) < 0,
        center2 = behind ? -center1 : center1,

But that is just what the interpreter would do automatically under the hood with reassignments allowed, and there is always a risk of introducing bugs when doing it manually (as well as making the code a bit harder to read IMO). The best way would probably be to rewrite the logic above altogether, but I don't immediately see a good way to do that. Any thoughts?
Reply | Threaded
Open this post in threaded view
|

Re: Assignment semantics

nophead
There should only be immutable constants as currently the case in the released version. It is far more readable when a symbol has the same value throughout the program, not different values in different places. centre0, centre1, etc is just a lack of clarity. They should have longer names explaining their meaning.


On 19 May 2014 18:46, Oskar <[hidden email]> wrote:
G. Wade Johnson wrote
> On Sat, 17 May 2014 13:56:32 -0400
> Marius Kintel &lt;

> marius@

> &gt; wrote:
>
>> ..so to go further we need to evaluate whether or not reassignment of
>> immutable variables is important or not.
>
> For me, I would prefer not to allow reassignment, provided I can supply
> parameters on the command line and have a default in the script if not
> defined.

Disallowing reassignments feels like the cleanest solution, but they are
quite handy sometimes. Here is an example of a function in my own code where
I used reassignments a few times:

// Compute the circumcenter of a triangle on a sphere
function circumcentre(points, triangle) = let(
        p0 = points[triangle[0]],
        p1 = points[triangle[1]],
        p2 = points[triangle[2]],
        n  = cross(p2-p0, p1-p0),
        m2 = 1 / (n*n),
        m  = sqrt(m2),

        radius = asin(.5 * m * norm(p0 - p1) * norm(p1 - p2) * norm(p2 - p0)),

        // centre in barycentric coordinates
        a = .5 * m2 * norm_sq((p1 - p2)) * ((p0 - p1) * (p0 - p2)),
        b = .5 * m2 * norm_sq((p0 - p2)) * ((p1 - p0) * (p1 - p2)),
        c = .5 * m2 * norm_sq((p0 - p1)) * ((p2 - p0) * (p2 - p1)),
        center = a*p0 + b*p1 + c*p2,
        center = norm(center) > epsilon ? unit(center) : unit(n),

        behind = distance(plane(points, triangle[0], triangle[1], triangle[2]),
center) < 0,
        center = behind ? -center : center,
        radius = behind ? 180 - radius : radius
) [center, radius, behind];

This can of course be rewritten to avoid it. The mechanical rewrite would
mean just appending a suffix to each reassignment (and use that in the
following code). I.e.:

        center0 = a*p0 + b*p1 + c*p2,
        center1 = norm(center0) > epsilon ? unit(center0) : unit(n),
        behind = distance(plane(points, triangle[0], triangle[1], triangle[2]),
center1) < 0,
        center2 = behind ? -center1 : center1,

But that is just what the interpreter would do automatically under the hood
with reassignments allowed, and there is always a risk of introducing bugs
when doing it manually (as well as making the code a bit harder to read
IMO). The best way would probably be to rewrite the logic above altogether,
but I don't immediately see a good way to do that. Any thoughts?




--
View this message in context: http://forum.openscad.org/Assignment-semantics-tp7913p7978.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Assignment semantics

Oskar
nophead wrote
There should only be immutable constants as currently the case in the
released version. It is far more readable when a symbol has the same value
throughout the program, not different values in different places. centre0,
centre1, etc is just a lack of clarity. They should have longer names
explaining their meaning.
I don't disagree. I wanted to see if there was a good case for reassignment, and this was the most compelling I found.
Reply | Threaded
Open this post in threaded view
|

Re: Assignment semantics

G. Wade Johnson
In reply to this post by Oskar
On Mon, 19 May 2014 10:13:46 -0700 (PDT)
Oskar <[hidden email]> wrote:

> kintel wrote
> > I started on a wiki page to keep track of this:
> > https://github.com/openscad/openscad/wiki/File-Format-Versioning
>
> I like that suggestion. One of the most important aspects of a
> versioning system would be how to avoid having to keep maintaining
> depreciated code and behaviors. Your suggestion to offer to
> automatically upgrade old syntax seem like an excellent (and very
> feasible) way do to it.

I think versioning the language is probably a reasonable thing to do.

I've maintained systems that did the automatic upgrade thing. It is not
a big deal at the first version change, after that it tends to get
hairy.

1. If you are dealing with more than one version update, separating the
the update code into a separate script/program (or more than one) is
often a really good idea.

2. How would we want to handle the case of a file with no version
specified?

3. How would incompatible or missing version string be handled in the
command line mode?

I normally write OpenSCAD files in vim and use the tool to view the
output and build STLs at the command line. I can easily see forgetting
the version string.

G. Wade
--
If there's no solution, there's no problem.        -- Rick Hoselton
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Assignment semantics

nophead
In reply to this post by Oskar



On 19 May 2014 22:31, Oskar <[hidden email]> wrote:
nophead wrote
> There should only be immutable constants as currently the case in the
> released version. It is far more readable when a symbol has the same value
> throughout the program, not different values in different places. centre0,
> centre1, etc is just a lack of clarity. They should have longer names
> explaining their meaning.

I don't disagree. I wanted to see if there was a good case for reassignment,
and this was the most compelling I found.


 
Well if you were writing a book or a technical paper would it make sense to use the same variable name for different things on consecutive lines? It's nonsense mathematically, so should not be allowed in computer languages.

Unfortunately a lot of languages allow it so it seems strange to programmers to disallow it. However, it makes the code easier to read, less prone to errors and easier or the compiler to optimise.

I can't see any disadvantage other than it takes a bit more time to think of suitable variable names.


--
View this message in context: http://forum.openscad.org/Assignment-semantics-tp7913p7985.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Assignment semantics

Kenneth Sloan
This is an ancient argument - which has long since advanced past the point of
“what seems obvious to me”.  Any such discussion should acknowledge that there
are two sides to the question - simply assuming that the other side is “ignorant”
or “misguided” is…both ignorant and misguided.

A surprising amount of the confusion comes from the lack of an “assignment arrow”
on an ASR-33 Teletype(™).

It is also a decision which is best to make systematically and consistently
throughout a language.  

There is a place in the world for both kinds of language.  The questions should
be which *type* of language do you want OpenSCAD to be?  What are the
established norms for *that* kind of language?  What are the known points of
confusion (esp. for users primarily trained in the other point of view)?

In my (admittedly limited) experience, the “functional” approach works well
for smaller programs used to define static things.
The “procedural” approach (along with suitable
scoping rules) works well for large-scale,
multi-author projects which describe dynamic processes.
It seems quite common for a new language to start
off as functional, and then slowly become “polluted” with procedural features.
This tends to piss off the original designers, temporarily makes the language
more accessible to procedural programmers…and eventually dooms the language
to obscurity as it becomes less and less principled and “pure” over time.

My personal bias (and most of my experience) is in favor of procedural languages.
Do not assume that this is because I don’t understand, or have no experience with
functional programming.  In my personal opinion, the concepts of “time” and “process" are the ones
that separate “mathematicians” and “programmers”.  [and…hint: neither approach is
more or less “mathematical” or “correct”].

My observation (over a fairly significant period of time) is that new “niche” languages
often begin as functional, and then add procedural features as both the programmer population
and the problem sizes get bigger.

And…(also in my limited experience)…any language defined by committee eventually becomes
both widely used AND wildly inconsistent in its theoretical underpinnings.

My strong preference is to use a mixture of languages.  The implementation phase of my 1977 
PhD work involved using both (very “pure”) LISP and (gasp, the horror!) FORTRAN.  Today, for
solid modeling and shape analysis, I tend to use a mixture of OpenSCAD and Java.  I
use both not because there is anything in one of the languages that can’t (in theory) be
done in the other - but because some things are more convenient and “natural” in one than
in the other.  I’d be happy to use just about *any* language, if it made my life easier.

“The only thing missing from PERL is a lightweight scripting language.”

Is it the fate of OpenSCAD to have “everything except a good CSG modeler”?

Questions to ponder: in what language is OpenSCAD *implemented*?  in what language
is the semantics of OpenSCAD *defined*? (that may be a sore point…)

In my opinion, OpenSCAD discussions could be much improved by paying *some* attention
to what has gone before, and some attention to standard usage and terminology.
We might start with “cube”.


--
Kenneth Sloan
[hidden email]


On May 19, 2014, at 18:55 , nop head <[hidden email]> wrote:




On 19 May 2014 22:31, Oskar <[hidden email]> wrote:
nophead wrote
> There should only be immutable constants as currently the case in the
> released version. It is far more readable when a symbol has the same value
> throughout the program, not different values in different places. centre0,
> centre1, etc is just a lack of clarity. They should have longer names
> explaining their meaning.

I don't disagree. I wanted to see if there was a good case for reassignment,
and this was the most compelling I found.


 
Well if you were writing a book or a technical paper would it make sense to use the same variable name for different things on consecutive lines? It's nonsense mathematically, so should not be allowed in computer languages.

Unfortunately a lot of languages allow it so it seems strange to programmers to disallow it. However, it makes the code easier to read, less prone to errors and easier or the compiler to optimise.

I can't see any disadvantage other than it takes a bit more time to think of suitable variable names.


--
View this message in context: http://forum.openscad.org/Assignment-semantics-tp7913p7985.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Assignment semantics

G. Wade Johnson
On Mon, 19 May 2014 20:08:10 -0500
Kenneth Sloan <[hidden email]> wrote:

> This is an ancient argument - which has long since advanced past the
> point of “what seems obvious to me”.  Any such discussion should
> acknowledge that there are two sides to the question - simply
> assuming that the other side is “ignorant” or “misguided” is…both
> ignorant and misguided.
>
> A surprising amount of the confusion comes from the lack of an
> “assignment arrow” on an ASR-33 Teletype(™).
>
> It is also a decision which is best to make systematically and
> consistently throughout a language.  
>
> There is a place in the world for both kinds of language.  The
> questions should be which *type* of language do you want OpenSCAD to
> be?  What are the established norms for *that* kind of language?
> What are the known points of confusion (esp. for users primarily
> trained in the other point of view)?

To my mind, the biggest "problem" with OpenSCAD's handling of named
values has been calling them "variables". People with a programming
background expect variables to vary.

I haven't found the lack of "real variables" to be an issue in any
design I've made so far.

> In my (admittedly limited) experience, the “functional” approach
> works well for smaller programs used to define static things.

Many in the programming circles that I frequent have been using
functional approaches for low-level code in mostly procedural or object
oriented systems.

My view of OpenSCAD is more declarative than functional. We are mostly
giving a description of a static thing, rather than processing data to
get a result. (Hmmm. That sounded better in my head than it reads.)

> The “procedural” approach (along with suitable
> scoping rules) works well for large-scale,
> multi-author projects which describe dynamic processes.
> It seems quite common for a new language to start
> off as functional, and then slowly become “polluted” with procedural
> features. This tends to piss off the original designers, temporarily

I can't think of an actual functional language that started off as
purely functional. Without some way of generating side-effects (input
and output), pure functional approaches are relatively useless.

> makes the language more accessible to procedural programmers…and
> eventually dooms the language to obscurity as it becomes less and
> less principled and “pure” over time.
>
> My personal bias (and most of my experience) is in favor of
> procedural languages. Do not assume that this is because I don’t
> understand, or have no experience with functional programming.  In my
> personal opinion, the concepts of “time” and “process" are the ones
> that separate “mathematicians” and “programmers”.  [and…hint: neither
> approach is more or less “mathematical” or “correct”].
>
> My observation (over a fairly significant period of time) is that new
> “niche” languages often begin as functional, and then add procedural
> features as both the programmer population and the problem sizes get
> bigger.
>
> And…(also in my limited experience)…any language defined by committee
> eventually becomes both widely used AND wildly inconsistent in its
> theoretical underpinnings.
>
> My strong preference is to use a mixture of languages.  The
> implementation phase of my 1977 PhD work involved using both (very
> “pure”) LISP and (gasp, the horror!) FORTRAN.  Today, for solid
> modeling and shape analysis, I tend to use a mixture of OpenSCAD and
> Java.  I use both not because there is anything in one of the
> languages that can’t (in theory) be done in the other - but because
> some things are more convenient and “natural” in one than in the
> other.  I’d be happy to use just about *any* language, if it made my
> life easier.

Agreed.

> “The only thing missing from PERL is a lightweight scripting
> language.”

Really? Is gratuitous language bashing really helping the discussion?

> Is it the fate of OpenSCAD to have “everything except a good CSG
> modeler”?
>
> Questions to ponder: in what language is OpenSCAD *implemented*?  in
> what language is the semantics of OpenSCAD *defined*? (that may be a
> sore point…)
>
> In my opinion, OpenSCAD discussions could be much improved by paying
> *some* attention to what has gone before, and some attention to
> standard usage and terminology. We might start with “cube”.

Each language I've worked with over the years has had strengths and
weaknesses. One thing that OpenSCAD seems to do pretty well (and others
not so much) is specify what it does not do.

Some of the discussion in this area appears to result from people
asking OpenSCAD to be more like their favorite language. It seems that
hammering out the _intent_ of OpenSCAD, what it will do and what it
won't, is a viable starting point. Since we already have a pretty good
language that does things mostly well, refining the intent might be a
good idea.

G. Wade

> --
> Kenneth Sloan
> [hidden email]
>
>
> On May 19, 2014, at 18:55 , nop head <[hidden email]> wrote:
>
> >
> >
> >
> > On 19 May 2014 22:31, Oskar <[hidden email]> wrote:
> > nophead wrote
> > > There should only be immutable constants as currently the case in
> > > the released version. It is far more readable when a symbol has
> > > the same value throughout the program, not different values in
> > > different places. centre0, centre1, etc is just a lack of
> > > clarity. They should have longer names explaining their meaning.
> >
> > I don't disagree. I wanted to see if there was a good case for
> > reassignment, and this was the most compelling I found.
> >
> >
> >  
> > Well if you were writing a book or a technical paper would it make
> > sense to use the same variable name for different things on
> > consecutive lines? It's nonsense mathematically, so should not be
> > allowed in computer languages.
> >
> > Unfortunately a lot of languages allow it so it seems strange to
> > programmers to disallow it. However, it makes the code easier to
> > read, less prone to errors and easier or the compiler to optimise.
> >
> > I can't see any disadvantage other than it takes a bit more time to
> > think of suitable variable names.
> >
> >
> > --
> > View this message in context:
> > http://forum.openscad.org/Assignment-semantics-tp7913p7985.html
> > Sent from the OpenSCAD mailing list archive at Nabble.com.
> > _______________________________________________ OpenSCAD mailing
> > list [hidden email]
> > http://rocklinux.net/mailman/listinfo/openscad
> > http://openscad.org - https://flattr.com/thing/121566
> >
> > _______________________________________________
> > OpenSCAD mailing list
> > [hidden email]
> > http://rocklinux.net/mailman/listinfo/openscad
> > http://openscad.org - https://flattr.com/thing/121566
>


--
Ever wonder why the SAME PEOPLE make up ALL the conspiracy theories?
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Assignment semantics

Joseph Lenox
In reply to this post by kintel
On 05/19/2014 11:35 AM, Marius Kintel wrote:
> On May 15, 2014, at 16:59 PM, Oskar <[hidden email]> wrote:
>> Do you have any other changes in mind that wouldn't be backwards compatible?
> I started on a wiki page to keep track of this:
> https://github.com/openscad/openscad/wiki/File-Format-Versioning
>
>   -Marius
>
Anyone else here familiar with VHDL or Verilog? There's quite a bit here
similar to OpenSCAD. Probably by design,  but I'm new enough to not know.

I, for one, wouldn't mind basing semantics on how other HDLs do it.
VHDL, specifically, is structured and verbose, with two modes.
Structural, which has an implicit union and is functional,  and
behavioral, which has procedual bits.

Right now, openscad's variables are more like signals.

Perhaps a sane solution is add syntax moving into a procedural mode?

--
--Joseph Lenox, BS, MS
I'm an engineer. I solve problems.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Assignment semantics

kintel
Administrator
In reply to this post by Kenneth Sloan

On May 19, 2014, at 21:08 PM, Kenneth Sloan <[hidden email]> wrote:
>
> Questions to ponder: in what language is OpenSCAD *implemented*?  in what language
> is the semantics of OpenSCAD *defined*? (that may be a sore point…)
>
As OpenSCAD was conceptualized by people with background in C and some Java, it borrowed some ideas from there, including being implemented in C++.
Also, as OpenSCAD started out as a Java-based plugin to an existing modeling tool, the entire idea behind how to structure 3D models was based on a hierarchical _description_ of models.

> In my opinion, OpenSCAD discussions could be much improved by paying *some* attention
> to what has gone before, and some attention to standard usage and terminology.
> We might start with “cube”.
>
OpenSCAD became popular while being in what one could call an "early alpha developer preview”, and we never took the initiative to make a clean break with how things worked back then. I don’t doubt at all that starting something from scratch today, based on existing experiences, would yield a much more coherent result.

About “cube”, I blame SGI for poisoning the geometric namespace, starting with Open Inventor ;)

-Marius
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
tp3
Reply | Threaded
Open this post in threaded view
|

Re: Assignment semantics

tp3
In reply to this post by Kenneth Sloan
Kenneth Sloan wrote
Is it the fate of OpenSCAD to have “everything except a good CSG modeler”?
That it actually the point I'm tossing around in my mind. I wonder if we should put lots of effort into inventing yet another language (with the added problem to have an existing one that can't be changed easily without breaking existing stuff -- I guess we can ask the python people with their v2 -> v3 transition about how that feels).

I wonder if it's possible (and agreeable) to add something like scad-v2 based on some existing language engine. Both would need to coexist for quite some time too but it might not be a lot more problematic than supporting two self-made languages. Main benefit I see is that the focus could go back to the modeling part instead the many problems of a more powerful language interpreter.
-- Torsten
12