Re: [Reduce-algebra-developers] How to use "in" and "out" and "shut" commands with file names that saved as variables?

[Arthur N. <ac...@ca...>]

Reduce has a user interface built round a model where all variables hold 
algebraic formulae. Numbers are merely a special case of that. Lists and 
vectors are thought of in that context and mostly matrices are things 
defined once at the top level and that their elements are not much more 
than variables that one gets indexed access to. Was designed for users who 
were performing algebra and the emphasis of implementrers over the years 
have been that (and in some areas the support may now feel ancient but in 
others the speed and reliability may be good and the breadth of support 
fully adqequate). Some other systems take the view that they will not 
modify or simplift user input until explicitly asked to. Reduce has a 
fundamental model that where4 it can it will always concert formulae to a 
representation that is as canonical as it can. Well the area that applies 
most strongly is that brackets are (almost) always multiplied out and and 
terms in a formula are sorted (often alphabetically). Its response to 
different users wanting to see output in various formats is generally 
handled bt flags and the like that influence output presentation. eg 
"factor x;" causes output to display things as polynomials in x, and "on 
revpri;" changes whether high or low order terms come first. Neither of 
those influence what is going on inside the system when it calculates.

Now I explain all this (again because I hope that material in the archive 
of the mailing list can help others in the future - ie my audience is not 
just you!) because that means that passing file names around and 
collecting string forms of expressions into lists is not the "expected" 
use case.

Howver in some sense with Reduce one can claim that almost ANYTHING is 
possible. That is because it has these4 two layers - symbolic and 
algebraic modes. Algabraic mode is aimes as above at people who have a 
particular algebric problem that is more or less within the system's scope 
that they want solved. We perhaps believe that that covers the vast 
majority of users and you see that the manual explaining what is available 
for them is already quite bulky.
Then there is symbolic mode which is for people who wish or need to work 
with strings, custom formatted output, resource limits, the detailed data 
structures that represent formulae (eg to assess their bulk, which is what 
I expect you mean by leafcount - but note that a discussion is needed 
there about what tree you are counting the leaves on and what constitutes 
a leaf), to use hash-tables and build new data structures that are special 
to their application.
There is a degree of overlaps in what can be done in each mode - so in 
algebaic mode one can have procedures and work with lists and there are 
functions for operations like "give me the first term from this formula". 
But there is DRAMATICALLY greater flexibility when one moves to the lower 
level. Of course accessing that comes with a learning curve. Over the 
years a number of us have had experience assisting various mathematicians 
and scientists who have (algebraic) problems to cope with that, and the 
primers in the documentation represent some of that. But also the 
availability of the source code for browsing and to provide model 
fragments of code that maybe do things similar to what is needed.

So for instance while Reduce is being built there has to be code that
reads in thousand or so little files that make up its full source, with a 
master file (packages/packge.map) listing the names and locations of each 
module and each module typically starting with a statement that indicated 
the set of files that make it up, as in
create!-package('(rlisp module newtok rsupport slfns superv tok xread
                   lpri parser block form proc forstat loops statmisc
                   smacro io infix switch where list array inter
                   charname newtok1),
                  nil);
which arranges that when the "rlisp" package is built or rebuilt that 
26 files with names like packages/rlisp/loops.red are all processed. 
Obviously the short name "loops" there is subject to bits ot string 
concatenation to get the full name of the file to be used. And there are 
functions for checking if particular files exist, looking at and 
comparing data-stamps and basically all the things that those who are 
looking for a reasonably general purpose programming language rather than 
a user interface aimed at algebra might need.

If one goes to the top of the reduce source tree and goes
    scripts/testall.sh
you will find that that runs a test file for each module that has one. It 
achieves this by inspecting packages/package.map to sort out the bunch
pf package names and calls scripts/test1.sh for each. We do not expect 
novice users who start by looking at the algebraic capabilities of Reduce 
to be able to set up scripts like that in short order, and various details 
of it represent several iterations. That stuff is also not coded with a 
view to it being the cleanest neatest example of how to do things! But
in terms of what you are now explaining it shows what some of us did in 
response to a related need.

