Overloading relational operators separately; thoughts?

[Russel Winder via Digitalmars-d]

On Fri, 2016-09-30 at 21:43 +0000, Dominikus Dittes Scherkl via
Digitalmars-d wrote:

> But operator overloading doesn't increase the language 
> expressiveness.

Expressiveness is not a metric, there isn't even a partial order, it is
a qualitative thing, thus personal to a great extent. What I consider
expressive and what you consider expressive likely are entirely
unrelated. There can be a shared agreement or a disagreement. What is
not acceptable is to state that one person's opinion is true for all
people 
 
> They provide nothing that you can't already do using ordinary 
> function calls.

Correct.

> So forget expressiveness as an argument.

No.

> Operator overload is syntactic sugar, added to serve a single 
> purpose: to allow mimic buildin types. So they should provide 
> everything needed to do so, and nothing more. Adding more may be 
> asked for, but this is not reasonable, because it is unrelated to 
> the original purpose but increases only the possibilities to 
> obfuscate the code by doing something misleading (there are 
> already endless such possibilities, but that makes asking for 
> more no more reasonable).

All high level languages are syntactic sugar, the one true language is
machine code, all else is fluff. It just happens that layers of
abstraction and "syntactic sugar" are really rather important to
building complex software systems. 

Any programming language is in fact a meta-language to enable people to
construct new languages. All programs are DSLs for some domain. The
question at hand is whether a programming language has the right tools
for the job. Operator overloading is one tool in the creation of DSLs.
D currently seems to have a very hobbled version of this compared to
C++, Python, and a very grandiose scheme compared to Go, Fortran.

This debate is about whether D constrains people as Java does or
whether it enables people as C++ and Python do.

> You are allowed to walk. You can express everything that is 
> possible with operator overloading in lots of other ways. And you 
> can express everything that operator overloading was designed for 
> with it - but maybe not everything beyond that. Use other ways to 
> express such. If the compactness of expression written using 
> operators is everything you are interested in - define some 
> language and write a parser for it, and enjoy how short you can 
> express everything you need with it.
> You can even write such stuff directly in your D code and let 
> some string mixins massage it to compile.

Or use C++ or Python which allow for this. Fine, end of D having a
future amongst a large section of the programming population. This is
fine. Unless D wants to be a player in this game. 

> I can't see the point to relax the rules for operator overloading 
> unless you can show that they prevent parts of the original 
> design goal.

This has already been done, read the thread. SQLAlchemy. The expression
language is a a lovely builder DSL for constructing SQL entirely in
Python with no parser overhead. No operator overloading, no DSL for
builder languages. See same on the JVM: in Java you can't do it,
Kotlin, Ceylon, Scala, Groovy, do it beautifully, and a lot of people
do.

Java only survives as a language for constructing new systems because a
very large part of the Java programming community cannot be bothered to
learn new stuff that doesn't have Java on the label. Even then many are
not sure about this Java 8 thing. Indeed many are not even sure Java 5
was a good thing. Yes there are a lot of people still writing new stuff
in Java 1.4.2 because generics, streams, modern programming techniques
are new fangled syntactic sugar that is not needed to express the
algorithm. I can give lots of anecdotal evidence on this drawn from
workshops I have presented.

The question here is whether D wants to include these sorts of things
or reject them.

But at the heart of the debate is whether a DIP will be evolved into a
change to the D language or whether it will be rejected even before it
is put together.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20161001/9d2bf7c8/attachment-0001.sig>