On Mon, 2016-01-04 at 15:38 -0500, Andrei Alexandrescu via Digitalmars- d wrote:
> 
[…]
> I don't think regexen were the point as much as an example. What is Boost.Sprint? I haven't heard of it, and can't find it. Thanks!

As others mentioned, it was a mis-type, it is Boost.Spirit.

http://boost-spirit.com/home/

> 
-- 
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 01/07/2016 02:02 PM, Russel Winder via Digitalmars-d wrote:
> On Mon, 2016-01-04 at 15:38 -0500, Andrei Alexandrescu via Digitalmars-
> d wrote:
>>
> […]
>> I don't think regexen were the point as much as an example. What is
>> Boost.Sprint? I haven't heard of it, and can't find it. Thanks!
>
> As others mentioned, it was a mis-type, it is Boost.Spirit.
>
> http://boost-spirit.com/home/

Got it, thanks. I took a look at a familiar topic - json grammars.

I just googled `boost spirit json` and followed through the top result. For C++, the grammar definition would be https://github.com/cierelabs/json_spirit/blob/master/ciere/json/parser/grammar_def.hpp.

Then I googled `pegged json` and the top result led to https://github.com/PhilippeSigaud/Pegged/blob/master/pegged/examples/json.d.

Which do you like more?


Andrei

On Tuesday, 5 January 2016 at 22:12:05 UTC, Mengu wrote:
>
> guys, what we need is a DB abstraction supporting PostgreSQL, MySQL and other major database systems and we need it yesterday. let's not make things more complex than they are and build up this thing.
>

I'm personally a fan of dplyr using R. bachmeier is apparently working on a way to embed R in D. Might be an option if you need it yesterday.

An example I saw above of

people.filter!(x => x.surname == "Slughorn");

looked a lot like a D version of dplyr's filter function.

On Monday, 4 January 2016 at 09:44:35 UTC, Walter Bright wrote:
> On 1/1/2016 3:33 AM, Russel Winder via Digitalmars-d wrote:
>> Or alternative 4, fix D so that proper operator definition can be
>> achieved.
>
> The way D's operator overloading is designed is not a mistake. It's limitations are a feature, not a bug. It was deliberately set up to:
>
> 1. Make doing C++ style iostreams hard.

struct _cout {

  auto opBinary(string s : "<<", T)(auto ref T rhs) {
    import std.stdio : write;

    write(rhs);
    return this;
  }
}

_cout cout;
void main() {
  cout << "Walter " << "hates " << "this." << endl;
}


and yet, I can't overload the address-of operator because Walter is afraid I might shoot my foot.

On Thu, 2016-01-07 at 15:32 -0500, Andrei Alexandrescu via Digitalmars- d wrote:
> On 01/07/2016 02:02 PM, Russel Winder via Digitalmars-d wrote:
[…]
> 
> Got it, thanks. I took a look at a familiar topic - json grammars.
> 
> I just googled `boost spirit json` and followed through the top
> result.
> For C++, the grammar definition would be
> https://github.com/cierelabs/json_spirit/blob/master/ciere/json/parse
> r/grammar_def.hpp.
> 
> Then I googled `pegged json` and the top result led to https://github.com/PhilippeSigaud/Pegged/blob/master/pegged/examples/ json.d.
> 
> Which do you like more?

Just a quick look I'm afraid, so very superficial at this stage:

The D code as presented is clearly simpler and easy to read. However the D grammar is a string and not code so the anticipation is that errors in the C++ code would be easier to find and correct. I guess the question here is how good the compile time evaluation of strings is in D and does it do good error reporting.

I still prefer the concept of Internal DSL explicitly in the code rather than in strings just now, but this may still just be prejudice.

-- 
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 Mon, 2016-01-04 at 12:07 -0800, Walter Bright via Digitalmars-d wrote:
> 
[…]
> I'm surprised you'd ask. I thought this was well known.
> 
> 1. ugly as hell

For you perhaps, others have different opinions. I like it.

> 2. not exception safe

Indeed. but then most code is not exception safe which is part of the problem with computing. Fixing C++ I/O is only about 0.001% of the problem.

> 3. not thread safe

Indeed. But then a properly architected system only has one point of I/O per channel, which could then be single threaded, so less of a problem.

> 4. interleaved output in the middle of lines when writing to both stdout and stderr

This is a shell problem not a C++ problem.

> 2..4 are caused by inability to encapsulate a sequence of these operations.

And also generally bad architecting of I/O in applications.

[…]

> 
+.
> 
>   #define BEGIN {
>   #define END }
> 
> is still C++, too.

I thought Stephen Bourne was the only person who ever thought this was sensible.

There is a difference always between what you can do and what you should do. The language should not be fascist in stopping all things not deemed the one true way by the language designers. To do so stops serendipitous evolution.

[…]

> 
> What do you suggest when the operators and precedence of the desired
> algebraic
> type simply do not map cleanly onto C++ operators and precedence
> grammar? Allow
> users to define their own operators and redefine the precedence?
> Where is the
> line that shouldn't be crossed?

There is no line. cf. Algol68.

Python only offers compiler understood operators and preserves precedence, ditto C++ (the relationship is fairly obvious). Scala allows arbitrary operators, cf. Algol68. Groovy follows the Python/C++ approach over Java.

