www.digitalmars.com         C & C++   DMDScript  

D - is this intentional?

reply "Carlos" <carlos8294 msn.com> writes:
why is ~= correct but ~ = is not? what's the point? does it happen also to
other operators?


-------------------------
Carlos 8294
http://carlos3.netfirms.com/
Jun 17 2002
next sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Yeah, that's how C works.  Some operators are made up of two characters, and
must be kept together.  Other examples include:

+=
-=
*=
/=
%=
&=
|=
!=
<=
=

|| and so on... Carlos wrote:
 why is ~= correct but ~ = is not? what's the point? does it happen also to
 other operators?

 -------------------------
 Carlos 8294
 http://carlos3.netfirms.com/

-- 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))) ]
Jun 17 2002
parent reply "Carlos" <carlos8294 msn.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> escribió en el mensaje
news:3D0E4FAD.553C3DB deming-os.org...
 Yeah, that's how C works.  Some operators are made up of two characters,

 must be kept together.  Other examples include:

 +=
 -=
 *=
 /=
 %=
 &=
 |=
 !=
 <=
=

||

others? what could possibly happen if there's something that's not a space (or tab or newline, etc.) between + and = ? error. that's the only. but if i write a + = b ; it should be ok. why a += b ; is ok and a + = b ; is not? i know c does it that way, but d is supposed to be better than c.
Jun 17 2002
next sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
It makes the tokenization easier if you don't have to deal with whitespace.
Also, it makes the code easier to read if the various characters of a token
aren't spread around the place.  Other than that, I don't see any reason why it
*has* to be this way...but I think it's better as it is, personally.

--
The Villagers are Online! http://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))) ]
Jun 17 2002
prev sibling parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
I feel for you Carlos.  (<=== betcha a translator program will have a field
day with that one!)

I suppose one could make a lexer work that way, but I've never done so.  Can
it be done?  I think the problem there is that the lexer would need info
from the parser syntax phase to determine what kind of token to return.
However this can probably be kludged around by accepting multiple single
tokens *or* one combined token in the parser because a + ( = b ) is not
syntactically correct.  However a + = b would have to be syntactically
correct because of how it's used if it's joined so to differentiate between
the two would have to be in the semantic analysis phase.  Right?  This is
the kind of thing Walter is trying to avoid with D.

Sean

"Carlos" <carlos8294 msn.com> wrote in message
news:aeljpk$dof$1 digitaldaemon.com...
 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> escribió en el mensaje
 news:3D0E4FAD.553C3DB deming-os.org...
 Yeah, that's how C works.  Some operators are made up of two characters,

 must be kept together.  Other examples include:

 +=
 -=
 *=
 /=
 %=
 &=
 |=
 !=
 <=
=

||

others? what could possibly happen if there's something that's not a space (or tab or newline, etc.) between + and = ? error. that's the only. but if

 write

 a              +               =                 b                   ;

 it should be ok. why

 a
 +=
 b
 ;

 is ok and

 a + = b ;

 is not? i know c does it that way, but d is supposed to be better than c.

Jun 17 2002
parent reply Burton Radons <loth users.sourceforge.net> writes:
Sean L. Palmer wrote:
 I feel for you Carlos.  (<=== betcha a translator program will have a field
 day with that one!)
 
 I suppose one could make a lexer work that way, but I've never done so.  Can
 it be done?  I think the problem there is that the lexer would need info
 from the parser syntax phase to determine what kind of token to return.
 However this can probably be kludged around by accepting multiple single
 tokens *or* one combined token in the parser because a + ( = b ) is not
 syntactically correct.  However a + = b would have to be syntactically
 correct because of how it's used if it's joined so to differentiate between
 the two would have to be in the semantic analysis phase.  Right?  This is
 the kind of thing Walter is trying to avoid with D.

The first lexers I wrote did this search, but then I realised that C couldn't handle it and thought that was a damned fine idea. It's identified in the lexer by knowing what tokens could be formed with additional characters and searching for those... there's no ambiguity, as C and D's operators are already carefully setup to never get false operator matches with valid combinations regardless of whitespace.
Jun 18 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Burton Radons" <loth users.sourceforge.net> wrote in message
news:3D0EE40D.1020902 users.sourceforge.net...
 The first lexers I wrote did this search, but then I realised that C
 couldn't handle it and thought that was a damned fine idea.  It's
 identified in the lexer by knowing what tokens could be formed with
 additional characters and searching for those... there's no ambiguity,
 as C and D's operators are already carefully setup to never get false
 operator matches with valid combinations regardless of whitespace.

C++ exhibits troubles one can get into with lexing ambiguities, the classic one being is >> a right shift or is it two separate nested template argument list closures?
Jun 18 2002
parent "OddesE" <OddesE_XYZ hotmail.com> writes:
"Walter" <walter digitalmars.com> wrote in message
news:aenor2$2jho$1 digitaldaemon.com...
 "Burton Radons" <loth users.sourceforge.net> wrote in message
 news:3D0EE40D.1020902 users.sourceforge.net...
 The first lexers I wrote did this search, but then I realised that C
 couldn't handle it and thought that was a damned fine idea.  It's
 identified in the lexer by knowing what tokens could be formed with
 additional characters and searching for those... there's no ambiguity,
 as C and D's operators are already carefully setup to never get false
 operator matches with valid combinations regardless of whitespace.

C++ exhibits troubles one can get into with lexing ambiguities, the

 one being is >> a right shift or is it two separate nested template

 list closures?

Yeah, that one really sucks! -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net _________________________________________________ Remove _XYZ from my address when replying by mail
Jun 24 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Carlos" <carlos8294 msn.com> wrote in message
news:aelggm$act$1 digitaldaemon.com...
 why is ~= correct but ~ = is not? what's the point? does it happen also to
 other operators?

~= (no space) is considered a single token, where as ~ space = is considered two separate tokens. The same holds true for the other assignment operators. -Walter
Jun 17 2002