|constatnt initialization firstname.lastname@example.org (2003-12-03)|
|Re: constatnt initialization email@example.com (2003-12-08)|
|Re: constatnt initialization firstname.lastname@example.org (Clint Olsen) (2003-12-13)|
|Re: constatnt initialization email@example.com (Nick Roberts) (2003-12-13)|
|Re: constatnt initialization firstname.lastname@example.org (Joachim Durchholz) (2003-12-14)|
|From:||Joachim Durchholz <email@example.com>|
|Date:||14 Dec 2003 22:11:11 -0500|
|Organization:||Oberberg Online Infosysteme|
|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).
Return to the
Search the comp.compilers archives again.