Hi all, I changed how the stack checker works. Previously, if a word's stack effect could not be inferred, a compile error/warning would be generated and the word would be compiled with the non-optimizing compiler, as would all words that called it, directly or indirectly. (Inline words and macros were an exception to the latter rule; a combinator like 'each' doesn't infer but its callers do if the quotation is known).
This has changed: - Inline words and macros no longer produce compiler warnings. This is because a warning here won't tell you anything you don't already know. As before, callers which pass literal or curried quotations infer and get optimized, etc. - If a word fails to compile with a compiler error, then calling the word throws an error. This means that unless a word is inlined, then either its stack effect declaration is correct, or calling it halts execution -- so the stack checker does not have to recursively check stack effects of words, it just trusts your declaration and lets the compiler sort it out. So stack effect inference is now a purely local operation, operating on a word and its inlined factors only. This has three important consequences: - It is now possible to write code that produces no compiler warnings and errors, and in fact this is now the normal mode of operation since code with warnings and errors won't run. If you don't understand the combinator inlining rules, you can always use call( and execute( everywhere too -- they are pretty efficient (of course not quite as efficient as inlining the combinator and quotation away entirely). When a compiler error popups up, you'll know for sure its something in your code, instead of being confronted with a list of 500 warnings after loading a library from basis/. - If you accidentally make a word not infer, its callers are not affected. So, for example, something as simple as this would break Factor, and/or make the UI really slow, because most words in the system would cease to infer and get unoptimized; almost everything calls 'length' via transitivity, and so all those callers would get deoptimized since length would cease to have a static stack effect: TUPLE: bad-sequence ; M: bad-sequence length 1 2 3 ; ! stack effect error; length is declared ( seq -- n ), our method leaves with 4 items Now, the above code just generates a compiler error for that one method, everything else works, and calling the method throws an error. FORGET: bad-sequence removes the method and the error goes away. Try it! - Bootstrap and loading source files is faster now. Together with the new UI error list tool, these changes should make programming in Factor more enjoyable. Faster loading time is a good plus too, and I have some more changes planned that should improve load time. Once the dust settles, I plan on doing a screencast to demo the recent UI tool changes, the new error list tool, and the stack checker. Enjoy, Slava ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p _______________________________________________ Factor-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/factor-talk
