Proposal: Database Engine for D

[Walter Bright via Digitalmars-d]

On 1/4/2016 10:25 AM, Russel Winder via Digitalmars-d wrote:
> On Mon, 2016-01-04 at 01:44 -0800, Walter Bright via Digitalmars-d
> wrote:
>> 1. Make doing C++ style iostreams hard.
> What is the problem with having the << and >> operators do input
> output. Very object-oriented.

I'm surprised you'd ask. I thought this was well known.

1. ugly as hell
2. not exception safe
3. not thread safe
4. interleaved output in the middle of lines when writing to both stdout and stderr

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


>> 2. Prevent clever use of operator overloading and expression
>> templates to create
>> languages that look like D, but are NOT.
>
> But it would be D. Boost.Sprint code may look like EBNF, but it is C++.

  #define BEGIN {
  #define END }

is still C++, too.


>> 3. Work well when using operator overloading to implement arithmetic
>> types.
>
> It is important that this works. But it should be possible to create an
> operator algebra for any type: arithmetic types are a very small subset
> of types used in computing.

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?


> I avoid regular expressions except when editing using ed, sed, or
> emacs, so I cannot properly comment on the above. However I find
> Boost.Sprint a very sensible way of using compile-time meta-object
> protocols. You write a grammar in EBNF in the source code, and the
> compiler writes the parser. Excellent use of internal DSL. And type
> safe.

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.