[prev in list] [next in list] [prev in thread] [next in thread] 

List:       e-lang
Subject:    [e-lang] Re: conflicting definitions error
From:       Mark Miller <markm () cs ! jhu ! edu>
Date:       2004-11-09 14:00:56
Message-ID: 4190CD98.7020102 () cs ! jhu ! edu
[Download RAW message or body]

Peter Dimitrov wrote:
> Hi Mark,
> 
> I noticed that when i use when catch the following warning occurs:
> 
> *** conflicting definitions of __main$makenode__C$node__C$done__C
> 
> What exactly this warning means?

That there are multiple objects defined with this same fully qualified name. 
This occurs with when-catch usage when you say, for example,


     def makenode {
         ...
         def node {
            ...
            when (...) -> done(...) { ... } catch ... { ... }
            ...
            when (...) -> done(...) { ... } catch ... { ... }
            ...
         }
     }

"done" is not a keyword above. Instead, it is simply used to name the object 
(the "done-closure") which behaves according to the code appearing to the 
right of the "->", much as "node" is used to name the object which behaves 
according to the code in the containing object definition above.

The fully qualified name is formed, as in Java, by appending the package path 
(in your case, "__main") with the path of names of containing object 
definitions. This is in addition to the normal variable scoping rules, so it 
doesn't matter if the two when-catch clauses above are within different 
lexical scopes (i.e., different methods or control constructs), so long as 
they are both nested within the same immediately containing object -- in your 
case, "node".

The four ways to address this:

* Give each done-closure a unique name:

     def makenode {
         ...
         def node {
            ...
            when (...) -> done1(...) { ... } catch ... { ... }
            ...
            when (...) -> done2(...) { ... } catch ... { ... }
            ...
         }
     }

* [Recommended] As above, but give them descriptive names. Once we're using 
our distributed debugger, Causeway, giving each a descriptive name will help 
tremendously. (Causeway may indeed become ready in time to help with our class 
projects.)

* Use anonymous done-closures:

     def makenode {
         ...
         def node {
            ...
            when (...) -> _(...) { ... } catch ... { ... }
            ...
            when (...) -> _(...) { ... } catch ... { ... }
            ...
         }
     }

* Ignore the warning for now, as, in this version of E, it's harmless. 
However, in a future version of E, these warnings will turn into errors, 
causing such code to be rejected.

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM


_______________________________________________
e-lang mailing list
e-lang@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang
[prev in list] [next in list] [prev in thread] [next in thread]