I think adding more dynamic typing to D would be a splendid idea to
further widen the variety of solutions for different problems.
Modular app development is a very good practice and modularity means
dynamicity, which in turn means, that one needs to give up on lots of
sweet stuff like templates, overloading and string mixins.
Variant is the first step towards dynamic alter-ego of D, which is
completely undeveloped currently.
Although my benchmarks show, that variant is quite slow and I'd really
like a version of variant, optimized for ultimate performance.
Also, there are lots of stuff, that i really need at run-time, which i
only have at compile-time:
* Interfaces. dynamic interfaces are very important to highly modular
applications, heavily based on plugins. By dynamic interfaces i mean
the set of attributes and methods of an object, which is only known at
run-time.
* Overloading. A.K.A multimethods. required by dynamic interfaces.
* Dynamic templates. In other words, value-based overloading (since
type is yet another attribute of dynamically typed data).

Dynamic interfaces are also different from static ones because the interface isn't _implemented_ by a type, it's _matched_ by a type, which means, that if a type fits into an interface at run-time, i can safely cast it to that interface type and work with it.

Being able to obtain the dynamic version of a delegate would be great to pass around generic callbacks.

Gor Gyolchanyan wrote:
> I think adding more dynamic typing to D would be a splendid idea to
> further widen the variety of solutions for different problems.
> Modular app development is a very good practice and modularity means
> dynamicity, which in turn means, that one needs to give up on lots of
> sweet stuff like templates, overloading and string mixins.
> Variant is the first step towards dynamic alter-ego of D, which is
> completely undeveloped currently.

If Algebraic/Variant could be recognized by the language it would give some interesting possibilities, like Variant array literals:

auto array = [10, 2.0, "abc"];

types it as Algebraic!(int, double, string)[];

auto AA = [ "a" : 10, "b" : 2.0, 3 : "abc" ];

types it as Algebraic!(int, double, string)[Algebraic!(string, int)];

for example, that may be used to express JSON structures with literals only:

int x, y;

auto json = [
    "x" : x,
    "y" : y,
    "colors" : [
        [
            r : 255,
            g : 0,
            b : 0
        ],
        [
            r : 0,
            g : 0,
            b : 255
        ]
    ]
]

On Tue, 25 Oct 2011 06:31:13 -0400, Piotr Szturmaj <bncrbme@jadamspam.pl> wrote:

> Gor Gyolchanyan wrote:
>> I think adding more dynamic typing to D would be a splendid idea to
>> further widen the variety of solutions for different problems.
>> Modular app development is a very good practice and modularity means
>> dynamicity, which in turn means, that one needs to give up on lots of
>> sweet stuff like templates, overloading and string mixins.
>> Variant is the first step towards dynamic alter-ego of D, which is
>> completely undeveloped currently.
>
> If Algebraic/Variant could be recognized by the language it would give
> some interesting possibilities, like Variant array literals:
>
> auto array = [10, 2.0, "abc"];
>
> types it as Algebraic!(int, double, string)[];
>
> auto AA = [ "a" : 10, "b" : 2.0, 3 : "abc" ];
>
> types it as Algebraic!(int, double, string)[Algebraic!(string, int)];
>
> for example, that may be used to express JSON structures with literals only:
>
> int x, y;
>
> auto json = [
>      "x" : x,
>      "y" : y,
>      "colors" : [
>          [
>              r : 255,
>              g : 0,
>              b : 0
>          ],
>          [
>              r : 0,
>              g : 0,
>              b : 255
>          ]
>      ]
> ]

Why do we need language support? This works in my variant proposal:

auto json = Variant(
    "x",x,
    "y",y,
    "colors", [[
        "r":255,
        "g":0,
        "b":0],[
        "r":0,
        "g":0,
        "b":255]
    ]
);

Granted if ["r":255,"g":0,"b":0] weren't all int, it would have to be declared Variant("r",255,"g",0,"b",0), but we could always shorten Variant to var or something.

