> I'm also thinking that the stack-effect data could be more binding than it
> currently is. I noticed while compiling some new words that the compiler
> will infer a stack-effect, and tell you when you've written it
incorrectly.
> This looks almost binding. So my suggestion/question is: Can we use the
> stack effects to check at least the superficial (type- and count-based)
> correctness of a Factor expression, as it is assembled on a Listener
command
> line?
The stack effects are already binding. When you enter a word
definition, and the compiler determines that the code's stack effect
does not match the declared effect, you'll get an immediate compiler
error. The one exception to this is "inline" higher-order words (words
such as "map" that take a quotation as input)-for these words, stack
checking will be deferred to call sites that use the inline
higher-order word, because the stack checking can't be done thoroughly
without a quotation to fill in the parameter. If the word declares a
static stack effect for its quotations, the effect will be enforced on
the caller:
I'm puzzled by the stuff inside the stack-effect syntax: "( -- )".
I thought that the tokens on either side of the "--"
are just dummy variables representing, on the one hand, strictly
the number of input arguments and the number of results, and, on the other,
loosely the types of those arguments and results. I must not have the
right idea. How can per-stack-position type-integrity be enforced if
this is so?
--
( scratchpad ) : foo ( x quot: ( x -- ) -- ) call ; inline
( scratchpad ) : bar ( x y -- ) [ + . ] foo ;
! "bar" should cause an "Input quotation to foo doesn't match its
expected effect" error
--
I don't understand above what "quot:" and more generally what "x quot: ( x
-- )"
as the before-effect of foo is doing. The colon on the right side of
"quot:" is
confusing me, because I am trying to read RPN, left to right. This syntax
makes me want to reverse my reading direction for that expression. I can't
find any info in Browser on "quot:".
If the word declares a polymorphic effect (using "..a" style stack
variables to represent a variable number of values), the arities of
the stack variables will be unified, and an error raised if
unification fails:
Does "Unification" mean "arities of stack variables are determined to be
equal"?
There is a section in Browser called "Stack effect checking". What should I
read
besides this to understand the full significance of the stack-effect syntax,
what
it can do and not do, and how it affects compiler behavior?
--
( scratchpad ) \ if see
: if ( ..a ? true: ( ..a -- ..b ) false: ( ..a -- ..b ) -- ..b )
? call ;
( scratchpad ) : bas ( x y z? -- ) [ + ] [ neg ] if ;
! "bas" should cause an "Input quotations to "if" don't match their
expected effects" error
--
I'm not understanding the English in the comment above. Ditto for the
similar comment above. The quotes are matched, but I cannot make any sense
of it.
If a higher-order word declares no stack effect for its quotation
arguments, the overall stack effect of the caller will still be
checked when the body of the higher-order word and its arguments have
been inlined.
That makes sense, but I need to study a full description of the stack-effect
syntax
and it ramifications for thinking about the effects of higher-order words.
Shaping
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
