I didn't see any compiler errors when I added the 'ALIAS: second seconds' to calendar. In fact, Factor didn't even throw the popup exception until I bootstrapped again. I could have been using the same image for a few more days and made lots of commits before ever having to bootstrap again. I've been hit by this shadowing bug at least four times and every time it takes a lot of debugging and WTFs to find a solution.
To address the hypothetical problem, if you're editing A, and X Y Z depend on A, then A is some sort of library, utility, or component of X Y Z and you should therefore have to fix X Y Z too. If, on the other hand, A is using X Y Z and something in one of those causes a resolve error, then X Y Z are the libraries and you are writing some kind of application. If the libraries change, then it's fine to have the application writer update his code. Libraries need to be written with more care than applications so that they are reusable, and this means avoiding common word names or adding lots of RESOLVE:s. Doug On Aug 31, 2008, at 6:16 PM, Eduardo Cavazos wrote: > 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 ------------------------------------------------------------------------- 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
