Maxima error when having strings in terms

The testcase is("x">0)
was just there for illustration, but the real
problem is that if somewhere in your term there
is a string, like 

is(g(f("x")) > 0);
Maxima encountered a Lisp error:
 "x" is not of type LIST.

then you get an error, where g (and f) are declared as posfun.

The application is simply that for data-sets we have various
strings describing application-variables, rows in data-sets
and so on, and from these strings we want to create
atoms like f(string), which then can be used for various
things (like constraint-variables (not Maxima-variables)).

For example the application mentions the "variable" "AIS".
Out of that we want to make in a systematic (algorithmic) way
some "propositional variable" (at object-level, not at meta-level),
and using something like f("AIS") would have all the properties
we wanted (where f is an unevaluated function declared as positive).
In this case one could also generate some symbol, like prefix_ais,
and declare it as positive. However the approach using function-names
seems to be more convenient, since we can easily use several
arguments, and if needed (for example when standardising names
to natural numbers), we can just evaluate the terms, given
some temporary definition for f. And we definitely have
terms like f("x","y",5,"z",7), and replacing all these strings
by symbols doesn't look like a good idea to me. 

Oliver

P.S. Important is also that the function f can be declared once
and for all as a noun and as positive, and then we can use
terms like f("d"), f(7) and so on to define (object-level(!))
variables (which are different). We do this already heavily
for all sort of Maxima-terms t, i.e., using terms f(t), and
now we have the new application, where strings are naturally
part of the instance, and our general system would just
do the job, if only f("x") would be treated as a normal term.
f here is just a universal wrapper.

On Sat, Mar 20, 2010 at 09:53:01AM -0700, Robert Dodier wrote:
> On 3/20/10, Oliver Kullmann <O.Kullmann at swansea.ac.uk> wrote:
> 
> > (%i1) is("x">0);
> > Maxima encountered a Lisp error:
> >  "x" is not of type LIST.
> 
> I agree that this is a bug. However, since a value cannot be assigned to
> a string, I don't see how is("x" > 0) could ever be anything other than false.
> 
> At present, Maxima is somewhat inconsistent as to whether strings can
> represent variables; e.g. "foo" + "foo" => 2*"foo", but ev(%, "foo"=1) =>
> "Only symbols can be bound; found: foo". I am inclined to say that
> Maxima should steer away from treating strings as variables; one can
> use symbols instead, and getting the same treatment for strings as
> symbols would be too much trouble for an unclear benefit.
> 
> > This seems like a clear bug to me, and hopefully something can be done
> > (otherwise our statistics application seem to become very clumsy, always
> > having to translate strings into, say, numbers).
> 
> Can you use symbols instead of strings? What are you trying to accomplish,
> by the way?
> 
> best
> 
> Robert Dodier

-- 
Dr. Oliver Kullmann
Computer Science Department
Swansea University
Faraday Building, Singleton Park
Swansea SA2 8PP, UK
http://cs.swan.ac.uk/~csoliver/