On Sun, Aug 31, 2008 at 6:16 PM, Eduardo Cavazos <[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
