Hi all,
I'm going to implement two languages changes pretty soon.
#1) First of all, the >r and r> words are going away. You will need to
use the dip combinator instead.
Several reasons for this change:
- Having both dip and >r/r> around is two ways of achieving the exact
same thing. Removing one makes the language easier to learn. Since dip
is more versatile (it works with locals and fry, for example) it will
be the one to stay.
- Explicit retain stack access makes the execution model more complex,
making it harder to implement various meta-programming tricks. For
example, fry and locals don't work with >r/r>. compose has problems
too;
[ >r ] [ r> ] compose call
fails. Solving these would be not worth the effort.
- Explicit retain stack access can break invariants. For example, you
can dig into the retain stack, mess with the internal state of a map
or each, and crash Factor.
- The compiler checks retain stack usage and raises compile errors if
it doesn't balance out, but with 'dip' there is no possibility of a
compile error relating to retain stack usage at all; if your code
parses, its retain stack usage is sound. Not having to do these checks
simplifies the compiler.
#2) Static stack effect safety will be enforced. Inference errors will
be parse errors. Code with unbalanced branches, etc, will not load.
Inference warnings will become inference errors.
Code which doesn't infer right now generally falls into two categories:
- Combinators which take quotations from the stack. To make these
words infer, their stack comments will contain nested quotation
declarations:
: each ( seq quot: ( elt -- ) -- )
- Words which call non-literal quotations, for example by extracting
them from variables, tuple slots, etc. These will need a stack
declaration at the call site:
: foo ( x -- )
my-hook get call: ( x -- ) ;
If your word has a truly dynamic stack discipline, for example, you're
implementing the listener and you're evaluating user input, your word
will need a different stack effect declaration:
: foo ( string -- ... )
eval ;
If the list of output parameters ends with ..., the word will not be
optimized, and words which call it will also need to have the same ...
in their stack effect.
This change will have several benefits:
- It will be possible to define virtual sequences and assocs whose
nth, at methods call quotations in tuple slots.
- Since almost all words will now get stack effect checking (except
for a small handful which really are dynamic), more bugs will be
caught at compile time.
- Compile time will improve, for various reasons.
Slava
-------------------------------------------------------------------------
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
