On 2/24/2020 9:24 AM, Arine wrote:
> No [...]

Using unprofessional language will result in your posts being deleted. Please stop.

On 2/24/20 2:35 PM, Walter Bright wrote:
> Having the compiler lower string interpolation to some hidden template is - AST macros. We're not doing AST macros.

How can you possibly arrive at this conclusion? We lower to templates all the time. By this definition all operator overloading in D is AST macros. This means all the operations on associative arrays are AST macros. array dup and idup -- AST macro. destroy is an AST macro.

> 
> Hidden user-defined semantics are not for D. Every language I'm familiar with that supports it wound up with users creating their own completely undocumented personal language that nobody else can use or has the remotest interest in using.

Except that's not what's happening here. It's lowering to a template defined by the language, not the user. The user creates their own API (not language) by accepting such a template and unsurprisingly can react differently to different parameters to said function or template.

If you have an example that proves me wrong, I'd love to see it. How can this feature do something that is "like AST macros"?

> If someone sees an i"abc" in the source code, they should be able to look in the language spec and know exactly what it does. They should not have to go trolling through imports looking for the definition of some template they never heard of.

I don't know where to begin here. The very argument rebuts itself -- The reason you look in the spec is to find out about the type of an interpolated string. Then you've heard of it. Are we supposed to only implement features that people have heard of before reading the spec? How would they have heard of it if they don't read the spec? Why do they have to go "trolling through imports" (whatever that means -- this template will be in object.d), and read the implementation? I mean, people compare 2 objects all the time without reading the definition for object.opEquals, I'm sure they could manage understanding that there's something different about interpolated strings, and still use writefln with them.

This whole response continues to imply that we do not understand each other's point of view.

-Steve

On 2/24/2020 11:45 AM, Adam D. Ruppe wrote:
> On Monday, 24 February 2020 at 19:35:16 UTC, Walter Bright wrote:
>> Having the compiler lower string interpolation to some hidden template is - AST macros. We're not doing AST macros.
> 
> This is untrue.
> 
>> Hidden user-defined semantics are not for D.
> 
> We are NOT calling for this.
> 

https://digitalmars.com/d/archives/digitalmars/D/DIP_1027--String_Interpolation--Final_Review_Discussion_Thread_335065.html#N335132

> * put the format literal in a wrapper type.
> i"$foo %"
> is translated to the tuple:
> __d_format_literal!("%s %%"), foo


and also you wrote:

> if we can
> all agree to amend it to put in the template thing we can fix
> everything. Even with just the one string arg, we can do a lot
> with it...

and proposed a lowering to:

> i"your hex data is ${%02x}someByte"
>
> (_d_interpolated_string!("your hex data is ",
> _d_interpolated_format_spec("%02x"))(), someByte)

and proposed:

> i"$foo %"
> is translated to the tuple:
> __d_format_literal!("%s %%"), foo
> struct __d_format_literal(string fmt) {
>          enum f = fmt;
>          alias f this;
> }

On 2/24/2020 12:19 PM, Steven Schveighoffer wrote:
> How can you possibly arrive at this conclusion? We lower to templates all the time.

The language is nowhere defined as lowering to specific templates. There are indeed some lowerings to templates in the implementation of the language, but those are NOT user defined templates, they are simply an implementation convenience.

> By this definition all operator overloading in D is AST macros.

Operator overloading is not supported for basic types. It's fundamentally different from what was proposed for interpolated strings.


> Except that's not what's happening here. It's lowering to a template defined by the language, not the user. The user creates their own API (not language) by accepting such a template and unsurprisingly can react differently to different parameters to said function or template.

"creates their own API" => AST macros


> If you have an example that proves me wrong, I'd love to see it. How can this feature do something that is "like AST macros"?

Because the proposed templates modify the behavior of basic types. From the discussion:

> i"$apples and ${%d}bananas"
> =>
> (__d_format_literal!(Format.init, " and ", Format("%d")),
 apples, bananas)

On Monday, 24 February 2020 at 20:55:16 UTC, Walter Bright wrote:
> and proposed a lowering to:
>
> > i"your hex data is ${%02x}someByte"
> >
> > (_d_interpolated_string!("your hex data is ",
> > _d_interpolated_format_spec("%02x"))(), someByte)

Do you understand that `_d_interpolated_string` and `_d_interpolated_format_spec` are to be defined EXCLUSIVELY inside druntime?

There's nothing user-defined about this.

On Monday, 24 February 2020 at 21:23:43 UTC, Adam D. Ruppe wrote:
> On Monday, 24 February 2020 at 20:55:16 UTC, Walter Bright wrote:
>> and proposed a lowering to:
>>
>> > i"your hex data is ${%02x}someByte"
>> >
>> > (_d_interpolated_string!("your hex data is ",
>> > _d_interpolated_format_spec("%02x"))(), someByte)
>
> Do you understand that `_d_interpolated_string` and `_d_interpolated_format_spec` are to be defined EXCLUSIVELY inside druntime?
>
> There's nothing user-defined about this.

Does that mean no betterC support if it's in druntime?

Actually, was it different with the pure tuple approach in DIP1027?

