>>
>> Running version=a prints "hi" while version=b prints "true."  If there
>> were
>> some way in the language to say "cond() is a property" then this issue
>> would
>> not be silently introduced when changing cond from a variable to a method.
>
> Oh how I am with you on this. I've always thought mentioning a delegate name should NOT EVER evaluate the delegate. Walter definitely took the wrong turn down that alley there. And guess what. He got ambushed by the "lazy" keyword right there. I told Walter to not do that "lazy" keyword, he disregarded, but the time will come when that stone will be turned.
>
>
> Andrei
>

He mentions your name right there on the description of lazy, though. I always thought it was basically your idea because of that, or at least that you designed it together.  Given what you are saying above, you might want to ask him politely to remove your name from that page.

--bb

On Fri, Oct 3, 2008 at 2:32 AM, KennyTM~ <kennytm@gmail.com> wrote:
> Andrei Alexandrescu wrote:
>>
>> I'm impressed a lot by the analogy with math because it is one extra argument in my favor. In math there's no function without arguments. At most people would say f(.) (with a central dot) when referring to what is akin to the address of the function.
>>
>
> Sorry, in math the normal way to represent a function is to just use the symbol, i.e. f, e.g. chain rule (f o g)' = g' * f' o g.

Yeh, and that's because in math there *are* no zero argument functions so in math just writing the symbol means essentially "pointer to function", while in D that is &f.    At best the math precedent argues that f() should be illegal and plain f should be the only way to evaluate this thing-that-is-not-a-function-because-it-takes-no-arguments, but I don't think that's what Andrei really wants.

> The central dot is used only when the "function" is not represented in the
> form f(a,b,c,...), e.g. the commutator [.,.] and the mean <.>. I have
> *never* seen anyone writes f(.).

I have, when talking about functionals (functions of functions). Something like   g(f(., .)).   I think the point was to remind the reader that the argument f is really a  function and show how many arguments it takes, without implying that you're evaluating it. Maybe that's what Andrei was trying to say by "taking the address". But I've forgotten what the point of this was.

--bb

Bill Baxter wrote:
>>> Running version=a prints "hi" while version=b prints "true."  If there
>>> were
>>> some way in the language to say "cond() is a property" then this issue
>>> would
>>> not be silently introduced when changing cond from a variable to a method.
>> Oh how I am with you on this. I've always thought mentioning a delegate name
>> should NOT EVER evaluate the delegate. Walter definitely took the wrong turn
>> down that alley there. And guess what. He got ambushed by the "lazy" keyword
>> right there. I told Walter to not do that "lazy" keyword, he disregarded,
>> but the time will come when that stone will be turned.
>>
>>
>> Andrei
>>
> 
> He mentions your name right there on the description of lazy, though.
> I always thought it was basically your idea because of that, or at
> least that you designed it together.  Given what you are saying above,
> you might want to ask him politely to remove your name from that page.

I suggested that a function taking a delegate should accept an unadorned expression:

void twice(void delegate() fun) { fun(); fun(); }
...
int a;
twice(++a); // makes a = 2

That has a number of issues itself, which can be worked out. Then somebody (in the newsgroup if I remember correctly) said, well this is fine and dandy, but just add a "lazy" keyword there. He did, and I knew it was a mistake the first time I saw it.


Andrei

Bill Baxter wrote:
> On Fri, Oct 3, 2008 at 3:16 AM, Fawzi Mohamed <fmohamed@mac.com> wrote:
> 
>> This is a very nice feature to have.
>> D reaches this with a minimal change to the language:
>> optional parenthesis, and setter functions.
>>
>> ...
>> It does have some limitation (no +=,-=,...) but is very compact, and simple
>> to explain.
> 
> Fortunately this is an orthogonal issue.  This could (and should IMO)
> be fixed independent of the current discussion.

Yah, overloaded ops are due for an overhaul. I'm almost afraid to ask... any ideas? :o)

One goal is to fix opIndexAssign and make it work similar to the way it works in arrays, e.g. a[b] += c. Indexing into hash tables is a good test bed.


Andrei

Andrei Alexandrescu wrote:
> I suggested that a function taking a delegate should accept an unadorned expression:
> 
> void twice(void delegate() fun) { fun(); fun(); }
> ...
> int a;
> twice(++a); // makes a = 2
> 
> That has a number of issues itself, which can be worked out. Then somebody (in the newsgroup if I remember correctly) said, well this is fine and dandy, but just add a "lazy" keyword there. He did, and I knew it was a mistake the first time I saw it.

