Parkinbot said:

I don't personally feel the need for user defined operators. Functions are
good enough for me. I want to keep the language simple.

User defined operators can be quite complicated to implement, if you have
operator declarations that dynamically change the grammar. Then you no
longer have a context free grammar, you instead have to parse operator
declarations and feed grammar information back down to the lexical analyzer
and parser. We should avoid this.

Not all schemes for user defined infix operators require special operator
declarations or a dynamically changeable grammar. Look at Smalltalk, for
example.

In Haskell, you can turn any binary function into an infix operator using
backticks. The syntax
x f y
is equivalent to
f(x,y)
For example,
K = L concat M;
This is easy enough to implement. Would we really need anything more
complicated than this?

Operator overloading is a huge leap in complexity from defining new
operators. That presupposes the ability to define new user defined data
types. Do we really need this? Industrial strength data abstraction is a
can of worms that I don't want to open. For that, I feel it is better to
embed the OpenSCAD primitives in another programming language, via an
OpenSCAD library. Again, I want to keep the language simple.

Let me add this: I think that shapes should be values, and you should be
able to query the attributes of a shape, probably using dot notation. For
example, if you have a sphere, you should be able to ask for its radius.
And the same thing extends to user defined shapes: you should be able to
query the model parameters of any shape. Or query and operate on the
underlying geometry information. And I want to try implementing this in
OpenSCAD2.

Since I have professional experience as an object oriented programmer, the
"obvious" approach is to add object oriented programming and class
definitions to OpenSCAD. But I don't want to do this, because keep the
language simple. So I'm going to try to implement this idea in a really
simple way, without introducing user defined data types. That's the goal, I
won't start coding this until some time next year probably.

Parkinbot said:

Marius said:

In OpenSCAD2, functions and shapes are both first class values. Since
functions can take shapes as arguments and return them as results, the
current distinction between functions and modules ceases to make sense.
Functions can do everything that modules do. You can even use syntax like
'rotate(45) cube(10)' if 'rotate' and 'cube' are defined as functions. The
OpenSCAD2 design doc explains how this works in more detail, and I've
implemented the function part of this already.

So then it will become possible to stop using module definitions and write
all of your code using function definitions. So that's my eventual plan for
function/module unification. I don't want function definitions to be more
awkward to write than module definitions, and that partly motivates
"qualified expressions".

If my goal was to make OpenSCAD look more like C or Javascript, then I'd
probably implement Javascript style function definitions, like
function f(x) {
a = ...;
b = ...;
return result;
}
But if I wanted to write code like this, I'd switch to using OpenJsCAD.

My actual goals are different than this. I like the fact that OpenSCAD is a
purely declarative language. I want to move it more in the direction of a
pure expression language, where you eliminate the distinction between the
world of statements and the world of expressions, and where you can do
everything using expressions. (Marius mentioned Scala as an example of an
expression language; there are many others.) In an expression language, you
can introduce local variable definitions inside an expression, and that's
what let expressions and qualified expressions are for. In my version of
reality, function definitions are made purely of expressions, they don't
contain embedded statements (using our current statement grammar).

Right now, I'm trying to improve debuggability. I'm adding a breakpoint
action, for breaking into the debugger. I want to be able to insert
conditional breakpoints and conditional echo actions into any expression,
without the requirement to first break down complex expressions into a
sequence of variable assignments so that I can insert debug statements in
between the variable assignments, which I sometimes need to do in a
procedural language. So I need to extend qualified expressions so that they
can contain conditional and unconditional actions.

OpenSCAD2 has a fixed set of data types, based on JSON. What's missing,
that I've added, is a "record" data type. The current syntax is like this:
p = {x=1, y=2};
echo(p.x); // ECHO: 1
The basic use case is to represent a set of named model parameters. I also
intend to use this as the basis for JSON import/export.

Record literals are part of the reason I don't want to use curly braces for
compound actions inside of qualified expressions. The brace characters are
reserved for records.

Doug.

On 16 November 2016 at 00:19, Marius Kintel marius@kintel.net wrote:

doug.moen wrote

p = {x=1, y=2}; is a struct and p() = {whatever}; a function. A compiler
and a human can distinquish it.

