On Wed, 2016-09-28 at 20:30 +0000, pineapple via Digitalmars-d wrote:
> On Wednesday, 28 September 2016 at 20:16:08 UTC, Walter Bright wrote:
> > 
> > Because there is no way to stop the former but still have operator overloading.
> > 
> > To reiterate, operator overloading exists in D to support the inclusion of arithmetic library types. Any other purpose is discouraged, and that includes expression templates and things like << for iostreams.
> 
> This is an obsolete way of thinking about operators. Operator overloading exists to make the programmer's life easier, and limiting the ways in which a valuable tool can be used drives people to languages which allow them to be more expressive.

Definitely, yes.

However, this has come up many times, and every time Walter says "no, it's wrong". Whilst the C++ iostreams << may have problems, using this as a single point argument as to why overloading fails in all other cases except numeric arithmetic is bad philosophy. In my view this is holding D back.

> For my job I write Python. We use a database layer called sqlalchemy that allows us to express queries by writing, for example, `session.query(some_table).filter(row1 == row2)` and I cannot begin to express how useful this is when writing code, when maintaining code, and when attempting to understand code that someone else wrote.

Definitely. I spend a lot of my time trying to inculcate people into DSL-based thinking as an extension of abstraction and leading towards understanding and modelling the solution to problems in the domain. Python has it's problems, C++ more, but this is a far superior way of going than the Java approach of "operator overloading is too hard for programmers to deal with so let's ban it". Hence Groovy, Scala, Kotlin, Ceylon, etc. all of which bring back this feature Java eschewed from C++ – possibly because the Oak developers had their problems.

> The objective should never be to stop the programmer from doing something because you personally dislike the practice.

I guess it depends on whether the language is wanting to gain traction in the market or remain a pet project.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Thursday, 29 September 2016 at 11:29:55 UTC, Russel Winder wrote:
> However, this has come up many times, and every time Walter says "no, it's wrong". Whilst the C++ iostreams << may have problems, using this as a single point argument as to why overloading fails in all other cases except numeric arithmetic is bad philosophy. In my view this is holding D back.

To add some thoughts to this,

The use of << being bad is purely a matter of opinion.
If you believe that << is to only be used for bit-shifting operations, you might hold the view that it is bad.
On the other hand, if you come from a background like Haskell or Ruby, you might have a very different opinion.

ie.
In Ruby, << is named the shovel operator. It's uses are things like appending an element into an Array.

Hence, a less opinionated point is necessary here.

On Wed, 2016-09-28 at 21:15 -0700, Walter Bright via Digitalmars-d wrote:
> On 9/28/2016 1:40 PM, Timon Gehr wrote:
> > 
> > What's wrong with that usage?
> 
> Because then something other than comparison is happening with <=, <,
> >, >= and
> there'll be nothing in the code to give the user a hint.

This is a very "tunnel vision" view of programming language and the way programs are constructed and perceived. But sadly I know we have been round this many times, and you will not be changing you viewpoint. But even though I know nothing will change, I feel required to take on the challenge again. Until you cite psychology of programming experimental data to back up any position, it is all just opinion and personal experience. I am happy with << as very much less than, or output depending on context, you are not. But it is bad philosophy for me to say << is comprehensible to me and so it is comprehensible to everyone, and equally bad philosophy for you to say the same with s/comprehensible/incomprehensible/.

This sort of thing happened in Python with the reduce function, leaving Python 3 in a truly inconsistent position regarding higher order functions.

So when it comes to writing DSLs I'll stick with Python and Groovy, until D gets it right.

[…]


-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Thu, 2016-09-29 at 11:50 +0000, Minty Fresh via Digitalmars-d wrote:
> On Thursday, 29 September 2016 at 11:29:55 UTC, Russel Winder wrote:
> > 
> > However, this has come up many times, and every time Walter says "no, it's wrong". Whilst the C++ iostreams << may have problems, using this as a single point argument as to why overloading fails in all other cases except numeric arithmetic is bad philosophy. In my view this is holding D back.
> 
> To add some thoughts to this,
> 
> The use of << being bad is purely a matter of opinion.
> If you believe that << is to only be used for bit-shifting
> operations, you might hold the view that it is bad.

But, but, but, << means very much less than, everyone knows this. What is this bitshifting of which you speak.

!

