Proposal: Database Engine for D

[Russel Winder via Digitalmars-d]

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 at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20160109/c9be293e/attachment.sig>