[OpenSCAD] Polygon using relative points rather than absolute?

wolf wv99999 at gmail.com
Thu Jun 2 03:59:28 EDT 2016


With "https://github.com/openscad/openscad/wiki/Mutable-Variables" doug.moen
has written a specification for imperative extensions to the
OpenSCADlanguage that in version 2.0 is full of design bugs. So are the
comments written so far.

Before I deal with them, remember that the lowest level of computer language
is assembler. Within assembler, you are permitted to MOV (write, in English)
a value from one location to another (e.g. from a register onto the stack).
If that MOV went to the location it was supposed to go, great. But if it
went somewhere else, you have a BUG! If you use a compiler as intermediate
between your program and assembler, you have a good chance of catching it
before the bug does irreparable damage, and your program fails. In catching
a bug, a functional language has an advantage over an imperative language,
since the compiler knows (almost) everything about the programmer's
intentions.

A Haskel fan has this to write
(http://www.haskellforall.com/2012/01/haskell-for-c-programmers-for-loops.html)
"Haskell is an excellent language because functional programming is the
perfect foundation for rigorously building more sophisticated abstractions.
Imperative languages can't do this because they can't opt-out of state and
side effects, making it incredibly difficult to reason about the correctness
of abstractions." 
"state and side effects" is just a way of fudging the real issue: if you
don't read or write the proper memory location, your program state is likely
to be busted, and you have side effects.

The Rust programming language (https://doc.rust-lang.org/book/unsafe.html)
is more clear about the issues at stake here. It clearly distinguishes
between writing safe and unsafe code:
"Safe, in the context of Rust, means ‘doesn’t do anything unsafe’. It’s also
important to know that there are certain behaviors that are probably not
desirable in your code, but are expressly not unsafe. . . Rust cannot
prevent all kinds of software problems. Buggy code can and will be written
in Rust."
The paper then goes on to describe what the compiler cannot be expected to
catch, safe mode or unsafe mode.

Doug.moen has written his "Mutable-Variables" paper from the viewpoint of a
user. Had he used the viewpoint of a compiler, he would have realized the
bugs he has introduced.

Here they are:

c=3.1416;        // this defines an immutable variable (a constant). The
                          compiler does not need more information, it can
define
                          the data type itself
var x;
var x:=0;        // the compiler needs more information, it does not know is
                        this a double or single precision number, an
integer, or a 
                        character? There is a need for what in C is called a
header.
x=x+1;           // the use of a colon is not necessary and has been omitted
                         here. Since x is already defined as mutable
elsewhere, the 
                         compiler has all the necessary information. x=x+1
is perfectly
                         acceptable.
c=c+1;           // This is illegal code, as c is auto-typed by the compiler
                         as immutable. The compiler should flag it as
"Variable not 
                         assigned". If done so, no unexperienced user is
likely to lug 
                         his/her lack of understanding onto this forum.

With regards to the use of procedures (if, as I assume, he means Pascal-type
procedures), I fail to see their utility. A procedure does exactly the same
as a function, except that it does not return a value. Rather, I would like
to see a clean-up of how a function is currently written so that it is
possible to build a function from compound statements. This would also make
functions much more easily readable. Readability is more of an issue here
than capability, in particular if you want to scope a mutable variable to be
limited to that function. And from what I can gather from the paper, a "do
block" would be just another name for a procedure: another function that
writes some memory area, but does not return anything and would not expand
on OpenSCAD's ability to create shapes.

What "assert()" is supposed to do I cannot make out at all.

If, while and for are great to have, provided C-style programming is
avoided. What I want to have is an OpenSCAD that is easy to learn, without
first becoming an expert in C. Therefore, no C-style anywhere. C-style is
good for C programmers only, for all others it is a pain in the backside and
barely readable. If you can read English, you should be able to read
OpenSCAD. If not, improve the language and make it more like English. Be
verbose where you must; if you really want to be universal, program in
assembler. And if you want to be truly concise, maybe you should use
Haskell?

I am very much in favour of using "mutable variables". But there are limits,
as I pointed out elsewhere
(http://forum.openscad.org/feedback-on-quot-C-style-for-quot-td17512.html).
Rust has defined these limits in terms of "safe" vs "unsafe" code. I suggest
that the OpenSCAD developer community do something similar for OpenSCAD, if
they fear imperative programming taking over their beloved functional style
nonsense and poor readability (in places).

Keep OpenSCAD simple, focused upon the creation of shapes, and implement
OpenSCAD2 as soon as possible. For those who want extensions to the
language, allow them to write a library (and its associated manual) and add
it to OpenSCAD for a limited number of years, the same way MCAD got added.
Throw the library out if it, or its manual, is not maintained or does not
get used.

That is enough criticism (hopefully constructive). The other bugs in the
discussion so far you should be able to discern yourself, once to see the
issues from a compiler's perspective.


wolf



--
View this message in context: http://forum.openscad.org/Polygon-using-relative-points-rather-than-absolute-tp17414p17522.html
Sent from the OpenSCAD mailing list archive at Nabble.com.




More information about the Discuss mailing list