Variant is heavy. It contains and does lots of things, that are not
always required.
a tiny type-less variable is versatile and can be used for any
purposes. It's even type-safe in debug mode.
Also, Variant needs explicit construction, whereas the tiny typeless
variable automatically accepts any value.
Also, Variant does not grant access to underlying raw data, but tiny
typeless value can be taken address of (void*).

On Tue, Oct 25, 2011 at 5:11 PM, Robert Jacques <sandford@jhu.edu> wrote:
> On Tue, 25 Oct 2011 06:31:13 -0400, Piotr Szturmaj <bncrbme@jadamspam.pl> wrote:
>
>> Gor Gyolchanyan wrote:
>>>
>>> I think adding more dynamic typing to D would be a splendid idea to
>>> further widen the variety of solutions for different problems.
>>> Modular app development is a very good practice and modularity means
>>> dynamicity, which in turn means, that one needs to give up on lots of
>>> sweet stuff like templates, overloading and string mixins.
>>> Variant is the first step towards dynamic alter-ego of D, which is
>>> completely undeveloped currently.
>>
>> If Algebraic/Variant could be recognized by the language it would give some interesting possibilities, like Variant array literals:
>>
>> auto array = [10, 2.0, "abc"];
>>
>> types it as Algebraic!(int, double, string)[];
>>
>> auto AA = [ "a" : 10, "b" : 2.0, 3 : "abc" ];
>>
>> types it as Algebraic!(int, double, string)[Algebraic!(string, int)];
>>
>> for example, that may be used to express JSON structures with literals only:
>>
>> int x, y;
>>
>> auto json = [
>>     "x" : x,
>>     "y" : y,
>>     "colors" : [
>>         [
>>             r : 255,
>>             g : 0,
>>             b : 0
>>         ],
>>         [
>>             r : 0,
>>             g : 0,
>>             b : 255
>>         ]
>>     ]
>> ]
>
> Why do we need language support? This works in my variant proposal:
>
> auto json = Variant(
>    "x",x,
>    "y",y,
>    "colors", [[
>        "r":255,
>        "g":0,
>        "b":0],[
>        "r":0,
>        "g":0,
>        "b":255]
>    ]
> );
>
> Granted if ["r":255,"g":0,"b":0] weren't all int, it would have to be declared Variant("r",255,"g",0,"b",0), but we could always shorten Variant to var or something.
>

I need an extremely fast and small typeless container for a single object, which i can use to implement a fast and efficient dynamic callback mechanism, where the exact number and types of parameters are only known to the callback and to the source of the parameter values and all intermediate manager classes, who hold and return the callback do not know it.

On Tue, Oct 25, 2011 at 5:20 PM, Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com> wrote:
> Variant is heavy. It contains and does lots of things, that are not
> always required.
> a tiny type-less variable is versatile and can be used for any
> purposes. It's even type-safe in debug mode.
> Also, Variant needs explicit construction, whereas the tiny typeless
> variable automatically accepts any value.
> Also, Variant does not grant access to underlying raw data, but tiny
> typeless value can be taken address of (void*).
>
> On Tue, Oct 25, 2011 at 5:11 PM, Robert Jacques <sandford@jhu.edu> wrote:
>> On Tue, 25 Oct 2011 06:31:13 -0400, Piotr Szturmaj <bncrbme@jadamspam.pl> wrote:
>>
>>> Gor Gyolchanyan wrote:
>>>>
>>>> I think adding more dynamic typing to D would be a splendid idea to
>>>> further widen the variety of solutions for different problems.
>>>> Modular app development is a very good practice and modularity means
>>>> dynamicity, which in turn means, that one needs to give up on lots of
>>>> sweet stuff like templates, overloading and string mixins.
>>>> Variant is the first step towards dynamic alter-ego of D, which is
>>>> completely undeveloped currently.
>>>
>>> If Algebraic/Variant could be recognized by the language it would give some interesting possibilities, like Variant array literals:
>>>
>>> auto array = [10, 2.0, "abc"];
>>>
>>> types it as Algebraic!(int, double, string)[];
>>>
>>> auto AA = [ "a" : 10, "b" : 2.0, 3 : "abc" ];
>>>
>>> types it as Algebraic!(int, double, string)[Algebraic!(string, int)];
>>>
>>> for example, that may be used to express JSON structures with literals only:
>>>
>>> int x, y;
>>>
>>> auto json = [
>>>     "x" : x,
>>>     "y" : y,
>>>     "colors" : [
>>>         [
>>>             r : 255,
>>>             g : 0,
>>>             b : 0
>>>         ],
>>>         [
>>>             r : 0,
>>>             g : 0,
>>>             b : 255
>>>         ]
>>>     ]
>>> ]
>>
>> Why do we need language support? This works in my variant proposal:
>>
>> auto json = Variant(
>>    "x",x,
>>    "y",y,
>>    "colors", [[
>>        "r":255,
>>        "g":0,
>>        "b":0],[
>>        "r":0,
>>        "g":0,
>>        "b":255]
>>    ]
>> );
>>
>> Granted if ["r":255,"g":0,"b":0] weren't all int, it would have to be declared Variant("r",255,"g",0,"b",0), but we could always shorten Variant to var or something.
>>
>

