Assuming you mean MTF here?
>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.
>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.
>You can imagine how horrible the syntax would look if we had to create the
>Magnitude objects with the standard MRL syntax.
Agreed.
-- kurt.