"Manfred Nowak"

> ... and this is also a severe blow onto the secureness of the whisper notation.

[cue music from "Rocky", or "Jaws"]


The drama! :-D

DMD for both Win32 & linux supports method chaining. GDC supports method chaining. I believe Walter intends D to support method chaining. You don't see anything about it in the spec ...

Instead of the "severe blow" dramatics, why don't you simply ask Walter if method-chaining is supported or not? If it is an illegal or non-deterministic construct, then I'll change the way Mango.io operates ~ no big deal. If it is officially supported, then you can derive some pleasure giving Walter hell for not writing about it :)

- Kris

"BCS" <BCS_member@pathlink.com> wrote
[snip]
> struct A
> {
> int opCall(int);
> }
>
> struct B
> {
> B opCall(A);
> B opCall(int){return this;}
> }

A a;
B b;

// b.(a)(i);
b (a) (i);        // is this correct? (no dot)


For the moment, let's assume that's what you meant?

b (a) (i);

> //this
> int t1 = a.opCall(i)
> b.opCall(t1);

To get t1, where did the A lvalue come from, for a.opCall(i)?

It is conceptually possible to see "(a)" as the A lvalue, with superfluous parens around it. Is this what you are getting at? But then, "(i)" would be treated the same ~ there would be no opCall at all. At that point there would be a syntax error with an orphaned "b".

For opCall to function, I imagine the '(' is being eaten before the parser reaches a 'terminal' state, where the '(' would be considered to be something else, like the start of a subexpression.

Of course, one can enforce right-to-left evaluation:

b (a (i));      // or b ((a) (i));

Does this answer your question, or were you getting at something else?

Kris wrote:

[...]
> Does this answer your question, or were you getting at something else?

Yes.
Let's assume the compiler scans the code from left to right, which
the compiler isn't enforced to do.

Let's further assume, that the code read is `b(a)'.

Now your argument is, that the compiler should evaluate `b(a)'.

Your further and wrong implicite argument is, that the compiler for this evaluation is restricted to the code portion currently read. Only under this assumption, the compiler has no choice.

If this restriction does not exist---and the docs do not say anything about the existence of such restriction---after evaluating the argument list `a' the compiler is not disallowed to scan further, recognizing that a `(' follows,  concluding the need to evaluate the `a' to the address of a function, which is provided by the `opCall' in `A', and then bind the `(i)' to that `opCall', resulting in first executing the `a.opCall(i)'.

On the other hand: are you able to proof under the restrictions of the current specs that there is only one syntax tree possible, when scanning the code from right to left under an LARL-parser?

-manfred

"Manfred Nowak" <svv1999@hotmail.com>...
>
> If you cannot recognize the contradiction to your own argument given in the part cited with [...] it is useless to post any further.


OK ... I'm confused. Can someone /please/ explain what this supposed contradiction is about? I'm reposting the [...] snippet referred to above:

==========================

classRef.method1().method2().method3();

Each dereferenced lValue *cannot be determined* until the appropriate call has been made. You see?  The expression evaluates deterministically, because of one simple observation: the very act of retrieving each subsequent lValue has the "side effect" of executing each method in the desired order. Again, to unwind:

auto a = classRef.method1();
auto b = a.method2();
b.method3();

That is; method2 cannot be called until method1 returns an lValue. Method3 cannot be called until method2 returns an lValue. These are cleary ordered, and this is what chaining effects ... something entirely different from what you appear to be stating.

===========================

On Fri, 9 Dec 2005 22:52:16 -0800, Kris wrote:

> "Manfred Nowak" <svv1999@hotmail.com>...
>>
>> If you cannot recognize the contradiction to your own argument given in the part cited with [...] it is useless to post any further.
> 
> 
> OK ... I'm confused. Can someone /please/ explain what this supposed contradiction is about?

Sorry but I don't know what Manfred is talking about either.

> I'm reposting the [...] snippet referred to above:
> 
> ==========================
> 
> classRef.method1().method2().method3();

I'm with you Kris on this too, BTW. If we assume left-to-right scanning the code generation is fairly obvious. But even if the compiler scans right-to-left, I see it goes something like this ...

