> Slava, generally speaking, can all these warnings possibly be cleaned
> up? Or are some of them "unfixable"?
>

Some of them are unfixable without redesigning code. For example, in the
lists.lazy vocabulary, many of the tuples have a slot which contains a quot
(lazy-from-by is an example). This means that code which calls the quot slot
in an instance of lazy-from-by could do anything, so its stack effect cannot
be inferred. This means that anything which uses this code, such as the
json.reader vocabulary, will not be inferrable. Thus any word which uses
json> will throw a warning, as will any word which calls that word, and so
on.

TUPLE: lazy-from-by n quot ;

C: lfrom-by lazy-from-by ( n quot -- list )

M: lazy-from-by cdr ( lazy-from-by -- cdr )
    [ n>> ] keep
    quot>> dup slip lfrom-by ; ! cannot be inferred, since quot could do
anything

A possible solution to this problem which I think has been discussed before
is to make it possible to declare what you want the stack effect of the quot
run by call (or slip, etc.) to be. Maybe something like this:

M: lazy-from-by cdr ( lazy-from-by -- cdr )
    [ n>> ] keep
    quot>> dup ( n -- n' ) slip lfrom-by ; ! declare the stack effect of the
next quot passed to call

Or this:

TUPLE: lazy-from-by n { quot quot ( n -- n' ) } ; ! enforce the stack effect
of the quot in any instance of lazy-from-by

Somehow the compiler has to know when slip is called, that the quot has the
stack effect ( n -- n' ).

Alex
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/factor-talk

Reply via email to