Pavel Minayev wrote:

> "Patrick Down" <pat@codemoon.com> wrote in message news:Xns91F1EBD9CDFFpatcodemooncom@63.105.9.61...
>
> > I would argue for the former. :)  If you adopt this method then the latter example can always be constructed like this...
> >
> > int temp = Fred();
> > b[].Baz(temp)
> >
> > but it's impossible to go the other way without explictily making the loop.
>
> Where you want a loop, it's better to state it clearly by making a loop. However, when you write:
>
>     b[].baz(fred());
>
> You only see fred() once in the expression, so, IMO, it should
> be evaluated only once.

They both are convincing arguments.  I guess that whatever the syntax
is, it should match all other array operations.  Does
    b[] += fred();
call fred() once or many times?

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Pavel Minayev" <evilone@omen.ru> wrote in news:a9e8cb$elj$1 @digitaldaemon.com:
> 
> Where you want a loop, it's better to state it clearly by making a loop. However, when you write:
> 
>     b[].baz(fred());
> 
> You only see fred() once in the expression, so, IMO, it should
> be evaluated only once.

Ok I've changed my mind. :)  fred() should only be executed once. My problem is that I want some sort of foreach construct in D and was trying to make the vector syntax fit that role.

For the other problem I'd rather have this.

foreach(a in b[]) // foreach(a,b[]), foreach(a,b) ??
{
  a.baz(fred());
}

Patrick Down wrote:

> foreach(a in b[]) // foreach(a,b[]), foreach(a,b) ??
> {
>   a.baz(fred());
> }

The first syntax makes sense to me from my ksh programming...but it would seem to conflict with the normal use of "in" - to test for presence of a key.  What about "of" ?

    foreach(a of b[])
    {
        a.baz(fred());
    }

'a' would automatically get its type from the underlying type of the array.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Patrick Down wrote:

> "Pavel Minayev" <evilone@omen.ru> wrote in news:a9e8cb$elj$1 @digitaldaemon.com:
> >
> > Where you want a loop, it's better to state it clearly by making a loop. However, when you write:
> >
> >     b[].baz(fred());
> >
> > You only see fred() once in the expression, so, IMO, it should
> > be evaluated only once.
>
> Ok I've changed my mind. :)  fred() should only be executed once. My problem is that I want some sort of foreach construct in D and was trying to make the vector syntax fit that role.

Wouldn't it be simpler to restrict the kinds of arguments that delegates are allowed to have?  For example, require that delegates must have only discrete pass-by-value parameters.  Concerns about single versus multiple argument evaluation should then go away.

Delegate arrays are a powerful tool, and any limits placed on them should be there only to make them more generally useful.  Restricting the arguments would simply mean the programmer would have to write code to circumvent the restriction (pass a function pointer in the above example, and call it within each delegate), which makes the risk explicit in the code instead of implicit in the language.

That's good programming practice and good language design.  Don't make the risky stuff (like side effects) impossible.  But don't make them too easy either.  And don't muck things up by mandating special execution behavior (single versus multiple evaluation) for delegate arrays:  That just makes using delegate arrays more complex.  Who will remember the rules correctly every time?  (Other than Pavel, of course!)

The compiler won't be able to help much in such situations unless the restrictions can be easily flagged at compile time (and easily fixed). Let's not make things so complex that we'll need a lint for D!


-BobC

"Robert W. Cunningham" <rcunning@acm.org> wrote in message news:3CBB9E37.1B196FB6@acm.org...

> Wouldn't it be simpler to restrict the kinds of arguments that delegates are allowed to have?  For example, require that delegates must have only discrete pass-by-value parameters.  Concerns about single versus multiple argument evaluation should then go away.

No, it doesn't:

    foo[].bar(baz());

Don't forget that baz() might do something as well, as well as return
different values each time it's called. So the behaviour of this code
could depend on whethe baz() is called once or many times.

"Robert W. Cunningham" <rcunning@acm.org> wrote in message news:3CBB9E37.1B196FB6@acm.org...
> That's good programming practice and good language design.  Don't make the risky stuff (like side effects) impossible.  But don't make them too easy either.  And don't muck things up by mandating special execution behavior (single versus multiple evaluation) for delegate arrays:  That just makes using delegate arrays more complex.  Who will remember the rules correctly every time?

That's a point worth repeating. I'm willing to sacrifice some expressive power of the language to gain orthogonality, consistency, and clarity in understanding code written by others. Every special case rule added to the language substantially reduces this, making it harder to learn/remember the language, and harder to read other peoples' code. That's also why D uses C's operator priority and integral promotion rules verbatim - such rules are a mess, but programmers are so used to them that changing them would be like trying to get people to switch from QWERTY to Dvorak.

Walter a écrit :

> "Robert W. Cunningham" <rcunning@acm.org> wrote in message news:3CBB9E37.1B196FB6@acm.org...
> > That's good programming practice and good language design.  Don't make the risky stuff (like side effects) impossible.  But don't make them too easy either.  And don't muck things up by mandating special execution behavior (single versus multiple evaluation) for delegate arrays:  That just makes using delegate arrays more complex.  Who will remember the rules correctly every time?
>
> That's a point worth repeating. I'm willing to sacrifice some expressive power of the language to gain orthogonality, consistency, and clarity in understanding code written by others. Every special case rule added to the language substantially reduces this, making it harder to learn/remember the language, and harder to read other peoples' code. That's also why D uses C's operator priority and integral promotion rules verbatim - such rules are a mess, but programmers are so used to them that changing them would be like trying to get people to switch from QWERTY to Dvorak.

Yes..i should have posted my last post (D and real macros) in chat.. It is not D phylosophy, but it is still interesting i hope.

roland