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

[Valeriy E. Ushakov]

On Fri, Dec 31, 1999 at 01:46:46PM +0100, Giovanni Zezza wrote:

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

Precisely because of the absense of side-effects.  Jeff perhaps can
answer this one better, since that was his choice.  On my part, let me
refer you to the DSSSL standard which uses a side-effect-free subset
of Scheme as its language.

In general one doesn't select language features individually, they all
work together towards a common goal.  And you can't take out the
functional part of Lout without destroying other aspects of the
language, like galleys and cross-references.

For an example of what happens when creaping featurism takes over -
consider C++.  Down that path lies madness!   You should have seen a
colleague of mine from C++ compiler team, when he found a clause in
The Draft that defined a situation where parentheses do change the
meaning of expression.  But I digressed.


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

You can start from WWW VL page on programming langauges:
<http://src.doc.ic.ac.uk/bySubject/Computing/Languages.html>

"Constraint Programming Languages, their specification and
Genereation" by Wm Leler (sic, "Wm") AW 1988, ISBN 0-201-06243-7 was a
great introductory book for me.


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

Minus, "-" is an exported symbol in @Eq, so you need to quote it:

    "-0.3f" @HShift


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

No, no, no.  That one is on *vectors*.  Conside for example:

    address@hidden ++ 2f atangle 135d

which refers to a point 2f away at angle of 135 degrees from the NW
label of diagram node SomeNode.


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

I believe I didn't say "restricted", sorry if that was the impression.
What I meant is arithmetic that is "aware" of lengths, or quantities
in DSSSL speak.



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

Tell that to people that want PDF output from Lout and want graphics
in PDF and don't want to mess with distillation (e.g. in a CGI
script). ;-)


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

Do you have any specific scenario in mind where this is potentially
useful?


PS: Well, let me now put my list-maintainer's hat on and wish everyone
    happy New Year!  I hope that Lout was a useful tool for you and
    that the mailing list was a helpful source of information and
    help.

    See you in 2000!

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