On 11/14/2013 1:25 AM, dennis luehring wrote:
> Am 14.11.2013 10:12, schrieb Walter Bright:
>> I've also seen the sheer awfulness of what happens with these systems over the
>> long term. The fascinating thing about this awfulness is people are well aware
>> of it in everyone's macro libraries but their own.
>
> the same was said about templates AND string mixins before - but currently only
> the wise guys building good/great templates/mixins which are in use by everyone
> - no terror from the deep

I don't buy that these are analogous. They are very different features.

On 11/14/2013 2:07 AM, Chris Cain wrote:
> I guess I would have thought the exact opposite from you... that this is
> precisely something that *should* be done with a library-defined macro.

Again, I reiterate what experience shows happens with macro systems in the long term.

On 11/14/2013 1:08 AM, dennis luehring wrote:
> Am 14.11.2013 10:06, schrieb dennis luehring:
>> Am 14.11.2013 09:53, schrieb Walter Bright:
>>> On 11/13/2013 11:37 PM, Jacob Carlborg wrote:
>>>> On 2013-11-14 01:16, Walter Bright wrote:
>>>>
>>>>> Yes. But that's a good thing. I'd be pretty skeptical of the value of an
>>>>> AST macro that took 3+4 and changed it so it did something other than
>>>>> compute 7.
>>>>
>>>> You can still do stupid things like that with operator overloading. Not on
>>>> built-in types, but on user defined types. Every language allows you to do
>>>> stupid things, one way or another.
>>>
>>> Sure, but the issue is that expression templates are not for "int+int", but for
>>> "T+int". My question is what value would there be in a rewrite of "int+int" to
>>> mean something different.
>>
>> "int + int" could be part of an PC<->GPU kombination that generates
>> CUDA- and D-interchange code at compiletime
>
> or like Don Blade Engine with string mixins
>
> could produce "high performance x87 asm" code for normal D expressions
>

Good example, but still quite doable using type T instead.

On Thursday, 14 November 2013 at 09:12:38 UTC, Walter Bright wrote:
> I do understand this. I've not only extensively used macro systems, I've designed two successful ones and implemented other peoples' designs.
>
> I've also seen the sheer awfulness of what happens with these systems over the long term. The fascinating thing about this awfulness is people are well aware of it in everyone's macro libraries but their own.

What kind of macro systems are you talking about? C-like macros? Assembly macros? Lisp-like macros? It seems that Jacob's proposed system is similar to none of these.

On 11/14/2013 9:08 AM, Meta wrote:
> What kind of macro systems are you talking about? C-like macros? Assembly
> macros? Lisp-like macros? It seems that Jacob's proposed system is similar to
> none of these.

See my first comment in this thread - it's an ancestor to this one.

>
> 1. I've seen very heavy use of such macros in macro assemblers. What happens is people use it to invent their own (very baroque) language on top of the existing assembler one. Anyone trying to read the code has to learn this new unique language, and given the limitations of the macro capability, it often comes with unfixable bizarre corner cases and limitations.
>

Metaprogramming (almost) does the same. At least that is my impression. Sometimes I have to go through hundreds of lines of templated D code to understand what a single line does...

On 11/14/13 2:17 AM, Walter Bright wrote:
> On 11/14/2013 2:07 AM, Chris Cain wrote:
>> I guess I would have thought the exact opposite from you... that this is
>> precisely something that *should* be done with a library-defined macro.
>
> Again, I reiterate what experience shows happens with macro systems in
> the long term.

FWIW Walter talked me back around 2005-2006 into abandoning my own ideas about languages with configurable syntax.

There are quite a few failings about comparing programming languages against natural languages, but here's one that I think does have value: fixed syntax is ingrained into people's notion of language, and swapping syntax within an otherwise identical linguistic context is extremely taxing on the brain. Anyone who's read with a C or C++ codebase full of macros and #if-driven code can attest how unbelievably difficult juxtapositions of the normal syntax with preprocessor syntax can quickly become. That's part of why "static if" has been so successful in D - it drives new semantics but within the same syntax.

Natural languages are "humans complete" because they are the one vehicle we use to describe and manipulate our understanding of the entire reality. If configurable syntax was something necessary to model the world, it would have inevitably occurred in natural languages one way or another. Instead, all human languages (with no exception I know of) have fixed syntax and prefer to add modeling power in other ways. There must be something about this.


Andrei

On 2013-11-14 19:23, Andrei Alexandrescu wrote:

> FWIW Walter talked me back around 2005-2006 into abandoning my own ideas
> about languages with configurable syntax.
>
> There are quite a few failings about comparing programming languages
> against natural languages, but here's one that I think does have value:
> fixed syntax is ingrained into people's notion of language, and swapping
> syntax within an otherwise identical linguistic context is extremely
> taxing on the brain. Anyone who's read with a C or C++ codebase full of
> macros and #if-driven code can attest how unbelievably difficult
> juxtapositions of the normal syntax with preprocessor syntax can quickly
> become. That's part of why "static if" has been so successful in D - it
> drives new semantics but within the same syntax.

AST macros cannot change the syntax or introduce new syntax. C preprocessor macros and AST macros are not the same. I'm starting to regret that I called it "macros".

-- 
/Jacob Carlborg

On Thursday, 14 November 2013 at 17:55:57 UTC, Walter Bright wrote:
> On 11/14/2013 9:08 AM, Meta wrote:
>> What kind of macro systems are you talking about? C-like macros? Assembly
>> macros? Lisp-like macros? It seems that Jacob's proposed system is similar to
>> none of these.
>
> See my first comment in this thread - it's an ancestor to this one.

I'm using the website forum, so I see posts in a continuous format, not a threaded view.

Anyway, it seems like assembly macros are actually quite similar to Lisp macros. Again, it seems like what Jacob proposes is not really much like Lisp macros, nor C macros.

On Thursday, 14 November 2013 at 19:22:08 UTC, Meta wrote:
> On Thursday, 14 November 2013 at 17:55:57 UTC, Walter Bright wrote:
>> On 11/14/2013 9:08 AM, Meta wrote:
>>> What kind of macro systems are you talking about? C-like macros? Assembly
>>> macros? Lisp-like macros? It seems that Jacob's proposed system is similar to
>>> none of these.
>>
>> See my first comment in this thread - it's an ancestor to this one.
>
> I'm using the website forum, so I see posts in a continuous format, not a threaded view.
>
> Anyway, it seems like assembly macros are actually quite similar to Lisp macros. Again, it seems like what Jacob proposes is not really much like Lisp macros, nor C macros.

At the top of the page you should have "view mode" links which supports a threaded view.