> On the other hand, if you come from a background like Haskell or Ruby, you might have a very different opinion.

Is there anyone from an Haskell background here. :-) Anyway everyone who wants to make Haskell code mainstream is using Frege.

> ie.
> In Ruby, << is named the shovel operator. It's uses are things
> like appending an element into an Array.

Groovy, and indeed Python, likewise. We ignore the mess Algol68 and Scala have got themselves into with this.

> 
> Hence, a less opinionated point is necessary here.

Opinionated is not always bad. Look at Go, the developers know that
there is no sane way of doing generics so they ban it. Also they know
that exceptions are totally incomprehensible to all programmers so they
ban them. Rust developers know that all memory handling must be
explicit all the world falls apart. Opinionated languages clearly get
traction – not usually because of the opinions, it has to be said, more
usually because of the amount of money thrown at marketing. Except
Python, obviously.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Thursday, 29 September 2016 at 12:20:42 UTC, Russel Winder wrote:
> Opinionated is not always bad. Look at Go, the developers know that
> there is no sane way of doing generics so they ban it. Also they know
> that exceptions are totally incomprehensible to all programmers so they
> ban them. Rust developers know that all memory handling must be
> explicit all the world falls apart. Opinionated languages clearly get
> traction – not usually because of the opinions, it has to be said, more
> usually because of the amount of money thrown at marketing. Except
> Python, obviously.

Reminds me of this - https://twitter.com/paniq/status/757951588057096192

On 2016-09-29 09:58, Walter Bright wrote:

> I.e. you can overload '+' to do bad things. Yes, you can, and as I
> replied upthread that can be done because there's no way to prevent that
> while having operator overloading at all.
>
> But that is not justification for allowing such disasters for the
> comparison operators. I.e. one weakness is not justification for opening
> the door to all weakness.

You're using the same justification when rejecting most feature requests you don't like: you had one bad experience with C++ and therefore it must be banned for all eternity. It's not a valid argument.

> Interestingly, by shutting the door on misuse of the comparison
> operators, it seems D has been successful in discouraging nutburger
> designs like overloading '+' to mean 'OR'.

It's also shutting the door on doing a lot of useful things. My goal is no to use the comparison operators to mean something different than comparison. The goal is, for example, to build a corresponding SQL query out of an expression. But the == operator would still be used for equality.

One major issue with using string literals is, if we use the SQL query as an example again, as follows:

First try:

auto bar = `"bar"`;
auto query = "SELECT * FROM foo WHERE bar = " ~ bar;

Is have the issue of SQL injection.

Second try:

auto bar = "bar";
auto foo = "foo";
auto q = query("SELECT * FROM foo WHERE bar = $1 AND foo = $2", bar, foo);

This has the issue that the value and the place of where a value is used far away from each other in the code making it more difficult to read. This was "solved" in Rails by using an associative array mapping the column names to the values:

foo = "foo"
bar = "bar"
Foo.where(bar: bar, foo: foo)

That has the issue of only working with equality and "AND". Now way to do less than or "OR".

Third try:

auto foo = "foo";
auto bar = "bar";
Foo.where(q => q.foo == foo && q.bar == "bar");

The above expression would be translated to the query in the second example, with the values properly escaped. Now this is how I want the code to look like.

>> The language you just provide a set of tools, then it's up the to the
>> programmer
>> to do what he/she wants to do.
>
> That can be used to justify any feature at all.

> I know you really want AST macros for D. We've discussed that at length
> before.
>
> BTW, there's a CTFE parser generator for D around somewhere.

And that will handle all that the DMD parser does? I don't think so.

-- 
/Jacob Carlborg

Me and Cauterite were toying with the idea of AST macros but in a completely new form a while ago.

Below is the usage of it.

Something you'll notice about it is that it could turn the asm block into a library solution (which is clearly what we'd want anyway). Not to mention Linq style queries.

In theory it shouldn't be too complex to implement since you are only doing basic checks to determine if to parse the given statement / block to a rewriter function.