To be honest, I still don't know which scope rules apply in OpenSCAD - is't
that a thing that is mainly connected with {} despite it gets changed with
every new release? And there is a lot of confusion going on having two
syntaxes for modules and functions. Why not confess that other languages
have solved this long time ago. Or is your final aim to get rid of modules?
Which would kick out the 95% of the users that don't write their own
functions.

Also, with OpenSCAD2 I would go so far to allow any module calls in
functions. Why? View them as debugging outputs like echo. But I guess,
again, there will be a scope or a bracket problem.

--
View this message in context: http://forum.openscad.org/feedback-let-echo-and-assert-in-expressions-tp19111p19157.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

It seems to me that OpenSCAD2 is totally hampering OpenSCAD development.
Not only do additions need to be backwards compatible with OpenSCAD they
now have to be forwards compatible with OpenSCAD2. That means a simple
thing like echo in functions that people have been asking for years never
gets implemented, even when there are perfectly good pull requests.
Meanwhile I waste time debugging functions on a daily basis although I have
no interest in OpenSCAD2.

On 16 November 2016 at 17:54, Parkinbot rudolf@parkinbot.com wrote:

On 11/16/2016 07:03 PM, nop head wrote:

This is merged now and I think the discussion did lead to
a more sensible and useful implementation.

The initial pull request was not perfectly good as it
did not even have a single test case, and those always
prove very important. The last delay for merging echo()
was actually an issue I've introduced when adding assert()
and missed a test for this specific case with vectors.
This affected echo() as well as both share some code.

There's quite a number of issues that are open for a
long time, but the reason for the delays is certainly
not the OpenSCAD2 discussion (which does seem to go off
at a tangent sometimes, but is very useful and important
in my opinion). The main issue (at least for me) is just
simple lack of time.

I think all those discussions about OpenSCAD2 are a
good thing, even if there's disagreements in some places.
In my opinion carrying over some ideas into current
OpenSCAD has improved todays application quite a bit.

ciao,
Torsten.

What’s hampering OpenSCAD development is totally not OpenSCAD2, but the lack of good language design in the past, together with limited spare time among our very few developers. OpenSCAD2 is actually an attempt to avoid making grave language design mistakes by thinking ahead, and thus make OpenSCAD development easier in the future.

-Marius

Agreed.  While most of the arguments/discussion in this thread and other
similar threads goes right over my head, I appreciate the point that
unless the base code and language concepts are cleaned up and
streamlined, then people who volunteer their time will have to "waste"
most of it just to accommodate the clever, but almost random (but
inspired!), features that have accumulated.  The fact that OpenSCAD is
as powerful and productive as it is, is a testimony to the creativity
and ability of all the people who have contributed, and they must be
congratulated, but unless some review is held that gives a more unified
approach, patches, upon patches, upon patches will just tire existing
people out and not encourage other new people to contribute.

Keep up the good work guys!

Rob

On 17/11/16 07:42, Marius Kintel wrote:

Parkinbot said: "To be honest, I still don't know which scope rules apply
in OpenSCAD"

OpenSCAD doesn't have scope rules in the normal sense. Most programming
languages use 'lexical' or 'static' scoping. This means you can look at a
variable name at a particular point in the program and say, statically,
which variable definition it corresponds to (or say that the variable is
undefined at that point).

OpenSCAD uses some weird variant of dynamic scoping. The variable
definition that a given instance of a variable name refers to is determined
at run time, and can change dynamically during runtime. It doesn't work
like any other programming language, so in practice the behaviour is
unpredictable for normal users. You just have to run the program and see
what it does. The rules aren't documented and I've never been able to fully
figure them out. This also means I don't know how to compile OpenSCAD into
efficient code.

The OpenSCAD interpreter doesn't have a compile phase. It directly
interprets a parse tree. And that's what leads to the dynamic behaviour of
variable lookup.

In the research prototype that I am building, I have a compiler that looks
up every variable reference at compile time, using lexical scoping rules.
Variable references are converted into integer indexes into a stack frame.
At run time, the scope of a variable is fixed. That's how all modern
languages work. The interpreter runs faster, because indexing into a stack
frame is faster than looking up a string in a chain of symbol tables.