So currently most people stick with know operators and allow redefinition within a fixed precedence structure. Easy for the compiler writer, constraining for the user programmers, but workable usually.

Scala has shown the way that Algol68 set out, compiler writers should give up on imposing fixed expression structures in their languages. Haskell has gone a little this way using `` for infix operator words. Sort of works can be ugly. Of course Scala code can be made incomprehensible using the operator definitions.

In the end it is up to programmers to do the right thing, and for compiler writers not to tell them what they may or may not thing in a given language.  Restrictive languages, lead to restrictive applications, and demise in the market.

[…]
> 
> EBNF doesn't map onto C++ operators and precedence, either. It's still a hack:
> 
>    https://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_Form
> 
> With CFTE, the user can actually write actual EBNF.

Assuming EBNF is actually a good way of writing grammers. ;-)

-- 
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 1/9/2016 2:49 AM, Russel Winder via Digitalmars-d wrote:
> The D code as presented is clearly simpler and easy to read. However
> the D grammar is a string and not code so the anticipation is that
> errors in the C++ code would be easier to find and correct. I guess the
> question here is how good the compile time evaluation of strings is in
> D and does it do good error reporting.

The compiler does not report the errors. The parsing is done by code supplied by the module, and the error messages are as good or as bad as that code is written. The point being that one is not subjected to compiler generated error messages based on the compiler thinking it is C++/D code, but a custom written parser for the DSL that can give messages specific to the DSL.


> I still prefer the concept of Internal DSL explicitly in the code
> rather than in strings just now, but this may still just be prejudice.

I can see only one advantage to using ETs for DSLs:

* 3rd party tools like syntax directed editors, formatters and highlighters will operate on it. But they'll still operate on it as if it were C++ code.

CTFE based DSLs win on every other point I can think of, including error messages.

On 1/9/2016 3:02 AM, Russel Winder via Digitalmars-d wrote:
> [...]
> And also generally bad architecting of I/O in applications.

These problems have persisted since the genesis of iostreams. The problems do not exist in the way other modern languages do I/O. Iostreams was a great idea in 1985, but 30 years of experience has shown there are better ways.


> There is a difference always between what you can do and what you
> should do. The language should not be fascist in stopping all things
> not deemed the one true way by the language designers. To do so stops
> serendipitous evolution.

On the other hand, consider the C preprocessor. It has well known problems. But this never seems to discourage the most execrable edifices built on top of it. Their designers inevitably regard them as shining examples of their creativity. And maybe they are. But do they belong in professional code? No. But the only way to stop them is to not have a preprocessor in the language. (Of course, you can always use m4 as a front end to any language, but thankfully nobody seems to do that.)

I believe there is a notion of "best practices", that some practices are simply better than others. A good language design makes it easy to follow best practices, and hard to follow known inferior ones. D is meant for professional use, and people who want professional code tend to want some mechanical assurance that best practices are followed (consider the increasing smorgasbord of third party tools designed to ferret out bad practices in C/C++ code).

There is plenty of innovation in programming language practice, I don't think it is stifled.

On Saturday, 9 January 2016 at 11:02:46 UTC, Russel Winder wrote:
> There is a difference always between what you can do and what you should do. The language should not be fascist in stopping all things not deemed the one true way by the language designers. To do so stops serendipitous evolution.

Indeed, although I think languages should have a library-mode and an application-mode.

That way you can constrain certain types of meta-programming to libraries and keep application implementation syntax simple and readable.

This is what happens in well structured programs anyway.

On 1/9/16 5:49 AM, Russel Winder via Digitalmars-d wrote:
> On Thu, 2016-01-07 at 15:32 -0500, Andrei Alexandrescu via Digitalmars-
> d wrote:
>> On 01/07/2016 02:02 PM, Russel Winder via Digitalmars-d wrote:
> […]
>>
>> Got it, thanks. I took a look at a familiar topic - json grammars.
>>
>> I just googled `boost spirit json` and followed through the top
>> result.
>> For C++, the grammar definition would be
>> https://github.com/cierelabs/json_spirit/blob/master/ciere/json/parse
>> r/grammar_def.hpp.
>>
>> Then I googled `pegged json` and the top result led to
>> https://github.com/PhilippeSigaud/Pegged/blob/master/pegged/examples/
>> json.d.
>>
>> Which do you like more?
>
> Just a quick look I'm afraid, so very superficial at this stage:
>
> The D code as presented is clearly simpler and easy to read. However
> the D grammar is a string and not code so the anticipation is that
> errors in the C++ code would be easier to find and correct. I guess the
> question here is how good the compile time evaluation of strings is in
> D and does it do good error reporting.

The string parser is custom code and issues errors as defined by the library author. (I don't have experience with Pegged in particular.) I think one difficulty with ETs is reporting line where errors occur in multi-line strings. Language facilities could help here. This is an area of strategic importance for D.

I do have extensive experience with error messages in C++ ETs, which were and are inscrutable.

> I still prefer the concept of Internal DSL explicitly in the code
> rather than in strings just now, but this may still just be prejudice.

Prejudice can last only so long in the face of evidence.


Andrei