Needed enhancements

	Send calc comments, suggestions, bug fixes, enhancements and
	interesting calc scripts that you would like you see included in
	future distributions to:

		dbell@auug.org.au
		chongo@toad.com

	The following items are in the calc wish list.  Programs like this
	can be extended and improved forever.

	*  Implement an autoload feature.  Associate a calc library filename
	   with a function or global variable.  On the first reference of
	   such item, perform an automatic load of that file.

	*  Use faster multiply and divide algorithms for large numbers.

	*  Add error handling statements, so that QUITs, errors from the
	   'eval' function, division by zeroes, and so on can be caught.
	   This should be done using syntax similar to:

		    ONERROR statement DO statement;

	   Something like signal isn't versatile enough.

	*  Add a debugging capability so that functions can be single stepped,
	   breakpoints inserted, variables displayed, and so on.

	*  Figure out how to write all variables out to a file, including
	   deeply nested arrays, lists, and objects.

	*  Implement pointers.

	*  Eliminate the need for the define keyword by doing smarter parsing.

	*  Allow results of a command (or all commands) to be re-directed to a
	   file or piped into a command.

	*  Add some kind of #include and #define facility.  Perhaps use
	   the C pre-processor itself?

	*  Allow one to undefine anything.  Allow one to test if anything
	   is defined.

	*  Support a more general input and output base mode other than
	   just dec, hex or octal.

	*  Implement a form of symbolic algebra.  Work on this has already
	   begun.  This will use backquotes to define expressions, and new
	   functions will be able to act on expressions.  For example:

	   	x = `hello * strlen(mom)`;
		x = sub(x, `hello`, `hello + 1`);
		x = sub(x, `hello`, 10, `mom`, "curds");
		eval(x);

	   prints 55.

	*  Place the results of previous commands into a parallel history list.
	   Add a binding that returns the saved result of the command so
	   that one does not need to re-execute a previous command simply
	   to obtain its value.

	   If you have a command that takes a very long time to execute,
	   it would be nice if you could get at its result without having
	   to spend the time to reexecute it.

	*  Add a binding to delete a value from the history list.

	   One may need to remove a large value from the history list if
	   it is very large.  Deleting the value would replace the history
	   entry with a null value.

	*  Add a binding to delete a command from the history list.

	   Since you can delete values, you might as well be able to
	   delete commands.

	*  All one to alter the size of the history list thru config().

	   In some cases, 256 values is too small, in others it is too large.

	*  Add a builtin that returns a value from the history list.
	   As an example:

		histval(-10)

	   returns the 10th value on the history value list, if such
	   a value is in the history list (null otherwise).  And:

		histval(23)

	   return the value of the 23rd command given to calc, if
	   such a value is in the history list (null otherwise).

	   It would be very helpful to use the history values in
	   subsequent equations.

	*  Add a builtin that returns command as a string from the
	   history list.  As an example:

		history(-10)

	   returns a string containing the 10th command on the
	   history list, if a such a value is in the history list
	   (empty string otherwise).  And:

		history(23)

	   return the string containing the 23rd command given to calc, if
	   such a value is in the history list (empty string otherwise).

	   One could use the eval() function to re-evaluate the command.

	*  Allow one to optionally restore the command number to calc
	   prompts.  When going back in the history list, indicate the
	   command number that is being examined.

	   The command number was a useful item.  When one is scanning the
	   history list, knowing where you are is hard without it.  It can
	   get confusing when the history list wraps or when you use
	   search bindings.  Command numbers would be useful in
	   conjunction with positive args for the history() and histval()
	   functions as suggested above.

	*  Add a builtin that returns the current command number.
	   For example:

		cmdnum()

	   returns the current command number.

	   This would allow one to tag a value in the history list.  One
	   could save the result of cmdnum() in a variable and later use
	   it as an arg to the histval() or history() functions.

	*  Add a builtin to determine if an object as been defined.
	   For example:

		isobjdef("surd")

	   would return true if one had previously defined the
	   surd object.  I.e., if "obj surd {...};" had been
	   executed.

	   One cannot redefine an object.  If a script defines an object,
	   one cannot reload it without getting lots of already defined
	   errors.  If two scripts needed the same object, both could
	   define it and use isobjdef() to avoid redefinition problems.

	*  Add a builtin to determine if a function as been defined.
	   For example:

		isfunct("foo")

	   would return true if foo has been defined as a function.

	*  Permit one to destroy an object.

	   What if one does want to redefine an object?  Consider the case
	   where one it debugging a script and wants to reload it.  If
	   that script defines an object you are doomed.  Perhaps
	   destroying a object would undefine all of its related functions
	   and values?

	*  One some machines (such as the 486), floating point can be faster
	   than integer arithmetic.  Often such floating point would allow
	   for a larger base than 2^16, allowing calc to run even faster.
	   Allow calc to take advantage of such hardware.

	*  Add NAN (Not A Number) to calc.  Where is it reasonable, change
	   calc to process these values in way similar to that of the IEEE
	   floating point.

	*  Add a factoring builtin functions.  Provide functions that perform
	   multiple polynomial quadratic sieves, elliptic curve, difference
	   of two squares, N-1 factoring as so on.  Provide a easy general
	   factoring builtin (say factor(foo)) that would attempt to apply
	   whatever process was needed based on the value.

	   Factoring builtins would return a matrix of factors.

	   It would be handy to configure, via config(), the maximum time
	   that one should try to factor a number.  By default the time
	   should be infinite.  If one set the time limit to a finite
	   value and the time limit was exceeded, the factoring builtin
	   would return whatever if had found thus far, even if no new
	   factors had been found.

	   Another factoring configuration interface, via config(), that
	   is needed would be to direct the factoring builtins to return
	   as soon as a factor was found.

	*  Allow one to config calc break up long output lines.

	   The command:  calc '2^100000'  will produce one very long
	   line.  Many times this is reasonable.  Long output lines
	   are a problem for some utilities.  It would be nice if one
	   could configure, via config(), calc to fold long lines.

	   By default, calc should continue to produce long lines.

	   One option to config should be to specify the length to
	   fold output.  Another option should be to append a trailing
	   \ on folded lines (as some symbolic packages use).

	*  Add scanf() and fscanf() functions.

	   The scanf function should be able to handle both long lines
	   and split lines with trailing \'s.  It should also be able
	   to ignore the leading ~.

	*  Add the ability to read and write a value in some binary form.

	   Clearly this is easy for non-neg integers.  The question of
	   everything else is worth pondering.

	*  Allow one to use the READ and WRITE commands inside a function.

	*  Add individual help for each symbol, statement keyword and
	   builtin function.  Such help would provide limits, allowed
	   argument types and examples.  If one typed:

		help ptest

	   one would obtain detailed help just about ptest.  Some of these
	   individual help files have been written, others have not.
	   See the ${MISSING_HELP} list in help/Makefile or look for
	   short help files that say "Sorry, this help file has not ...".

	*  Remove or increase limits on factor(), lfactor(), isprime(),
	   nextprime(), and prevprime().  Currently these functions cannot
	   search for factors > 2^32.

	*  Make the cryrand functions, or some useful subset builtin
	   functions.  This is needed for speed reasons.

	   The additive 55 / shuffle generators in cryrand.cal have
	   been turned into the rand() builtin function.  The main
	   crypto / Blum-Blum-Shub generators still need to be
	   converted into builtin functions.

	*  Add a builtin to generate random primes using methods suggested
	   by Ueli M. Maurer: "Fast Generation of Prime Numbers and
	   Secure Public-Key Cryptographic Parameters" 9 Sep 1991.
	   Such a builtin would be useful to generate large primes.

	*  Be sure that regress.cal tests every builtin function.
	   The following builtin functions are not tested by
	   the regress.cal as shipped in calc2.9.3t9.0:

		acos acosh appr arg asin asinh atan atan2 atanh
		bround btrunc cfappr cfsim cos cosh cp dp errno
		exp factor fclose feof ferror fflush fgetc fgetline
		fgets fopen fprintf fputc fputs fseek fsize ftell
		hash ln mattrans near param polar power printf prompt
		quomod rcin rcmul rcout rcpow rcsq root round runtime
		sin sinh strprintf swap tan tanh trunc

	* The rand(), srand() and randbit() builtin functions as well as
	  the various file operations need to be tested on 64 bit processors.

	* The author of the 64 bit file position code in fposval.c feels
	  that it is gross and needs be re-written.