```D
void main() {
    // \/ parsed by iasm.c by matches {}'s and sending contents to it
    asm {
        ...
    }

    import linq;
    @Linq
    DataSource source = ...;
    Tree[] trees = source.trees.where(name = "abc").limit(20);

    import Assembly_x86;

    asm {
        ...
    }
}

struct Linq {
    string __ast(OnType, ExpectedType)(string statement) {
        assert(statement == "source.trees.where(name = "abc").limit(20);");
        static assert(OnType == DataSource);
        static assert(ExpectedType == Tree[]);
    }
}

// Assembly_x86.d

struct X86 {}
struct ASM {

    string __ast(OnType, ExpectedType)(string statement) {
        assert(statement == "asm {\n        ...\n    };");
        static assert(OnType == X86);
        static assert(ExpectedType == void);
    }
}

@ASM
X86 asm;
```

On 2016-09-29 11:31, pineapple wrote:

> This is not an argument to justify adding just any feature, it's an
> argument that it is idiocy to give a programmer a powerful tool, and
> then impose arbitrary limitations upon how they are allowed to use it.
>
> One of the most popular topics of discussion in this forum is "Why is D
> not more widely adopted?" and "What can we do to get broader adoption
> for D?"
>
> Perhaps one of the more obvious answers is: Do not prevent programmers
> from doing something solely on the basis that _you_ would not want to do
> it.
>
> I think camelCase is hideous, but does that mean I should forbid another
> programmer defining symbols in that style? Of course not. That they are
> able to write their code that way doesn't mean I have to, and doesn't
> mean I have to use or interface with their code. I agree that '+' should
> always mean addition and '~' should always mean concatenation, but does
> that mean I should forbid another programmer from defining them
> differently? Of course not. Just because they are able to do it that way
> doesn't mean I have to, or that I have to use their code.
>
> If I thought '>' and '<' should always mean arithmetic comparison, does
> that mean I should forbid another programmer from defining them
> differently?
>
> You need to understand that _you are not the only one writing code in
> this language_. Your use cases do not summarize all possible use cases.
> That you do not need to use a tool in a specific way is not a valid
> argument against allowing others to use the tool that way.
>
> Give us a rational argument. We are unconcerned with your personal
> dogma. What you refer to as a weakness I view as a strength. Programmers
> require more flexibility and expressiveness, not less.

Well said.

-- 
/Jacob Carlborg

On 2016-09-29 14:57, rikki cattermole wrote:
> Me and Cauterite were toying with the idea of AST macros but in a
> completely new form a while ago.
>
> Below is the usage of it.
>
> Something you'll notice about it is that it could turn the asm block
> into a library solution (which is clearly what we'd want anyway). Not to
> mention Linq style queries.
>
> In theory it shouldn't be too complex to implement since you are only
> doing basic checks to determine if to parse the given statement / block
> to a rewriter function.
>
> ```D
> void main() {
>     // \/ parsed by iasm.c by matches {}'s and sending contents to it
>     asm {
>         ...
>     }
>
>     import linq;
>     @Linq
>     DataSource source = ...;
>     Tree[] trees = source.trees.where(name = "abc").limit(20);
>
>     import Assembly_x86;
>
>     asm {
>         ...
>     }
> }
>
> struct Linq {
>     string __ast(OnType, ExpectedType)(string statement) {
>         assert(statement == "source.trees.where(name = "abc").limit(20);");
>         static assert(OnType == DataSource);
>         static assert(ExpectedType == Tree[]);
>     }
> }
>
> // Assembly_x86.d
>
> struct X86 {}
> struct ASM {
>
>     string __ast(OnType, ExpectedType)(string statement) {
>         assert(statement == "asm {\n        ...\n    };");
>         static assert(OnType == X86);
>         static assert(ExpectedType == void);
>     }
> }
>
> @ASM
> X86 asm;
> ```

Hmm, I find this to be somewhat difficult to follow. You get the AST as a string? Which means you need to implement a parser. How will the macro invocation be transformed? Return a string from the macro which will be reparsed by the compiler and inserted at the call site?

-- 
/Jacob Carlborg

On Thursday, 29 September 2016 at 12:54:54 UTC, Jacob Carlborg wrote:
>> BTW, there's a CTFE parser generator for D around somewhere.
>
> And that will handle all that the DMD parser does? I don't think so.

I agree with this entirely. Lest you have an entire D compiler implemented in CTFE (reductio ad absurdum), you're working with a limited subset of the language, and pose additional challenges for a developer trying to debug.

Not to mention that string mixins render IDE features like code completion and error highlighting essentially unusable.