Re: Strange behavior of "root" in "over"'s context

[Valeriy E. Ushakov]

On several occasions Giovanni Zezza wrote:

> I'm facing an incorrect behavior of "root" I can't fix in some
> circumstances (Lout 3.13, Windows version):
>
> @Eq { { n root {a + b}} over c }           # here "n" is misaligned

"root" uses "sup" internally and "sup" is affected by @VSqueeze.  This
can be solved by explicitly specifying "gap" parameter to "sup" in the
definition of "root" to be 0.43fk (i.e. @SupGap when z = f).


> Eq seems to work at least questionably with index that have descendants:
> 
>     @Eq {j root a}
> 
> again, the index symbol is too near to the root.

"sup" shifts the horizontal mark proportionally (i.e. in terms of
w-unit).  This is probably fine for "sup" proper, but for "root"
there's a natural delimiter below the index, the 'tick' of the
radical, so in this case we are more interested in the distance
between the tick of the radical and the index.  "root" should probably
use a different symbol, similar to "sup" but tailored to this
particular usage.


> Trying to fix this problems I couldn't help to ask me some
> questions: why can't I use any arithmetics in lengths? (something
> like {x &{1r - 1f}o y} could possibly solve anything) Why aren't
> here variables (where to store objects lengths and so on), logical
> operators and all the other stuffs usually present in every language
> (even a functional one (like Lisp), even a logical one (like Progol)
> and other far more esoteric languages)?

First, to be pedantic, Lisp is *NOT* a functional language.  Second,
functional languages do *NOT* have _vari_ables.  The most common
definition of being "functional" is referential transparency, once you
have variables (e.g. something that you can destructively modify), the
referential transparency is gone.

Also (speaking of "more esoteric languages") note that Lout relies on
the constraint satisfaction engine to perform the layout.

Currently you can use several syntactic kludges to perform simple
arithmetic on length.  E.g. to shift the vertical mark to 0.3f from
the right edge of the object you can write

    -0.03f @HShift { 1w @HShift obj }

You can do more arythmetic by using @YUnit and @ZUnit as accumulators,
e.g.:

    1f @ZUnit +10p @ZUnit 0.5z @ZUnit # set 1z = (1f + 10p)/2
    1z @Width { @FullWidthRule }

My guess is that you only rarely need to go down to complex
arithmetic, because of the constraint-satisfaction nature of the
layout process in Lout.  For cases where this is really neccessary you
can use "natural arithmetic properties" of builtin symbols (like
@HShift example above) or do slightly more comples stuff with @ZUnit.

Some form of explicit arithmetic, especially on lengths, is definitely
necessary.  A real problem is to come up with a good syntax and
semantic for it.  Lout has undocumented @Plus and @Minus symbols, but
they don't work with lengths (the only thing they are currently used
for is structured page numbers in "include/dsf").

Perhaps a special builtin could be introduced, as if defined like this:

    export # ...
    def @LengthArith
      body @Body
    {

      def f precedence ... left factor {}
      def "+" precedence ... right x left y {}
      def "/" precedence ... right x left y {}

      # ... and so on, defining an algebra on lengths.  See @Diag,
      # where this is done for vectors (via PostScript), User's Guide,
      # p178.

      @Body
    }

that will introduce a special scope where arithmetic signs have there
usual meaning, so that one could write

    @LengthArith { {1f+10p}/2 } @Wide { ... }

    x //@LengthArith{0.5f+2p} y

Instead of messing with @ZUnit assember-like tricks.

SY, Uwe
-- 
address@hidden                         |       Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/            |       Ist zu Grunde gehen