Moving this to 'factor-talk' so others can chime in. You give a good enough description below so that others can catch up.
Slava wrote: > We figured this out. Doug added a 'second' word to calendar which shadowed > sequences:second in ui.gestures. > > This took me 5 minutes to bootstrap and another 5 to debug. Adding the time > Doug spent on this, we have about half an hour of lost work between the two > of us. > > Let me again propose the feature where if you have a:foo and b:foo, then > USING: a b ; foo, you get a parse time error about ambiguity in the search > order. A RESOLVE: parsing word could be used to specify which one you want, > so adding RESOLVE: a foo or RESOLVE: b foo would solve the parse error. If > this had been a parse error, Doug could've bootstrapped and Factor would've > immediately indicated that something was wrong. He would see a message much > like the following: > > The word "second" is defined in more than one vocabulary in the search path > but no RESOLVE: form was given. > > Restarts: > > 1: Use calendar > 2: Use sequences > > This would have enabled him to fix the issue in a matter of seconds and > saved us both time. OK. This is a nice real world example of the problem. But when you say "Let me again propose the feature..." I'm taking that to mean "propose for further analysis" and not "propose for immediate inclusion". Let's think about how this would impact things. Let's say vocabularies X Y Z use vocabulary A. I edit A. I refresh-all. Let's suppose that 'refresh-all' has the proposed behaviour whereby it refreshes X Y and Z since they depend on A (I believe you mentioned that this is a planned feature). Alright, let's say the above problem scenario occurs; a new word in A shadows a word from a vocabulary that X Y and Z use. When I do my refresh-all I'm going to get error messages about how the change is causing problems in X Y and Z. So this is going to lead to a situation where I am constrained about how I name things in my vocabulary based on how *others* use it. The whole freedom to name is now impeded a bit. Moreover, the above notifications about how I'm impacting other vocabularies *only* happen if I happen to have X, Y, and Z loaded. What about all the stuff in the CFAN (CPAN for factor...)? I'm not going to know I'm impacting any of that. What about stuff that's in 'extra' that I haven't bothered to load? I also have a request. Let's do an analysis of the current code base. Let's suppose RESOLVE: were implemented. How many vocabularies would be impacted? Here's something else to consider. Your complaint is that the shadowing occured but you weren't notified about it. It's quite possible that when such shadowing occurs, you'll get compile time errors because of a mismatched stack effect. Did you not see such errors after Doug added 'second' to calendar? This sort of detection is only going to go up as folks use types in their effects more often and the compiler gets better at detecting inconsistencies. Maybe it's a good and necessary idea. I'm just trying to think about it. Ed ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Factor-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/factor-talk
