So the interpolated dip thread got me thinking, and wondering if any time there's been a proposal for an opMixin? It can possibly be the hash tag symbol? And opMixin does what mixin does, and mixes the code in the spot.

struct interpolator {
  void opMixin!(string)() {
  }
}

// globally declared interpolator
interpolator i;

--- code.d

import interpolation;

string str = i#"an ${interpolated} string";

Advantages over template mixins include that this has a return type so it can be used to create things out of the current context and give you something back.

auto html = json#q{ // compile error if invalid json
  "hello": "${variable}",
  "another: "${a + b}",
};

Another one is function mixin templates? So maybe that can be done with eponymous mixin templates?

mixin template i(string str) {
    string i() {
        return str;
    }
}

string s = i#"someting";

If it can't be done eponymously then how about:

mixin string s(string str)() {
  // parse str
  return mixin(stuff);
}

You get the hygiene with # as I believe it's not used anywhere? And this enables string interpolation libraries that have the syntax that any or all of the dips that are being propose have.

- ali

On Thursday, 12 December 2019 at 10:33:21 UTC, aliak wrote:
> struct interpolator {
>   void opMixin!(string)() {
>   }
> }
>
> // globally declared interpolator
> interpolator i;

Ok, so this is interesting, in the sense that you can have a runtime configured interpolator that can take localization for various countries into account.

But opMixin should take any parameter, not just string.

so you could do:

i#"string"
i#3
i#(3,4,5)

> Advantages over template mixins include that this has a return type so it can be used to create things out of the current context and give you something back.

Yes.

It could be used for composition at runtime.

But how do you type check the resulting code?

This is getting close to AST macros... but you should be able to put constraint on the resulting AST.

On Thursday, 12 December 2019 at 10:33:21 UTC, aliak wrote:
> So the interpolated dip thread got me thinking, and wondering if any time there's been a proposal for an opMixin? It can possibly be the hash tag symbol? And opMixin does what mixin does, and mixes the code in the spot.
>
> struct interpolator {
>   void opMixin!(string)() {
>   }
> }
>
> // globally declared interpolator
> interpolator i;
>
> --- code.d
>
> import interpolation;
>
> string str = i#"an ${interpolated} string";
>
> Advantages over template mixins include that this has a return type so it can be used to create things out of the current context and give you something back.
>
> auto html = json#q{ // compile error if invalid json
>   "hello": "${variable}",
>   "another: "${a + b}",
> };
>
> Another one is function mixin templates? So maybe that can be done with eponymous mixin templates?
>
> mixin template i(string str) {
>     string i() {
>         return str;
>     }
> }
>
> string s = i#"someting";
>
> If it can't be done eponymously then how about:
>
> mixin string s(string str)() {
>   // parse str
>   return mixin(stuff);
> }
>
> You get the hygiene with # as I believe it's not used anywhere? And this enables string interpolation libraries that have the syntax that any or all of the dips that are being propose have.
>
> - ali

this is similar to my idea. for reference:
https://forum.dlang.org/post/qqrblbqygugpkkqgttxp@forum.dlang.org

I'm all in favor of improving D meta programming to the point we can express stuff like string interpolation in library code because it might allow for other new cool stuff we were not able to do before.

On Thursday, 12 December 2019 at 11:48:47 UTC, Zoadian wrote:
> I'm all in favor of improving D meta programming to the point we can express stuff like string interpolation in library code because it might allow for other new cool stuff we were not able to do before.

Yes, but you also need to reduce the chance of the mixin doing things completely unexpected or being used for weird things.

I suggest the following constraints:

1. opMixin should resolve to the executing of an anonymous function with the following constraints:

   a. the function must return something that can be used in an expression

   b. the function must be pure

   c. all parameters given to the function must be const

   d. all the parameters given to the function must be found in the opMixin input

   e. parameters should compile (obviously)

2. opMixin can only be used where you have a expression

1d) will be adhoc for strings, basically it requires the opMixin output function parameters to be word-boundary substrings in the opMixin input.

So i#"My {value} pony +2" could result in a one parameter function like this:

anonfunc(value)
anonfunc(My)
anonfunc(pony)
anonfunc(pony +2)

but nothing else (for 1 parameter)

