[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: x + (y) + z
From: |
Frank Heckenbach |
Subject: |
Re: x + (y) + z |
Date: |
Fri, 4 Mar 2005 19:19:58 +0100 |
User-agent: |
semail 20050101 |
Derek M Jones wrote:
> >> The statement (y)+z can be parsed as casting
> >> +z to the type y, or as adding y to z. A couple of
> >> %dprecs solve this problem (I think the cast is the
> >> common case for - and a binary expression for +).
> >
> >What the "common case" is doesn't really matter since a correct
> >parser should be able to recognize all valid inputs, not only the
> >most common ones. So if I understand right what you plan, this would
> >all be just heuristics which don't really solve the problem.
>
> Since both parses will recognise the input one has to be
> selected. Picking the common case means that there is
> less work which has to be undone later in the semantics phase.
Undoing and reversing parsing (as you also mentioned in another
mail) may be an option, but IMHO not a very good one, if you can't
use the parser the way it's supposed to.
But since you don't state why you don't do the usual thing (separate
token for type names), I can't say anything more ...
Frank
--
Frank Heckenbach, address@hidden
http://fjf.gnu.de/
GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)
- Re: Forcing multiple parse stacks to 'reduce', (continued)
- Re: Forcing multiple parse stacks to 'reduce', Derek M Jones, 2005/03/01
- Re: Forcing multiple parse stacks to 'reduce', Hans Aberg, 2005/03/01
- Re: Forcing multiple parse stacks to 'reduce', Hans Aberg, 2005/03/01
- Re: Forcing multiple parse stacks to 'reduce', Derek M Jones, 2005/03/02
- Re: x + (y) + z, Frank Heckenbach, 2005/03/03
- Re: x + (y) + z, Derek M Jones, 2005/03/04
- Re: x + (y) + z,
Frank Heckenbach <=
- Message not available
- Re: x + (y) + z, Frank Heckenbach, 2005/03/06
- Re: x + (y) + z, Derek M Jones, 2005/03/06
- Re: x + (y) + z, Kelly Leahy, 2005/03/04