www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP1027 + Design by Introspection

reply Daniel N <no public.email> writes:
DIP1027 + Design by Introspection

Since DIP1027 is simpler than DIP1036 I wanted to take a step 
back and see what could be done to fix DIP1027 to be even better 
than DIP1036.

1) q{} is designed for code generation it needs to be supported 
with Interpolation.
2) DbI

IMHO both DIP1027 and DIP1036 suffers when trying to support 
custom formatting...
which makes the syntax as hard to read as the original manual 
writefln format string.

My DIP1027+ proposal is based on UDA and can support any function 
with trivial syntax.
   printf(i"I ate $apples and $bananas totalling $(apples + 
bananas) fruit.");
writefln(i"I ate $apples and $bananas totalling $(apples + 
bananas) fruit.");

Key insight, the function specifies what format it expects.
printf(...)    formatting!printf_style
writefln(...)  formatting!writefln_style
This way it doesn't have to be repeated in user-facing code over 
and over.

Basically the compiler will invoke "printf_style!int" and the 
function will return "%d",
the compiler doesn't know anything about printf, it will just 
introspect/ask the function.
Feb 02
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 2 February 2021 at 15:55:23 UTC, Daniel N wrote:
 Since DIP1027 is simpler than DIP1036
This is a myth, with the exception of the implicit to string conversion. DIP 1027 had to break up the string and reconstruct a new one while reordering the tuple. DIP 1036 is a direct syntax rewrite. It just splits the string on the ${ character into a tuple and puts a simple struct wrapper around the string parts so you can identify them. See for yourself how simple the diff is: https://github.com/dlang/dmd/compare/master...adamdruppe:string_interp The implicit to string part isn't implemented (gotta figure out how to express `alias toString this;` inside the compiler basically, it might be easy but I don't know how).
 Key insight, the function specifies what format it expects.
 printf(...)    formatting!printf_style
 writefln(...)  formatting!writefln_style
DIP 1036 can do this as it is already written! You don't need a magic UDA, you just overload the function on the interp type as a library author. Or you can simply call a function inside the interpolation thing if you want to do custom stuff as a user.
Feb 02
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Tuesday, 2 February 2021 at 16:57:36 UTC, Adam D. Ruppe wrote:
 On Tuesday, 2 February 2021 at 15:55:23 UTC, Daniel N wrote:
 Since DIP1027 is simpler than DIP1036
This is a myth, with the exception of the implicit to string conversion. DIP 1027 had to break up the string and reconstruct a new one while reordering the tuple. DIP 1036 is a direct syntax rewrite. It just splits the string on the ${ character into a tuple and puts a simple struct wrapper around the string parts so you can identify them.
DIP 1027 is a single direct syntax rewrite with no library support required. DIP 1036 is two separate syntax rewrites, plus an algorithm for choosing between them, plus support code for the rewrites in druntime. DIP 1036 has plenty of advantages compared to DIP 1027, but trying to pretend it is a simpler proposal is just dishonest.
Feb 02
parent reply Daniel N <no public.email> writes:
On Tuesday, 2 February 2021 at 17:04:47 UTC, Paul Backus wrote:
 DIP 1036 has plenty of advantages compared to DIP 1027, but 
 trying to pretend it is a simpler proposal is just dishonest.
I thought the only thing everyone could agree on was that DIP1027 is less complex, at least I could get the gist of it in an instant in contrast to DIP1036. My mistake, I guess it hasn't been established as a fact, I was not intentionally misleading, for me it was as obvious as "the sky is blue", but people would contest that also since it's not always blue, now is it?
Feb 02
parent reply Paul Backus <snarwin gmail.com> writes:
On Tuesday, 2 February 2021 at 17:39:06 UTC, Daniel N wrote:
 On Tuesday, 2 February 2021 at 17:04:47 UTC, Paul Backus wrote:
 DIP 1036 has plenty of advantages compared to DIP 1027, but 
 trying to pretend it is a simpler proposal is just dishonest.
I thought the only thing everyone could agree on was that DIP1027 is less complex, at least I could get the gist of it in an instant in contrast to DIP1036.
Did you mean to reply to Adam instead of me? I agree with you--DIP 1027 is less complex than DIP 1036.
Feb 02
parent Daniel N <no public.email> writes:
On Tuesday, 2 February 2021 at 17:56:32 UTC, Paul Backus wrote:
 On Tuesday, 2 February 2021 at 17:39:06 UTC, Daniel N wrote:
 On Tuesday, 2 February 2021 at 17:04:47 UTC, Paul Backus wrote:
 DIP 1036 has plenty of advantages compared to DIP 1027, but 
 trying to pretend it is a simpler proposal is just dishonest.
I thought the only thing everyone could agree on was that DIP1027 is less complex, at least I could get the gist of it in an instant in contrast to DIP1036.
Did you mean to reply to Adam instead of me? I agree with you--DIP 1027 is less complex than DIP 1036.
My bad again ;) Yes!
Feb 02
prev sibling parent reply Daniel N <no public.email> writes:
On Tuesday, 2 February 2021 at 16:57:36 UTC, Adam D. Ruppe wrote:
 Key insight, the function specifies what format it expects.
 printf(...)    formatting!printf_style
 writefln(...)  formatting!writefln_style
DIP 1036 can do this as it is already written! You don't need a magic UDA, you just overload the function on the interp type as a library author. Or you can simply call a function inside the interpolation thing if you want to do custom stuff as a user.
In my opinion the user-facing interface of my proposal is cleaner as you don't have to introduce an interp template, you won't have to overload anything nor wrap anything.
Feb 02
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 2 February 2021 at 17:29:53 UTC, Daniel N wrote:
 In my opinion the user-facing interface of my proposal is 
 cleaner as you don't have to introduce an interp template, you 
 won't have to overload anything nor wrap anything.
But you have to modify the source code in the library anyway. And then how do you add new styles? How does formatting!printf_style actually get applied?
Feb 02
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 2/2/21 12:29 PM, Daniel N wrote:
 On Tuesday, 2 February 2021 at 16:57:36 UTC, Adam D. Ruppe wrote:
 Key insight, the function specifies what format it expects.
 printf(...)    formatting!printf_style
 writefln(...)  formatting!writefln_style
DIP 1036 can do this as it is already written! You don't need a magic UDA, you just overload the function on the interp type as a library author. Or you can simply call a function inside the interpolation thing if you want to do custom stuff as a user.
In my opinion the user-facing interface of my proposal is cleaner as you don't have to introduce an interp template, you won't have to overload anything nor wrap anything.
This is somewhat of a fallacy. You are overloading and wrapping (in a severely inflexible way). Just doing it with the compiler instead of an actual overload. Knowing how the compiler treats the rewrite is still a cognitive load on the user. And there are several issues: 1. It doesn't help when the function isn't "blueprint then data" style, which is costly compared to interleaved data, and only allows one interpolation string parameter. 2. It doesn't support "blueprint then data" implementations that require positional parameters (for example, Postgresql). And if you wanted something to support this, a. you'd have to rename it, as an overload would match the existing function, and b. you would still be able to call either function with either style (string + args or interpolation tuple). 3. It doesn't allow compile-time processing of the format string, nor really any useful compile-time introspection that isn't already available with the type being passed in the value tuple anyway. 4. There is no mechanism to overload "compiler-provided formats" with "user-provided formats". This means the resulting function must still guard against invalid input, instead of making it a compiler error (except, of course, with the magic help of the compiler specifically for printf). I want to expand a bit on point 1 too. Consider that DIP1036 is a straight rewrite of i"a${b}${c}d" as interp!"a", b, c, interp!"d". This is straightforward, intuitive, and can be explained easily. DIP1027 is a rewrite of i"a${b}${c}d" as "a%s%sd", b, c. This is not intuitive, nor cheap. I know it seems intuitive to C programmers, but for sure, blueprint+args is NOT intuitive to those not used to printf. Not only that but guess what functions like printf and writef do. They reinterpret the parameters using the blueprint to get them back into order. And this means iterating in parallel a PARSED version of the blueprint along with the parameters. Why would we want to do something that's harder to explain, harder to implement, and ironically round tripped from something parsed at compile-time to something that requires runtime parsing? I would note that DIP1027 would be a great CIP. D is not C. We have insanely good tools for this. Making it so you can't use introspection tools is not my idea of "better". -Steve
Feb 02
parent Daniel N <no public.email> writes:
On Tuesday, 2 February 2021 at 18:47:48 UTC, Steven Schveighoffer 
wrote:
 I would note that DIP1027 would be a great CIP. D is not C. We 
 have insanely good tools for this. Making it so you can't use 
 introspection tools is not my idea of "better".

 -Steve
That was some good destructing, kudos! I still think UDA has merit, but I can't fix all your concerns without increasing complexity even beyond DIP1036. Will try from the other direction, to see if I can offer any ideas to simplify DIP1036 instead... /Daniel
Feb 03
prev sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Tuesday, 2 February 2021 at 15:55:23 UTC, Daniel N wrote:
 DIP1027 + Design by Introspection

 Since DIP1027 is simpler than DIP1036 I wanted to take a step 
 back and see what could be done to fix DIP1027 to be even 
 better than DIP1036.

 1) q{} is designed for code generation it needs to be supported 
 with Interpolation.
 2) DbI

 IMHO both DIP1027 and DIP1036 suffers when trying to support 
 custom formatting...
 which makes the syntax as hard to read as the original manual 
 writefln format string.

 My DIP1027+ proposal is based on UDA and can support any 
 function with trivial syntax.
   printf(i"I ate $apples and $bananas totalling $(apples + 
 bananas) fruit.");
 writefln(i"I ate $apples and $bananas totalling $(apples + 
 bananas) fruit.");

 Key insight, the function specifies what format it expects.
 printf(...)    formatting!printf_style
 writefln(...)  formatting!writefln_style
 This way it doesn't have to be repeated in user-facing code 
 over and over.

 Basically the compiler will invoke "printf_style!int" and the 
 function will return "%d",
 the compiler doesn't know anything about printf, it will just 
 introspect/ask the function.
We don't need more built in attributes to an attribute filled language. -Alex
Feb 02
parent Daniel N <no public.email> writes:
On Tuesday, 2 February 2021 at 18:36:30 UTC, 12345swordy wrote:
 We don't need more built in attributes to an attribute filled 
 language.

 -Alex
Sorry to inform you that this one kinda already exist. https://dlang.org/spec/pragma.html#printf Although, I prefer attributes over pragma, as it can be introspected. It's actually a fairly common solution, even gcc has format attribute: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html See "format (archetype, string-index, first-to-check)"
Feb 02