On Tue, 25 Oct 2011 09:23:10 -0400, Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com> wrote:
> I need an extremely fast and small typeless container for a single
> object, which i can use to implement a fast and efficient dynamic
> callback mechanism, where the exact number and types of parameters are
> only known to the callback and to the source of the parameter values
> and all intermediate manager classes, who hold and return the callback
> do not know it.
>
> On Tue, Oct 25, 2011 at 5:20 PM, Gor Gyolchanyan
> <gor.f.gyolchanyan@gmail.com> wrote:
>> Variant is heavy. It contains and does lots of things, that are not
>> always required.
>> a tiny type-less variable is versatile and can be used for any
>> purposes. It's even type-safe in debug mode.
>> Also, Variant needs explicit construction, whereas the tiny typeless
>> variable automatically accepts any value.
>> Also, Variant does not grant access to underlying raw data, but tiny
>> typeless value can be taken address of (void*).

Just because something is feature-full, doesn't make it heavy weight. But I guess over a raw tagged-union with a limited interface, it would be considered heavy. But, I don't understand you concept of a type-less variable. Truly type-less variables don't exist in any language; you always have a pluripotent dynamic type like variant under the hood.

That's the point. You don't always need to carry around your type.
Also because you might do it in a specific and very efficient way.
Imposing a single way of storing the type is a very inflexible decision.
The type check may also be done at different points, after which it's
not necessary to carry around.
Also, as i said before, type checking WILL be done in debug mode and
dropped in release mode.
Variant could be built on that typeless value concept to ensure type
safety at all times.

On Tue, Oct 25, 2011 at 7:33 PM, Robert Jacques <sandford@jhu.edu> wrote:
> On Tue, 25 Oct 2011 09:23:10 -0400, Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com> wrote:
>>
>> I need an extremely fast and small typeless container for a single object, which i can use to implement a fast and efficient dynamic callback mechanism, where the exact number and types of parameters are only known to the callback and to the source of the parameter values and all intermediate manager classes, who hold and return the callback do not know it.
>>
>> On Tue, Oct 25, 2011 at 5:20 PM, Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com> wrote:
>>>
>>> Variant is heavy. It contains and does lots of things, that are not
>>> always required.
>>> a tiny type-less variable is versatile and can be used for any
>>> purposes. It's even type-safe in debug mode.
>>> Also, Variant needs explicit construction, whereas the tiny typeless
>>> variable automatically accepts any value.
>>> Also, Variant does not grant access to underlying raw data, but tiny
>>> typeless value can be taken address of (void*).
>
> Just because something is feature-full, doesn't make it heavy weight. But I guess over a raw tagged-union with a limited interface, it would be considered heavy. But, I don't understand you concept of a type-less variable. Truly type-less variables don't exist in any language; you always have a pluripotent dynamic type like variant under the hood.
>

