@dharr 

I have worked a bit with the two additional ideas that you have most recently described. I'm not sure whether I will find them helpful for the sort of work that I do. Here're my thoughts on those two.

The notion of only computing with the units of a variable that has no value in the list of equations is equivalent to stating that the value of that variable is 1. That might sometimes be what I would want perhaps, but most often I'd rather just leave that variable intact in the expression and give it a different value at some other time as needed. To leave it intact, I'll just not list it. So I don't plan to adopt that idea.

The idea of making it possible to specify units for indexed variables is interesting. I haven't usually found occasion to write expressions that involve indexed variables, but perhaps I will in future. The basic notion seems a good one, and a variant that I have considered might be even more useful. If one had the equation F = m * a and had a list m := [ 1, 2, 3 ], then one might want to evaluate for F as in evalu( F, [m=m[1],a=3] ) . That would evan enable one to turn the index [1] into [i] and loop through a list of values. This doesn't work, of cource, since the m=m[1] equation raises the error "protected". If, however, there were some way around this error that did't force a renaming to avoid the error, then that might prove useful, too. I'm keeping the basic idea described in my own code, although I'm not sure when I might have occasion to use it.

I have also made different addition to your basic notion of using Maple attributes since I posted my last version. The symbols in the sort of expressions that I deal with include symbols for constants, and constants, too, usually have units. I define all the constants in a .mpl file which I read at the outset in a worksheet, so they are always available. My convention is to denote constants with the same symbol as occurs in expressions but with a postfix underline added, e.g. G_ = 6.67e-8 * Unit(dyn*cm/g^2) is the Newton gravitational constant. Then when I want to evaluate an expression that contains the constant, I just put the equation G=G_ into the list of equations for the evalu procedure. When I do that, the value for this equation will already have units. To facilitate that approach, I have made two modifications. 1) I added a findunits procedure; 2) the evalu procedure now sends entire equations rather than just variables to findunits; 3) if the findunits procedure detects existing units in rhs(vals) it returns a 1 instead of units. Doing this lets the rhs(val) that already has units to pass through into the calculations without having any units added. These changes are in the following.

findunits := proc(val)
   local var, valu:
   var:=lhs(val); valu:=rhs(val);
   if type(var,symbol) and type(var, `attributed`) then
      return attributes(var);            # var is a symbol that has attibutes, assumed to be units
   elif type(var,symbol) then
      if type(rhs(val), with_unit) then
         return 1;                   # var is a symbol that has no attributes but already has units
      end if:
   else
      if type( op(0,var), `attributed`) then
         return attributes(op(0,var));   # var is not symbol but its base name is has attributes
      else
         return "an equation has no attributes and no units";
      end if :
   end if;
end proc:

evalu := proc(expr,vals::{set(equation),list(equation),equation})
   if type(vals,equation) then
      combine(eval(expr,lhs(vals)=rhs(vals)*findunits(vals)),units);
   elif type(vals,set) or type(vals,list) then
      combine(eval(expr,map(vals->lhs(vals)=rhs(vals)*findunits(vals),vals)),units);
   else
      return "2nd argument must be equation or list or set of equations";
   end if:
end proc:

So the suggestion from dharr 2118 to use the Maple "attribute" facility provided the key that enabled me to put together a way to operate with Units in exactly the way that I had hoped might be possible. I can now create worksheets for physical problems that use units, and I only need to declare the symbols for the variables in use together with their units. All subsequent evaluations of expressions that are produced are then done with a simple command like this one: evalu(expression, [x=1, y=2, z=3]). Each of the values has a unit attribute which is automatically attached and then put into the expression. The result then has units. A worksheet illustrating the method is attached. This is the goal I hoped to attain, and I thank everyone for their suggestions. A special BIG THANKS to dharr 2118SymbolUnits.mwSymbolUnits.mw whose suggestion proved to be the key to the method!

Thanks to both acer 23514 and tomleslie 9355 for thinking about my question and for posting answers.

Unfortunately, tomleslie 9355's suggestion doesn't hide the units, so it doesn't accomplish what I'd hoped to find. I had in mind something like the declaration statements that one puts at the beginning of program units and subprograms in a language like Fortran. I was hoping that somewhere in the vast Maple repertoire there is something like that that would declare units that would be attached to a symbol and that would then eliminate the need to append units along with a value each time a symbol gets evaluated. I hoped that such existed in Maple and that I had simply missed finding it. That seems not to be the case, however, which I guess is not all that surprising, since it may be considered antithetical to the Maple general philosophy of avoiding strong typing.

acer 23514's suggestion is rather closer to accomplishing my goal. It's a clever stratagem that does in fact let one use symbols which have units attached but which units don't appear until after a symbol has been given a value-units in an expression. I played with this approach and some variants for a while, but I was unable to see a way to make the scheme into something that satifies all my preferred modes of operation. A main reservation is that the method establishes two symbols instead of just one for each of the conceptual symbols and that these both need to appear in various contexts along the way in derivations and calculations. That fact prevents using a single set of symbols throughout a complex series of derivations and then the evaluations of them. That's both desireable and conceptually simpler from my perspective.

For your information, if you're interested, I use Maple primarily for physics, and the derivations of multiple expressions in the course of exploring a topic can become fairly commplex. So the units need to be involved in a fairly simple way, so as not to encumber keeping conceptual track of what's going on. The topics can also require symbols whose units are complex combinations of the basic units, and it can be taxing to remember or distracting to reconstruct them all each time they are used. Attaching units like Units(x)*Units(y)^3/Units(z)^2/Units(q) = Units(x*y^3/z^2/q) can additionally become cumbersome.

Since you are interested enough in the use of units to think about my issue and to make a suggestion, you may be interested to see the attached simple worksheet which illustrates the system that I now use. At the outset, or in a .mpl file which I read in at the beginning of a worksheet - like my file of physical constants as shown - I define a set of unit symbols, one for each type of physical variable that I will use: mass, length, time, force, velocity, etc for basic units and combinations of these for more complex types. Then when I want to evaluate an expression, I assign to each this way - symbol:=value*typeunit. In this way, I only need to know the physical type of a symbol in order to assign units to it. I like this approach, mainly because it is explicitly true to the conceptual basis of units, and because it keeps me focussed on the conceptual aspects of my work and avoids nearly all details of manipulating the units of the symbols that implement it.

Thanks, again, for your suggestions.

Download: GenUnits.mw