It finds

   .method3()

This is a function call of a member of some class, struct or module. So what is it? It then finds

   .method2()

This is also a call to a member of something, so I have to find out what so I can work out what it's return value is so I can then find out if method3() is a valid member of whatever method2() returns. It then finds

  .method1()

Ditto. It then finds

   classRef

So now it can tell what method1() returns, and thus if method2() is valid,
and so forth for method3(). And this is all before generating any code. So
now it can generate code to correctly invoke method3(). It must generate
code to call method1() first, then using its return value to call method2()
then its return to call method3().

Thus this syntax will always work as a chained call.

-- 
Derek Parnell
Melbourne, Australia
10/12/2005 7:17:19 PM

"Manfred Nowak" <svv1999@hotmail.com>
> Kris wrote:
>
> [...]
>> Does this answer your question, or were you getting at something else?
>
> Yes.

Ah. Well, D doesn't operate like that. If it did, that example would result in 3 operands with zero operators. Not much use to anyone? Just like this statement:  3 arf  'c';


> Let's assume the compiler scans the code from left to right, which the compiler isn't enforced to do.
>
> Let's further assume, that the code read is `b(a)'.
>
> Now your argument is, that the compiler should evaluate `b(a)'.

Not "should". The compiler *does* evaluate `b(a)', and then each subsequent opCall in turn :-)


> Your further and wrong implicite argument is, that the compiler for this evaluation is restricted to the code portion currently read. Only under this assumption, the compiler has no choice.

Patently false ~ you're asserting things that weren't even implied :-)


> If this restriction does not exist---and the docs do not say anything about the existence of such restriction---after evaluating the argument list `a' the compiler is not disallowed to scan further, recognizing that a `(' follows,  concluding the need to evaluate the `a' to the address of a function, which is provided by the `opCall' in `A', and then bind the `(i)' to that `opCall', resulting in first executing the `a.opCall(i)'.

Stack fault :: parser failed. Core dumped.   Sorry.


> On the other hand: are you able to proof under the restrictions of the current specs that there is only one syntax tree possible, when scanning the code from right to left under an LARL-parser?

Have absolutely zero intention of bothering :-)

I'm tired.

Don't know about you, but I'm talking about a language claiming to follow on from C++ (and Java for that matter). Both those languages support method-chaining. C supports function chaining. DMD currently supports method chaining on two platforms. GDC supports method chaining. That's three D compilers.

Are you arguing that they don't really? Or that they shouldn't? Are you talking about the same language? You've so far stated, in a variety of ways, that the approach chosen by mango.io is broken, non-portable, and somehow restrictive upon the language (eh?). Yet that's clearly not the case ~ mango.io has been working on a number of OS using a number of D compilers. Is your position perhaps about a personal distaste for method-chaining, and a gripe about lack of documentation? Of course, I am making an implicit assumption that you're not trolling. I mean, "Wohoo! Second strike" ??  What is that about? Sounds like a rush of gleeful pettiness?

Thus, you've picked entirely the wrong person to have an "academic debate" with. If you want to complain about the documentation not being explicit about chaining behaviour, then take it up with Walter? If he stands up and says "Thou Shalt Not Method-Chain!" , then I will consider the ramifications, and not before. Until then you're simply speculating, blowing lots of vapid air, and we're both wasting bandwidth.

You really should ask him ... if you feel you can't do that, then I will.

Cheers :-)

Thank you, Derek.



