Bill Baxter Wrote:

> Good counterpoints to my argument.  So I give up on that line.
> 
> Here's another, how do you implement the opBinary_r operators with opDispatch?

Kinda cooky, but what about this:

a + b -> b.opDispatch!("r+" )(a)

-Steve

On Tue, Dec 1, 2009 at 4:22 PM, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> Bill Baxter Wrote:
>
>> Good counterpoints to my argument.  So I give up on that line.
>>
>> Here's another, how do you implement the opBinary_r operators with opDispatch?
>
> Kinda cooky, but what about this:
>
> a + b -> b.opDispatch!("r+" )(a)

That's what I had in mind too, so I guess it's not so hard to guess.
Really the _r convention is also kooky.  We're just more used to that.
 So this isn't really a strong argument for separating opBinary out of
opDispatch.

But that is part of why I was asking about opIn -- if opIn_r's spelling remains "opIn_r" then we will have both conventions to deal with.  Not so good.  But if that one's changing to opDispatch!"in" also, then we'll need opSomething!"rin".  Which is kookier than "r+", I think, but at least maintains consistency.

But there is a problem.  It means you can't opDispatch on a method called "rin".
So I think there would have to be some non-symbol char in the "r"
prefix used.  Maybe "r:+", "r:+=", "r:in".  Or just a space -- "r +",
"r in", ... etc.
But now it's a notch less intuitive.

--bb

Bill Baxter Wrote:

> On Tue, Dec 1, 2009 at 4:22 PM, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> > Bill Baxter Wrote:
> >
> >> Good counterpoints to my argument.  So I give up on that line.
> >>
> >> Here's another, how do you implement the opBinary_r operators with opDispatch?
> >
> > Kinda cooky, but what about this:
> >
> > a + b -> b.opDispatch!("r+" )(a)
> 
> That's what I had in mind too, so I guess it's not so hard to guess.
> Really the _r convention is also kooky.  We're just more used to that.
>  So this isn't really a strong argument for separating opBinary out of
> opDispatch.

Another argument for at least keeping opBinary and opBinary_r to be defined by the same function -- commutative operators can be defined once:

T opDispatch(string s)(T x) if(s == "+" || s == "r+") { return T(this.val + x.val);}

> 
> But that is part of why I was asking about opIn -- if opIn_r's spelling remains "opIn_r" then we will have both conventions to deal with.  Not so good.  But if that one's changing to opDispatch!"in" also, then we'll need opSomething!"rin".  Which is kookier than "r+", I think, but at least maintains consistency.
> 
> But there is a problem.  It means you can't opDispatch on a method called "rin".
> So I think there would have to be some non-symbol char in the "r"
> prefix used.  Maybe "r:+", "r:+=", "r:in".  Or just a space -- "r +",
> "r in", ... etc.
> But now it's a notch less intuitive.

opIn is definitely a weird one.  Normally, you only want to define the reverse version.  Like you said, you can't use "rin" because rin isn't a keyword.

I think we can probably come up with a non-symbol representation to denote "Reverse" that's intuitive or at least memorable enough.

other ideas to ponder:

