2009/10/26  <[email protected]>:
> On Mon, Oct 26, 2009 at 5:45 PM, Mike Samuel <[email protected]> wrote:
>> 2009/10/26 Mike Samuel <[email protected]>:
>>> To really get the scope creation and listener concerns separate, we
>>> would have to change analyzer to create its own intermediate scope
>>> object, since right now, it relies on the scope instance in defSite.
>>> It might be worthwhile to separate that out and then we could
>>> introduce a scopeIntroduced(ScopeType, AncestorChain<?> scopeRoot)
>>> message which would allow the scope creation part to compose.
>>
>> So I guess the upshot is that you're absolutely right that the
>> distinction is unnecessary, but the current implementation is lacking
>> because ScopeAnalyzer is unnecessarily entangled with the
>> implementation of the scope class.
>
> Hmm, I see ....
>
> So I guess my point (maybe you are agreeing above?) was that there
> need be only one Scope implementation -- a simple "information holder"
> that (perhaps) points back to the ParseTreeNodes and holds whatever
> information about them the ScopeAnalyzer was able to divulge. And so
> the ScopeAnalyzer and Scope classes would form a unit much like the
> Parser and ParseTreeNode classes do.
>
> Was that your point too?

No.  My point was that ScopeFactory is unnecessary.

The troubles I've been having with the current one are:
  (1) The warnings issued.
  (2) LocalType is too blunt.  Sometimes it makes sense to track all
declarations per name, sometimes just one, and issue an error.
  (3) It doesn't make it easy to retrieve the declaration/initialization point.

I think you're right that we could move to a single scope class, but
often clients of a scope implementation want to treat a scope as a
symbol table, so have a "symbol" instance to hang their hat on.  That
can always be stored in side-tables, but then you need a way to go
from a scope to those side tables.  So why not just let the listener
that creates a scope object -- if the client needs one at all --
collect the symbol information as it sees fit.


> Ihab
>
> --
> Ihab A.B. Awad, Palo Alto, CA
>

Reply via email to