I guess that someone was me (and at the NG, so you remember right). But yea, let's just trivialize all the broken code and surrounding issues :P
People actually wanted to burn lazy evaluation on a stack, and my post was merely an attempt on reaching a compromise.

And I didn't really say it was all fine and dandy. Why not? Suddenly you got conflicts between:

void foo(int delegate())
void foo(int)

Apparently some libraries used that. And I don't think that any of my own libs were the issue. So please bear in mind that there were more people behind it and their frustration level was at some point pretty high (along the lines of "Walter keeps releasing new stuff and instead of fixing old issues, breaks fine code. [Expletive deleted] this."). If you had ideas to work it out, it would've been fine time to state them. I'm actually looking forward to the solution for D2.0.


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode

Thu, 02 Oct 2008 15:03:42 -0500,
Andrei Alexandrescu wrote:
> Yah, overloaded ops are due for an overhaul. I'm almost afraid to ask... any ideas? :o)
> 
> One goal is to fix opIndexAssign and make it work similar to the way it works in arrays, e.g. a[b] += c. Indexing into hash tables is a good test bed.

What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?

On Fri, Oct 3, 2008 at 8:04 AM, Sergey Gromov <snake.scaly@gmail.com> wrote:
> Thu, 02 Oct 2008 15:03:42 -0500,
> Andrei Alexandrescu wrote:
>> Yah, overloaded ops are due for an overhaul. I'm almost afraid to ask... any ideas? :o)
>>
>> One goal is to fix opIndexAssign and make it work similar to the way it works in arrays, e.g. a[b] += c. Indexing into hash tables is a good test bed.
>
> What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
>

Indeed.  I thought there wasn't a lot of debate needed on this, just action.

--bb

On Fri, Oct 3, 2008 at 9:32 AM, Bill Baxter <wbaxter@gmail.com> wrote:
> On Fri, Oct 3, 2008 at 8:04 AM, Sergey Gromov <snake.scaly@gmail.com> wrote:
>> Thu, 02 Oct 2008 15:03:42 -0500,
>> Andrei Alexandrescu wrote:
>>> Yah, overloaded ops are due for an overhaul. I'm almost afraid to ask... any ideas? :o)
>>>
>>> One goal is to fix opIndexAssign and make it work similar to the way it works in arrays, e.g. a[b] += c. Indexing into hash tables is a good test bed.
>>
>> What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
>>
>
> Indeed.  I thought there wasn't a lot of debate needed on this, just action.

... except these extras do have the same issue that plain property assignment does.  They would open up a new class of things that are valid code but don't behave as expected.  writefln += 5.

And also, a[b] += c should probably be rewritten as  "a.opIndex(b) += c"  *if* a returns a reference of some sort.  Ok, so maybe there is a little to talk about.  :-)

--bb

On Fri, Oct 3, 2008 at 9:37 AM, Bill Baxter <wbaxter@gmail.com> wrote:
> ... except these extras do have the same issue that plain property assignment does.  They would open up a new class of things that are valid code but don't behave as expected.  writefln += 5.
>

Doh, obviously writefln is a bad example there.  Imagine a function that takes an int, tries to do something that many times, then returns an int indicating how many times it actually managed to do it.

--bb

Fri, 3 Oct 2008 09:37:46 +0900,
Bill Baxter wrote:
> On Fri, Oct 3, 2008 at 9:32 AM, Bill Baxter <wbaxter@gmail.com> wrote:
> > On Fri, Oct 3, 2008 at 8:04 AM, Sergey Gromov <snake.scaly@gmail.com> wrote:
> >> Thu, 02 Oct 2008 15:03:42 -0500,
> >> Andrei Alexandrescu wrote:
> >>> Yah, overloaded ops are due for an overhaul. I'm almost afraid to ask... any ideas? :o)
> >>>
> >>> One goal is to fix opIndexAssign and make it work similar to the way it works in arrays, e.g. a[b] += c. Indexing into hash tables is a good test bed.
> >>
> >> What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
> >>
> >
> > Indeed.  I thought there wasn't a lot of debate needed on this, just action.
> .
> ... except these extras do have the same issue that plain property
> assignment does.  They would open up a new class of things that are
> valid code but don't behave as expected.  writefln += 5.
> 
> And also, a[b] += c should probably be rewritten as  "a.opIndex(b) += c"  *if* a returns a reference of some sort.  Ok, so maybe there is a little to talk about.  :-)

I think that any expression "a @= b" should first check whether the expression on the left is an lvalue.  If yes then use it as any other lvalue, otherwise try to re-write an expression using op@Assign.  This works in many scenarios, like opIndex returning a reference.