[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DotGNU]compilation error on using namespace

From: Jonathan P Springer
Subject: Re: [DotGNU]compilation error on using namespace
Date: Mon, 23 Dec 2002 13:04:51 -0500
User-agent: Mutt/1.4i

On Mon, Dec 23, 2002 at 03:43:12PM +0530, Gopal V wrote:
> Fixing this bug needs a bit of tweaking the existing thing to add a
> "quiet" mode which probes for correct member or type or namespace..

I've been thinking about this for the past few weeks, but haven't had
the cycles to implement.  The problem, as I see it, is that semantic
analysis of MemberAccess needs to be able to do three things:

1)  Variable.Member
2)  Type.Member
3)  Namespace.Type.Member

As you can see, the lhs of a '.' operation can be semantically analyzed
as one of three different things.  It gets even hairier when something
like Namespace.Type.Member.Member comes into play.

The reason the "quiet" methods came along was to defer the printing of
errors until the semantic analyzer had a clue what was going on.
Unfortunately, as Rhys noted privately and I will confess to publically,
it turned into stringy pasta.

Knowing what I do now, I'd suggest we reconsider MemberAccess semantic
analysis with the following changes:

1)  Deferred error processing - Queue errors up in storage and output
only once the semantic analyzer is sure what's going on (or completely lost).

2)  "Quantum" semantic analysis - Analyze the left-hand-side of each '.'
for all three possibilities and store the results of all of the semantic
analysis in the node.  The node only "resolves" when the top of the
MemberAccess tree is reached.  At that point, appropriate errors are
dumped from the queue.

I haven't had the time to dive into the details here, but what I like is
the "to error or not to error" decision lives at the same place as the
"what type is this" decision, avoiding a lot of spaghetti.  It also
removes a lot of the "hmm, should I really do this" code.  The downside
is some unnecessary processing, but I come from the "code (cleanly)
first, tune later" school of thought.

(n.b. This approach may also be needed for
> Which is sort of saying "I know it's broken, I know how to fix it,
> but it's so radical that it needs some expert design decisions"..

Hope that's given you something to chew on.  I think I'll worry away at
it some more after I finish Floating Point parsing :-/.

-js 212-314-4893

-Jonathan P Springer <address@hidden>
"A standard is an arbitrary solution to a recurring problem." - Joe Hazen

reply via email to

[Prev in Thread] Current Thread [Next in Thread]