On 4/18/2017 2:56 PM, Jonathan Marler wrote:
> Have you thought about supporting format specifiers as well?  I looked at the C#
> version and it looks like they can specify them using a colon like this:
>
>     $"{a} in hex is {a:x}"

There are additional problems, such as:

    $"{a} in %s {b}"

and positional parameters:

    $"{a} in {0}"

Of course, the easiest solution is to just disallow that stuff.

On 4/18/2017 4:58 PM, bpr wrote:
> Here's how it's done in Nim, a statically typed language similar to D, but with
> Python syntax, and macros. It takes some knowledge to understand, sure, macros
> are not a beginner tool, but wouldn't say this is extremely complex. I bet a
> D-with-macros would have a similar complexity solution.

I'm not saying you cannot do cool and useful things with AST macros. My position is it encourages absolutely awful code as (usually inexperienced) programmers compete to show how clever their macros are.

The language gets balkanized into a collection of dialects that are unrecognizable across user groups.

As a compiler dev who gets stuck figuring out users' bug reports, dealing with templates is bad enough (the first thing I do with a bug report is redo it to remove all the templates). I do not want to deal with some custom syntax. If I may pull the "I'm older" card, programmers will find as they gain experience that the AST macros are just not worth it.

This disastrous state of affairs has occurred with every language that supports macros.

If you want a nauseous example, check out the Boost C preprocessor metaprogramming library. Or C++ expression templates - so cool, and yet so utterly wretched.

Reminds me of a story from the 1980s. Microsoft's MASM stood for "Macro Assembler". Inevitably, Microsoft programmers invented a pile of macros that sort of turned asm programming into a pseudo-high-level language. This was shipped with every copy of MASM.

A friend of mine who worked at MS was once given the task of fixing a bug in 50K of MASM code written in this macro language. The author of it had long since moved on. Every coder assigned to this task failed. My friend got it fixed in a couple hours. He was asked by his astonished manager how he'd managed to do it:

"I assembled the code into an object file. Then I disassembled it with Zortech's OBJ2ASM, figured out how to fix it, then submitted the disassembled code as the new source code."

On Saturday, 15 April 2017 at 20:04:13 UTC, Jonas Drewsen wrote:
>   I've been wanting to have support for interpolated strings in D for some time now that will allow you to write e.g.:
> [...]

One place I'd appreciate interpolated strings is as an option when working with heredoc strings. These strings are often multiple lines or paragraphs, using format style construction is often error-prone due to length.

--Jon

On Wednesday, 19 April 2017 at 00:30:31 UTC, Walter Bright wrote:
> I'm not saying you cannot do cool and useful things with AST macros. My position is it encourages absolutely awful code as (usually inexperienced) programmers compete to show how clever their macros are.

I'd think that that's a problem with community coding standards.

> The language gets balkanized into a collection of dialects that are unrecognizable across user groups.

I'm pretty sure that hasn't happened with every language that supports macros. Even in the case of Scheme, I don't think it's the macros that are responsible for all of the dialects. It's the fact that the core language never includes enough (no records, exceptions, modules, ...) so every group adds their own versions of these features. Maybe if macros didn't make that easier then Schemers would have added those things to the core, but that's a counterfactual that I don't find convincing.

> As a compiler dev who gets stuck figuring out users' bug reports, dealing with templates is bad enough (the first thing I do with a bug report is redo it to remove all the templates). I do not want to deal with some custom syntax. If I may pull the "I'm older" card, programmers will find as they gain experience that the AST macros are just not worth it.

Some programmers will not find that. Others will find that other features you value are just not worth it. There are absolutely no categorical statements. :-)

> This disastrous state of affairs has occurred with every language that supports macros.

I don't think I've ever heard from Common Lisp, Scheme or Clojure programmers that they'd like to remove macros from their respective languages for the reasons you mention. I don't see the disasters there. The Julia folks looked at the Lisp experience and decided to include macros.

Both Rust and Nim support macros. Scala too. Not long enough for the disaster yet?

It's certainly not all roses, and writing and debugging macros can be a PITA. I try to avoid them, and consider them a tool of last resort. But they're very powerful, and sometimes I'm not smart enough to figure out how to do what I want cleanly with less powerful features.

> If you want a nauseous example, check out the Boost C preprocessor metaprogramming library. Or C++ expression templates - so cool, and yet so utterly wretched.

Have you checked out examples of macros that are not so nauseating? I find Nim decent, and of course the Lisps have a long history of macrology. I think you're drawing a view of macros from cpp, and MASM, and such, and not so much from the Lisp family, or Nim. cpp macrology is very different!

D is interesting to me mostly because of it's powerful templates and CTFE. It seems a shame (to me, obviously) that such a powerful static metaprogramming feature as macros will not be a part of D, but it's your language!

On Wednesday, 19 April 2017 at 03:49:09 UTC, bpr wrote:
> I don't think I've ever heard from Common Lisp, Scheme or Clojure programmers that they'd like to remove macros from their respective languages for the reasons you mention. I don't see the disasters there. The Julia folks looked at the Lisp experience and decided to include macros.

Lisp AST is minimal.

> Both Rust and Nim support macros. Scala too. Not long enough for the disaster yet?