On 2/24/20 4:10 PM, Walter Bright wrote:
> On 2/24/2020 12:19 PM, Steven Schveighoffer wrote:
>> How can you possibly arrive at this conclusion? We lower to templates all the time.
> 
> The language is nowhere defined as lowering to specific templates. There are indeed some lowerings to templates in the implementation of the language, but those are NOT user defined templates, they are simply an implementation convenience.

typeid expressions lower to a TypeInfo object. That is a specific named object in object.d.

All we're saying is that it lowers to a specified type in object.d.

>> By this definition all operator overloading in D is AST macros.
> 
> Operator overloading is not supported for basic types. It's fundamentally different from what was proposed for interpolated strings.

Not at all. In fact, operator overloading lowers to a specific template on that type, which allows the user to write whatever code they want. This is how lowering works.

Our proposal is even more restrictive, as the template and its API are actually defined by the language.

>> Except that's not what's happening here. It's lowering to a template defined by the language, not the user. The user creates their own API (not language) by accepting such a template and unsurprisingly can react differently to different parameters to said function or template.
> 
> "creates their own API" => AST macros

No. It's overloading, not AST macros. How can an overload affect the AST other than to generate code specific to the type being accepted?

>> If you have an example that proves me wrong, I'd love to see it. How can this feature do something that is "like AST macros"?
> 
> Because the proposed templates modify the behavior of basic types. From the discussion:
> 
>  > i"$apples and ${%d}bananas"
>  > =>
>  > (__d_format_literal!(Format.init, " and ", Format("%d")),
>   apples, bananas)

Where is the basic type modification here? i"..." is not a basic type, it's a string interpolation. It's never been in the language before. It doesn't translate into any basic type, it translates into a compile-time list of expressions.

How is this an AST macro, but (string-literal, apples, bananas) not?

---

Probably this is being misunderstood. Let me rephrase the proposal. Let's assume we agree on the format string grammar that was presented in the DIP:

i"$apples and $%{d}bananas" will be transformed into:

(interpolation_spec, apples, bananas)

Where interpolation spec will be an instance of a language-defined type. It will have the following API:

1. spec.formatString!(s) where s is a string, will be a compile-time constant format string (guaranteed to end in a null character) where all the interpolated expressions are handled as follows:
  a. If an interpolation expression is preceded with {x}, where x is the string literal in the braces, the entire interpolation expression will be replaced with the string literal x.
  b. If an interpolation expression is not preceded with {...}, then the entire interpolation expression will be replaced with the string `s` passed into the formatString member template.

2. spec.formatStringZ() will return the equivalent of `formatString!("%s").ptr`.
3. If all interpolations are determined to have a {...} specifier, then the interpolation_spec can be implicitly converted to a null-terminated const(char)*.

4. There will be an isInterpolationSpec(T) template added to object.d which will return true if the parameter T is an interpolation spec type.

---

That's it. The whole definition of the template and whatever is simply implementation details.

-Steve

On 2/24/20 4:41 PM, aliak wrote:
> On Monday, 24 February 2020 at 21:23:43 UTC, Adam D. Ruppe wrote:
>> On Monday, 24 February 2020 at 20:55:16 UTC, Walter Bright wrote:
>>> and proposed a lowering to:
>>>
>>> > i"your hex data is ${%02x}someByte"
>>> >
>>> > (_d_interpolated_string!("your hex data is ",
>>> > _d_interpolated_format_spec("%02x"))(), someByte)
>>
>> Do you understand that `_d_interpolated_string` and `_d_interpolated_format_spec` are to be defined EXCLUSIVELY inside druntime?
>>
>> There's nothing user-defined about this.
> 
> Does that mean no betterC support if it's in druntime?

It will be supported in betterC, as long as you have object.d available. This does not require any D features such as TypeInfo, ModuleInfo, static constructors, GC, etc.

-Steve

On 2/24/20 4:45 PM, Steven Schveighoffer wrote:
> i"$apples and $%{d}bananas" will be transformed into:

Of course that should have read i"$apples and ${%d}bananas"

-Steve

On 2/24/2020 1:45 PM, Steven Schveighoffer wrote:
> Our proposal is even more restrictive, as the template and its API are actually defined by the language.

API is defined by the language, but not the behavior.


> No. It's overloading, not AST macros. How can an overload affect the AST other than to generate code specific to the type being accepted?

"generate code" is how.


> How is this an AST macro, but (string-literal, apples, bananas) not?

Because its behavior is defined by a template, not the language spec.


> That's it. The whole definition of the template and whatever is simply implementation details.

No, it isn't. It's leaving things up to templates like "formatString".

There are other instances of the compiler lowering things to templates, but the behavior is still defined by the language, not the template. The templates were not strictly necessary, they were just a convenience.

Operator overloading is for user defined types, not builtin types.

---

The semantics of an interpolated string must be defined by the DIP, not deferred to some template. If the implementation of those defined language features is done by a template, that is an implementation choice, not part of the DIP or spec.

My inference of the discussion about this in the n.g. was the templates would be used so users could customize the behavior to be whatever they wanted.