You know, forth also has this problem, and I agree it should be taken care of, but seems like you can't entirely solve it, unless you sacrifice some comfort. To state my point of view, a solution would be to change USING: to require both the vocab and the word. then there would be no ambiguity, and if you USE the same word twice, you'll get a parse error that would tell you to qualify one of them in the source.
kobi Slava Pestov wrote: > On Sun, Aug 31, 2008 at 6:16 PM, Eduardo Cavazos > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: > > 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). > > > This is not a planned feature. I invest considerable time into getting > the compiler to recompile the right words when a source file is > reloaded precisely so that I don't need to do this. It would be > annoying to change and reload 'sequences' and then have every other > file reload and recompile because they depend on it. > > 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. > > > The other alternative is that X, Y, and Z stop working and you have no > indication until you try using words from those vocabs (which might be > 6 months later). > > 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? > > > You can't avoid breaking other code sometimes by changing names. The > point is to detect the problem as early as possible: at parse time, > not run time. > > 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. > > > Both sequences:second and calendar:second have the same effect ( a -- > b ) so the compiler didn't complain. > > If you have a static type system like the one found in ML and Haskell, > you don't need things like this because type signatures can be very > precise, but we shouldn't postpone improvements which can benefit us > immediately based on some blue-sky feature which or may not materialize. > > Slava > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > 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