How many Rust programmers write their own macros? My impression is that Rust macros is a temporary fix because they don't have another meta programming scheme in place. I also believe that Rust macros can break between releases.

> last resort. But they're very powerful, and sometimes I'm not smart enough to figure out how to do what I want cleanly with less powerful features.

Like what?

Certainly, term-rewrite-languages are powerful, e.g. the language Pure:
https://en.wikipedia.org/wiki/Pure_(programming_language)

But I don't quite see it as an important feature for an imperative language with an AST as complex as D and with rather non-uniform semantics.

If you want AST-macros in D you should also argue for redefining the core language, and turn everything that is unnecessary and that can be done as lowering into macros (e.g. "for each").

On Monday, 17 April 2017 at 19:41:14 UTC, Jonas Drewsen wrote:
> On Monday, 17 April 2017 at 19:12:37 UTC, Martin Tschierschke wrote:
>> defining a new method exho! (derived from echo + mixin...:-)
>>
>>   auto exho(string x)(){
>>      return mixin("writeln("~interp!x~")");}
>>
>> You can just write:
>>
>>    exho!"The number ${num} doubled is ${num * 2}!"
>
> It requires 'num' to be available to the exho function definition so will not
> work in the general case.
Thats a pity, so shouldn't we than try to find a way to define a alias like 'shortcut'
for something like

        mixin(compiletime_expresion!var)

so we can write just

        shortcut!var     ?

Or what about defining a new return type for functions allowing them to return a mixin  even if defined in a lib? (Because the code above is allowed but only working if exho is defined in the same scope as the var 'num'.)

Regards mt.

On 2017-04-19 02:30, Walter Bright wrote:

> I'm not saying you cannot do cool and useful things with AST macros. My
> position is it encourages absolutely awful code as (usually
> inexperienced) programmers compete to show how clever their macros are.
>
> The language gets balkanized into a collection of dialects that are
> unrecognizable across user groups.
>
> As a compiler dev who gets stuck figuring out users' bug reports,
> dealing with templates is bad enough (the first thing I do with a bug
> report is redo it to remove all the templates). I do not want to deal
> with some custom syntax. If I may pull the "I'm older" card, programmers
> will find as they gain experience that the AST macros are just not worth
> it.
>
> This disastrous state of affairs has occurred with every language that
> supports macros.
>
> If you want a nauseous example, check out the Boost C preprocessor
> metaprogramming library. Or C++ expression templates - so cool, and yet
> so utterly wretched.
>
> Reminds me of a story from the 1980s. Microsoft's MASM stood for "Macro
> Assembler". Inevitably, Microsoft programmers invented a pile of macros
> that sort of turned asm programming into a pseudo-high-level language.
> This was shipped with every copy of MASM.
>
> A friend of mine who worked at MS was once given the task of fixing a
> bug in 50K of MASM code written in this macro language. The author of it
> had long since moved on. Every coder assigned to this task failed. My
> friend got it fixed in a couple hours. He was asked by his astonished
> manager how he'd managed to do it:
>
> "I assembled the code into an object file. Then I disassembled it with
> Zortech's OBJ2ASM, figured out how to fix it, then submitted the
> disassembled code as the new source code."

I have a suspension that it's the name "macro" that is the problem here. It leaves a bad taste due to issues with macros in the past.

-- 
/Jacob Carlborg

On 2017-04-19 08:51, Ola Fosheim Grøstad wrote:

> If you want AST-macros in D you should also argue for redefining the
> core language, and turn everything that is unnecessary and that can be
> done as lowering into macros (e.g. "for each").

If D had AST macros from the beginning, then yes, "foreach" could have been implemented as a macro.

-- 
/Jacob Carlborg

On Wednesday, 19 April 2017 at 00:08:19 UTC, Walter Bright wrote:
> There are additional problems, such as:
>
>     $"{a} in %s {b}"

% should be escaped: "%s in %%s %s". There would be no use for a single % otherwise.

> and positional parameters:
>
>     $"{a} in {0}"

That would be literal 0: `"%s in %s", a, 0`. Could be disallowed but maybe not important.

Presumably braces would be escaped $"\{ \}" -> "{ }". Also having no {code} block in an interpolated string should be an error.

I like the simplicity of the lowering but it doesn't have much advantage over text(a, " in ", b), you still have to import a function. I suppose the advantage is readability for longer strings.

Also, there are compile-time tricks to make formatting more efficient with a compile time format string - e.g. format!"%s in %s"(true, null). Here format can know the length of the resulting string. With your lowering format can't receive the format string as a compile-time argument.

On Wednesday, 19 April 2017 at 00:08:19 UTC, Walter Bright wrote:
> On 4/18/2017 2:56 PM, Jonathan Marler wrote:
>> Have you thought about supporting format specifiers as well?  I looked at the C#
>> version and it looks like they can specify them using a colon like this:
>>
>>     $"{a} in hex is {a:x}"
>
> There are additional problems, such as:
>
>     $"{a} in %s {b}"
>
> and positional parameters:
>
>     $"{a} in {0}"
>
> Of course, the easiest solution is to just disallow that stuff.

What about supporting an optional prefix inside the {} like:

int year = 2017;
format($"The date is {%04d year}");

so if there is a % immediately following the { then the chars until next whitespace is format specifier. You can of course leave out the format specifier and it will default to %s.