>> My intuition for representing this would be different. Given that the >> '*Symbol' classes are where definitions of things tend to be stored in >> the >> Chapel compiler (e.g., a function's formals and return type are in >> FnSymbol, not FnType, for better or worse), I'd be inclined to represent >> the notion that 'c_char' is an alias in its 'TypeSymbol', or possibly a >> subclass of 'TypeSymbol' (e.g., 'TypeDefSymbol' or 'TypeAliasSymbol'?) >> rather than in the 'Type' class itself. > > > I'm not sure I understand how I could make this change without > changing also what is stored in the Type class. > > If I have two variables: > var a_char: c_char; > var an_int: int(8); > > both will have Type int(8), and so type->symbol will be the int(8) symbol. > I need to add another TypeSymbol for c_char and connect a_char's type > to it. So I believe that means I also need to add something to the Type > attached to a_char > (I can certainly add to both a_char->type and a_char->type->symbol, > but I don't see how I can only add to a_char->type->symbol). > > I suppose that I could add a 2nd type to VarSymbol for these cases, > but that doesn't feel like a good strategy to me...
I was suggesting ceasing to use VarSymbol to represent these cases (because they're not really variables) and to switch to TypeDefSymbol or TypeAliasSymbol, which might be a sub-class of TypeSybmol and in addition to the inherited 'type' field, it would also have a 'typeAlias' field. So it would be the thing storing two types, not Type nor VarSymbol. -Brad ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
