[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Strange behavior of "root" in "over"'s context
From: |
Valeriy E. Ushakov |
Subject: |
Re: Strange behavior of "root" in "over"'s context |
Date: |
Fri, 31 Dec 1999 20:42:03 +0300 |
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