On 1/3/2016 11:40 PM, Jacob Carlborg wrote:
> There's of course AST macros as well, which have many other good use cases.
> Unfortunately you don't like those either :(

Neither Andrei nor I have changed our minds on that one.

On 1/1/2016 3:37 AM, Russel Winder via Digitalmars-d wrote:
> 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".


"Also" is the wrong word. See my other post in this thread for why that was done, and no, it is not Java's reason. It has nothing to do with "too hard for programmers".

On Monday, 4 January 2016 at 00:49:29 UTC, Andrei Alexandrescu wrote:
> Second, ET as a mechanism for SQL interface has other inherent limitations. Consider the "LIKE" operator in SQL, which has no ET equivalent in C++ with similar syntax, and no direct

like(Person.Name,"peter%")

Person.Name == pattern("peter%")

> On another example, C++'s overloading of &&, ||, and the comma operator are considered downright disastrous and are unrecommended by virtually all coding standards and guidelines,

Guideline means that you should think hard about it before you do break it. A guidelines does not mean that you never should do it. It means you should only break the guideline when you have good reasons to do so.

If you can overload "and" and "or", you also can implement ternary logic, fuzzy logic and other logics. In some cases that is desirable.

In C++ features were abused when they were new because people were eager to stretch new features to the limits. This is not a problem in regular C++ programs. And in the case of C++ iostreams, it has become an idiom that isn't causing any problems. C++ programmers are never confused by shift and output operators.

But if this is a big deal the easy solution is to add unicode operators without default behaviour.

String processing is not an acceptable alternative, it ruins tooling. You should essentially never be able to turn a symbol into a string and vice versa. D unfortunately allows you to do it. That is a mal-feature aka a textual macro feature.

You can't really say that D has gotten rid of macros when you actually encourage using macro-like textual substitution features in place of processing  proper symbols. That is an outdated 70s paradigm.

On Monday, 4 January 2016 at 09:44:35 UTC, Walter Bright wrote:
> My not-so-humble opinion is these sorts of DSLs are technical demonstrations, but not useful nor desirable tools.

Well, this is wrong. They are desirable and work with tooling, editors, code completion etc. And also allow user extensions if done right.

Symbols should not be referenced as strings. That's bad. That's textual macro processing.

On Monday, 4 January 2016 at 07:48:14 UTC, Jacob Carlborg wrote:
> Perhaps I'm missing something obvious but there are several problems with this:
>
> 1. What happens when you use more than one query for the same table at the same scope? In the above case, "Person" is already defined the second time "db" is invoked. It's not possible to add fields for already declared structs. Unless you use some form of opDispatch backed by an associative array of variants

While it wasn't apparent, when I said "later" I meant "later" in git's history. The second version would be in a future commit, i.e. when changes are made. Then you can diff it and generate migration code. (Obviously this requires the DSL to be in a separate file without other code. We used to have such a reflective system in place in our continuous deployment. It would look at the changes in git since the last deployment and when certain files changed it knew it had to do certain stuff.)

> 2. What happens if I want to execute a custom query in a function, i.e. a query that is only used once. Will it generate the sturct inside the function or am I forced to always use this mixin at module level?

I suppose you need to declare each and every query in the DSL. But you might be on to something ugly in what I am proposing.

Having said that, facebook seems to be going the DSL route. https://facebook.github.io/graphql and https://facebook.github.io/react/blog/2015/05/01/graphql-introduction.html

Another benefit of a DSL is that you can generate code for other languages. For instance you could generate a JS, Swift or Android client.

> I still think it's a lot easier to declare the struct with standard D code. I don't think the DSL adds any value in this case. Just do something like:
>
> @db struct Person
> {
>     string name;
>     int age;
> }
>
> The @db attribute would allow to create the migrations.

But then you are back to square one with regards to queries.

On 1/4/2016 2:34 AM, Ola Fosheim Grøstad wrote:
> On Monday, 4 January 2016 at 09:44:35 UTC, Walter Bright wrote:
>> My not-so-humble opinion is these sorts of DSLs are technical demonstrations,
>> but not useful nor desirable tools.
>
> Well, this is wrong. They are desirable and work with tooling, editors, code
> completion etc. And also allow user extensions if done right.

You didn't address my points. Have you used C++ ETs for production? They fall apart in real world use for the reasons I mentioned. It's one thing to read a paper about something, and another to use it for something larger than will fit on a slide.

On Mon, 2016-01-04 at 08:29 +0000, rsw0x via Digitalmars-d wrote:
> 
[…]
> compiler plugins like Rust to enable AST macros could fix this but walter and andrei seem extremely opposed to any form of macros so we end up with ugly heavily templated ugly band-aids

Rust may have macros, in fact it has two sorts, but they are not as useful as you might at first think.

The macro system as in Rust stable is not up to the task of doing code generation such that you can replicate PyTest's pytest.mark.parametrize decorator in Rust. The compiler plugins that would allow this are only allowed in Rust nightly and are forbidden in  Rust beta and stable. Rust nightly is effectively a totally different platform to Rust beta or stable, which is undermining the Rust platform.

I must now try creating a D version of the pytest.mark.parametrize decorator – unless someone already has and I have just missed it.

> shame, because I think D will quickly lose their lead in the metaprogramming area if Rust keeps it up - e.g, someone already made a GC Plugin for rust's compiler

I think Rust and not C++17 is the biggest threat to D just now.

I am still intending to rewrite Me TV in D.
-- 
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 2016-01-04 10:44, Walter Bright wrote:

> So, what does D do?
>
>     http://dlang.org/phobos/std_regex.html
>
> D enables CTFE to write a PROPER compile time regex language, with
> correct regex grammar, correct regex tokens, regex-specific error
> messages, etc. And it works great! It's not a hack, compromise, or
> workaround. It's a real, embedded DSL. And it's faster than any other
> regex engine on the market.

And how would you do that for SQL. Build a CTFE SQL database?

-- 
/Jacob Carlborg

On 2016-01-04 12:14, Sebastiaan Koppe wrote:

> But then you are back to square one with regards to queries.

If you can't use the host language, i.e. Person.where(e => e.name == "John");, what's the point of inventing a new DSL? Why not just use SQL if the DSL needs to be in a string anyway.

-- 
/Jacob Carlborg

On Monday, 4 January 2016 at 12:28:47 UTC, Russel Winder wrote:
> I must now try creating a D version of the pytest.mark.parametrize decorator – unless someone already has and I have just missed it.

I quick look at pytest.mark.parametrize suggests it could be implemented with UDAs and a test-runner that finds all declarations a module (recursively) and does all the relevant logic (e.g. that's got more than one instance of parametrize, so do some sort of cartesian product of the inputs) and actually runs the test.

The main thing that python has here over D is that D's UDAs can't directly modify the function they're attached to, but I don't think that's necessary for parametrize.

Interestingly, functions can query their own attributes:

@(3) auto attr()
{
	return __traits(getAttributes, attr)[0];
}

unittest
{
	assert(attr() == 3);
}

not sure when I'd use that though...