On Thursday, 14 November 2013 at 19:27:42 UTC, simendsjo wrote:
> At the top of the page you should have "view mode" links which supports a threaded view.

Neat. I have my browser set up to auto-login, so I rarely, if ever, have to look up there.

On Thursday, 14 November 2013 at 18:23:20 UTC, Andrei Alexandrescu wrote:
> 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.
>

This is not proposing to configure 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.
>

C macro can introduce new syntax. This cannot.

> 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

I think this very post pretty much show that you missed the point of the DIP.

On Thursday, 14 November 2013 at 18:23:20 UTC, Andrei Alexandrescu wrote:
> 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

D's syntax remains the same ( statements, expressions, function calling, numbers etc. ). These AST manipulation tools just define new words or language constructs. Human languages tend to be altered as times passes and the needs change. That's why new words appear. Even the grammar is not the same as the one my grandparents used.

On Thursday, 14 November 2013 at 18:23:20 UTC, Andrei Alexandrescu wrote:
[...]
>
> 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

Not an unreasonable assumption to make, so assuming it's true, then we need a fixed way to deal with a certain set of problems that so far cannot be done reasonably (or at all) in current D.

One case, which I also so happen to want to solve, is the async/await type of problem. There's simply no reasonable solution available other than through extensions to the language, which may or may not ever materialize. It's very frustrating when you want to explore possibilities today rather than wait for an extension that may never arrive.

Adding in the async/await extensions can help solve only that specific problem, but how many other types of problems that are similar to this one will programmers still want to solve? A more general solution would seem to be far more useful.

The other simple problem I encountered, at first seems like a mixin can deal with or perhaps a template, but current D simply cannot do it in a reasonable way that I'm aware of.

I want to be able to pass an argument to an "inspect" function, that will log or display the symbol name of the top-level argument and it's corresponding value.

Example:

int a = 300;
inspect( a ); // or inspect!a;

The only way I can do this is through double entry of the item to inspect
eg

inspect( a.stringof, a ); // error prone and irritatingly redundant

I can get some success using an alias template parameter, but it does not work in general, only in a few cases will it work, so templates are not a solution without some additional enhancements.

May be by adding in something like __ARGS__, or expanding on__traits can solve this type of problem, but there's no doubt many other scenarios that will require similar extensions that users of the language cannot implement. There's no end to this without much better access to reflection.

--rt

On 11/14/2013 11:18 AM, Jacob Carlborg wrote:
> 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".

If it is powerful enough to do async/await but look like normal D syntax, then is going to suffer from these faults.

(A lot of the C++ macro abuse looks like normal syntax to the user, but it behaves in a way that the casual user would find completely unexpected. In the same vein, macro assembler abuse of macros did not introduce new syntax - the syntax for the macros was straightforward. It was what those macros *did* that made them incomprehensible.)

On 11/14/2013 11:40 AM, deadalnix wrote:
> This is not proposing to configure syntax.

Right, it is about inserting arbitrarily different meaning into existing syntax.

For example, I have a friend from the middle east who worked at Microsoft. His english was excellent. But sometimes he'd get tripped up - for example, he'd take his idea to his boss, who'd discuss it, and then say:

    "fine"

He took that to mean "my boss approves of my great idea!" Unfortunately, "fine" has undergone a meaning reversal colloquially, and actually means "your idea sux". This wound up getting him into trouble. There were a few other phrases like this with unintentionally hilarious misunderstandings.

(Also, a popular way of encrypting communications is to have private meanings for phrases like "my cat ate my homework" meaning "initiate Operation X".)

Now, let's take the AST macros, and pass it "4+3". Apparently is a feature that the macro can transform this to produce "hello" as the result. The result is that although the language looks the same, there is no "anchor" a person can rely on to indicate the meaning. The meaning of "fine" is reversed, so to speak.

The riposte is, of course, every feature can be abused and good programmers won't do that. Unfortunately, it's IN THE VERY NATURE of macros to be abusive, and even the very best programmers can and will take it to the limit. They will see and decry the abuse in everyone else's code but their own, which they will justify. As I said, I see this over and over again.

On the other hand, with string mixins, it is immediately obvious that one is dealing with different syntax, and so expect something different to happen.

On Thu, Nov 14, 2013 at 01:12:11PM -0800, Walter Bright wrote:
> On 11/14/2013 11:40 AM, deadalnix wrote:
> >This is not proposing to configure syntax.
> 
> Right, it is about inserting arbitrarily different meaning into existing syntax.
[...]
> Now, let's take the AST macros, and pass it "4+3". Apparently is a feature that the macro can transform this to produce "hello" as the result. The result is that although the language looks the same, there is no "anchor" a person can rely on to indicate the meaning. The meaning of "fine" is reversed, so to speak.
[...]
> On the other hand, with string mixins, it is immediately obvious that one is dealing with different syntax, and so expect something different to happen.

