OpenSCAD2 currently uses the following syntax for this:

stuff = { name1 = 10; name2 = 20; name3 = [12,22]; };

and stuff.name1 returns 10.

https://github.com/doug-moen/openscad2/blob/master/rfc/Objects.md

On 15 July 2015 at 09:42, Neon22 mschafer@wireframe.biz wrote:

doug.moen wrote

This is my favorite !!!

Except that the last ";" could be omitted:

{ name1=10, name2=20, name3=[12,22] }

i.e., instead of having a statement terminator ";", using "," as a separator
like the following cases:

1. for (x=arr1, y = arr2 )
2. let ( name1=10, name2=20 ...)
3. [2,3,4]

After all, its purpose is to separate items.

Also, using ":" is much easier to type than using "=", but this is probably
just me.

$  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-tp13156p13218.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

I think other people in this thread have explained the behaviour, this is
more of a comment.

This behaviour has been discussed on the forum before, and it
surprises/confuses everyone who encounters it for the first time. I
consider it a bug in the language design, and it will be fixed in
OpenSCAD2. There is no reason that a simple language for geometric
modelling should require such a hard to explain, weird and counterintuitive
design for "variables", which are really just model parameters.

The wiki contains language about "variables being evaluated at compile
time", but I think this is a confabulation. I can't find any such compile
time/run time distinction in the actual implementation, and in any case I
have had to come up with a different mental model to correctly understand
how OpenSCAD works. What Nop Head said is accurate.

A more general critique of OpenSCAD, in its current incarnation, is that it
is intended to be a stateless, purely declarative language. But the syntax
is C-like, parameter definitions like "radius = diameter/2;" look like C
assignment statements, and the documentation plays into this confusion by
calling them variables and assignment statements. You can even "assign" the
same variable twice in the same scope, and it almost seems to work, but
then you get weird results that don't fit the model of an imperative
programming language. It's a recipe for confusion.

I would like to evolve the language away from this situation, so that the
documentation and the syntax don't send mixed messages about whether
OpenSCAD is a declarative language, or an imperative language. One of the
goals of OpenSCAD2 is to achieve this without breaking existing scripts
(backward compatibility).

At the documentation level, I would like to describe "width = 10;" as a
definition of 'width', not as an assignment statement. Likewise, 'function
f(x)=x+1;' is a definition of 'f': slightly different syntax, but still
just a definition. And 'module box(x,y,z) cube([x,y,z]);' is a definition
of 'box'. I want the definitions of 'width', 'f' and 'box' to have the same
status, and obey the same rules. This is important in light of another
goal, which is to elevate functions and modules to the status of first
class values, so you can pass them as parameters, return them as results,
store them in lists, and so on.

At the language level, I think that duplicate definitions should be
reported as an error. That is, if you define the same numeric parameter (or
the same function) twice with the same name in the same scope, within the
same source file, you should get an error. So Amadee's original test cases
would produce an error message:

 a = 1;
 b = 2;
 b = a;  // Error: duplicate definition of 'b'

This means that the include statement needs to be implemented differently.
The only reason we support code like the above script at all, is really a
side effect of the semantics of 'include'. When you include another script,

include <myscript.scad>

the semantics are that the definitions in 'myscript.scad' override earlier
definitions in the parent script, and later definitions in the parent
script override definitions imported from 'myscript'. We can implement
these override semantics directly.

Untangling these issues, and coming up with simple, consistent and
unsurprising rules for definitions and include statements, is part of what
I'm trying to accomplish in the OpenSCAD2 language definition.

Doug Moen.

On 15 July 2015 at 05:07, Amedee openscad@e.bulles.eu wrote:

doug.moen wrote

Is there any point of not starting that way with wiki now?

I have been tempted to remove 'variable' from the wiki, but didn't want to
step on toes.

Don't forget the cmd line -D var=val issue. It apparently is the main reason
re 'reassigns' according to MK.

For include<> something like the following is something I'd like.

include <myscript.scad> as ms
ms.mysize=10; // make it bigger

Allowance for public/private definitions in the include'ed scad would be a
bonus.

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. This work is published globally via the internet. :) Inclusion of works of previous authors is not included in the above.

The TPP is no simple “trade agreement.”  Fight it! http://www.ourfairdeal.org/

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

The syntax is what it is, because of the way that OpenSCAD2 is a backward
compatible extension of OpenSCAD.

This is an OpenSCAD script:
size=10;
cube(size);

You can type this script into an OpenSCAD source code window, and you will
see a cube.

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);

}

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.

On 17 July 2015 at 22:03, runsun runsun@gmail.com wrote:

MichaelAtOz said:

Is there any point of not starting that way with wiki now?

I have been tempted to remove 'variable' from the wiki, but didn't want to
step on toes.

I agree with you. I first had these thoughts over a year ago. At that time,
I did not want to change the wiki, because I had no idea of how variables
actually worked. Anything I could have written back then would have been
misleading and incorrect. It has taken me a long time, much reading of
forum posts, and a lot of experimentation, to get to the point where I
actually understand what is going on.

On 17 July 2015 at 23:12, MichaelAtOz oz.at.michael@gmail.com wrote:

assign() is deeply unfortunate - something like

with(x=14) {
	blah
}

would have worked better.

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.

I agree entirely with your description of the problem and proposal. Once
you've got clean groups I think the problem (for me at least) with
include goes away, as I can cleanly define a set of parameters as a
function or object and pass them to the method that generates my thing.

Alan