On Fri, 2016-01-01 at 10:45 +0000, Ola Fosheim Grøstad via Digitalmars- d wrote:
> 
[…]
> In D1 Walter made a point about restricting operator overloading to discourage reuse of operators. In D2 there are many ways to […]

Java also went the route of "operator definition is too hard for programmers to deal with so we will not allow it". Every language on the JVM other than Java has made a point of allowing, indeed encouraging, sensible operator definition (*).  Sadly too few people working on the JVM are allowed to use languages other than Java.

(*) Arguably Scala takes this too far.

-- 
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 Friday, 1 January 2016 at 11:37:40 UTC, Russel Winder wrote:
> Java also went the route of "operator definition is too hard for programmers to deal with so we will not allow it". Every language on the JVM other than Java has made a point of allowing, indeed encouraging, sensible operator definition (*).

Unfortunately language design is often not as principled, scientific or ergonomic as it ought to be and is often heavily tainted by the moral opinions and personal practices of their designers.

Unfortunately infrastructure matters more than ergonomics. I guess Python is a rare exception.

On 2016-01-01 12:33, Russel Winder via Digitalmars-d wrote:
> On Fri, 2016-01-01 at 11:03 +0000, Jacob Carlborg via Digitalmars-d
> wrote:
>>
> […]
>> That's exactly the problem. See an issue reported [1] and a
>> related thread [2]. AST macros could solve the problem as well
>> [3] (and many other problems).
>>
>> [1] https://issues.dlang.org/show_bug.cgi?id=14593
>> [2] http://forum.dlang.org/thread/msvapl$2rmn$1@digitalmars.com
>> [3] http://wiki.dlang.org/DIP50
>
> Or alternative 4, fix D so that proper operator definition can be
> achieved.

That would be the first link and the second link discussing that issue.

-- 
/Jacob Carlborg

On 2016-01-01 11:45, Ola Fosheim Grøstad wrote:

> In D1 Walter made a point about restricting operator overloading to
> discourage reuse of operators. In D2 there are many ways to create your
> own weird syntax, but Walter is locked on his D1 position, even though
> it makes little sense in D2.
>
> This is an overarching theme in D: the design rationale, that goes a
> decade back and is based on making a restricted easy to use version of
> C++, does not change, even though the context is very different in 2015
> and the premises has changed.
>
> These things are unlikely to change without a fork. Which is a pitty as
> D needs a more coherent design to get out of stagnation.

The core developers are making a big deal out of being able to have DSL's as string literals and process them at compile time. Although that's kind of pointless with SQL, since one still needs to send to string to the database to perform the query. The only thing that's possible is to validate the syntax at compile time.

-- 
/Jacob Carlborg

On Saturday, 2 January 2016 at 12:23:30 UTC, Jacob Carlborg wrote:
> The core developers are making a big deal out of being able to have DSL's as string literals and process them at compile time.

They have probably never done professional work with an ORM...

Nobody wants that.

On Friday, 1 January 2016 at 11:37:40 UTC, Russel Winder wrote:
> (*) Arguably Scala takes this too far.


Btw, regarding operator overloading:

Your comment about Scala made me think about the proposals for Algol which allowed the language to be heavily extended with even custom operator precedence IIRC. Interestingly, the Pony authors have decided that most operators should be explicitly grouped using parentheses, they argue that most programmers fail to remember precedence. I think that is mostly the case, especially with the somewhat flawed C precedence rules.

Related note, I find this tongue-in-cheek comparison of Go and Algol68 is quite entertaining:

http://cowlark.com/2009-11-15-go/

I think older languages such as Simula67, Algol68, Beta, ML etc still are quite interesting objects for study. It is scary how little progress have been made in the past 30 years... Fortunately some people are preserving books in PDF format.

http://www.softwarepreservation.org/projects/ALGOL/book/Lindsey_van_der_Meulen-IItA68-Revised.pdf

On Friday, 1 January 2016 at 01:34:53 UTC, Rikki Cattermole wrote:
> You've just introduced two topics.
> The first is a database engine, abstracting away the drivers.
> And second an ORM.

And maybe even an object-oriented database management system to some extent. OTOH, I removed SQL from the stack.

Piotrek

On Friday, 1 January 2016 at 04:20:19 UTC, tcak wrote:
> You know someone needs to maintain all that code base continuously. When SQLite is a separate project, it has its own developers and we just bind to its library; it is same for other DBs. Your proposal is nice, but creating another standard, and a group of people needs to take care of it in both documentation and coding wise continuously are biggest issues.

Agree. Lack of resources is an enemy of every project.

BTW. I don't introduce any new standard except a new file format.

Piotrek

On Friday, 1 January 2016 at 10:00:43 UTC, Kapps wrote:

> This example shows the difficulty of doing this in D. You can't really have something like `p.Name == "James"`, or `p.Age < 21` translate to SQL properly without language changes, which I believe Walter or Andrei were against. This has been the key problem when things like Linq to Sql for D have been brought up before.

Not really. There is no translation stage to SQL or any other DSL in the proposal. So this problem doesn't exist and no language changes are needed.

However there is another issue which must be taken into account. One should decide if the object is retrieved directly or via via proxy. Especially for big objects with lot of aggregated types.

Piotrek

On Saturday, 2 January 2016 at 12:23:30 UTC, Jacob Carlborg wrote:
> The core developers are making a big deal out of being able to have DSL's as string literals and process them at compile time. Although that's kind of pointless with SQL, since one still needs to send to string to the database to perform the query. The only thing that's possible is to validate the syntax at compile time.

Well, you can also generate the structs and specific serialization code. And depending on how advanced your dsl you can also auto generate database migration code. There are propably tons of other stuff you can do with it.

All in all much better than extending the language.