Everyone seems to be on board with this change, so I've pushed it to the main git repository. Fresh updates from git might experience turbulence while I hunt down any remaining build errors uncovered by the automated builder, but hopefully I caught most of the problems in the course of my own testing.
-Joe On Mon, Mar 8, 2010 at 10:31 PM, Joe Groff <arc...@gmail.com> wrote: > Hi guys. I'm working on improving Factor's stack checker so that it can > check the stack effect of input quotations to higher-order words such as > "each" and "if*" and give a more helpful error message when they would cause > stack imbalances. Currently, if your quotation would lead to an imbalanced > stack, you'll get an opaque "Unbalanced branches" or "digs arbitrarily deep > into the stack" error, usually reporting some word or set of quotations from > an implementation detail word five levels deep with no apparent relation to > the code that caused the error. If this isn't the #1 worst usability problem > for Factor, it's definitely up there. With my changes, you'll get a detailed > error message that lays your sloppy stack discipline out in full detail: > ( scratchpad ) [ '[ _ + ] [ + + ] if* ] infer. > The input quotations to if* don't match their expected effects > Input Expected Got > [ _ + ] (( ..a ? -- ..b )) (( x -- x )) > [ + + ] (( ..a -- ..b )) (( x x x -- x )) > The "..a" and "..b" identifiers you see in the "expected" column are a new > addition to the stack effect syntax that let you declare variable stack > effects. You can declare these effects on input parameters in the stack > effect for your combinator like so: > : if* ( ..a ? true: ( ..a ? -- ..b ) false: ( ..a -- ..b ) -- ..b ) > : each ( ... seq quot: ( ... x -- ... ) -- ... ) > : while ( ..a pred: ( ..a -- ..b ? ) body: ( ..b -- ..a ) -- ..b ) > When the updated stack checker sees nested stack effect declarations > attached to input parameters, it verifies that the corresponding quotations' > stack effects actually match those declarations, with ..a, ..b, etc. > standing in for some number of stack values that has to be consistent among > all of the parameters. In order to get the improved error checking for your > own inline combinators, you will need to add stack effect declarations to > their quotation inputs. Without an effect declaration, the old stack checker > mechanism still exists, and it can still give you the same old cryptic error > messages. However, in many cases, even without declarations on your own > combinators, you'll still get better error messages, since all the > foundational loop and branching combinators in core have been given declared > effects. > This change should be mostly backward compatible. There will be, however, > some language changes that could break existing code: > - If you have code that use inline combinators with invalid quotations that > somehow still managed to compile, that code will no longer compile with the > new checks. > - Similarly, if you've declared effects on the inputs of an inline > combinator and then used it with quotations that don't match that exact > effect, you'll now get compiler errors. You might need to add ".." variables > to generalize your declared effects. > - The effect parser now only allows a variable of the form "..a" to appear > at the begin of the inputs or outputs list, so if you have been using "..." > in your stack effects (perhaps for a macro), you will need to change the > stack effect slightly to parse under the new rules. An ellipsis can still be > used as a normal value name if preceded by a letter, so "quots...", > "inputs...", "etc..." are valid substitutes. > - If you were manually constructing stack effect objects with "effect boa", > that will no longer work, because the effect object layout changed slightly > to accommodate the ".." variables. However, the "<effect>" constructor word > remains the same, and there are new "<terminated-effect>" and > "<variable-effect>" constructors (to construct potentially throwing stack > effects and effects with variables, respectively) to handle more general > cases. > Any complaints or comments about these changes? > -Joe ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
