Re: constatnt initialization

Joachim Durchholz <>
14 Dec 2003 22:11:11 -0500

          From comp.compilers

Related articles
constatnt initialization (2003-12-03)
Re: constatnt initialization (2003-12-08)
Re: constatnt initialization (Clint Olsen) (2003-12-13)
Re: constatnt initialization (Nick Roberts) (2003-12-13)
Re: constatnt initialization (Joachim Durchholz) (2003-12-14)
| List of all articles for this month |

From: Joachim Durchholz <>
Newsgroups: comp.compilers
Date: 14 Dec 2003 22:11:11 -0500
Organization: Oberberg Online Infosysteme
References: 03-12-046 03-12-085
Keywords: analysis
Posted-Date: 14 Dec 2003 22:11:11 EST

Clint Olsen wrote:

> You're going to have to implement type equivalence checking to your
> compiler. There are a couple of ways to do it. The brute force way
> is to write a 'deep' comparison which recursively descends into 'type'
> and compares it against 'expression' at each phase along the way to
> determine that they are assignment compatible. This means, for
> structs (records) comparing each field and ensuring that the number
> and type of each field is compatible with each element in the
> expression, comparing the subtype and number of elements for arrays,
> and then simple checks for the intrinsic types (integer, real, string)
> etc. You walk 'type' to help guide you for what to expect for
> successive elements. If you're writing a recursive descent parser,
> this is pretty straightforward since you'll build the 'type' before
> you parse the expression.

This is straightforward only if there are no cycles in the paths that
the comparator follows. Cycles are quite common; they are usually
introduced through pointers. One way is to break cycles (e.g. at
pointers) and use name equality here. The other is to implement a
comparison algorithm that can handle cycles (it's not that difficult:
you mainly have to keep a record of nodes that you already visited).


Post a followup to this message

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