"op.r"  (no need for ..r because opDot doesn't have a reverse version) "op this" denoting that 'this' is on the right hand side

-Steve

Tue, 01 Dec 2009 12:40:21 -0500, Steven Schveighoffer wrote:

> On Tue, 01 Dec 2009 11:58:43 -0500, Denis Koroskin <2korden@gmail.com> wrote:
> 
>> On Tue, 01 Dec 2009 19:41:46 +0300, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>>
>>> On Tue, 01 Dec 2009 11:20:06 -0500, Denis Koroskin <2korden@gmail.com> wrote:
>>>
>>>> On Tue, 01 Dec 2009 19:02:27 +0300, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>>>>
>>>>
>>>>> You are missing the point of opDispatch.  It is not runtime defined, because the compiler statically decides to call opDispatch.  The dynamic part of opDispatch comes if you want to do something based on runtime values within the opDispatch function.  e.g. the compiler doesn't decide at *runtime* whether to call opDispatch or some normal function named quack, it's decided at compile time. opDispatch could be completely compile-time defined since it is a template.  But the 'dynamicness' of it is basically no more dynamic than a normal function which does something based on runtime values.
>>>>>
>>>>> Compare that to a dynamic language with which you can add methods to any object instance to make it different than another object, or make it conform to some interface.
>>>>>
>>>>>
>>>> Well, I believe it's possible to implement the same with opDispatch (not just to any object, but to those that support it):
>>>>
>>>> void foo() {}
>>>>
>>>> Dynamic d = ..;
>>>> if (!d.foo) {
>>>>      d.foo = &foo;
>>>> }
>>>>
>>>> d.foo();
>>>
>>> You could do something like this (I don't think your exact syntax would work), but you could also do something like this without opDispatch. But the name 'foo' is still statically decided.  Note that opDispatch doesn't implement this ability for you, you still have to implement the dynamic calls behind it.  The special nature of opDispatch is how you can define how to map any symbol to any implementation without having to explicitly use strings.  In fact, opDispatch is slightly less powerful than such a method if the method uses a runtime string for dispatch.
>>>
>>> For example, in php, I can do this:
>>>
>>> foo($var)
>>> {
>>>     $obj->$var();
>>> }
>>>
>>> The equivalent in D would be:
>>>
>>> foo(string var)
>>> {
>>>     obj.opDispatch!(var)();
>>> }
>>>
>>> This I would consider to be true runtime-decided dispatch.
>>>
>>> -Steve
>>
>> As pointed out, ActionScript and JavaScript use foo.bar and foo["bar"] interchangeably, so I believe we could do something similar.
>>
>> I believe there is no real difference between d.foo and d.bar for opDispatch (except that it could calculate string hash at compile time for faster hast-table lookup), and it would just call a generic run-time method anyway. As such, this method could be made visible to everyone:
>>
>> class Dynamic
>> {
>>      // getter
>>      @property Dynamic opDispatch(string prop) {
>>          return this[prop];
>>      }
>>
>>      // setter
>>      @property void opDispatch(string prop)(Dynamic value) {
>>          this[prop] = value;
>>      }
>>
>>      ref Dynamic opIndex(string propName)
>>      {
>>          // do a hash-table lookup
>>      }
>>
>>      Dynamic opCall(Args...)(Args args)
>>      {
>>          // do magic
>>      }
>> }
> 
> This is a very nice example, I only see one minor problem with it:  the "do a hash table lookup" has to tentatively add an element if one doesn't yet exist.
> 
> However, opDispatch is even less runtime-decided in this example (it can
> always be inlined).
> 
>> So essentially, opDispatch is just a syntax sugar. But it's very important one, because not only it makes writing code easier, it would allow using dynamic objects with generic algorithms.
> 
> Essentially you could say opDispatch is dynamic at compile time. Runtime, not so much.  But anything decided at compile time can be forwarded to a runtime function.

You don't seem to have any idea what the term 'dynamic' means. From http://en.wikipedia.org/wiki/Dynamic_programming_language

“Dynamic programming language is a term used broadly in computer science to describe a class of high-level programming languages that execute at runtime many common behaviors that other languages might perform during compilation, if at all.”

From http://en.wikipedia.org/wiki/Dynamic_typing#Dynamic_typing

“A programming language is said to be dynamically typed, when the majority of its type checking is performed at run-time as opposed to at compile-time. In dynamic typing, types are associated with values not variables.”

The dynamic quite clearly means something that happens at runtime. It's not a compile time feature.

On 28/11/2009 00:30, Walter Bright wrote:
> One thing Java and Python, Ruby, etc., still hold over D is dynamic
> classes, i.e. classes that are only known at runtime, not compile time.
> In D, this:
>
> s.foo(3);

Should opDispatch also enable dynamic property injection ?

I just thought that it would be nice to have  a new __traits() thingy for properties. would make perfectly sense f.i. GUI widgets.
Guess I like dispatching but not dymamic injection of properties.

which leads me to this question : Will there be support in traits for properties ?

Thanks for ignoring my ignorance once again.

retard wrote:
> Tue, 01 Dec 2009 12:40:21 -0500, Steven Schveighoffer wrote:
> 
>> On Tue, 01 Dec 2009 11:58:43 -0500, Denis Koroskin <2korden@gmail.com>
>> wrote:
>>
>>> On Tue, 01 Dec 2009 19:41:46 +0300, Steven Schveighoffer
>>> <schveiguy@yahoo.com> wrote:
>>>
>>>> On Tue, 01 Dec 2009 11:20:06 -0500, Denis Koroskin <2korden@gmail.com>
>>>> wrote:
>>>>
>>>>> On Tue, 01 Dec 2009 19:02:27 +0300, Steven Schveighoffer
>>>>> <schveiguy@yahoo.com> wrote:
>>>>>
>>>>>
>>>>>> You are missing the point of opDispatch.  It is not runtime defined,
>>>>>> because the compiler statically decides to call opDispatch.  The
>>>>>> dynamic part of opDispatch comes if you want to do something based
>>>>>> on runtime values within the opDispatch function.  e.g. the compiler
>>>>>> doesn't decide at *runtime* whether to call opDispatch or some
>>>>>> normal function named quack, it's decided at compile time. opDispatch could be completely compile-time defined since it is a
>>>>>> template.  But the 'dynamicness' of it is basically no more dynamic
>>>>>> than a normal function which does something based on runtime values.
>>>>>>
>>>>>> Compare that to a dynamic language with which you can add methods to
>>>>>> any object instance to make it different than another object, or
>>>>>> make it conform to some interface.
>>>>>>
>>>>>>
>>>>> Well, I believe it's possible to implement the same with opDispatch
>>>>> (not just to any object, but to those that support it):
>>>>>
>>>>> void foo() {}
>>>>>
>>>>> Dynamic d = ..;
>>>>> if (!d.foo) {
>>>>>      d.foo = &foo;
>>>>> }
>>>>>
>>>>> d.foo();
>>>> You could do something like this (I don't think your exact syntax
>>>> would work), but you could also do something like this without
>>>> opDispatch. But the name 'foo' is still statically decided.  Note that
>>>> opDispatch doesn't implement this ability for you, you still have to
>>>> implement the dynamic calls behind it.  The special nature of
>>>> opDispatch is how you can define how to map any symbol to any
>>>> implementation without having to explicitly use strings.  In fact,
>>>> opDispatch is slightly less powerful than such a method if the method
>>>> uses a runtime string for dispatch.
>>>>
>>>> For example, in php, I can do this:
>>>>
>>>> foo($var)
>>>> {
>>>>     $obj->$var();
>>>> }
>>>>
>>>> The equivalent in D would be:
>>>>
>>>> foo(string var)
>>>> {
>>>>     obj.opDispatch!(var)();
>>>> }
>>>>
>>>> This I would consider to be true runtime-decided dispatch.
>>>>
>>>> -Steve
>>> As pointed out, ActionScript and JavaScript use foo.bar and foo["bar"]
>>> interchangeably, so I believe we could do something similar.
>>>
>>> I believe there is no real difference between d.foo and d.bar for
>>> opDispatch (except that it could calculate string hash at compile time
>>> for faster hast-table lookup), and it would just call a generic
>>> run-time method anyway. As such, this method could be made visible to
>>> everyone:
>>>
>>> class Dynamic
>>> {
>>>      // getter
>>>      @property Dynamic opDispatch(string prop) {
>>>          return this[prop];
>>>      }
>>>
>>>      // setter
>>>      @property void opDispatch(string prop)(Dynamic value) {
>>>          this[prop] = value;
>>>      }
>>>
>>>      ref Dynamic opIndex(string propName)
>>>      {
>>>          // do a hash-table lookup
>>>      }
>>>
>>>      Dynamic opCall(Args...)(Args args)
>>>      {
>>>          // do magic
>>>      }
>>> }
>> This is a very nice example, I only see one minor problem with it:  the
>> "do a hash table lookup" has to tentatively add an element if one
>> doesn't yet exist.
>>
>> However, opDispatch is even less runtime-decided in this example (it can
>> always be inlined).
>>
>>> So essentially, opDispatch is just a syntax sugar. But it's very
>>> important one, because not only it makes writing code easier, it would
>>> allow using dynamic objects with generic algorithms.
>> Essentially you could say opDispatch is dynamic at compile time. Runtime, not so much.  But anything decided at compile time can be
>> forwarded to a runtime function.
> 
> You don't seem to have any idea what the term 'dynamic' means. From http://en.wikipedia.org/wiki/Dynamic_programming_language
> 
> “Dynamic programming language is a term used broadly in computer science to describe a class of high-level programming languages that execute at runtime many common behaviors that other languages might perform during compilation, if at all.”
> 
> From http://en.wikipedia.org/wiki/Dynamic_typing#Dynamic_typing
> 
> “A programming language is said to be dynamically typed, when the majority of its type checking is performed at run-time as opposed to at compile-time. In dynamic typing, types are associated with values not variables.”
> 
> The dynamic quite clearly means something that happens at runtime. It's not a compile time feature.

Well, it does seem to be rather novel in a statically typed, compiled language. It blurs the boundary a bit, so it's not quite clear what naming is appropriate. It enables the same syntax which dynamic programming languages use at runtime. I'm not sure that the fact that it occurs at compile-time rather than run-time is important. (Presumably, a dynamic language is permitted to implement functionality at compile time, if it can do so without affecting the semantics).

On Wed, 02 Dec 2009 00:01:41 +0300, Bill Baxter <wbaxter@gmail.com> wrote:

> On Tue, Dec 1, 2009 at 12:38 PM, Steven Schveighoffer
> <schveiguy@yahoo.com> wrote:
>> On Tue, 01 Dec 2009 15:06:27 -0500, Pelle Månsson <pelle.mansson@gmail.com>
>> wrote:
>>
>>> Steven Schveighoffer wrote:
>>
>>>>  Isn't opBinary almost identical to opDispatch?  The only difference I
>>>> see is that opBinary works with operators as the 'symbol' and dispatch works
>>>> with valid symbols.  Is it important to distinguish between operators and
>>>> custom dispatch?
>>>>  -Steve
>>>
>>> opBinary is a binary operator, opDispatch can be anything. I think they
>>> should be kept separate.
>>
>> You could say the same thing about dynamic properties.  How come we don't
>> split those out as opProperty?
>
> That's because of what Andrei pointed out:  &a.b .
> The compiler can't tell if you want a delegate to the method b, or the
> address of a property b.
>

Technically, you are wrong. There is the same ambiguity without function overloads:

void foo(int a);
void foo(float a);

auto dg = &foo; // which one of the two overloads is chosen and why?

Resolving properties is much easier: property and function names can't overlap, i.e. you can't have property *and* any function with the same name.

Bill Baxter wrote:
> On Tue, Dec 1, 2009 at 11:43 AM, Don <nospam@nospam.com> wrote:
>> Bill Baxter wrote:
>>> On Tue, Dec 1, 2009 at 5:18 AM, Lutger <lutger.blijdestijn@gmail.com>
>>> wrote:
>>>> Ary Borenszweig wrote:
>>>>>>>>> The feature isn't very dynamic since the dispatch rules are defined
>>>>>>>>> statically. The only thing you can do is rewire the associative
>>>> I don't get it, what if WhatTypeToPutHere does a dynamic lookup, then
>>>> it's
>>>> pretty much the same a Javascript isn't it? Except that everything in
>>>> Javascript does dynamic lookup and in D you are restricted to types that
>>>> have this dynamic lookup (which, pending a phobos solution you have to
>>>> code
>>>> yourself). Do you mean to say this 'except' is the obstacle somehow?
>>>>
>>>> How is that less dynamic? You would be able to call or even redefine at
>>>> runtime, for example, signals defined in xml files used to build gui
>>>> components.
>>> It is a bit less dynamic because in D it's all done with templates.
>> It's a helluva lot more dynamic in D because it can do code generation on
>> request. The "dynamic" bit in Javascript is really an AA lookup, +
>> reflection.
> 
> But that's code generation /at compile time/.
> You can call that "more dynamic" if you like, but it seems to fall
> more in the realm of what is considered "static" to me.
> Doesn't mean it's not really useful, but calling it dynamic seems to
> be stretching the traditional definition a bit too far.
> 
> --bb

Yeah, it's all about naming. The thing is, the traditional "dynamic" isn't very dynamic. You can't *really* add new functions at run-time. They all exist in the source code, all you're doing is manipulating function pointers, and the dynamic thing is just syntax sugar for that. If you have a language with a built-in compiler or interpreter, it can be truly dynamic, but I don't think that's the normal use of the term.

Hello Denis,

> What if you don't know argument names a-priori? Consider a generic
> Dynamic  class that has nothing but a single opDispatch method.
> 

you can do whatever logic you want, even (I think) aliasing the function

template opDispatch(string s)
{
    static if(WhateverLogicYouNeed!(s))
          alias Something!(s) opDispatch;
    else
          alias SomethingElse!(s) opDispatch;

}

On Wed, 02 Dec 2009 02:22:01 -0500, retard <re@tard.com.invalid> wrote:


> You don't seem to have any idea what the term 'dynamic' means. From
> http://en.wikipedia.org/wiki/Dynamic_programming_language

I'm sure the first person who suggested C++ templates were a functional language was shown wikipedia (or whatever the equivalent at the time was) as well :)

-Steve