We could imagine using this kind of compiler technology in a future release
of OpenSCAD, where we impose lexical scoping rules, and compile OpenSCAD
into efficient code, maybe into fast parallel code that uses multiple cores
or runs on a GPU. But it wouldn't be fully backward compatible. And I don't
know what the lexical scoping rules should even be, since the current
behaviour is pretty random. I'd leave that decision to Marius and Torsten.

Here are some demos of weird variable lookup behaviour.

1    echo(a,b); // ECHO: 1,undef
2    b=a;
3    a=1;

The output is:
WARNING: Ignoring unknown variable 'a'
ECHO: 1,undef

When I first started using OpenSCAD, I assumed it was lexically scoped,
because that's how all languages work (I thought). Based on that
assumption, I deduced that the scope of 'a' is line 1, but not line 2. The
warning shows that 'a' is not in scope on line 2.

But that's the wrong way to think about OpenSCAD, because variables don't
have static scopes.

1    a = 0;
2    module m()
3    {
4        function f() = a;
5        x = f();
6        a = 1;
7        y = f();
8        echo(x,y);
9    }
10  m();

Look at line 4. In a lexically scoped language, the variable name 'a' would
statically refer to either the outer definition on line 1, or the inner
definition on line 6. One or the other. But you can't meaningfully ask
"what is the scope of 'a'" in OpenSCAD, because the choice is made at run
time, and changes dynamically. So the output is:
ECHO: 0,1

Fun question: is any of this behaviour a bug?

Doug.

On 16 November 2016 at 12:54, Parkinbot rudolf@parkinbot.com wrote:

doug.moen wrote

Fun answers:
"Wanna start programming with OpenSCAD? Have a pair of dice printed first."
"No, it is not our design that is buggy, is it your expectation."
"We don't want to break freaky code, that has passed our randomizer".

So you are effectively saying, it is more or less random by design, and you
are willing to build even more randomness upon that in OpenSCAD2?

--
View this message in context: http://forum.openscad.org/feedback-let-echo-and-assert-in-expressions-tp19111p19185.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

"So you are effectively saying, it is more or less random by design, and you
are willing to build even more randomness upon that in OpenSCAD2?"

Maybe I was being overly dramatic and critical. But it's increasing clear
that the "backwards compatibility" part of the OpenSCAD2 project is a very
complex undertaking, at least with my current approach of building a new
compiler and VM from scratch.

What I'm building right now is core technology, a compiler and a VM, to be
followed later by a GPU based geometry engine that's integrated with the
VM. The actual language syntax is just a UI on top of the core. To make
faster progress on the core, I need to keep the language part as simple and
regular as possible. Implementing full backward compatibility at this stage
would delay things by a year or so. So my prototype is not compatible with
OpenSCAD, and won't be for some time. I'm hoping that some of my results
will be useful enough that they can be adopted into the OpenSCAD project in
some form, even if I'm not personally building an OpenSCAD compatible
system right now.

In the long term, I don't know what happens.

1. Maybe the most useful parts of my design get incorporated into
   OpenSCAD, and my project is shelved.
2. Maybe I release an OpenSCAD-like CAD system with a new and
   incompatible language design. In that case, I won't call it OpenSCAD2 but
   something else. I do not want to create confusion. This will at least free
   me up to fully implement the vision without compromise, with the risk that
   few people will ever use it.
3. Maybe I do #2, and include the ability to import OpenSCAD scripts, as
   one of the supported file formats. That would entail reimplementing
   OpenSCAD on top of my compiler and VM, with interoperability between the
   two languages. Since OpenSCAD would just be an import format, this
   subproject wouldn't block progress on the main project.
4. Maybe the OpenSCAD team (Marius, Torsten, et al) will evolve OpenSCAD
   in a direction that makes it more compatible with my compiler and VM,
   introducing minor incompatibilities but cleaning up the language.

One of my concerns about lexical scoping is that I have implemented first
class function values in the standard way, as lexical closures. I don't see
a way to implement first class function values in a way that is both
correct and fully backward compatible with OpenSCAD functions as they
currently work, with weird dynamic scoping. I'd probably end up with an
ugly mess, eg anonymous functions that have different semantics than an
identical named function definition.

On 16 November 2016 at 21:07, Parkinbot rudolf@parkinbot.com wrote: