# HG changeset patch # User Mario de Sousa # Date 1331378464 0 # Node ID da650a87662db725f291ef252e679b73144202fe # Parent d2cd05c5e01abe5c1a510cfe61b8e273e6ca4b72 Bringing comment up to date. diff -r d2cd05c5e01a -r da650a87662d absyntax/absyntax.def --- a/absyntax/absyntax.def Fri Mar 09 17:58:19 2012 +0000 +++ b/absyntax/absyntax.def Sat Mar 10 11:21:04 2012 +0000 @@ -164,34 +164,15 @@ * OR * neg_literal_c -> real_literal_c * - * In the semantic verification and code generation stages of the compiler, - * the integer_c is treated as a basic (undefined) data type, since an integer - * constant may be used as a BYTE, BOOLEAN, REAL, etc..., depending on the - * context in which it is used. - * However, an integer_c that is preceded by a '-' may not be used - * as an ANY_BIT data type (BYTE, BOOLEAN, WORD, ...). - * We must therefore be able to determine, holding a simple pointer - * to an integer_c, if that integer_c value is preceded by a '-'. - * However, since the neg_literal_c points to the integer_c, and not - * vice-versa, we can't determine that. - * There are 3 simple ways of working around this: - * - change the order of the pointers: - * have the integer_c and real_c point to the neg_literal_c - * - maintain the order of the pointers, and - * add redundant info to the integer_c and real_c + * However, this has since been changed to... * - replace the neg_literal_c with two distinc classes * (neg_integer_c and neg_real_c), one for each - * lietral type. This means that we can now treat - * each of these classes as an unknown data type - * just as we do with the integer_c and real_c. - * - * The second option is simply ugly. - * and the first has a serious drawback: when generating code it is - * easier to encapsulate the real or integer values inside prefix - * and postfix symbols (e.g. NEG() - with postfix ')' ) - * if we keep the pointer order as is. - * - * For the above reasoning, we use the third option. + * lietral type. + * + * This change was done in order to ease the writing of semantic verification (stage3) code. + * However, that version of the code has since been replaced by a newer and better algoritm. + * This means the above change can now be undone, but there is really no need to undo it, + * so we leave it as it is. */ SYM_REF1(neg_real_c, exp) SYM_REF1(neg_integer_c, exp)