Re: The signs of literals

David L Moore <dlmoore@ix.netcom.com>
10 Dec 1997 00:32:30 -0500

          From comp.compilers

Related articles
The signs of literals lin@cs.monash.edu.au (Hung-Ta Lin) (1997-12-07)
Re: The signs of literals dlmoore@ix.netcom.com (David L Moore) (1997-12-10)
Re: The signs of literals clark@quarry.zk3.dec.com (Chris Clark USG) (1997-12-10)
Re: The signs of literals hbaker@netcom.com (1997-12-12)
Re: The signs of literals tim@wagner.Princeton.EDU (1997-12-12)
Re: The signs of literals mtimmerm@microstar.no-spam.com (Matt Timmermans) (1997-12-12)
Re: The signs of literals dlmoore@ix.netcom.com (David L Moore) (1997-12-13)
| List of all articles for this month |

From: David L Moore <dlmoore@ix.netcom.com>
Newsgroups: comp.compilers
Date: 10 Dec 1997 00:32:30 -0500
Organization: Netcom
References: 97-12-053
Keywords: syntax

Hung-Ta Lin wrote:
>
> Hi, I am working on a grammar that explicitly treats sign as part of a
> integer literal:


> The grammar is ambiguous because [minus could be part of the literal or a
> part of a unary minus expression]:


Two quick points.


First, the grammar is not ambiguous because if you decide to fold the
minus into a lexical symbol then you have one symbol. The grammar does
not see the minus sign in this case, so there is no conflict. What is
ambiguous is the lexer.


This is not an uncommon situation. For example, in Pascal, the string
"1..2" is 1, followed by .., followed by 2, not a real literal, and
. and an int literal.


Lexers frequently have to look ahead to disambiguate symbols. This is
what you need to do here.


Second, it would be incorrect to treat a negative number as a positive
number with a unary minus preceding it because, if your machine is
two's compliment, you can now not represent the largest negative
integer (eg -32768 in 16 bit) as a constant.


You can also avoid this problem by using "infinite arithmetic" for the
representation of numeric literals.


Third (nobody expects the Spanish Inquisition) If you do not use
infinite size arithmetic, make sure you convert the constant to binary
by assuming it is negative, and then converting it to positive at the
end if it is not negative, rather than the other way round. Otherwise
you are stuck with an overflow on the maximum negative value again as
you cannot represent it as a positive binary value.


--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.