New programming paradigm

[EntangledQuanta via Digitalmars-d-learn]

On Thursday, 7 September 2017 at 15:36:47 UTC, Jesse Phillips 
wrote:
> On Monday, 4 September 2017 at 03:26:23 UTC, EntangledQuanta 
> wrote:
>> To get a feel for what this new way of dealing with dynamic 
>> types might look like:
>>
>> void foo(var y) { writeln(y); }
>>
>> var x = "3"; // or possibly var!(string, int) for the explicit 
>> types used
>> foo(x);
>> x = 3;
>> foo(x);
>>
>> (just pseudo code, don't take the syntax literally, that is 
>> not what is important)
>>
>> While this example is trivial, the thing to note is that there 
>> is one foo declared, but two created at runtime. One for 
>> string and one for and int. It is like a variant, yet we don't 
>> have to do any testing. It is very similar to `dynamic` in C#, 
>> but better since actually can "know" the type at compile time, 
>> so to speak. It's not that we actually know, but that we write 
>> code as if we knew.. it's treated as if it's statically typed.
>
> It is an interesting thought but I'm not sure of its utility. 
> First let me describe how I had to go about thinking of what 
> this means. Today I think it would be possible for a given 
> function 'call()' to write this:
>
>     alias var = Algebraic!(double, string);
>
>     void foo(var y) {
>         mixin(call!writeln(y));
>     }
>
> Again the implementation of call() is yet to exist but likely 
> uses many of the techniques you describe and use.
>
> Where I'm questioning the utility, and I haven't used C#'s 
> dynamic much, is with the frequency I'm manipulating arbitrary 
> data the same, that is to say:
>
>     auto m = var(4);
>     mixin(call!find(m, "hello"));
>
> This would have to throw a runtime exception, that is to say, 
> in order to use the type value I need to know its type.

All types have a type ;) You specified in the above case that m 
is an int by setting it to 4(I assume that is what var(4) means). 
But the downside, at least on some level, all the usable types 
must be know or the switch cannot be generated(there is the 
default case which might be able to solve the unknown type 
problem in some way).

> A couple of additional thoughts:
>
> The call() function could do something similar to pattern 
> matching but args could be confusing:
>
>     mixin(call!(find, round)(m, "hello"));
>
> But I feel that would just get confusing. The call() function 
> could still be useful even when needing to check the type to 
> know what operations to do.
>
>     if(m.type == string)
>         mixin(call!find(m, "hello"));
>
> instead of:
>     if(m.type == string)
>         m.get!string.find("hello");

The whole point is to avoid those checks as much as possible. 
With the typical library solution using variant, the checks are 
100% necessary. With the solution I'm proposing, the compiler 
generates the checks behind the scenes and calls the template 
that corresponds to the check. This is the main difference. We 
can use a single template that the switch directs all checks to. 
But since the template is compile time, we only need one, and we 
can treat it like any other compile time template(that is the 
main key here, we are leveraging D's template's to deal with the 
runtime complexity).

See my reply to Biotronic with the examples I gave as they should 
be more clear.

The usefulness of such things are as useful as they are. Hard to 
tell without the actual ability to use them. The code I created 
in the other thread was useful to me as it allowed me to handle a 
variant type that was beyond my control(given to me by an 
external library) in a nice and simple way using a template. 
Since all the types were confluent(integral values), I could use 
a single template without any type dispatching... so it worked 
out well.

e.g., Take com's variant. If you are doing com programming, 
you'll have to deal with it. The only way is a large switch 
statement. You can't get around that. Even with this method it 
will still require approximately the same checking because most 
of the types are not confluent. So, in these cases all the method 
does is push the "switch" in to the template. BUT it still turns 
it in to a compile time test(since the runtime test was done in 
the switch). Instead of one large switch one can do it in 
templates(and specialize where necessary) which, IMO, looks nicer 
with the added benefit of more control and more inline with how D 
works.

Also, most of the work is simply at the "end" point. If, say, all 
of phobos was rewritten to us these variants instead of runtime 
types, then a normal program would have to deal very little with 
any type checking. The downside would be an explosion in size and 
decrease in performance(possibly mitigated to some degree but 
still large).

So, it's not a panacea, but nothing is. I see it as more of a 
bridge between runtime and compile time that helps in certain 
cases quite well. e.g., Having to write a switch statement for 
all possible types a variable could have. With the mxin, or a 
comiler solution, this is reduced to virtually nothing in many 
cases and ends up just looking like normal D template code. 
Remember, a template is actually N different normal functions so 
they are quite useful for collapsing code down by large factors, 
which is why they are so useful.