An example is in order:
if vocab1 has 5 words, we type the ones we need:
USING: vocab1 { foo bar } vocab2 { bar baz } ;
in the actual source of the file, we use words as normal
but we'll get an error for 'bar', asking to qualify it and use the
qualified version in the source (where needed).
(to minimize the verbosity, maybe it's possible that only one of the
words would need qualified,
once the compiler sees a qualification of the word, it would assume the
other uses of the word belong to the other vocab)
Anything that makes things more transparent for the programmer is a good
thing, in my opinion.
what do you think of the above syntax for using? a bonus of the approach
could be a warning/note about unused words. please :)
thanks, Kobi
Kobi Lurie wrote:
> 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
>
>
-------------------------------------------------------------------------
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
