discuss@lists.openscad.org

OpenSCAD general discussion Mailing-list

View all threads

"Ignoring unknown variable" issue...

NH
nop head
Sat, Jul 18, 2015 3:14 PM

I don't think the issue is the syntax of the assignment statement. It is
the semantics of x = x +1, which is nonsense mathematically and so should
not appear in a description of geometry, which is what OpenScad is.

On 18 July 2015 at 15:32, jon jon@jonbondy.com wrote:

I agree.  Coming from Modula 2 and Pascal, ":=" for assignment and "=" for
equality seems clear and correct.  The C (and now countless other
languages) convention of "=" meaning assignment and "==" meaning equality
test is popular, but wrong-headed.

I know I will not win this argument.  Just saying.

=========

Alan Cox wrote

I do disagree on the C assign statements however.

     x = 4

is mathematics. It's BCPL (and thus C) that abused it. Some languages at
least had the taste to use :=  ;)

In other words I don't think the use of a = b; is a mistake in OpenSCAD,
or one it can fix. OpenSCAD is right, C is wrong.


OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

I don't think the issue is the syntax of the assignment statement. It is the semantics of x = x +1, which is nonsense mathematically and so should not appear in a description of geometry, which is what OpenScad is. On 18 July 2015 at 15:32, jon <jon@jonbondy.com> wrote: > I agree. Coming from Modula 2 and Pascal, ":=" for assignment and "=" for > equality seems clear and correct. The C (and now countless other > languages) convention of "=" meaning assignment and "==" meaning equality > test is popular, but wrong-headed. > > I know I will not win this argument. Just saying. > > > ========= > > Alan Cox wrote > > > I do disagree on the C assign statements however. > > x = 4 > > is mathematics. It's BCPL (and thus C) that abused it. Some languages at > least had the taste to use := ;) > > In other words I don't think the use of a = b; is a mistake in OpenSCAD, > or one it can fix. OpenSCAD is right, C is wrong. > > > > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >
R
runsun
Sat, Jul 18, 2015 4:30 PM

doug.moen wrote

You can put a script inside of brace brackets. The result is a geometric
object that you can pass as an argument to a module:

 rotate(45) {
    size=10;
    cube(size);
}

I see. It's not just a place holder for data. This is cool.

In OpenSCAD2, the syntax {...} is an expression that returns a geometric
object.
For example, { size=10; cube(size); } is an expression.

You can give this expression a name:

mycube = {
   size=10;
   cube(size);
};

Now 'mycube' is the name of a geometric object.

echo(mycube.size); // ECHO: 10

rotate(45) mycube;

Doug.

I'll bring my idea about this to your other thread about "OpenSCAD2 doc"
(more relevant to the thread topic)


$  Runsun Pan, PhD

$ -- OpenScad_DocTest ( Thingiverse ), faces , Offliner

$ -- hash parameter model: here , here

$ -- Linux Mint 17.1 Rebecca x64  + OpenSCAD 2015.03.15/2015.04.01.nightly

--
View this message in context: http://forum.openscad.org/Ignoring-unknown-variable-issue-tp13156p13231.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

doug.moen wrote > You can put a script inside of brace brackets. The result is a geometric > object that you can pass as an argument to a module: > > rotate(45) { > size=10; > cube(size); > } I see. It's not just a place holder for data. This is cool. > > In OpenSCAD2, the syntax {...} is an expression that returns a geometric > object. > For example, { size=10; cube(size); } is an expression. > > You can give this expression a name: > > mycube = { > size=10; > cube(size); > }; > > Now 'mycube' is the name of a geometric object. > > echo(mycube.size); // ECHO: 10 > > rotate(45) mycube; > > Doug. I'll bring my idea about this to your other thread about "OpenSCAD2 doc" (more relevant to the thread topic) ----- $ Runsun Pan, PhD $ -- OpenScad_DocTest ( Thingiverse ), faces , Offliner $ -- hash parameter model: here , here $ -- Linux Mint 17.1 Rebecca x64 + OpenSCAD 2015.03.15/2015.04.01.nightly -- View this message in context: http://forum.openscad.org/Ignoring-unknown-variable-issue-tp13156p13231.html Sent from the OpenSCAD mailing list archive at Nabble.com.
R
runsun
Mon, Jul 27, 2015 2:43 PM

nophead wrote

Perhaps it is more correct to say the "variables" (actually named
constants) only have one value throughout their lexical scope and that is
the value assigned last. Yes the compiler could work out the value of b
but
the point is it isn't in scope at the first point a is defined, so using
it
breaks the scope rules.

I'd like to provide an alternative way of seeing this. Note that this is
the way I see it (to make it more easily understood), not an
understanding of how it actually operates behind, which I have no
knowledge about.

openscad scans thru codes twice. The first scan checks syntax
and eliminates repeated var assignments. So the code:

 a = 1; 
 b = 2; 
 a = b;  

becomes this after the first scan:

 a = b; 
 b = 2; 
 //a = b; <== this line is to be ignored by the 2nd scan. 

The 2nd scad actually runs the code, which gives up a
warning that variable "b" is unknown when it sees a=b
before b is assigned.

With this in mind, whenever you see :

WARNING: Ignoring unknown variable X

It could be one of the following two conditions :

  1. X is not defined in any place prior to that line,
    means the issue is on X;

  2. You try to assign X to something:

    A = X

    but A is already defined prior to that line.

    In this case, the issue is on A, not on X.

So besides checking if X is pre-defined, remember to also
check if A is pre-defined.


$  Runsun Pan, PhD

$ -- libs: doctest , faces ( git ), offliner ( git );

ideas: hash ( 1 , 2 ), sweep

$ -- Linux Mint 17.1 Rebecca x64  + OpenSCAD 2015.03.15/2015.04.01.nightly

--
View this message in context: http://forum.openscad.org/Ignoring-unknown-variable-issue-tp13156p13321.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

nophead wrote > Perhaps it is more correct to say the "variables" (actually named > constants) only have one value throughout their lexical scope and that is > the value assigned last. Yes the compiler could work out the value of b > but > the point is it isn't in scope at the first point a is defined, so using > it > breaks the scope rules. I'd like to provide an alternative way of seeing this. Note that this is the way I see it (to make it more easily understood), not an understanding of how it actually operates behind, which I have no knowledge about. openscad scans thru codes twice. The first scan checks syntax and eliminates repeated var assignments. So the code: a = 1; b = 2; a = b; becomes this after the first scan: a = b; b = 2; //a = b; <== this line is to be ignored by the 2nd scan. The 2nd scad actually runs the code, which gives up a warning that variable "b" is unknown when it sees a=b before b is assigned. With this in mind, whenever you see : WARNING: Ignoring unknown variable X It could be one of the following two conditions : 1) X is not defined in any place prior to that line, means the issue is on X; 2) You try to assign X to something: A = X but A is already defined prior to that line. In this case, *the issue is on A, not on X.* So besides checking if X is pre-defined, remember to also check if A is pre-defined. ----- $ Runsun Pan, PhD $ -- libs: doctest , faces ( git ), offliner ( git ); ideas: hash ( 1 , 2 ), sweep $ -- Linux Mint 17.1 Rebecca x64 + OpenSCAD 2015.03.15/2015.04.01.nightly -- View this message in context: http://forum.openscad.org/Ignoring-unknown-variable-issue-tp13156p13321.html Sent from the OpenSCAD mailing list archive at Nabble.com.