I tend to agree with Andrey. Let's not make the interface too complicated.
Another point for not providing '--eval-lisp' is that we should not burn
it to much into the API that LISP is the underlying system (although it
will be for many years from now).
The option --eval ')lisp ...' is good enough if needed.
I would, however, allow multiple appearances of --eval so that one is
not forced to create a file if one just wants to execute two system
commands like ")cd" or ")read" etc.
Piled syntax in --eval would be a problem anyway and should be rewritten
into a non-piled form. I just don't know exactly whether current fricas
allows such a transformation for every possible source code. However,
Code in --eval should not be too long anyway.
Ralf
On 01/11/2011 04:10 PM, Andrey G. Grozin wrote:
On Mon, 10 Jan 2011, Waldek Hebisch wrote:
Yes, that is useful. I think that 'pre' is too unspecific, what
about 'FRICAS_PREINIT' and '--preinit'? Also I similar way we can
add 'FRICAS_EVAL_LISP' and '--eval-lisp' to evaluate arbitrary
piece of Lisp code. And maybe 'FRICAS_EVAL' and '--eval' for
interpreter input. The execution order would be Lisp, then
preinit then eval.
It seems that --eval provides all the necessary functionality.
--eval ')lisp (lisp-code)'
--eval ')read something.input'
The file something.input can contain )lisp lines
All possibilities are covered.
This should be evaluated after .fricas.input but before an interactive
session, so that something.input could adjust things from .fricas.input
for the purpose of the present session (for example, a session from
TeXmacs or from emacs).
Andrey
--
You received this message because you are subscribed to the Google Groups "FriCAS -
computer algebra system" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