In a different style of doing things packages/support/remake.red involved 
passing a module name to a function, uising module2!-to!-file to derive an 
associates file name and then package!-remake builds or rebuilds that 
module. And building Reduce involves scripts that either as such or 
explicitly do that over and over again. For PSL the top level is 
orchestrated by shell scripting, for CSL it all happens within the system, 
using a capability that says "OK you have just done something interesting, 
but now do a full restart so that I can do the next step with a clean 
slate".

You say "put the names of files in a list and iterate over it". So you see 
that both in testall.sh and in the PSL build scripts rather than making a 
list within Reduce and iterating it we just process each file one after 
the other. Eg rather than having
   list_of_files := '("file1" "file2" ...)$
we might have
   process "files"; process "file2";
or
   in "file1"; in "file2";
or go
   for f in file1 file2 ...; do redcsl $f -l $f.log; done
at shell level.

A great deal of what you have been asking about is not the solving of 
individual alghebraic problems. It is more system-oriented and the sense 
that I get is that you start with clear initial ideas about exactly what 
input and output formats you want, with those choices having been built up 
from your experiences with other systems. That can all be done in Reduce 
but at a cost of learning how to use it as a system programmer and 
developer not as a simple mode user.

I will terminate this already too-lomg email with two further 
illustrations  of Reduce flexibility. A few years ago I became interested 
in Rubi (bu Al Rich). He could provides a bunch of rewrite rules to 
perform integration. 
But they are supplied in Mathematica syntax. That is not as such helpful 
for Reduce - so I sat down and coded enough of a parser that it can parse 
the Mathematica stuff into data structues that can exist within Reduce.
And if you look in packages/rubi_red you will see my response to reading a 
bunch of files - I have a line of code that calls the parse function on 
each. I had no thought of sitting putting the file-names in a list to 
iterate over in that that would not have shrunk the code much. The rubi 
experiemnt is then stalled because of a combination of me getting 
ditracted and the fact that the rules depend on the behaviour of 
Mathematica pattern matching. In that system I can not even in principle 
inspect the source code to reverse engineer exactly how the pattern 
matching works so I do not know just what is required. If things were the 
other way round ana Mathematica user needed to know EXACTLY how Reduce did 
something then they could start by using "trace" to watch function calls 
and data as it flowed through and then if they wanted they coulkd pick up 
the code wholesale and re-use it.

The final example is also from some years ago while I was visiting a 
Maple-centric university. Because I have access to all of the software 
stack of Reduce I could add to the CSL Reduce some facilitis such that a 
version of reduce compiled as a loadable module could be loaded fromn 
within Maple and data passed backwards and forwards. Traces of that can 
seen in the file csl/cslbase/maple_interface.cpp and elsewhere in the CSL 
sources.

I think that neither of those are for the feint-hearted but they may 
suggest to you that when one is ready to do a deep dive in Reduce is not 
as restricted or limited as you have perhaps gained as your first 
impression!

Arthur


On Sun, 7 Jan 2024, Nasser M. Abbasi wrote:

>
> in my script if I do
>
> ------------
> in "B.red";
> ------------
>
> It works. Where B.red is file in same folder.
>
> But if I do
>
> -----------
> file_name := "B.red";
> in file_name;
> -------------
>
> It gives error
>
> +++ Error file could not be opened: "file_name"
>
> It looks like "in", "out" and "shut" commands want literal arguments.
> But this is very limiting for me, as I need to pass the names of
> the files to process in variables and not hard code the file names,
> as I have 100's of files that I need to put in a list
> and loop over.
>
> Is there a way around this?
>
> Reduce (CSL, rev 6657), 10-Dec-2023
>
> Thanks,
> --Nasser
>
>
>
>
> _______________________________________________
> Reduce-algebra-developers mailing list
> Red...@li...
> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers
>