On Mon, 2016-01-04 at 01:45 -0800, Walter Bright via Digitalmars-d wrote:
> 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.

Pity I like good AST transforms: Groovy, Scala, Lisp, Clojure, Rust… C++ template meta-programming isn't really my cup of tea.

Rusts macros show it can be done well.

-- 
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 Monday, 4 January 2016 at 18:28:15 UTC, Russel Winder wrote:
> On Mon, 2016-01-04 at 01:45 -0800, Walter Bright via Digitalmars-d wrote:
>> 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.
>
> Pity I like good AST transforms: Groovy, Scala, Lisp, Clojure, Rust… C++ template meta-programming isn't really my cup of tea.
>
> Rusts macros show it can be done well.

I agree heavily with this, it feels like an arbitrary limitation.
D did wonders in making template metaprogramming usable compared to C++, but sometimes it feels like trying to pound nails in with a screwdriver.

I think just looking at the kind of stuff being done in languages that enable AST macros might change minds.

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.

On 01/04/2016 01:25 PM, Russel Winder via Digitalmars-d wrote:
> What is the problem with having the << and >> operators do input
> output. Very object-oriented.

What is the connection between using shift operators for I/O and object orientation?

> But it would be D. Boost.Sprint code may look like EBNF, but it is C++.
[snip]
> 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.

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! -- Andrei

On 01/04/2016 01:28 PM, Russel Winder via Digitalmars-d wrote:
> Rusts macros show it can be done well.

Do you have a few examples handy? Thanks. -- Andrei

On 01/04/2016 02:50 PM, rsw0x wrote:
> D did wonders in making template metaprogramming usable compared to C++,
> but sometimes it feels like trying to pound nails in with a screwdriver.

Do you have examples of that awkwardness happening? Is it suitable to supplement those with CTFE? -- Andrei

On Monday, 4 January 2016 at 20:07:55 UTC, Walter Bright wrote:
> On 1/4/2016 10:25 AM, Russel Winder via Digitalmars-d wrote:
>>
>> 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?
>
On this point specifically, I'm still considering attempting to write a DIP because it would be very useful to have some user-defined operators available.  Take the OCaml/F# approach where they provide a set of acceptable characters for operators and define precedence automatically (depending on first character of the name).  (And definitely don't do the Haskell thing where any binary function can be turned into an infix op.)

-Wyatt

> What is Boost.Sprint? I haven't heard of it, and can't find it. Thanks! -- Andrei

I believe he meant Boost Spirit

http://www.boost.org/doc/libs/1_60_0/libs/spirit/doc/html/spirit/introduction.html

Zz

FWIW, were I proposing a "Database Engine for D" I'd be proposing a B+Tree that was restricted to storing explicit data (no pointers or other indirection...including strings, you'd need to specify fixed size arrays of char, wchar, or dchar).  There would be one "type"/file, and the "type" would be given by a struct that contained no pointers either obvious or hidden (i.e., dynamic arrays, strings, etc.).  This would be for simplicity of implementation and basic functionality. Later I would consider implementing secondary keys which would be implemented as databases storing only the key value and the record number.  Since records are of fixed size, sorting them would be trivial, but only the secondary keys would provide this option because you want the record number of the main file to be reliable and invariant.

SQL seems like a poor fit to D.  At some point one might consider a fancier front end to the database that would allow indirections, but that's a whole can of worms, with threats of multiple copies that have different values for items that started out pointing to the same variable.

On 01/04/2016 12:39 PM, Andrei Alexandrescu via Digitalmars-d wrote:
> On 01/04/2016 01:28 PM, Russel Winder via Digitalmars-d wrote:
>> Rusts macros show it can be done well.
>
> Do you have a few examples handy? Thanks. -- Andrei
>

On Mon, 04 Jan 2016 08:55:53 +0100, Jacob Carlborg wrote:

> If D had better operator overloading or supported AST macros, opEquals would not return true. It would return a new proxy that overloads the || operator. The rest of the post falls apart from this mistake.

Not proposing language changes was an intentional feature, not a mistake.