error reporting:
    - errors in e4ll are not reported
    - errors in e2list.x1f4_deck_e2list are not reported
warning issuing?  uses would include:
    unused function definitions/declarations
e4.e4-e.3.c._x1f4_e4_size_expression is likely overestimating stack
    requirements.  modify (in line with new e4.7.c~20111229).  no longer I
    think it is overestimating, maybe it makes sense to check.
_WALK_LINK (step by step execution for C calling aime) docs example
describe e4line
describe e2list
describe type id constants functions (4_push_intrinsics et al)
extended temporaries disposal documentation:
    describe how registed methods are called before object frees
temporaries management depend on proper operation of the temporaries manager,
    primarily operated via call backs installed as function call observers.
    Yet, the observers are not called (to check) if the functions are called by
    C defined functions.  The mismanagement is likely not very harmful, and
    with only undesired effect of having some temporaries not freed promptly.
should reallocate stack after optimizing expression
    - all the code already in e4-e.4.c
x1f4_text_lx{decq,line,list} are mandatory.  make this clear.
    - well, it looks they are not that mandatory.  but they are still strictly
	required by the typeless interfaces, as are the proper type definitions
	for all the types that are not trivial.
extend e4/c1/a1 to allow implicit converter inserters (such as lxcast) to
    introduce explanatory error messages (like for when data is not promoted to
    the -object- type because its type is non referable, non intrinsic (like
    the tf23 -sequence- type))
record/list generic link or copy record methods (link what can be linked, copy
    otherwise)
there's a big mess around the `application type context' and the execution
    context, the former appearing in a1/c1 definitions.  Some of the datatype
    routines advertising as expecting the first are supplied sometimes/always
    the second
find a better solution to a1 storing the two data type definitions arrays (for
    retaining/releasing unnamed arguments to variadic functions)
    - merge them into one sorted array (to be bsearched)
+ the _clear_ argument to __slip_expression_ may have all sort of unwelcome
    effects - non zero values may cause a1 to lose memory (if certain
    temporaries collecting steps are missed).  see why is it needed.
consider options to the linked list as representation of c1 programs
reverse evaluation order for assignment operators
    not difficult to do, per se
    _LEFT_LAST flag and ev25 added for it (processing disabled in e4-config for
	now)
    add the _LEFT_LAST flag to all libaime assignment operators (including
	those combining an operation, like the +=)
* Create a higher order function
    implementation section, describing how functions should be called, with
    regard to flags such as TEXT and SIDE/SLIP (the last only applies normally
    only
    to functions known through pointers - so it applies, since we're talking
    higher order functions).  should WALK be considered somewhere?
exceptional aime:
  mid:
    - fix error code through e4ll - not strictly required, since a1 will
	disregard the actual non zero value (and replace it with
	CANNOT_CONTINUE)
  doc:
    - document that _copy_ method for lxnear should return the right status
a1 and reference variables
    - the a1 support for reference variables seems dubious at the very best
    - check passing a reference variable for a reference parameter.  does it
	make sense?  won't it break its atomic access?
clear reference variables
see whether objects are passed as references
    - yes, they are.  bad.
l_extract, r_extract (call it pull?)
list extensions:
    l_p_<type>s(l, p, c, d)? (c x l_p_<type>(l, p, d))
	l_p_n<type>? (ninteger, nreal, ntext, nlist, xinteger, xreal, xtext,
	    xlist - l_p_x<type>)
	l_p_n_<type>?
data extensions:
    delete and replace utilities (character, character set, string)
see BUGS
docs:
    advanced (!?) topics:
	executing two or more programs in the same memory space
	    .a new instant temporaries context is required for the new programs
		(push/lock_e4ll)
		.terrible idea anyhow.  temporaries management is stack based
		    and things will get screwed up terribly
	    .terrible idea anyhow
		.executing functions from other programs is bound to create
		    problems
----
make the memory layout tighter
    - allocating the c1 (c1_miss_type) variables in an array (instead of a
	linked list) not only would make the layout tighter, but would avoid
	some N * N algorithms, especially around a1 reference variables
	(see x1f4_lock_program)
