why is ~= correct but ~ = is not? what's the point? does it happen also to other operators?


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

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

"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,
and
> must be kept together.  Other examples include:
>
> +=
> -=
> *=
> /=
> %=
> &=
> |=
> !=
> <=
> >=
> &&
> ||
>
ok. thanks for reminding me that. i understand || and &&, but why the 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.

"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

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

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,
> and
> > must be kept together.  Other examples include:
> >
> > +=
> > -=
> > *=
> > /=
> > %=
> > &=
> > |=
> > !=
> > <=
> > >=
> > &&
> > ||
> >
> ok. thanks for reminding me that. i understand || and &&, but why the 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.

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.

"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?

"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
classic
> one being is >> a right shift or is it two separate nested template
argument
> 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