On Sat, Aug 08, 2020 at 12:42:06PM +0100, nop head wrote:

Warning, error, yes, that would seem appropriate to me.

Or a change of "the rules".

The first unnamed parameter goes to the first parameter that is not
already specified.

Or: If there is a named parameter, but if unnamed, that would've
assigned to the same parameter, count it as unnamed. Or said in
another way: If the name is redundant, count as an unnamed parameter.

IMHO it is stiffling for the language if bad decisions from the past
need to be kept intact.

Maybe the compatibility guys should get their way with a
$scad_version=1; default but when set to 2, then some of these
historical bugs can be fixed....

Roger. 

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

It is not a bug, it is how the language operates.
I don't mean offence, but just because you don't know the language, doesn't mean everyone and all
past programs must change.

--
This email has been checked for viruses by AVG.
https://www.avg.com

I expect the Python team has put a lot more thought into it and made it a
syntax error because it is error prone and confusing to put named arguments
before unnamed ones. OpenSCAD should probably add a warning or at least
warn when an argument is assigned twice.

On Sun, 9 Aug 2020 at 11:32, OzAtMichael oz.at.michael@gmail.com wrote:

On 09.08.20 13:01, nop head wrote:

That sounds like a good idea.

I still want to point out the irony of that thread, starting
with title "Useless warning" where the warning actually did
point out a bug in the original code and resulting in the
request for yet more warnings to be added.

To also put some positive notes into this thread, thanks
Nophead for the helpful and detailed answers. I'm sure it's
not just me appreciating that.

Anyway, there's also some work going on in scope of this
years GSoC which will bring an additional view for warnings
and errors.
See https://github.com/openscad/openscad/issues/3388 for
a screenshot of the initial prototype. This is supposed to
not just bring a new view but also extend the infrastructure
to group warnings by some topic and even ultimately support
for them to be enabled/disabled.

ciao,
Torsten.

On 8/9/2020 12:08 AM, nop head wrote:

In 2019.05, it warns but uses the old behavior.  Do the newer builds
switch behavior?

On Sun, Aug 09, 2020 at 08:31:05PM +1000, OzAtMichael wrote:

Languages need to be used by people. People expect certain things. Maybe
because they know other languages, maybe because of a generic expectation
of how things should work.

Now with
for (i=[5:2])
there is some real functionality: you can iterate from high to low, so
it is understandable that the language has a feature like this.

for (variable = [start : end ]  )

to be a shorthand for:
for (variable = [start : 1 : end ] )

i.e. the stepsize defaults to 1. However in openscad that is not true:
The compiler will decide when the end is lower than start that the
default for the stepsize can be -1 too! That is such unexpected
feature of the language that it generates a warning: if you really
want this specify a -1 step.

With the positional arguments overwriting named arguments specified
earlier: I can't see a normal use for that. Sure you can think up a
convoluted example where you can make use of the feature, but I don't
see any serious use for this.

I would say a warning is just as warranted as in the for loop
boundaries case.

Just to make sure that we're on the same page: I called that warning
"useless" because it didn't include teh line number of my program where
it found the problem. Should be an easy fix.

Roger. 

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

On 8/9/2020 11:46 AM, Rogier Wolff wrote:

It doesn't set the default stepsize to -1.  It swaps the start and end. 
This is from a development build from December:

for (i=[5:2]) echo(i);

DEPRECATED: Using ranges of the form [begin:end] with begin value
greater than the end value is deprecated, in file loops.scad, line 1 

ECHO: 2

ECHO: 3

ECHO: 4

ECHO: 5

It almost doesn't matter.  Other than through "side effects" like echo()
and errors, I don't immediately know how to tell what order OpenSCAD
modules execute in, and thus what order its loops execute in.  As long
as it hits all of the expected values, it could execute them in random
order and the results would be the same.  How's that for "strange
language behavior"?

Note:  I'm not saying that this is good, or bad... just
interesting.  OpenSCAD is not a general-purpose language.  It's
about producing 3D models, and based on that and some of its
architectural decisions you get some unobvious effects.  Some of
that is actively good:  because loop iterations are defined to be
totally independent of one another, they could all be executed and
rendered in parallel.  (OpenSCAD doesn't do that, but it could.)

Note that development builds have the file-and-line information that
you're looking for.