another example is dynamic callbacks.
You may carry around typeid of the function signature and a struct,
containing parameter values for it, which also contains the typeid of
it's target function's signature.
If you don't impose type information on the typeless values, i will be
able to check the types of the signatures (possibly by a hash value
for efficiency) and i won't need to check the types of each parameter
(since i'll be passing around array of typeless objects).


On Tue, Oct 25, 2011 at 7:33 PM, Robert Jacques <sandford@jhu.edu> wrote:
> On Tue, 25 Oct 2011 09:23:10 -0400, Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com> wrote:
>>
>> I need an extremely fast and small typeless container for a single object, which i can use to implement a fast and efficient dynamic callback mechanism, where the exact number and types of parameters are only known to the callback and to the source of the parameter values and all intermediate manager classes, who hold and return the callback do not know it.
>>
>> On Tue, Oct 25, 2011 at 5:20 PM, Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com> wrote:
>>>
>>> Variant is heavy. It contains and does lots of things, that are not
>>> always required.
>>> a tiny type-less variable is versatile and can be used for any
>>> purposes. It's even type-safe in debug mode.
>>> Also, Variant needs explicit construction, whereas the tiny typeless
>>> variable automatically accepts any value.
>>> Also, Variant does not grant access to underlying raw data, but tiny
>>> typeless value can be taken address of (void*).
>
> Just because something is feature-full, doesn't make it heavy weight. But I guess over a raw tagged-union with a limited interface, it would be considered heavy. But, I don't understand you concept of a type-less variable. Truly type-less variables don't exist in any language; you always have a pluripotent dynamic type like variant under the hood.
>

On Tue, 25 Oct 2011 11:45:48 -0400, Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com> wrote:
> another example is dynamic callbacks.
> You may carry around typeid of the function signature and a struct,
> containing parameter values for it, which also contains the typeid of
> it's target function's signature.
> If you don't impose type information on the typeless values, i will be
> able to check the types of the signatures (possibly by a hash value
> for efficiency) and i won't need to check the types of each parameter
> (since i'll be passing around array of typeless objects).

I'm confused. So delegate don't work because? What about unions? Or casting a ptr into an array of raw bytes?

Do you call the callback like 'dg();' or 'dg(x,y,z);'? If the latter, what about implicit variable conversions?

At some level, either you hold the type in the type system, or as a tag somewhere.

> So delegate don't work because?

Delegates won't work this way because the parameters aren't bound and are of unknown quantity and types.

> What about unions?

Unions allow only a limited number of types.

> Or casting a ptr into an array of raw bytes?

This won't always work, because static arrays must be converted to dynamic arrays and structs of size, greater, then (2*size_t.sizeof) must be passed by pointer. Otherwise it'll be the exact same thing as i'm trying to say.

> Do you call the callback like 'dg();' or 'dg(x,y,z);'?

The second one. The callback takes arguments, only known to the one calling it, not the one storing and returning it.

> At some level, either you hold the type in the type system, or as a tag somewhere.

Right, and all i'm trying to say is, that "somewhere" must be customizable. Moreover, that "somewhere" may not exist along the object's entire lifetime. The example with the dynamic callback showed when the types are not stored.

On Tue, Oct 25, 2011 at 8:20 PM, Robert Jacques <sandford@jhu.edu> wrote:
> On Tue, 25 Oct 2011 11:45:48 -0400, Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com> wrote:
>>
>> another example is dynamic callbacks.
>> You may carry around typeid of the function signature and a struct,
>> containing parameter values for it, which also contains the typeid of
>> it's target function's signature.
>> If you don't impose type information on the typeless values, i will be
>> able to check the types of the signatures (possibly by a hash value
>> for efficiency) and i won't need to check the types of each parameter
>> (since i'll be passing around array of typeless objects).
>
> I'm confused. So delegate don't work because? What about unions? Or casting a ptr into an array of raw bytes?
>
> Do you call the callback like 'dg();' or 'dg(x,y,z);'? If the latter, what
> about implicit variable conversions?
>
> At some level, either you hold the type in the type system, or as a tag somewhere.
>