RESOLVE: form
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=/
RSS Feed