What if macros adopted an overtly different syntax?


T

-- 
English has the lovely word "defenestrate", meaning "to execute by throwing someone out a window", or more recently "to remove Windows from a computer and replace it with something useful". :-) -- John Cowan

On Thursday, 14 November 2013 at 21:12:11 UTC, Walter Bright wrote:
> On the other hand, with string mixins, it is immediately obvious that one is dealing with different syntax, and so expect something different to happen.

This is exactly the reason why I have been asking to make denoting macro usage with explicit keyword mandatory, like it is done with mixins.

It does not change much about the concept itself and is not worth fixating upon as a blocker.

On Thursday, 14 November 2013 at 21:12:11 UTC, Walter Bright wrote:
> On 11/14/2013 11:40 AM, deadalnix wrote:
>> This is not proposing to configure syntax.
>
> Right, it is about inserting arbitrarily different meaning into existing syntax.
>
> For example, I have a friend from the middle east who worked at Microsoft. His english was excellent. But sometimes he'd get tripped up - for example, he'd take his idea to his boss, who'd discuss it, and then say:
>
>     "fine"
>
> He took that to mean "my boss approves of my great idea!" Unfortunately, "fine" has undergone a meaning reversal colloquially, and actually means "your idea sux". This wound up getting him into trouble. There were a few other phrases like this with unintentionally hilarious misunderstandings.
>
> (Also, a popular way of encrypting communications is to have private meanings for phrases like "my cat ate my homework" meaning "initiate Operation X".)
>
> Now, let's take the AST macros, and pass it "4+3". Apparently is a feature that the macro can transform this to produce "hello" as the result. The result is that although the language looks the same, there is no "anchor" a person can rely on to indicate the meaning. The meaning of "fine" is reversed, so to speak.
>
> The riposte is, of course, every feature can be abused and good programmers won't do that. Unfortunately, it's IN THE VERY NATURE of macros to be abusive, and even the very best programmers can and will take it to the limit. They will see and decry the abuse in everyone else's code but their own, which they will justify. As I said, I see this over and over again.
>
> On the other hand, with string mixins, it is immediately obvious that one is dealing with different syntax, and so expect something different to happen.

You have a point with the example, but just as with templates ( the distinctive binary ! operator), making macros not to look first class language elements when called does great job with readability. #-s or ×-s are just good for this, even if it look very foreign.

#loop ( ) {
  -- code --
}

Maybe for macros that return macros it would be ugly:
#(#macro1(params1))(params2);

But just as in C where the -> operator automatically dereferences pointers, it could be solved.
# macro1(params1) =#= (params2);
(Just for fun)

On Thursday, 14 November 2013 at 21:12:11 UTC, Walter Bright wrote:
> On 11/14/2013 11:40 AM, deadalnix wrote:
>> This is not proposing to configure syntax.
>
> Right, it is about inserting arbitrarily different meaning into existing syntax.
>

Yes, but EXPLICITELY.

> (Also, a popular way of encrypting communications is to have private meanings for phrases like "my cat ate my homework" meaning "initiate Operation X".)
>

Note that you do not pretend that sentence with "THIS IS AN ENCRYPTED SENTENCE, HERE TO DECRYPT IT DO XXX".

> Now, let's take the AST macros, and pass it "4+3". Apparently is a feature that the macro can transform this to produce "hello" as the result. The result is that although the language looks the same, there is no "anchor" a person can rely on to indicate the meaning. The meaning of "fine" is reversed, so to speak.
>

mymacro(4+3); // <= can be "hello"
myfunction(4+3); // <= can be "hello as well"

Quite frankly, this isn't really convincing.

> The riposte is, of course, every feature can be abused and good programmers won't do that. Unfortunately, it's IN THE VERY NATURE of macros to be abusive, and even the very best programmers can and will take it to the limit. They will see and decry the abuse in everyone else's code but their own, which they will justify. As I said, I see this over and over again.
>

I can find article on the internet saying the exact same thing for any feature ever invented. You'll find quite easily some about templates or operator overloading, but if you go in Functionnalland, you'll find the same about virtual dispatch and inheritance. If you go in OOPland, you'll find the exact same argument for monads.

You are qualifying the nature of macro here, that is not an argument. "Macros are bad, so I conclude macro are bad."

> On the other hand, with string mixins, it is immediately obvious that one is dealing with different syntax, and so expect something different to happen.

string mixins + a CTFE usable lexer+parser+D codegen from AST would achieve something close to the macros proposed here. This would obviously require quite a lot of work and is doomed to be dramatically slow and resources hungry, less hygienic (as identifier are implicitly resolved in the mixed in scope rather than explicitly) but quite close in term of capabilities.

You can't argue that string mixin is good while AST macro is bad.