Proposal: Database Engine for D

Andrei Alexandrescu via Digitalmars-d digitalmars-d at puremagic.com
Sat Jan 9 12:27:04 PST 2016


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



More information about the Digitalmars-d mailing list