New programming paradigm

[EntangledQuanta via Digitalmars-d-learn]

On Thursday, 7 September 2017 at 14:28:14 UTC, Biotronic wrote:
> On Wednesday, 6 September 2017 at 23:20:41 UTC, EntangledQuanta 
> wrote:
>> So, no body thinks this is a useful idea or is it that no one 
>> understands what I'm talking about?
>
> Frankly, you'd written a lot of fairly dense code, so 
> understanding exactly what it was doing took a while. So I sat 
> down and rewrote it in what I'd consider more idiomatic D, 
> partly to better understand what it was doing, partly to 
> facilitate discussion of your ideas.
>
> The usage section of your code boils down to this:
>


Sorry, I think you missed the point completely... or I didn't 
explain things very well.

I see no where in your code where you have a variant like type.


What I am talking about is quite simple: One chooses the correct 
template to use, not at compile time based on the type(like 
normal), but at runtime based on a runtime variable that 
specifies the type. This is has variants are normally used except 
one must manually call the correct function or code block based 
on the variable value.


Here is a demonstration of the problem:


import std.stdio, std.variant, std.conv;



void foo(T)(T t)
{
	writeln("\tfoo: Type = ", T.stringof, ", Value = ", t);
}

void bar(Variant val)
{
	writeln("Variant's Type = ", to!string(val.type));

	// foo called with val as a variant
	foo(val);

	writeln("Dynamic type conversion:");
	switch(to!string(val.type))
	{
		case "int": foo(val.get!int); break;	// foo called with val's 
value as int
		case "float": foo(val.get!float); break;	// foo called with 
val's value as float
		case "immutable(char)[]": foo(val.get!string); break;	// foo 
called with val's value as string
		case "short": foo(val.get!short); break;	// foo called with 
val's value as short
		default: writeln("Unknown Conversion!");
	}


}

void main()
{
	Variant val;
	writeln("\nVarant with int value:");
	val = 3;
	bar(val);
	writeln("\n\nVarant with float value:");
	val = 3.243f;
	bar(val);
	writeln("\n\nVarant with string value:");
	val = "XXX";
	bar(val);
	writeln("\n\nVarant with short value:");
	val = cast(short)2;
	bar(val);

	getchar();
}

Output:

Varant with int value:
Variant's Type = int
         foo: Type = VariantN!20u, Value = 3
Dynamic type conversion:
         foo: Type = int, Value = 3


Varant with float value:
Variant's Type = float
         foo: Type = VariantN!20u, Value = 3.243
Dynamic type conversion:
         foo: Type = float, Value = 3.243


Varant with string value:
Variant's Type = immutable(char)[]
         foo: Type = VariantN!20u, Value = XXX
Dynamic type conversion:
         foo: Type = string, Value = XXX


Varant with short value:
Variant's Type = short
         foo: Type = VariantN!20u, Value = 2
Dynamic type conversion:
         foo: Type = short, Value = 2

The concept to gleam from this is that the switch calls foo with 
the correct type AT compile time. The switch creates the mapping 
from the runtime type that the variant can have to the compile 
time foo.

So the first call to foo gives: `foo: Type = VariantN!20u, Value 
= 2`. The writeln call receives the val as a variant! It knows 
how to print a variant in this case, lucky for us, but we have 
called foo!(VariantN!20u)(val)!

But the switch actually sets it up so it calls 
foo!(int)(val.get!int). This is a different foo!

The switch statement can be seen as a dynamic dispatch that calls 
the appropriate compile time template BUT it actually depends on 
the runtime type of the variant!

This magic links up a Variant, who's type is dynamic, with 
compile time templates.

But you must realize the nature of the problem. Most code that 
uses a variant wouldn't use a single template to handle all the 
different cases:

	switch(to!string(val.type))
	{
		case "int": fooInt(val.get!int); break;	
		case "float": fooFloat(val.get!float); break;	
		case "immutable(char)[]": fooString(val.get!string); break;	
		case "short": fooShort(val.get!short); break;
		default: writeln("Unknown Conversion!");
	}



These functions might actually just be code blocks to handle the 
different cases.

Now, if you understand that, the paradigm I am talking about is 
to have D basically generate all the switching code for us 
instead of us ever having to deal with the variant internals.

We have something like

void bar(var t)
{
	writeln("\tbar: Type = ", t.type, ", Value = ", t);
}


AND it would effectively print the same results. var is akin to 
variant but the compiler understands this and generates N 
different bar's internally and a switch statement to dynamically 
call the desired one at runtime, yet, we can simply call bar with 
any value we want.

e.g.,

void main()
{
    bar(3); // calls bar as if bar was `void bar(int)`
    bar(3.4f); // calls bar as if bar was `void bar(float)`
    bar("sad"); // calls bar as if bar was `void bar(string)`
}

and the writeln in bar never sees a variant type(just like it 
doesn't in the first case with the switches).

As you can see, the code is much much less verbose. No switch 
statements are written by hand. bar is sort of like a template 
because it can accept different types.

The code I wrote simulates the above by using a mixin template to 
generate the switches and uses a template to call the right bar:

enum Types
{
    Int,
    Float,
    String,
    Short
}

void bar(T)(T t)
{
     writeln("\tbar: Type = ", t.type, ", Value = ", t);
}

void main()
{
    mixin(EnumMapper!("bar", Types, 3));
    mixin(EnumMapper!("bar", Types, 3.4f));
    mixin(EnumMapper!("bar", Types, "sad"));
}

Note that each mixin is a switch statement.

It's still much shorter than the original solution, specially if 
one uses dynamic types a lot... but still quite verbose. Imagine 
if the compiler did this for us!! Not only would it be very 
elegant it is also fast because it's just a switch statement. It 
basically turns dynamic types in to compile time types(at the 
cost of the switches, which is just a cmp and jmp instruction). 
dynamic in C# is pretty slow because it has to do a bit more than 
this, since it doesn't actually have a compile time template like 
D has.

Is that more clear? What it would allow us to do, if we wanted, 
is to never use auto or any explicit types and we would have 
something like a D version of a dynamically typed language(again, 
at the cost of the switches, but it's all hidden from us).

Of course, there are two problems with this: 1. The types have to 
be known at compile time(so it can generate the switch, although 
'default' could be used to handle unknown cases using standard 
techniques). 2. At some point we generally will have to do some 
type of manual switch on the types. Writeln, for example, does 
this internally for us, which is why I used it. If the types are 
confluent, then we can get away with out doing this such as the 
confluent primitive types. e.g., if we were just adding two 
numbers, we could have

auto bar(var t1, var t2) { return t1 + t2; }

and it would work as long as t1 and t2 were confluent.

What's more is that if we later decide we want to use only a 
specific type, we don't have to change anything but could simply 
change var to one of the types such as int, and the compiler and 
optimize out the switch.

What's more, is that we can return var's and this allows us to do 
do things like

var foo(var x)
{
    if (x == 3)
     return x;
    return "error!";
}

or whatever. It's clear, concise, fast, and bridges the gap 
between compile time and runtime variables. It obviously can't 
solve the impossible but does provide a nice solution for certain 
problems and for simple uses. I think the main drawback is that 
one can't really use this to the extreme because the code will 
explode both in size and performance cost. All those switches 
will add up in both memory size and cycles... I'm not sure if 
that would effect normal usage though.