"Derek Parnell" <derek@psych.ward> wrote in message news:1d9fnb3xux6cb$.eeeyn889n1f6$.dlg@40tude.net...
> On Fri, 9 Dec 2005 22:52:16 -0800, Kris wrote:
>
>> "Manfred Nowak" <svv1999@hotmail.com>...
>>>
>>> If you cannot recognize the contradiction to your own argument given in the part cited with [...] it is useless to post any further.
>>
>>
>> OK ... I'm confused. Can someone /please/ explain what this supposed contradiction is about?
>
> Sorry but I don't know what Manfred is talking about either.
>
>> I'm reposting the [...] snippet referred to above:
>>
>> ==========================
>>
>> classRef.method1().method2().method3();
>
> I'm with you Kris on this too, BTW. If we assume left-to-right scanning
> the
> code generation is fairly obvious. But even if the compiler scans
> right-to-left, I see it goes something like this ...
>
> It finds
>
>   .method3()
>
> This is a function call of a member of some class, struct or module. So what is it? It then finds
>
>   .method2()
>
> This is also a call to a member of something, so I have to find out what
> so
> I can work out what it's return value is so I can then find out if
> method3() is a valid member of whatever method2() returns. It then finds
>
>  .method1()
>
> Ditto. It then finds
>
>   classRef
>
> So now it can tell what method1() returns, and thus if method2() is valid,
> and so forth for method3(). And this is all before generating any code. So
> now it can generate code to correctly invoke method3(). It must generate
> code to call method1() first, then using its return value to call
> method2()
> then its return to call method3().
>
> Thus this syntax will always work as a chained call.
>
> -- 
> Derek Parnell
> Melbourne, Australia
> 10/12/2005 7:17:19 PM

BCS wrote:
> In article <dnd99m$1j9d$1@digitaldaemon.com>, Bruno Medeiros says...
> as to the evaluation of the "wisper syntax" how about the following
> 
> struct A
> {
> int opCall(int);
> }
> 
> struct B
> {
> B opCall(A);
> B opCall(int){return this;}
> }
> 
> A a;
> B b;
> 
> int i;
> 
> // is this
> b(a)(i);
> 
> //this
> int t1 = a.opCall(i)
> b.opCall(t1);
> 
> //or this
> B t2 = b.opCall(a);
> t2.opCall(i);

According to my understanding of the docs, and experience with D, the second one.  Really this whole discussion is silly.  The chained calls in the Whisper syntax can not be reordered, because each subsequent call is dependant on the previous call's return value.  In 100% of cases of:
# obj (a) (b) (c) ;

It is guaranteed that `?.opCall(b)` can not possibly be executed before `obj.opCall(a)` because of that little question-mark there, which stands for the return value of `obj.opCall(a)`.  Its all really very straightforward... in fact it reminds me of the sort of thing that would've been on a test in my High School C++ class.

Any expression, B, containing any operand whose value is taken from the result of another expression, A, must be evaluated /after/ the expression, A.  QED.  Any compiler that doesn't do this... really isn't useful at all.

-- Chris Sauls

Kris wrote:
[...]
> You really should ask him ... if you feel you can't do that, then I will.

As a member of this community created by the free will of intelligent people, I have no reason to ask Walter, because I assume that the contents of the current specs with respect to the subject of this thread is intended by Walter and I agree with the conclusions.

As a coeditor of the news I will bring anything to his special attention, if someone tells me to do so.

-manfred

Manfred Nowak wrote:
> Kris wrote:
> 
> [...]
> 
>>Does this answer your question, or were you getting at something
>>else? 
> 
> 
> Yes.
> Let's assume the compiler scans the code from left to right, which the compiler isn't enforced to do.
> 
> Let's further assume, that the code read is `b(a)'.
> 
> Now your argument is, that the compiler should evaluate `b(a)'.
> 
> Your further and wrong implicite argument is, that the compiler for this evaluation is restricted to the code portion currently read. Only under this assumption, the compiler has no choice.
> 
> If this restriction does not exist---and the docs do not say anything about the existence of such restriction---after evaluating the argument list `a' the compiler is not disallowed to scan further, recognizing that a `(' follows,  concluding the need to evaluate the `a' to the address of a function, which is provided by the `opCall' in `A', and then bind the `(i)' to that `opCall', resulting in first executing the `a.opCall(i)'.
> 
> On the other hand: are you able to proof under the restrictions of the current specs that there is only one syntax tree possible, when scanning the code from right to left under an LARL-parser?
> 

I think there should be only one syntax tree.

I think that when people talk about order of evaluation in for example:

a.method1().method2();

the question isn't wich one of these methods will be called but with for example:

int getI(){static int i = 0; i+=5; return i;}

a.method1(getI()).method2(getI());

OK, method1 *must* be called first and then method2 but is this
a.method1(5).method2(10);
or
a.method1(10).method2(5);
?