On Thursday, 12 December 2019 at 11:39:46 UTC, Ola Fosheim Grøstad wrote:
> [snip]
>
> This is getting close to AST macros... but you should be able to put constraint on the resulting AST.

If it is anything like AST macros, then I wouldn't expect Walter to be that supportive of it...

On Thursday, 12 December 2019 at 11:48:47 UTC, Zoadian wrote:
> [snip]
>
> this is similar to my idea. for reference:
> https://forum.dlang.org/post/qqrblbqygugpkkqgttxp@forum.dlang.org
>

The comment immediately after yours (at least viewing it on the web client) but not directly responding to you is about re-inventing the Lisp reader macro. I don't know much about Lisp, but when I checked it out [1] it looks quite similar to what people are trying to achieve with this idea. One difference would be that in Lisp they can assign the reader macro to something like "`" or "'", which I imagine Walter would be opposed to because he does not favor creating arbitrary DSL's.

[1] https://lisper.in/reader-macros

On Thursday, 12 December 2019 at 14:28:52 UTC, jmh530 wrote:
> If it is anything like AST macros, then I wouldn't expect Walter to be that supportive of it...

It isn't. Just typing constraints.

A string mixin that is type checked after construction.

On Thursday, 12 December 2019 at 11:48:47 UTC, Zoadian wrote:

> I'm all in favor of improving D meta programming to the point we can express stuff like string interpolation in library code because it might allow for other new cool stuff we were not able to do before.

I'm not, because you'll drive away large numbers of potential users. Metaprogramming might be cool, but you need to keep it under control because it can make the complexity of learning and using the language explode.

On Thu, Dec 12, 2019 at 04:53:36PM +0000, bachmeier via Digitalmars-d wrote:
> On Thursday, 12 December 2019 at 11:48:47 UTC, Zoadian wrote:
> 
> > I'm all in favor of improving D meta programming to the point we can express stuff like string interpolation in library code because it might allow for other new cool stuff we were not able to do before.
> 
> I'm not, because you'll drive away large numbers of potential users. Metaprogramming might be cool, but you need to keep it under control because it can make the complexity of learning and using the language explode.

Wut...?!  The primary reason I'm using D is *because* of metaprogramming features.  It's one of the things about D that stands out above other languages and differentiates it from them.  For me, it's one of the important things that make it worth using D in spite of whatever other flaws D may have.

Adam is currently working on a Java<->D glue library via JNI, which is turning out to be *extremely* nice: you just declare a class and annotate its methods with @Import and @Export, and it automagically creates JNI glue code, creates the right mangling, handles type conversions, etc., and you can call Java code from D directly (and vice versa).  You don't even need to do anything special (other than link with the JNI interface library of your chosen JVM) to make this work; just "import arsd.jni", derive your class from the provided template base class, and start calling Java methods like they were native D code.

The core of this library is some powerful metaprogramming not found in any other language to my knowledge.  Compile-time introspection, static foreach, UDAs, and pragma(mangle) all come together in one powerful package that completely automates what in any other language would have required truckloads of boilerplate and awkward external code generation tools. In D, the entire implementation sits in a single .d file.

Bring on the metaprogramming, I say.  Make string interpolation another powerful tool in the metaprogramming toolbox, and take D to a whole new level of awesome.  We should be embracing and honing metaprogramming in D, not shying away from it!


T

-- 
"You are a very disagreeable person." "NO."

On Thursday, 12 December 2019 at 10:33:21 UTC, aliak wrote:
> [snip]
>
> You get the hygiene with # as I believe it's not used anywhere? And this enables string interpolation libraries that have the syntax that any or all of the dips that are being propose have.
>
> - ali

The idea for the convenience operator is discussed on the DIP 1027 thread [1] by Paul Backus (though he uses @ and I'm a bit more sympathetic to your #). The way he describes it is just a simple re-write of
writeln(@interp!"The number ${num} doubled is ${num * 2}!"));
to
writeln(mixin(interp!"The number ${num} doubled is ${num * 2}!"));

I find it an interesting idea, but wonder what the consequences of this are more generally.


[1] https://forum.dlang.org/thread/abhpqwxqgiyzgqxmjaky@forum.dlang.org?page=7#post-tlyhhcpomntiwoqxsvjj:40forum.dlang.org