"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3D611057.D1573627@deming-os.org...
> There's no reason we couldn't use text operators.  Remember the inline
function
> syntax we played with a while back?
>
>     MyObj a;    OtherObj b;
>     a exp b;    // implemented by MyObj.exp(OtherObj) ???

Inline text operators, without any distinguishing special characters, would be a **** to parse. For example, this sentence would be valid D syntax.

Walter wrote:

> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3D611057.D1573627@deming-os.org...
> > There's no reason we couldn't use text operators.  Remember the inline
> function
> > syntax we played with a while back?
> >
> >     MyObj a;    OtherObj b;
> >     a exp b;    // implemented by MyObj.exp(OtherObj) ???
>
> Inline text operators, without any distinguishing special characters, would be a **** to parse. For example, this sentence would be valid D syntax.

I keep forgetting that.  Sorry.  Any thoughts on if it would be a good idea if there WERE distinguishing characters?  Any thoughts on what those characters could be?

--
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))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3D611A88.5EDF83A4@deming-os.org...
> > "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3D611057.D1573627@deming-os.org...
> > > There's no reason we couldn't use text operators.  Remember the inline
> > function
> > > syntax we played with a while back?
> > >
> > >     MyObj a;    OtherObj b;
> > >     a exp b;    // implemented by MyObj.exp(OtherObj) ???
> >
> > Inline text operators, without any distinguishing special characters,
would
> > be a **** to parse. For example, this sentence would be valid D syntax.
> I keep forgetting that.  Sorry.  Any thoughts on if it would be a good
idea if
> there WERE distinguishing characters?  Any thoughts on what those
characters
> could be?

It would be workable if there were distinguishing characters, like perhaps
bracketing the identifier with :,
as in a :exp: b. The next problem is what is the operator precedence.

"Walter" <walter@digitalmars.com> wrote in message news:ajruie$2edb$2@digitaldaemon.com...
>
> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3D611A88.5EDF83A4@deming-os.org...
> > > "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3D611057.D1573627@deming-os.org...
> > > > There's no reason we couldn't use text operators.  Remember the
inline
> > > function
> > > > syntax we played with a while back?
> > > >
> > > >     MyObj a;    OtherObj b;
> > > >     a exp b;    // implemented by MyObj.exp(OtherObj) ???
> > >
> > > Inline text operators, without any distinguishing special characters,
> would
> > > be a **** to parse. For example, this sentence would be valid D
syntax.
> > I keep forgetting that.  Sorry.  Any thoughts on if it would be a good
> idea if
> > there WERE distinguishing characters?  Any thoughts on what those
> characters
> > could be?
>
> It would be workable if there were distinguishing characters, like perhaps
> bracketing the identifier with :,
> as in a :exp: b. The next problem is what is the operator precedence.

Parhaps a number could be kept with the function definition.

int exp:4(int a, int b); //precedence level 4

...or as someone alreay suggested, give them all the same precedence. That level could be at the highest level just below brackets. I say that because, most often a :func: will be a high order function.

Walter wrote:

> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message
> news:3D611057.D1573627@deming-os.org...
> 
>>There's no reason we couldn't use text operators.  Remember the inline
>>
> function
> 
>>syntax we played with a while back?
>>
>>    MyObj a;    OtherObj b;
>>    a exp b;    // implemented by MyObj.exp(OtherObj) ???
>>
> 
> Inline text operators, without any distinguishing special characters, would
> be a **** to parse. For example, this sentence would be valid D syntax.

Not really.  In the first pass, you consume statements and declarations but keep function bodies and initialisers as strings of tokens; parse the context, then create the syntax trees for the stuff that was deferred.

The utility is a whole other matter.  I consider "a.exp (b)" superior to "(a exp b)" because:

a) It's explicit about who's doing what to whom.  Operator precedence is a non-issue.

b) It doesn't keep exp from being used in various contexts.

c) It's the same number of characters.

d) The (a exp b) syntax doesn't offer anything new.

e) Making expressions look closer to mathematical drawings is an IDE issue, not a lingual responsibility, and they're facilitated in this by keeping things simple and as method-based as possible.

Hi,

"Walter" <walter@digitalmars.com> wrote in message news:ajpa1n$268h$1@digitaldaemon.com...
> > > Hm... Maybe a^^b?
> > It looks like a logical xor to me.
> It's been proposed as a logical xor for C many times.

I often wondered why it wasn't there, as it would make the set of operators more consistent. It seems that I'm not the only one. The same could be said about &&= and ||=. However, I can't say I have missed them much, and the set of operators in D is already large enough. So consider this a comment, not a proposal for D. Keep up the good work.

Regards,
Martin

On Tue, 20 Aug 2002 17:22:22 +0100 "Martin M. Pedersen" <mmp@www.moeller-pedersen.dk> wrote:

> I often wondered why it wasn't there, as it would make the set of operators more consistent. It seems that I'm not the only one. The same could be said

Logical xor is operator !=

> about &&= and ||=. However, I can't say I have missed them much, and the set

These, I think they could be added. We have &= and |=, then why not &&= and ||= ?

Hi,

"Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374888137990278@news.digitalmars.com...
> Logical xor is operator !=

Not exactly, as 2!=1 yields true. != is only a logical xor if the operands are guaranteed to be either 0 or 1.

Regards,
Martin M. Pedersen

Walter wrote:
> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message
> news:3D611A88.5EDF83A4@deming-os.org...
> 
>>>"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message
>>>news:3D611057.D1573627@deming-os.org...
>>>
>>>>There's no reason we couldn't use text operators.  Remember the inline
>>>
>>>function
>>>
>>>>syntax we played with a while back?
>>>>
>>>>    MyObj a;    OtherObj b;
>>>>    a exp b;    // implemented by MyObj.exp(OtherObj) ???
>>>
>>>Inline text operators, without any distinguishing special characters,
>>
> would
> 
>>>be a **** to parse. For example, this sentence would be valid D syntax.
>>
>>I keep forgetting that.  Sorry.  Any thoughts on if it would be a good
> 
> idea if
> 
>>there WERE distinguishing characters?  Any thoughts on what those
> 
> characters
> 
>>could be?
> 
> 
> It would be workable if there were distinguishing characters, like perhaps
> bracketing the identifier with :,
> as in a :exp: b. The next problem is what is the operator precedence.

IMHO, it should be the same as function calls.  In fact, we really have a function call - it's just inline syntax because that is more readable for mathematical expressions.

"Russell Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3D6264F5.60704@deming-os.org...
> > as in a :exp: b. The next problem is what is the operator precedence.
> IMHO, it should be the same as function calls.  In fact, we really have a function call - it's just inline syntax because that is more readable for mathematical expressions.

Your rationale makes perfect sense.