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)
find a way to keep the e4 binaries small (not include the large optimizers)
extended temporaries disposal documentation:
    describe how registered 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 +=)
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
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_<type>_n? (l_p_real_n, l_p_integer_n)
	l_p_n_<type>?
	*l_pn_<type>? (better than l_np_<type> as it suggests l_push_n)
	l_np_<type>?
docs:
    advanced (!?) topics:
	error reporting - tricky when it comes to accessing the source
I need to say somewhere something of the ((a1?) context) feature in the
    function input array - and in the arguments of the staging routine for the
    variadic/anonymous functions
== operators?
make b_scrap 3rd parameter integer
tests:
    b_scrap negative n
new error:
    an extra error code parameter to error reporting functions, indicating the
	previous error (to be merged via _libx1f4i0_lxcall_land_slip)
what does the executive assembler is actually _not_ specified.  the description
    should include:
    the lxnear longpipe fixing
retain only those aime function parameters that are modified in the function?
BUGS
    see whether objects are passed as references
	- yes, they are.  bad.
	    bad how?  no real damage done found so far.
    there seems to be something wrong with output directed to a file
	-- see dtx/test1.a - quite slow
    there may be something wrong with sharing the temporaries allocator, check
	it.  is a coroutines demo program in order?
    lxport_data.link_u is modified.  is it an issue?
remove A1 CASTTYPE
remove LXWIDE CASTTYPE?  and all the other CASTTYPEs?
study cursors
remove X1f4_LXNEAR_TRANSFER (and corresponding fields)?
do something about the -text- type?
x1f4_push_e4ll/x1f4_lock_e4ll have one argument less in aime.h
