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

[Giovanni Zezza]

Il Thu, 30 Dec 1999 21:58:56 +0300, Valeriy E. Ushakov scriveva:

>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.

Then the question could be why Lout has to be a pure functional language;
or better (let be Lout what it want to be) why a formatting language has to
be pure functional.
Though very interested in linguistic matter (either natural or
computational one) I'm even more interested in having the job done; and I'm
inclined to think sometimes a non functional approach may be more
straightforward than a functional one.
(Thus, another interesting question, though out of topic in this list,
might be: it's possible to have a good designed, free of TeX-like
intricacies, powerful and still "conventional" formatting language?)

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

Sorry, I don't understand what this means. Please, give me some references,
if the answer is too long.

>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 }
>

I think this is what I was looking for (actually, I tried something like,
but wasn't able to get @HShift accepting a negative value; I'll try again).

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

Then this is (at least) the second time you do it[1]. Sorry, but I can't
understand why not to have a built in arithmetics written one time and
forever; and why to write it in Lout, like pretending Lout itself not
already know it, while using it all the time.
The problem, I agree, is to have a good syntax and semantic.

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

I understand (and agree) the need to have a special scope within only
arithmetics may be used, but I think it shouldn't be restricted a priori to
lengths only.

>    @LengthArith { {1f+10p}/2 } @Wide { ... }
>
>    x //@LengthArith{0.5f+2p} y
>
>Instead of messing with @ZUnit assember-like tricks.

This seems to me a reasonably good and comfortable (though a little prolix)
notation.

Ciao.

[1] Speaking of PostScript (and Jeff Kingston's complaint about Lout not to
be a complete formatting system because it relies on it) I don't completely
agree with Jeff Kingston's point. (Actually I don't completely agree about
a formatting system having to be a single, self contained monolithic thing,
instead of an environment built up from several instruments.) PostScript is
a great graphic language, and it seems to me a waste of time rewriting even
a subset of it in Lout.
A good thing, instead, would be a better integration with PostScript, maybe
having Lout understanding some PostScript's semantic, or at least
communicating in both directions with it (let's say, Lout isn't Lout but
Lout+PostScript). How this might be achieved (either with an internal
Ghoscript interpret or whatever) I don't know, but I know I would be
grateful to have it.