I think, if a list of definitions was available, we would find a few
anomalies. For example [] to indicate a list or vectors. Is [] used
elsewhere? Then there is a dot notation for the first three values. Why?
Other than saving a key stroke, what is the purpose? And, does vector in
openscad mean more than a vector elsewhere, like a cube in openscad is
not a cube in the outside world. Yes, and, I think therein lies a
fundamental problem. New concepts/notations can be introduced, and later
on there is too much complexity and broken rules in what is a fairly
succinct language.
However, if using a dot notation, then I would hope it would be in a
very broad sense, applied to modules within include files, down to
subset's of vectors, (not just the first three). However, instead of
adding bells and whistles, I would prefer more emphasis on improving
what is already there, error reporting/highlighting, etc. I realise that
it is all dependant on volunteer work, so I'm grateful for whatever happens.
Best wishes,
Ray
On 05/04/2021 16:29, NateTG wrote:
mondo wrote
On 05/04/2021 13:43, NateTG wrote:
How well does what you proposed fit with the existing OpenSCAD
syntax?
Is there a 'formal definition' of the syntax anywhere, or has it just
evolved, bit's added as needed?
I'm not aware of any formal design documents. I looked through the
usual documentation a bit to see what the restrictions on variable
identifiers are at ( http://www.openscad.org/documentation.html
http://www.openscad.org/documentation.html) as part of thinking
about this question and didn't come up with anything.
In another sense, the language grammar is formally defined in the
src/lexer.l and src/parser.y files. So, for example, it looks like
identifiers follow the regexp: $"?[a-zA-Z0-9_]+ based on line 256 of
lexer.l. I'm not sophisticated enough to figure out where the ".x"
stuff is in there.
Sent from the OpenSCAD mailing list archive
http://forum.openscad.org/ at Nabble.com.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Here’s the latest revision of my dictionaries proposal, which includes provisions for dot notation,
// Dictionaries proposal, v3.
// Dictionary declaration.
a = "fee"; b = "fie";
dict1 = {
"foo": 23, // KEY : VALUE
"bar": 77, // String key.
undef: 34, // undef key.
false: a, // Boolean key.
99 : 34, // Numeric key.
56 : "AZ", // Value can be any type.
"bar": 65, // Overwrites previous "bar" key entry.
.qux : 29, // Key literal syntax. Same as "qux"
str("c","a","t") : b // Expressions usable for keys or values.
a>b?a:b : a>b?5:8 // If you have a '?' then the next ':' is part of the ternary expression,
// not a separator. This should always be unambiguous. If not, use parens.
.func = function(self,a,b) self.foo*(a+b)} // Pseudo OOP?
};
// Dictionary comprehension.
dict2 = {
for (i=[0:100])
if(i%2==0) // if
works as expected.
each { // each
will expand sub-dictionaries, but only in a dictionary comprehension
i:i5, // Using each
on a dictionary in a list comprehension expands into [key,val] items.
i+0.5:i5+1
}
};
// Extending/merging dictionaries. Later duplicated keys overwrite previous ones.
// Lists merge into dictionaries using numeric positions as keys.
dict3 = concat(dict1, dict2, {"flee":0});
// Getting dictionary values.
w = dict3["bar"];
x = dict3.baz; // Same as dict3["baz"]. Lets you make structures.
u = dict3.func(dict3, 3, 8); // Calling a function literal pseudo-method.
y = dict3[a];
z = dict3["fit"]; // Returns undef for nonexistent keys.
// Iterating a dictionary. Iterate keys in original declared order?
for (kv = dict3) {
echo(key=kv[0], val=kv[1]);
}
// If we ever have mutable dictionaries, then you can set items like:
dict3.foo = 17; // Key literal syntax
dict3["bar"] = 12;
// Otherwise with immutable dictionaries, we end up doing
dict4 = concat(dict3, {"foo":17});
dict5 = {each dict4, .bar:12};
On Apr 5, 2021, at 8:29 AM, NateTG nate-openscadforum@pedantic.org wrote:
mondo wrote
On 05/04/2021 13:43, NateTG wrote:
How well does what you proposed fit with the existing OpenSCAD syntax?
Is there a 'formal definition' of the syntax anywhere, or has it just
evolved, bit's added as needed?
I'm not aware of any formal design documents. I looked through the usual documentation a bit to see what the restrictions on variable identifiers are at ( http://www.openscad.org/documentation.html http://www.openscad.org/documentation.html) as part of thinking about this question and didn't come up with anything.
In another sense, the language grammar is formally defined in the src/lexer.l and src/parser.y files. So, for example, it looks like identifiers follow the regexp: $"?[a-zA-Z0-9_]+ based on line 256 of lexer.l. I'm not sophisticated enough to figure out where the ".x" stuff is in there.
Sent from the OpenSCAD mailing list archive http://forum.openscad.org/ at Nabble.com.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
On 4/5/2021 11:04 AM, Ray West wrote:
For example [] to indicate a list or vectors. Is [] used elsewhere?
Ranges.
Then there is a dot notation for the first three values. Why? Other
than saving a key stroke, what is the purpose?
I think it's to make the semantics clearer. "foo.x" more clearly refers
to the X coordinate than "foo[0]" does.
That notation is currently special cased for x/y/z and begin/step/end
for ranges. There's some discussion of extending it to be more
general-purpose. I'm experimenting with it to support rich return
values from my "text metrics" work.
And, does vector in openscad mean more than a vector elsewhere,
It maps pretty well to a list/array/vector in languages like Python and
JavaScript, in that it's an ordered and indexed list of values, where
each value can be any of the data types.
New concepts/notations can be introduced, and later on there is too
much complexity and broken rules in what is a fairly succinct language.
And that's why the core developers are rightly very careful about what
they add.
"bar": 65, // Overwrites previous "bar" key entry.
// Iterating a dictionary. Iterate keys in original declared order?
for (kv = dict3) {
echo(key=kv[0], val=kv[1]);
Re declared order, does "bar":65 overwrite "bar" in position 2, or does the position 2 get removed and "bar":65 added to the end?
From: Revar Desmera [mailto:revarbat@gmail.com]
Sent: Tue, 6 Apr 2021 07:39
To: OpenSCAD general discussion
Subject: [OpenSCAD] Re: OO patterns in OpenSCAD
Here’s the latest revision of my dictionaries proposal, which includes provisions for dot notation,
// Dictionaries proposal, v3.
// Dictionary declaration.
a = "fee"; b = "fie";
dict1 = {
"foo": 23, // KEY : VALUE
"bar": 77, // String key.
undef: 34, // undef key.
false: a, // Boolean key.
99 : 34, // Numeric key.
56 : "AZ", // Value can be any type.
"bar": 65, // Overwrites previous "bar" key entry.
.qux : 29, // Key literal syntax. Same as "qux"
str("c","a","t") : b // Expressions usable for keys or values.
a>b?a:b : a>b?5:8 // If you have a '?' then the next ':' is part of the ternary expression,
// not a separator. This should always be unambiguous. If not, use parens.
.func = function(self,a,b) self.foo*(a+b)} // Pseudo OOP?
};
// Dictionary comprehension.
dict2 = {
for (i=[0:100])
if(i%2==0) // `if` works as expected.
each { // `each` will expand sub-dictionaries, but only in a dictionary comprehension
i:i*5, // Using `each` on a dictionary in a list comprehension expands into [key,val] items.
i+0.5:i*5+1
}
};
// Extending/merging dictionaries. Later duplicated keys overwrite previous ones.
// Lists merge into dictionaries using numeric positions as keys.
dict3 = concat(dict1, dict2, {"flee":0});
// Getting dictionary values.
w = dict3["bar"];
x = dict3.baz; // Same as dict3["baz"]. Lets you make structures.
u = dict3.func(dict3, 3, 8); // Calling a function literal pseudo-method.
y = dict3[a];
z = dict3["fit"]; // Returns undef for nonexistent keys.
// Iterating a dictionary. Iterate keys in original declared order?
for (kv = dict3) {
echo(key=kv[0], val=kv[1]);
}
// If we ever have mutable dictionaries, then you can set items like:
dict3.foo = 17; // Key literal syntax
dict3["bar"] = 12;
// Otherwise with immutable dictionaries, we end up doing
dict4 = concat(dict3, {"foo":17});
dict5 = {each dict4, .bar:12};
On Apr 5, 2021, at 8:29 AM, NateTG nate-openscadforum@pedantic.org wrote:
mondo wrote
On 05/04/2021 13:43, NateTG wrote:
How well does what you proposed fit with the existing OpenSCAD syntax?
Is there a 'formal definition' of the syntax anywhere, or has it just
evolved, bit's added as needed?
I'm not aware of any formal design documents. I looked through the usual documentation a bit to see what the restrictions on variable identifiers are at ( http://www.openscad.org/documentation.html) as part of thinking about this question and didn't come up with anything.
In another sense, the language grammar is formally defined in the src/lexer.l and src/parser.y files. So, for example, it looks like identifiers follow the regexp: $"?[a-zA-Z0-9_]+ based on line 256 of lexer.l. I'm not sophisticated enough to figure out where the ".x" stuff is in there.
Sent from the OpenSCAD mailing http://forum.openscad.org/ list archive at Nabble.com.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
--
This email has been checked for viruses by AVG.
https://www.avg.com
As yet dictionary key order is undefined in this spec. It’s viable to make key order the same as add order, or just hash value order.
On Apr 5, 2021, at 4:12 PM, MichaelAtOz oz.at.michael@gmail.com wrote:
"bar": 65, // Overwrites previous "bar" key entry.
// Iterating a dictionary. Iterate keys in original declared order?
for (kv = dict3) {
echo(key=kv[0], val=kv[1]);
Re declared order, does "bar":65 overwrite "bar" in position 2, or does the position 2 get removed and "bar":65 added to the end?
From: Revar Desmera [mailto:revarbat@gmail.com]
Sent: Tue, 6 Apr 2021 07:39
To: OpenSCAD general discussion
Subject: [OpenSCAD] Re: OO patterns in OpenSCAD
Here’s the latest revision of my dictionaries proposal, which includes provisions for dot notation,
// Dictionaries proposal, v3.
// Dictionary declaration.
a = "fee"; b = "fie";
dict1 = {
"foo": 23, // KEY : VALUE
"bar": 77, // String key.
undef: 34, // undef key.
false: a, // Boolean key.
99 : 34, // Numeric key.
56 : "AZ", // Value can be any type.
"bar": 65, // Overwrites previous "bar" key entry.
.qux : 29, // Key literal syntax. Same as "qux"
str("c","a","t") : b // Expressions usable for keys or values.
a>b?a:b : a>b?5:8 // If you have a '?' then the next ':' is part of the ternary expression,
// not a separator. This should always be unambiguous. If not, use parens.
.func = function(self,a,b) self.foo*(a+b)} // Pseudo OOP?
};
// Dictionary comprehension.
dict2 = {
for (i=[0:100])
if(i%2==0) // if
works as expected.
each { // each
will expand sub-dictionaries, but only in a dictionary comprehension
i:i5, // Using each
on a dictionary in a list comprehension expands into [key,val] items.
i+0.5:i5+1
}
};
// Extending/merging dictionaries. Later duplicated keys overwrite previous ones.
// Lists merge into dictionaries using numeric positions as keys.
dict3 = concat(dict1, dict2, {"flee":0});
// Getting dictionary values.
w = dict3["bar"];
x = dict3.baz; // Same as dict3["baz"]. Lets you make structures.
u = dict3.func(dict3, 3, 8); // Calling a function literal pseudo-method.
y = dict3[a];
z = dict3["fit"]; // Returns undef for nonexistent keys.
// Iterating a dictionary. Iterate keys in original declared order?
for (kv = dict3) {
echo(key=kv[0], val=kv[1]);
}
// If we ever have mutable dictionaries, then you can set items like:
dict3.foo = 17; // Key literal syntax
dict3["bar"] = 12;
// Otherwise with immutable dictionaries, we end up doing
dict4 = concat(dict3, {"foo":17});
dict5 = {each dict4, .bar:12};
On Apr 5, 2021, at 8:29 AM, NateTG <nate-openscadforum@pedantic.org mailto:nate-openscadforum@pedantic.org> wrote:
mondo wrote
On 05/04/2021 13:43, NateTG wrote:
How well does what you proposed fit with the existing OpenSCAD syntax?
Is there a 'formal definition' of the syntax anywhere, or has it just
evolved, bit's added as needed?
I'm not aware of any formal design documents. I looked through the usual documentation a bit to see what the restrictions on variable identifiers are at ( http://www.openscad.org/documentation.html http://www.openscad.org/documentation.html) as part of thinking about this question and didn't come up with anything.
In another sense, the language grammar is formally defined in the src/lexer.l and src/parser.y files. So, for example, it looks like identifiers follow the regexp: $"?[a-zA-Z0-9_]+ based on line 256 of lexer.l. I'm not sophisticated enough to figure out where the ".x" stuff is in there.
Sent from the OpenSCAD mailing list archive http://forum.openscad.org/ at Nabble.com http://nabble.com/.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org mailto: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 x-msg://5/#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org mailto:discuss-leave@lists.openscad.org
You can sort to hash value order, but you can't recreate original add order, so the later would probably be more useful.
From: Revar Desmera [mailto:revarbat@gmail.com]
Sent: Tue, 6 Apr 2021 10:01
To: OpenSCAD general discussion
Subject: [OpenSCAD] Re: OO patterns in OpenSCAD
As yet dictionary key order is undefined in this spec. It’s viable to make key order the same as add order, or just hash value order.
On Apr 5, 2021, at 4:12 PM, MichaelAtOz oz.at.michael@gmail.com wrote:
"bar": 65, // Overwrites previous "bar" key entry.
// Iterating a dictionary. Iterate keys in original declared order?
for (kv = dict3) {
echo(key=kv[0], val=kv[1]);
Re declared order, does "bar":65 overwrite "bar" in position 2, or does the position 2 get removed and "bar":65 added to the end?
From: Revar Desmera [mailto:revarbat@gmail.com]
Sent: Tue, 6 Apr 2021 07:39
To: OpenSCAD general discussion
Subject: [OpenSCAD] Re: OO patterns in OpenSCAD
Here’s the latest revision of my dictionaries proposal, which includes provisions for dot notation,
// Dictionaries proposal, v3.
// Dictionary declaration.
a = "fee"; b = "fie";
dict1 = {
"foo": 23, // KEY : VALUE
"bar": 77, // String key.
undef: 34, // undef key.
false: a, // Boolean key.
99 : 34, // Numeric key.
56 : "AZ", // Value can be any type.
"bar": 65, // Overwrites previous "bar" key entry.
.qux : 29, // Key literal syntax. Same as "qux"
str("c","a","t") : b // Expressions usable for keys or values.
a>b?a:b : a>b?5:8 // If you have a '?' then the next ':' is part of the ternary expression,
// not a separator. This should always be unambiguous. If not, use parens.
.func = function(self,a,b) self.foo*(a+b)} // Pseudo OOP?
};
// Dictionary comprehension.
dict2 = {
for (i=[0:100])
if(i%2==0) // `if` works as expected.
each { // `each` will expand sub-dictionaries, but only in a dictionary comprehension
i:i*5, // Using `each` on a dictionary in a list comprehension expands into [key,val] items.
i+0.5:i*5+1
}
};
// Extending/merging dictionaries. Later duplicated keys overwrite previous ones.
// Lists merge into dictionaries using numeric positions as keys.
dict3 = concat(dict1, dict2, {"flee":0});
// Getting dictionary values.
w = dict3["bar"];
x = dict3.baz; // Same as dict3["baz"]. Lets you make structures.
u = dict3.func(dict3, 3, 8); // Calling a function literal pseudo-method.
y = dict3[a];
z = dict3["fit"]; // Returns undef for nonexistent keys.
// Iterating a dictionary. Iterate keys in original declared order?
for (kv = dict3) {
echo(key=kv[0], val=kv[1]);
}
// If we ever have mutable dictionaries, then you can set items like:
dict3.foo = 17; // Key literal syntax
dict3["bar"] = 12;
// Otherwise with immutable dictionaries, we end up doing
dict4 = concat(dict3, {"foo":17});
dict5 = {each dict4, .bar:12};
On Apr 5, 2021, at 8:29 AM, NateTG nate-openscadforum@pedantic.org wrote:
mondo wrote
On 05/04/2021 13:43, NateTG wrote:
How well does what you proposed fit with the existing OpenSCAD syntax?
Is there a 'formal definition' of the syntax anywhere, or has it just
evolved, bit's added as needed?
I'm not aware of any formal design documents. I looked through the usual documentation a bit to see what the restrictions on variable identifiers are at ( http://www.openscad.org/documentation.html) as part of thinking about this question and didn't come up with anything.
In another sense, the language grammar is formally defined in the src/lexer.l and src/parser.y files. So, for example, it looks like identifiers follow the regexp: $"?[a-zA-Z0-9_]+ based on line 256 of lexer.l. I'm not sophisticated enough to figure out where the ".x" stuff is in there.
Sent from the OpenSCAD mailing list archive http://forum.openscad.org/ at Nabble.com http://nabble.com/ .
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Virus-free. http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient www.avg.com
x-msg://5/#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2
OpenSCAD mailing list
To unsubscribe send an email to mailto:discuss-leave@lists.openscad.org discuss-leave@lists.openscad.org
--
This email has been checked for viruses by AVG.
https://www.avg.com
RevarBat wrote
As yet dictionary key order is undefined in this spec. It’s viable to
make key order the same as add order, or just hash value order.
I'm certainly used to "if you care about the order use a list" thinking.
It's probably a good idea for there to be consistent behavior, but I'm not
sure having people rely on it is a good thing to encourage.
I can certainly see first beats the second, second beats the first, and
assert(false) as desired behaviors for key collision, and I don't think
there's a perfect solution for that. I can even see some utility in
retaining multiple (key,value) pairs for a single given key.
It seems like we should expect dict["key"] to evaluate to undef for unset
values, which leads to the question whether there should be a difference
between setting a value to undef and not setting the value in the first
place.
--
Sent from: http://forum.openscad.org/
the question whether there should be a difference between setting a value to undef and not setting the value in the first place.
Perhaps NAN is unfound, thus undef is the returned matched found value?
From: NateTG [mailto:nate-openscadforum@pedantic.org]
Sent: Tue, 6 Apr 2021 22:46
To: discuss@lists.openscad.org
Subject: [OpenSCAD] Re: OO patterns in OpenSCAD
RevarBat wrote
As yet dictionary key order is undefined in this spec. It’s viable to make key order the same as add order, or just hash value order.
I'm certainly used to "if you care about the order use a list" thinking. It's probably a good idea for there to be consistent behavior, but I'm not sure having people rely on it is a good thing to encourage.
I can certainly see first beats the second, second beats the first, and assert(false) as desired behaviors for key collision, and I don't think there's a perfect solution for that. I can even see some utility in retaining multiple (key,value) pairs for a single given key.
It seems like we should expect dict["key"] to evaluate to undef for unset values, which leads to the question whether there should be a difference between setting a value to undef and not setting the value in the first place.
Sent from the OpenSCAD mailing http://forum.openscad.org/ list archive at Nabble.com.
--
This email has been checked for viruses by AVG.
https://www.avg.com
Perhaps NAN is unfound, thus undef is the returned matched found value?
That seems like it's just changing the question from "what happens if a
value gets set to undef?" to "what happens if a value gets set to NaN?" Am
I missing something?
--
Sent from: http://forum.openscad.org/
On 4/5/2021 8:29 AM, NateTG wrote:
In another sense, the language grammar is formally defined in the
src/lexer.l and src/parser.y files. So, for example, it looks like
identifiers follow the regexp: $"?[a-zA-Z0-9_]+ based on line 256 of
lexer.l. I'm not sophisticated enough to figure out where the ".x"
stuff is in there.
It's in parser.y at line 473:
| call '.' TOK_ID
where a "call" is a constant, variable, array, range, function call,
array reference, or parenthesized expression.