gmane.comp.lang.factor.general

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.

(Continue reading)

headers

Slava Pestov | 1 Sep 01:53

Re: RESOLVE: form

On Sun, Aug 31, 2008 at 6:16 PM, Eduardo Cavazos <wayo.cavazos-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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
Factor-talk@...
https://lists.sourceforge.net/lists/listinfo/factor-talk

headers

Kobi Lurie | 1 Sep 15:46

Re: RESOLVE: form

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 
> <wayo.cavazos@...
<mailto:wayo.cavazos@...>> 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
> Factor-talk@...
> 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=/

headers

Kobi Lurie | 1 Sep 16:35

Re: RESOLVE: form

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
>>
<wayo.cavazos@...<mailto:wayo.cavazos@...>>
 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
>> Factor-talk@...
>> 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
> Factor-talk@...
> 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=/

headers

Slava Pestov | 1 Sep 19:48

Re: RESOLVE: form

On Mon, Sep 1, 2008 at 9:35 AM, Kobi Lurie <k_lurie@...> wrote:
> An example is in order:
> if vocab1 has 5 words, we type the ones we need:
>
> USING: vocab1 { foo bar } vocab2 { bar baz } ;

We already have this feature, look at the FROM: word in basis/qualified.

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=/

headers

Doug Coleman | 1 Sep 01:57

Re: RESOLVE: form

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
> Factor-talk@...
> 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=/

headers

Chris Double | 1 Sep 02:22

Re: RESOLVE: form

I've also hit this problem a few times and it's difficult to track
down. If there were a parse time error it would be easier.

If I change peg for example to add a new word that shadows something
in a users vocab, that user would probably like to know straight away
when they next update via a 'resolve error' or similar. Otherwise
they'll get odd, hard to track down, errors with no idea what could
have caused it.

Chris.
--

-- 
http://www.bluishcoder.co.nz

-------------------------------------------------------------------------
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=/

headers

Anton Rolls | 19 Sep 06:10

Re: RESOLVE: form

Hello everyone, if I may insert my opinion on this matter:

I think the way to really minimize this "extra baggage" problem
is for the "using" system to enforce (or "strongly encourage",
at least) the explicit naming of words.
eg. if vocabulary X uses vocabulary A, then X must explicitly
name each of the words from A that it needs.
Then A can be expanded with any number of extra words and it won't
ever affect X.

It's just like proper functional programming without side effects.
You name your input parameters, and you only work with them in
the function body.

Regards, and apologies if I misunderstand the situation.

Anton Rolls.

Eduardo Cavazos 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 

> 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.

> 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=/

headers

Slava Pestov | 19 Sep 10:07

Re: RESOLVE: form

Hi Anton,

This is already possible using the FROM: word in the qualified
vocabulary. With this word you can explicitly list all words to
import, no other words will appear in the search path:

FROM: sequences => each nth length ;

Whether this should be encouraged or not, I'm not so sure. If you're
only using one or two words from a vocabulary it might be a good idea,
but if you're using many the FROM: forms would get too long.

Slava

On Thu, Sep 18, 2008 at 11:10 PM, Anton Rolls <anton@...> wrote:
> Hello everyone, if I may insert my opinion on this matter:
>
> I think the way to really minimize this "extra baggage" problem
> is for the "using" system to enforce (or "strongly encourage",
> at least) the explicit naming of words.
> eg. if vocabulary X uses vocabulary A, then X must explicitly
> name each of the words from A that it needs.
> Then A can be expanded with any number of extra words and it won't
> ever affect X.
>
> It's just like proper functional programming without side effects.
> You name your input parameters, and you only work with them in
> the function body.
>
> Regards, and apologies if I misunderstand the situation.
>
> Anton Rolls.
>
> Eduardo Cavazos 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
>
>> 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.
>
>> 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
> Factor-talk@...
> 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=/