Hello Walter,

>>> It's handy for things like rewriting ++e so it can be used more than
>>> once but is only evaluated once:
>>> 
> (tmp = ++e, tmp)
> 
>> Uh? How is that different from "++e"
>> 
> You can then use tmp more than once with only one increment of e.
> 

how does that differ from using ++e the first time and then e for the other times?

BCS wrote:
> Hello Walter,
> 
>>>> It's handy for things like rewriting ++e so it can be used more than
>>>> once but is only evaluated once:
>>>>
>> (tmp = ++e, tmp)
>>
>>> Uh? How is that different from "++e"
>>>
>> You can then use tmp more than once with only one increment of e.
>>
> 
> how does that differ from using ++e the first time and then e for the other times?


1. e may be a global
2. ++e may be a more complicated expression with side effects

On Thu, Jul 9, 2009 at 7:08 PM, Walter Bright<newshound1@digitalmars.com> wrote:
> Jérôme M. Berger wrote:
>>
>> Walter Bright wrote:
>>>
>>> Nick Sabalausky wrote:
>>>>
>>>> "Walter Bright" <newshound1@digitalmars.com> wrote in message
>>>>>
>>>>> It's handy when you want to prefix one expression to another, as in:
>>>>>
>>>>>   (foo(), x + 3)
>>>>
>>>> I guess I'm not familiar with that syntax. What does that do and for what purpose?
>>>
>>> They're called Comma Expressions, and the left operand is evaluated first, its result discarded, then the right operand is evaluated and forms the type and result of the Comma Expression.
>>>
>>    I've always felt they were useless and confusing. What's the advantage
>> of "y = (foo(), x + 3);" over "foo(); y = x+3;"?
>
> When you only see the x+3 because you're recursively walking the tree generating code.

If it's internal to the parse tree can't you make the syntax whatever you want?
Something like (expr1 __exprSequencer expr2) should do just fine, right?
No reason it has to be a precious one-character symbol syntax.

--bb

Bill Baxter wrote:
> If it's internal to the parse tree can't you make the syntax whatever you want?
> Something like (expr1 __exprSequencer expr2) should do just fine, right?
> No reason it has to be a precious one-character symbol syntax.

What if you're writing a program that generates D code?

On Fri, Jul 10, 2009 at 12:09 AM, Walter Bright<newshound1@digitalmars.com> wrote:
> Bill Baxter wrote:
>>
>> If it's internal to the parse tree can't you make the syntax whatever you
>> want?
>> Something like (expr1 __exprSequencer expr2) should do just fine, right?
>> No reason it has to be a precious one-character symbol syntax.
>
> What if you're writing a program that generates D code?

..then you'd have it generate multiple statements?

Really, I'm not seeing the justification here!

Jarrett Billingsley wrote:
> On Fri, Jul 10, 2009 at 12:09 AM, Walter
> Bright<newshound1@digitalmars.com> wrote:
>> Bill Baxter wrote:
>>> If it's internal to the parse tree can't you make the syntax whatever you
>>> want?
>>> Something like (expr1 __exprSequencer expr2) should do just fine, right?
>>> No reason it has to be a precious one-character symbol syntax.
>> What if you're writing a program that generates D code?
> 
> ..then you'd have it generate multiple statements?

Your recursive function may not have any access to the parents of the expression node it is working on.

> Really, I'm not seeing the justification here!

You should come to my compiler seminar, then! http:www.astoriaseminar.com

Without any way to sequence expressions in place, a lot of manipulation becomes much more complicated. Comma expressions have been around a long time, they work well, and are often used.

On Thu, Jul 9, 2009 at 9:09 PM, Walter Bright<newshound1@digitalmars.com> wrote:
> Bill Baxter wrote:
>>
>> If it's internal to the parse tree can't you make the syntax whatever you
>> want?
>> Something like (expr1 __exprSequencer expr2) should do just fine, right?
>> No reason it has to be a precious one-character symbol syntax.
>
> What if you're writing a program that generates D code?

If you're generating code which is so tricky that it needs to rely on comma expressions, then I doubt it will be something that users will be expected to read and/or edit.  In which case, again, it doesn't matter how ugly the syntax is.  "__exprSequencer" would do just fine.

--bb

On Fri, Jul 10, 2009 at 1:50 AM, Walter Bright<newshound1@digitalmars.com> wrote:

> Without any way to sequence expressions in place, a lot of manipulation becomes much more complicated. Comma expressions have been around a long time, they work well, and are often used.

Then why not, as someone else has suggested, use some kind of internal sequence node, maybe with an obscure keyword as the separator?  It's just that the syntactic possibilities of the comma operator are too wonderful to ignore.  It seems like such a waste of an operator for something that most people won't use in _human-generated_ code outside of for loop headers.

Walter Bright wrote:

> Having a step size requires, of course, a third operand. This doesn't work too well with infix operator notation (the only 3 operand infix operator is ?:).
> 
> Having such a third operand, however, should mesh quite well with Andrei's range library construct.

In the programming language I'm currently designing, .. is overloaded twice to get the desired effect.

----------------------------------------
Interval interval(int a, int b) {
    result.lower <- a;
    result.upper <- b;
}

Interval interval(Interval a, int b) {
    result <- a;
    result.stride <- b;
}

for (i, 1..10..-1) {
    // i = 10, 9, 8, 7, 6, 5, 4, 3, 2, 1
}
----------------------------------------

(Clarification: 'interval' is the function name used to overload the .. operator. <- is the assignment operator. 'result' is automatically declared and returned.)

You see, .. can remain a binary operator. Perhaps something like this can work for D.

-- 
Michiel Helvensteijn

Jarrett Billingsley wrote:
> On Fri, Jul 10, 2009 at 1:50 AM, Walter
> Bright<newshound1@digitalmars.com> wrote:
> 
>> Without any way to sequence expressions in place, a lot of manipulation
>> becomes much more complicated. Comma expressions have been around a long
>> time, they work well, and are often used.
> 
> Then why not, as someone else has suggested, use some kind of internal
> sequence node, maybe with an obscure keyword as the separator?  It's
> just that the syntactic possibilities of the comma operator are too
> wonderful to ignore.  It seems like such a waste of an operator for
> something that most people won't use in _human-generated_ code outside
> of for loop headers.

Because an *internal* sequence node will not be available to anyone writing D code that generates D code.

The sequence operator is very valuable to anyone writing code that generates code, pulling it out of D would make D fairly unusable for advanced metaprogramming.