Slava, Thanks for the long answer. Yes, it is much clearer now.
Thanks again, Steve On Wed, Feb 4, 2009 at 7:43 AM, Slava Pestov <[email protected]> wrote: > Steve, > > Adding a stack effect after M: doesn't do anything, actually. > > Let me try to explain again. The first thing to realize is that stack > effect checking is like a very weak form of static typing, however it > is also optional and Factor can still run code which doesn't pass this > little type checker. > > Now, when you do this, it bails out: > > [ set-model ] infer. > > This means that even though set-model is defined with the stack effect > ( value model -- ), the compiler cannot _prove_ that this effect > holds. Any word that calls set-model won't get a static stack effect > either. Again, our stack effect inference is a "soft typing" system > where not all declarations are checked statically. For example, if you > look up a quotation in a hashtable, > > "foo" my-hash get call > > The compiler has no way of knowing at compile-time what the stack > effect of the quotation will be at runtime, so this bails out: > > [ "foo" my-hash get call ] infer. > > Words for which inference cannot deduce an effect are second-class > citizens. They run with reduced performance (because the compiler > doesn't perform optimizations here) and they cannot be used in certain > contexts. This is not very good, which is why I'm going to make the > stack inference model stronger at some point in the near future, and > for instance, you'll be able to declare that the quotation you just > looked up in the hashtable has a certain stack effect, and the type > system will assert this. > > So you cannot use set-model (and other words like it) in methods on > generic words defined by the system, for example accessors, or the > sequence protocol (nth, ...), because in this case any word that calls > the generic word in question will also fail to compile, hence your > earlier instance of ~2000 compiler warnings appearing. > > So until the new system is in place, here are two rough guidelines: > > - For your own code, it generally doesn't matter if words are > optimized or not. You can ignore compiler warnings in most cases > (these indicate that a word was not optimized). However in the > interest of performance and better static guarantees, you should try > to minimize them, if possible. However you won't be able to get rid of > them altogether, like in the above example with calling a quotation > from a hashtable. > > - When defining methods on generic words in other libraries, you > should only use words in the body that infer. The exception is generic > words that don't infer as-is (eg, some words in the UI like graft*). > > Does this make more sense now? > > As I said above, the situation is going to change very soon with > respect to stack effect declarations and the checking done by the > compiler. After the new system is in place, things will hopefully > become easier to understand and will definitely be more robust, with > additional bugs caught at load time rather than run time. > > Slava > > On Wed, Feb 4, 2009 at 5:48 AM, Steve Weeks <[email protected]> wrote: >> Oh. I had missed the bit about set-model. I read the references, but >> I'm still confused. I added the stack effect (simplified the example) >> to this: >> >> IN: foo >> >> USING: accessors models ; >> >> TUPLE: m < model ; >> >> : <m> ( value -- model ) m new-model ; >> >> M: m (>>loc) ( value object -- ) set-model ; >> >> With the stack effect factor still blows up. Since the inferred >> effect is stronger, then declaring an effect won't fix the problem, >> hence the continued problems. >> >> Sorry, but I still don't get it. >> Steve >> >> >> >> >> On Wed, Feb 4, 2009 at 5:40 AM, Slava Pestov <[email protected]> wrote: >>> On Wed, Feb 4, 2009 at 4:30 AM, Steve Weeks <[email protected]> wrote: >>>> I tried specifying the stack effect in the method body and still get >>>> problems. >>> >>> Whether or not a word has an inferred effect is a stronger property >>> than an effect being declared. You are right that one does not have to >>> declare effects on methods, but here the problem is that the compiler >>> is unable to prove that the 'set-model' word (and hence any caller of >>> it) has a static stack effect. >>> >>>> I think the issue is that there is no slot "loc" when I >>>> code >>>> >>>> M: loc-model (>>loc) set-model ; >>>> >>>> The line: >>>> >>>> M: loc-model loc>> value>> ; >>>> >>>> doesn't cause any problems, which seems strange since it to is using a >>>> generic without the slot being defined in the tuple. >>> >>> No, that's not the problem. There are a few places in the code where I >>> define 'virtual slots' in this manner. Try this for instance, >>> >>> TUPLE: my-tuple i ; >>> >>> SLOT: s >>> >>> M: my-tuple s>> i>> number>string ; >>> M: my-tuple (>>s) [ string>number ] dip (>>i) ; >>> >>> The SLOT: parsing word merely ensures that the generic words s>> and >>> (>>s) exist, if they don't already. >>> >>> The issue with your specific example is that the method bodies should >>> have static stack effects, and as I've mentioned before set-model does >>> not. You can read more about this in the FAQ. See the question, "What >>> are compiler errors and warnings", in >>> >>> https://concatenative.org/wiki/view/Factor/FAQ/Develop >>> >>> and check out the documentation pages referenced therein. >>> >>> Slava >>> >>> ------------------------------------------------------------------------------ >>> Create and Deploy Rich Internet Apps outside the browser with >>> Adobe(R)AIR(TM) >>> software. With Adobe AIR, Ajax developers can use existing skills and code >>> to >>> build responsive, highly engaging applications that combine the power of >>> local >>> resources and data with the reach of the web. Download the Adobe AIR SDK and >>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com >>> _______________________________________________ >>> Factor-talk mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/factor-talk >>> >> >> ------------------------------------------------------------------------------ >> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) >> software. With Adobe AIR, Ajax developers can use existing skills and code to >> build responsive, highly engaging applications that combine the power of >> local >> resources and data with the reach of the web. Download the Adobe AIR SDK and >> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com >> _______________________________________________ >> Factor-talk mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/factor-talk >> > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code to > build responsive, highly engaging applications that combine the power of local > resources and data with the reach of the web. Download the Adobe AIR SDK and > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com > _______________________________________________ > Factor-talk mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/factor-talk > ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Factor-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/factor-talk
