Add `define` macro with first argument treated as `this` to enable chaining

[dadhi]

I want to be able chain the output produced by define macro, e.g.

define AppendCsv($strBuilder, $list, $itemStr) {
     for (var i = 0; i < $list.Count, ++i)
         (i == 0 ? strBuilder : strBuilder.Append(", "))
             .Append($itemStr($list[i]));
     return $strBuilder;
}

string Curly(string x) => "{"+x+"}";
s.Append("(").AppendCsv(args, Curly).Append(")");

[qwertie]

This, in fact, would require changes to LeMP's engine, not just the define macro.

The problem is that a.b(c) essentially means (a.b)(c) and although macros can register themselves with the . operator to trigger on a.b, they cannot trigger on the parent expression a.b(c).

Making this more difficult, you want to be able to use a for loop inside an expression. Luckily I have already implemented limited support for this via the #ecs macro in combination with #runSequence... but it doesn't work in all cases (plain-old C# doesn't support it, and LeMP doesn't have access to type information, occasionally leading to awkward situations where statements-in-expressions can't be converted to C#.)

[dadhi]

@qwertie Thanks for the answer.

Do you have the docs, or samples, or tests for all macros available.. or maybe you can suggest the way how to search for them?

[qwertie]

The docs are here, each macro documented with a simple example. Hmm, I wonder if I forgot to link to any important macros from that main page... in any case, at the bottom you'll see 5 pages of documentation, and every macro should be mentioned on one of those 5 pages. Also, you can ask LeMP itself what macros it knows about (with brief documentation) by typing #printKnownMacros;.

[qwertie]

Note that Loyc APIs such as LNode are documented separately here. Here is a guide to using Loyc trees.

[dadhi]

@qwertie Really appreciate the docs. Personally, I always struggle to write them.

#printKnownMacros;

Cool!

[dadhi]

@qwertie

I found the tests for #runSequence here https://github.com/qwertie/ecsharp/blob/1743316eeb4ad57daba57fdc1e8dd5d2a47ebe98/Main/LeMP/Tests/TestSequenceExpressionMacro.cs

but still failing to understand when is fine to apply it... maybe missing something crucial here.

Meanwhile, I am experimenting with this kind of define operator where $s is a StringBuilder:

    define operator<<($s, $x) => $s.Append($x);

    define operator>>($s, ($items, $itemStr))
    {
        for (var i = 0; i < $items.Count; ++i)
            (i == 0 ? $s : $s << ", ") << $itemStr(its[i]);
        $s;
    }

Calling it like so

s << '(' >> (n.Arguments, ExpressionToCSharp) << ')';

produces kind of cryptic error:

CompileTimeDI.ecs(66,1,173,2): error : LeMP.StandardMacros.compileTime: (36,5): error CS0103: The name '_aposx2E' does not exist in the current context - in <    @_aposx2E(_numfor(_num(i), i < args.Count, _num(++i), > [C:\Code\LempTemplatingTest\CompileTimeDI\CompileTimeDI.csproj]

Btw, do you support define overloading/matching based on the input pattern, I want both to be <<.
Tried, but got and Ambiguous macros error.

[qwertie]

Um... I guess you're going for a C++-style cout << foo thing here, but in that case why mix << and >>? And what is its intended to mean?

_aposx2E represents '. and refers to the dot operator (I'll change it to output _apos_period in the next version so it's easier to see the connection with '.), while _numfor refers to a for loop. It looks like in the macro expansion, the left-hand side of the dot operator is a for loop, which can't be translated sensibly to C#, but the printer is trying its best to do a conversion anyway.

[dadhi]

but in that case why mix << and >>

I am using it just to distinguish from << to prevent ambiguous macros error. I would love to use << for the loop operation as well.

_aposx2E represents '. and refers to the dot operator (I'll change it to output _apos_period in the next version so it's easier to see the connection with '.)

Thanks.

My question is specifically about the define below - ignore the actual operator name selected

    define operator>>($s, ($items, $itemStr))
    {
        for (var i = 0; i < $items.Count; ++i)
            (i == 0 ? $s : $s << ", ") << $itemStr(its[i]);
        $s; // How to return a thing from macro?
    }

How can I combine for loop and "returning" something from define. I have looked at #runSequence tests as examples but I am not sure how to apply it in this case.

[qwertie]

define defines a macro to replaces one syntactic pattern with another, so if you write define foo($x) { while($x<10) $x++; } and then result = foo(xyz);, you'll get a nonsense result conceptually like result = (while ($x < 10) x++;), but it's actually printed as result = _numwhile(xyz < 10, xyz++);.

If you intend to use an operator in a C# expression, it must itself be an expression, but since the output of define is defined with a braced block, the expression must be written in statement notation (with a semicolon!):

define MulDiv($a, $b, $c) { ($a * $b) + $c; }
result = MulDiv(x, y, z);

// output
result = (x * y) + z;

The #ecs and #runSequence macros can often be used to work around this. I'm actually surprised that #runSequence {...} doesn't work, I think it's an oversight on my part.

There's a workaround as shown here:

#ecs;

define runSequence({ $(..args); }) {
	#runSequence($args);
}
define MakeItBig($x) {
	runSequence {
		while ($x < 1_000_000)
			$x *= 2;
		$x;
	}
}
void fn() {
	int x = 5;
	Console.WriteLine(MakeItBig(x));
}

// Generated from Untitled.ecs by LeMP 2.8.2.0.
void fn() {
	int x = 5;
	while (x < 1000000)
		x *= 2;
	Console.WriteLine(x);
}

Now, the behavior of #runSequence depends on context - if you write double x = #runSequence(Console.WriteLine(), Math.PI) at class scope, it employs a different transformation than if you use it at function scope, or rather, that's what it's supposed to do. Shockingly, #runSequence isn't processing double x = #runSequence(Console.WriteLine(), Math.PI); at all inside a function right now. That's a bug.

Unfortunately, if you are not inside a function nor a class, #runSequence doesn't work at all and ignores your request. Notably, compileTime and precompute are not contexts recognized by #runSequence at the present time.

So my advice is not to use #runSequence right now - If you are tempted to run statements inside define(), I recommend defining an ordinary function instead. Of course, you can also define an operator transformation that calls the ordinary function.

// MakeItBig as an ordinary function - based on my Loyc.Math generic numerics library
class Methods {
	public static T MakeItBig<T>(ref T x) {
		var m = Maths<T>.Math;
		while (m.IsLess(x < m.From(1000000)))
			x = m.Mul(x, m.From(2));
		return x;
	}
}

Finally, if you need to give one macro priority over another, you can:

define operator<<($a, $b) {
    $a.Append($b);
}
[PriorityOverride, Passive]
define operator<<($a, ($x, $y)) {
    $a.Append($x + $y); // or whatever
}

sb << foo << (a, b);

Alternately, use [PriorityFallback] to give one definition lower priority than another. However I would personally avoid defining that first macro because it completely replaces the original << operator, which can no longer be used.

[dadhi]

@qwertie
Thanks for the detailed answer. Will wait for the fixes.

Quick question, can I use the define macro of the two arguments (patterns) as a binary operator? Asking because it would be great for solving the fluent chain of opetations without overriding the "standard" operators.
Also I saw in the code somewhere the postfix `fooBar` notation.

[dadhi]

@qwertie Hi again,

Following the recent release of Source Generators I see them now as a niche solution with they own problems (including the maturity one).. So that returns me back to LeMP :)

Did you have a chance to look at this thing

Shockingly, #runSequence isn't processing double x = #runSequence(Console.WriteLine(), Math.PI); at all inside a function right now. That's a bug.

And sorry for bothering.