Mark Mitchell <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis wrote: | | > | the object-representation side; we need a PTRMEM_TYPE on the type side | > | as well. Because we don't have a proper lowering phase, the | > | difficulty is that we need to transmute PTRMEM_TYPE into | > | OFFSET_TYPE/RECORD_TYPE at some point. | > | | However, that's no excuse for forming a POINTER_TYPE pointing to | > a | > | METHOD_TYPE or member FUNCTION_TYPE. Such things should be replaced | > | with the RECORD_TYPEs we presently use to represent pointers to member | > | functions. | > Hmm, using RECORD_TYPE for both classes and pointer to member | > functions seem to me to be less desirable as say, using tree for just | > about any data structure. I would think as we gradually move toward | > representations closer to the standard specification we would | > represent | > distinct notions by distinct data structures. | | Isn't that exactly what I just said above?
I did not understand it that way. Thanks for the clarification. | | > I recon that such | > representation needs a lowering stage, but it looks like we're doing | > that more or less already. Do I miss something? | | Yes -- we don't really have a lowering stage, unless you count | transformation to GENERIC. Yes, I had transformation to GENERIC in mind. Were you thinking of having another stage in addition of transformation to GENERIC? What would be its distinctive characeteristics? -- Gaby