What I had in mind is not exactly what you had in mind, but you provide a more
general solution for the problem I wa posing. Let me answer your message item
by item.
----------------------------------------------------
> >..in the presentation model we introduced the notion of a Magnitude, defined
> >as follows:
> >
> >Enum Magnitude_Unit {
> > Pixel, Pica, Point, Cm, Inch
> >};
> >
> >Object Magnitude {
> > attribute value : Double
> > attribute units : Magnitude_Unit;
> >};
> >
> > ....
> >
> >An issue comes up in the MRL.
>
> Assuming you mean MTF here?
>
YES, I should have said MTF!!!
----------------------------------------------------
> >It would be nice to be able to type things
> >like the following, where units are used in literals:
> >
> > hguide : MM_Guide {
> > position = [object_name.bottom + top_margin];
> > top_margin = 10 pixels;
> > bottom_margin = 10 pixels;
> > }
>
> In my version of the presentation MRL, top_margin and bottom_margin are
> defined as Doubles as opposed to Magnitutes. Assuming that this has changed,
> it appears you want MTF to let you list the attribute values of an
> object in a positional notation as opposed to listing them by keywords
> (attribute names). Then if Object Magnitude had yet another attribute named
> width as in (MRL):
> Object Magnitude {
> attribute value : Double
> attribute units : Magnitude_Unit;
> attribute width : Double;
> };
>
> we could then say:
>
> top_margin = 10 pixels 20;
>
> to say that top_margin was 10 pixels long and 20 pixels wide. The value for
> the attribute would be chosen based upon its position in the list of values
> after the assignment statement. In this case, 20 is in the third position in
> the positional constructor list, so we assign it to the third attribute in the
> MRL definition (width). Is this what you had intended?
>
> If so, then this should not be too difficult, as we can use the name of
> the attribute (top_margin) to deduce the type of object that is meant to
> be constructed by the list of values. I'm pretty sure this is easy to parse
> and to implement. But when you embed these in expressions I think it opens
> a can of worms.
>
You are suggesting that for some attributes, their values can be given in
positional notation rather than in keyword notation. That is a very nice way
of putting it. The only complication is that in our keyword notation one had
to explicitly name the object to parse as in
hguide : MM_Guide { ....}
I assume that the parser first knows that it is looking at a MM_Guide. If the
MM_Guide was not there, then the parser would have to assume some type. As I
understant it, what you are suggesting is that for each attribute there is a
default type of object to create. So for guides it would be MM_Guide.
I think that would work fine, if it is doable.
Your additional generalization is that one can say that for an atttibute, the
values can be defined using a positional notation. Then the idea of saying
"5 pixels" would work because the "position" attribute of "Guide" is declared
to be of type "Magnitude", and the first to attributes in Magnitude are value
and units. I am trying to re-state what you said to make sure we are in sync.
----------------------------------------------------
> >or the following, where units are used in expressions:
> >
> > grids =
> > hgrid : MM_Grid {
> > direction = Horizontal;
> > start = [hguide.bottom_margin];
> > end = [bottom.top_margin];
> > distance = [height(font) + 2 pixels];
> > };
>
> I assume here that the return value of height() is an Object Magnitude?
> Detecting this is considerably more difficult than the case where you
> assign a positional object constructor to an attribute name. This is because
> the expressions can be arbitrarily large and can involve interactions between
> many different types of objects. The example you gave here is pretty simple
> because both of the addends are Magnitudes and the destination attribute is
> also a Magnitude. But from my understanding of expressions, we could
> compute magnitudes from other types of objects and compute other types of
> objects from magnitudes. When this happens, we will need some way to *infer*
> the type of an object from its positional constructor {2 pixels}.
>
> Maybe what we need at this point is some more discussion about expressions.
> I think that ultimately we can't decide whether the above is feasible without
> knowing the power of the expression language.
>
Hmm, yes, doing the same trick for expressions would be very hard. We don't
want to do type inferencing.
How about a syntax where if you have NUMBER MAGNITUDE_UNITS, it creates a
magnitude. So if the parser sees a number followed by one of the standard
units, it parses it as a magnitude, independent of the rest of the context.
It will be up to the expression analyzer/evaluator to figure out what it means
to add a font height to a magnitude. I am hoping that operator overlaoding
can be used to take care of this problem.
---------------------------------------------------
Pedro Szekely
USC/ISI, 4676 Admiralty Way, Marina del Rey, CA 90292
Phone: 310/822-1511, Fax: 310/823-6714
URL: http://www.isi.edu/isd/szekely.html