MRPP3, MRPP4

Hi,

rem642b@yahoo.com (Robert Maas, see http://tinyurl.com/uh3t) writes:

> It's  that TeX is still advertised as the state of art in math
> typesetting, when in 1975, *before* TeX, I created a better way to lay
> out math in MRPP3 [...]  Too bad Knuth didn't collaborate with me to
> combine my "overlays" with his finely-tuned font&kerning to get
> something both easy to use (like MRPP3) and locally pretty (like TeX).

Any links to code or papers regarding MRPP{3,4}?

Thanks,
Ludovic.

On Mar 27, 9:10 am, l...@gnu.org (Ludovic Court=E8s) wrote:
> Hi,
>
> rem6...@yahoo.com (Robert Maas, seehttp://tinyurl.com/uh3t) writes:
> 
>
> Any links to code or papers regarding MRPP{3,4}?
>
> Thanks,
> Ludovic.

Second that request - coming up dry on searches.

CY

C Y <smustudent1@yahoo.com> writes:

> On Mar 27, 9:10 am, l...@gnu.org (Ludovic Courtès) wrote: 
>
> Second that request - coming up dry on searches.

Yes, that may happen with stuff developped before the web.  Oldies
better put their stuff on the web soon, or they'll be forgotten
forever. (But perhaps by some strange archeologist who would still go
to physical "libraries"...).


--
__Pascal Bourguignon__

> From: l...@gnu.org (Ludovic examnotes)
> Any links to code or papers regarding MRPP{3,4}?

The code for MRPP3 was DEC PDP-10 assembly language (FAIL,
developed at Stanford AI Lab, better assembler than MACRO which was
developed by DEC). It ran on WAITS, the SU-AI machine in the D.C.
Powers building. It did WAITS I/O directed to the XGP (Xerox
Graphics Printer). If you have a PDP-10 + WAITS emulator plus XGP
emulator, I could show you the code if I still have it.

It used explicit nested macros following the structure of
mathematical parse trees to generate the bottom-up code to actually
generate the nested overlays. For example, if there was a macro for
generating a sum, and a macro for generating a product, you'd nest
the calls in the natural way as if function calls $!plus(5
$!product(x y)), and the product macro would expand into code for
building the x and y overlays the combining them into the product
overlay with a gensymmed name, and the plus macro would expand into
code for building the 5 overlay and combining it with the
previously-created product overlay. These math macros were the work
of Bill Gosper, after I built the engine to handle overlays and
nested macros. Bill also wrote a utility to convert internal
MacSyma structures (embedded in MacLISP, with funny-named symbols
and funny-named symbols in first-element position, different from
the usual Lisp operators for arithmetic) into the nested-macro
notation needed by his MRPP3 macros.

The code for MRPP4 was PSL (Portable Standard Lisp). I forget which
output devices it handled. (Later my boss insisted I parameterize
the device-control part of the program to allow it to be configured
dynamically for multiple output devices, yielding MRPP5, but under
time pressure and with no inspiration how to do it, and my boss not
available for design-talk, it came out a horrible mess, so I don't
advertise that edition of the series.)

All internal math expressions were basically in REDUCE format, i.e.
nested lists that if EVALuated would actually compute the result
numerically (except for functional operators such as
differentiation), i.e. exactly (PLUS 5 (TIMES X Y)). A math-printer
traversed these nested lists just the way that PRINT and
PRITTYPRINT would except the algorithm was multi-pass: First the
Lisp/REDUCE expressions were converted to nested-overlay
expressions, then the nested overlay structure was flattened to a
single-layer of <offsets text> tuples, then a charcter array of
sufficient size was allocated and all the pieces of text were
copied into appropriate places respecting their offset within that
array, then the array was printed by rows. (Something like that
anyway.) For output devices where a fixed-pitch character array
wasn't appropriate, compiling REDUCE expressions to nested overlays
was almost the same, and flattening might have been the same, but
output was done directly using random access on the IBM 2260(?) CRT
on VM/CMS or the window system 'X' on Unix.

I've wanted to translate MRPP4 to Common Lisp and have it use ASCII
character-array mode feeding into a <pre>...</pre> section of HTML,
but never got around to it because nobody ever showed any interest
and no funding was available and I never got in the mood to do it
with neither pay nor appreciation nor any user base except just
myself.

I've also considered writing a driver for TeX output, and also
directly to PostScript output, and also to RTF output, using
MRPP<n> to convert from Lisp/REDUCE expressions to nested overlays
then generating TeX/PS/RTF, but I've never had access to TeX nor
PostScript nor RTF, so no version of that task has been feasible.

I've also considered writing a driver for JPG or GIF or BMP output,
which could directly generate pretty mathprint-images for embedding
in Web pages, but I've never had direct Web access (except in a
public computer lab such as the library where I don't have any way
to do development work), so that idea hasn't been feasible either.

The head person where I developed MRPP4, Pat Suppes, later
published a paper about our CAI-Calculus software, but I didn't
receive a copy and haven't had access to it, so I don't know what
if anything he said specifically about the technology I developed
for MRPP4 and MRPP5, so I don't know whether there's anything in
print that would say anything I haven't said in this newsgroup
article.

By the way, the past few days I've been developing (without pay)
some software to draw near-optimal neighbor links between nodes in
ProxHash space, and to generate a nice ASCII character-array of the
graph so that I can directly see how my code is working. Here's the
output from one of the test runs (view with fixed-pitch font such
as Monaco).
...................................................AL.....................#
...................................................\......................#
....................................................\.....................#
....................................................\.....................#
....................................................\.....................#
.....................................................\....................#
.....................................................\....................#
......................................................\...................#
......................................................\...................#
......................................................\...................#
........................................AP-BI-----.....\..................#
...........................................|......-----BJ.................#
...........................................|...........|..................#
............................................|........./AA--...............#
............................................|......../.....--BH...........#
............................................|.....///......./.............#
.............................................|.../........../.............#
.............................................|///..........AM.............#
.............................................AQ............|.\\..........AI
#
.......................................AO..//..............|...\\......//.#
........................................\./................|.....\\..//...#
.........................................AF...............|........\AB....#
......................................../.................|...............#
..................................../AVAC.................|...............#
.................................../....\../BN--AW........AU..............#
.............................BE--AT......AD......\\.......|...............#
............................/....\.......\.........\....--BF..............#
.........................../......AX......BC......./AJ--...\..............#
.........................../.......\\.......\\..BGAR.......ASAG...........#
.......................---BK.........\\.......\BL.|........|..............#
.................------...|............\..........|........|..............#
............-AZ--.........|.............\\........|....---BABB............#
........----..............|...............\\...---AE---...|...............#
.....---..................AK.............../AN-...........|...............#
.----......................\.............//...............|...............#
AH...........................BD.........//..................|..............#
.............................\.......//....................|..............#
.............................\.....//......................|..............#
..............................\..//........................|..............#
...............................AY..........................|..............#
...........................................................|..............#
...........................................................|..............#
............................................................|.............#
............................................................|.............#
............................................................|.............#
............................................................BM............#

After verifying that all the dots line up in neat columns, and the
number-sign at right margin lines up (except at one spot where
where node "AI" sits right at the right margin forcing the
number-sign to be displaced to the right), showing that you really
do have a fixed-pitch font, replace each dot with space to get a
better visualization of the image.

For an even better view, instead of 46 lines of 75 characters each
(not counting the # mark, and not counting the one label "AI" which
overflows the margin), I can generate a character array of 80 rows
and appx. 163 columns which looks great in Monaco 4. (You can't
*read* the labels in that size font, but you can always copy a tiny
part of one row and paste into another edit buffer where the font
is normal and you can read it, or even paste into the find-string
dialog. Or you can mark part of the screen to highlight it then
switch to Monaco 9 then scroll until you see the highlighted region
appear.)

I also have a HyperCard script for converting (label,row,col)
tuples to paint-text labels with pretty circles around them, and
converting links between labels as (row1,col1, row2,col2) tuples to
ordinary pencil-lines on the GUI. But the ASCII array displays in
Monaco 4 has been good enough for my debugging purposes so I
haven't yet interfaced my in-development code with the HyperCard
script I wrote several years ago. (I would need to look at the
data structure used by my HyperCard script, then write an output
routine in my Common Lisp code to generate exactly that format of
output, then manually copy&paste a block of such output from the my
VT100 emulator showing CL output to the TextArea in HyperCard.
(Actually HyperScript calls it something different, "Card Field"
(or "Background Field" if it's on a shared background instead of on
just a specific card), but I'm trying here to communicate with an
audience that might not have ever programmed in HyperTalk but is
familiar with the jargon of HTML and Java.)

> Ludovic

Serbian (like Slobodan Milosevic)?
Or Croatian (like Dennis Kucinich)?
Or somewhere else in that region?

On Fri, 28 Mar 2008 16:31:03 +0100, pjb@informatimago.com (Pascal J.
Bourguignon) wrote:

>C Y <smustudent1@yahoo.com> writes:
> 
>
>Yes, that may happen with stuff developped before the web.  Oldies
>better put their stuff on the web soon, or they'll be forgotten
>forever. (But perhaps by some strange archeologist who would still go
>to physical "libraries"...).

There's a lot of interesting stuff to be found searching old FTP
sites.  A number of old sites are still running (some have switched to
web portals and shut down FTP access), but they aren't easy to find
using search engines unless you know the site name because the search
engine spiders routinely ignore them.  About the only way to find some
of them is by mention in a newsgroup.

George
--
for email reply remove "/" from address

pjb@informatimago.com (Pascal J. Bourguignon) writes:

> C Y <smustudent1@yahoo.com> writes:
> 
>
> Yes, that may happen with stuff developped before the web.  Oldies
> better put their stuff on the web soon, or they'll be forgotten
> forever. (But perhaps by some strange archeologist who would still go
> to physical "libraries"...).

IMO somewhere in the internet is enough.

No result with veronica, btw:

*** Search terms: MRPP ***
First 20 selectors displayed (total limit 1500; page 1).
Results sorted by apparent relevance.
0 total matches.

--
Nuno J. Silva (aka njsg)
LEIC student at Instituto Superior Técnico
Lisbon, Portugal
Homepage: http://njsg.no.sapo.pt/
Gopherspace: gopher://sdf-eu.org/11/users/njsg
Registered Linux User #402207 - http://counter.li.org

-=-=-
"The process of preparing programs for a digital computer
is especially attractive, not only because it can be economically
and scientifically rewarding, but also because it can be an aesthetic
experience much like composing poetry or music."
-- Donald Knuth

Hi,

rem642b@yahoo.com (Robert Maas, see http://tinyurl.com/uh3t) writes:

> The code for MRPP3 was DEC PDP-10 assembly language (FAIL,
> developed at Stanford AI Lab, better assembler than MACRO which was
> developed by DEC). It ran on WAITS, the SU-AI machine in the D.C.
> Powers building. It did WAITS I/O directed to the XGP (Xerox
> Graphics Printer). If you have a PDP-10 + WAITS emulator plus XGP
> emulator, I could show you the code if I still have it.

Thanks for the interesting description.  Too bad no "write ups" and no
code are available.  There's still interesting research being done on
document layout, notably using functional languages.
 
>
> Serbian (like Slobodan Milosevic)?
> Or Croatian (like Dennis Kucinich)?
> Or somewhere else in that region?

Not quite.  That's my first name (unlike Milosevic), from France.

Thanks,
Ludovic.

> From: l...@gnu.org (Ludovic examnotes)
> Thanks for the interesting description.  Too bad no "write ups"
> and no code are available.

There seems to be a misunderstanding. I'm not aware of any *published*
reports of that software I wrote, except possibly in this:
(1995) Computer-based advanced placement calculus for gifted students.
Instructional Science, 22, 339-362 (written by my supervisor about our work)
I don't have access to that journal, and I wasn't told (four years
after I got laid off in 1991 due to recession and consequent lack
of funding) even that such an article had ever been published, and
I never received a preprint or reprint of it despite the fact that
my own work on that project was essential for its success. It was
only in mid-2005 that somebody did a search for my name in some
database of published journal articles which I don't have access to,
and thereby discovered that article mentionning my name, and posted
the info about it in a newsgroup, so that I could subsequently cite
it in my resume.

However there are plenty of unpublished files/articles mentionning it:

** MRPP3 later renamed "Prototype Overlay Xerographics" = POX

POX     FAI     REM     Prototype Overlay Xerographics, formerly MRPP3.FAI
POX.DUC (REM024->REM021 RP3) (= POX.FAI) (Fdone.861103)

75801A  WRU             description of XGP and POX
75801A.810 (REM024->REM021 DC09) (Fdone.860208)

POX    POX             Source for pox writeup
POXPOX  DUC             Source for pox writeup
POXPOX.DUC (REM024->REM021 RP3) (= POX.WRU) (Fdone.861103)

POX     PLN     REM     Plans and requested bug-fixes in POX not yet done
POX.PLN (REM024->REM021 DCNR) (Fdone.861103)

POX     UPD     REM     New stuff in POX not yet in manual
POX.UPD (REM024->REM021 DCNR) (Fdone.861103)

MCR1    POX             REM's first attempt to make a macro library for POX
MCR1.POX (DEL REM024->REM021 DCGM) (Fdone.861103) -> POX1.ARC

GRAPH   POX             Some preliminary macros for graphics in POX
GRAPH.POX (DEL REM024->REM021 DCGM) (Fdone.861103) -> POX1.ARC

NGB25   FNT     REM     (BINARY) Mixed font for POX and LMD, will be obsolet
e
; someday
NGB25.FNT (DEL REM024->REM021 DCNR) (Gone <90.8.11)
NGB25.FNT-OCT (DCNR)

POXMAC  BIB             Bibliography of POX macro libraries
POXMAC.BIB (REM024->REM021 DCNR) (Fdone.861103)

POX1.ARC from these files: Part of 798g.p,
All of 6502ab.pox 6502d.pox 6502p.pox 798b.pox 798m.pox 798p.pox 799h.pox
comovl.pox datime.pox dial1.pox graph.pox grhock.pox mcr1.pox nutrzz.pox
wly.pox
POX1.ARC (90707P)

72827  REM             Good/bad qualities of REM, from Marilyn Taylor, POX
72827.REM (REM024->REM021 RP2)
72827   TTY             Good/bad qualities of REM, from Marilyn Taylor, ASCI
I
72827.TTY (REM024->REM021 RP2) (Fdone.860208)

** After MRPP3/POX, during interim before I got funding for MRPP4

MRPP4   PRO             Proposal for son of POX using MacLISP
MRPP4.PRO (REM024->REM021 RP3) (Fdone.860715) Long before IMSSS/PSL

MRPP4   STATUS          Status of son of POX (MRPP4) Long before IMSSS/PSL
MRPP4.STA (REM024->REM021 RP3) (Fdone.860715)
MRPP4.INF (DEL REM034->REM020 87730F) (Old name, renamed -> MRPP5.INF)


** MRPP4 and MRPP5 a.k.a. "MathPrint" in CAI-Calculus program

MRPP4.PRO (REM033 86Z87W) WorkCalc: New proposal for IMSSS work

MathPrint.I (91218W) WorkCalc: Math-printer stuff (MRPP4 and MRPP5)
; (formerly in *.INFO files on Tenex)

MRPP5HLP.STA
MP5HLP.STA (WatW-813) WorkCalc: For Arsen: Descr. language and spec of what
; formulas to print and how they will look

MRPP5U.NOT (DEL REM025->REM020 88624F) (Gone <90.8.11)
MRPP4U.NOT (DEL REM005 89128W) (No keywords yet)
MRPP5U.NOTFICHE (DEL WatF-922b) (Keywords now) (Same as WatF-206)
MRPP5U.NOTFICHE (DEL WatF-206)
MRPP5U.NOTFICHE-WatF-206-V0 (90B03W) WorkCalc: Collection of all
; documentation and notes directly relevant to writing a technical
; report and user's manual for MRPP4

WISHMP.PRO (DEL REM025->REM020 88624F) (Gone <90.8.11)
WISHMP.PRO (DEL REM005 89128W) (Gone <90.8.11)
WISHMP.PROFICHE (WatF-922c) WorkCalc: Wish list for mathprinter (MRPP4),
; proposed new features

89502A.NOT (WatW-601) WorkCalc: MRPP5 TODO-IDEAS

MRPP4I.PRO (REM030->REM020 87708F) (should be renamed as below)
MRPP5I.PRO = WorkCalc: Proposals for internal representation of infix
; boxes

MRPP5M.DOC (DEL REM025->REM020 88624F) (Gone <90.8.11)
MRPP4M.DOC (DEL REM005 89128W) Older than WatF-922b
MRPP5M.DOCFICHE (DEL WatF-922b) Has keywords, same as WatW-716
MRPP5M.DOC (DEL WatW-716)
MRPP5M.DOC-WatW-716-V0 (90B03W) WorkCalc: How to modify MRPP4 (user's
; manual)

MP4TRY.PSL (DEL REM031->REM020 88225F)
MRPP5TRY.PSL
MP5TRY.PSL (DEL REM025->REM020 88624F) - Nethdr; 4->5; One diff at end, else
; identical
MRPP5TRY.PSLFICHE (DEL WatF-216) - Keywords; Bugfix to call canonicalize
;One diff at end, else identical
MPTRY.PSLFICHE-WatF-216-V0 (90B11W) WorkCalc: Test rig for MRPP5

MRPP4.PSL (REM033 86Z87W) WorkCalc: Probably the version before converting t
o
; table-lookup and splitting into modules?

MPSTD.PSL (DEL REM031->REM020 88225F) (gone <90.5.18)
MPSTD.PSL (DEL REM025->REM020 88624F) <TINY> - Nethdr
MPSTD.PSLFICHE (DEL WatF-119) Keywords, Else identical to above
MPSTD.PSLFICHE-WatF-119-V0 (90B11W) WorkCalc: toplevel hook for MRPP5
; for STDASCII
MPUGS.PSL (DEL REM031->REM020 88225F) (gone <90.5.18)
MPUGS.PSL (DEL REM025->REM020 88624F) <TINY> - Nethdr
MPUGS.PSLFICHE (DEL WatF-C08) Keywords, Else identical to above
MPUGS.PSLFICHE-WatF-C08-V0 (90B11W) WorkCalc: toplevel hook for MRPP5
; for UGS
MRPP5A  PSL
MRPP5A.PSLFICHE (DEL WatF-922c) - Keywords; MRPP5; Identical to 813
MRPP5A.PSL (DEL WatW-813)
MPA.PSL-WatW-813-V0 (90B11W) WorkCalc: MRPP5A PSL = Part of mathprinter
; that sets up PrintEnv internally. This is presently run interpreted
; only.
MPB.PSLFICHE-WatF-C06a-V0 (90B11W) WorkCalc: MRPP5B PSL = Part of
; mathprinter that converts ME to OVERLAY, but only the parts that are
; fully table-driven.
MRPP5C.PSL (DEL REM025->REM020 88624F) Nethdr
MRPP5C.PSLFICHE (DEL WatF-C06a) Keywords, One line diff at end
MPC.PSLFICHE-WatF-C06a-V0 (90B11W) WorkCalc: Part of mathprinter that
; reformats overlays to fit a region or just checks to see if it already
; fits.
MRPP4D.PSL (DEL REM034->REM020 87730F) - MRPP4
MRPP5D  PSL
MRPP5D.PSLFICHE (DEL WatF-922c) - Keywords; MRPP5; 1 diff line at end
MRPP5D.PSL (DEL WatW-813)
MPD.PSL-WatW-813-V0 (90B11W) WorkCalc: Part of mathprinter that converts
; overlay to CPO.
M4DU.PSL (DEL REM030->REM020 87C29F)
MRPP5DU PSL
MRPP5DU.PSLFICHE (DEL WatF-922c) - Keywords; 4->5 Identical to 813
MRPP5DU.PSL (DEL WatW-813)
MPDU.PSL-WatW-813-V0 (90B11W) WorkCalc: Part of MRPP5D specific to UGS
M4DW.PSL (DEL REM030->REM020 87C29F)
MRPP5DW PSL
MRPP5DW.PSLFICHE (DEL WatF-922c) - Keywords; 4->5; Identical to 813
MRPP5DW.PSL (DEL WatW-813)
MPDW.PSL-WatW-813-V0 (90B11W) WorkCalc: Part of MRPP5D specific to WINDX
MRPP4E.PSL (DEL REM034->REM020 87730F)
MRPP5E  PSL
MRPP5E.PSLFICHE (DEL WatF-216) Keywords, 4->5, One line diff at end
MPE.PSLFICHE-WatF-216-V0 (90B11W) WorkCalc: Part of mathprinter that
; emits CPO to device.
M4EU.PSL (DEL REM030->REM020 87C29F)
MRPP5EU PSL
MRPP5EU.PSLFICHE (DEL WatF-216) - Keywords; Under edit to avoid load
; utility files; 4->5; Else same until 1 line before end
MPEU.PSLFICHE-WatF-216-V0 (90B11W) WorkCalc: Part of MRPP5 specific to
; UGS
M4EW.PSL (DEL REM034->REM020 87730F)
MRPP5EW PSL
MRPP5EW.PSLFICHE (DEL WatF-922c) - 4->5; Keywords; Else identical
MRPP5EW.PSL (DEL WatW-813) ;Identical to 922c
MPEW.PSL-WatW-813-V0 (90B11W) WorkCalc: Part of MRPP5 specific to WINDX
MP4OT.PSL (DEL REM031->REM020 88225F)
MRPP5OT PSL
MP5OT.PSL (DEL REM025->REM020 88624F) - Nethdr; 4->5; Else identical
MRPP5OT.PSLFICHE (DEL WatF-C06a) - Keywords; Else identical
MPOT.PSLFICHE-WatF-C06a-V0 (90B11W) WorkCalc: Part of MRPP5O needed for
; STDASCII but not UGS

MP4RUS.CTL (REM005 89128W) WorkCalc: Tenex/PUP-level script for sending
; mathprinter files to FERMAT

** Result of Google search I conducted tonight in response to your article:

<http://coding.derkeiler.com/Archive.../>
ax-34689-6/>
<http://www.interactivecode.com/soft...br />
6540-27/>
<http://groups.google.co.il/group/co...=sour
ce>
<http://ctan.math.utah.edu/ctan/tex-... />
M.comments>


Now back to direct reply to your article:

> There's still interesting research being done on document layout,
> notably using functional languages.

I don't see any advantage of using functional languages, compared
to using procedural or OO or even rule-driven coding style. Is this
just a case where it happens that people doing research on
functional languages are the only major group of people who are
*also* interested in automatic mathematical layout for
display/printing? Or can you explain why a functional language
would be of any particular advantage? All you need really is a
nested representation for math expressions, i.e. a parse tree, i.e.
Lisp data structures following the (operator arg1 arg2 ...)
convention, plus data-processing software to recursively traverse
such a structure to bottom-up build the result structure such as
nested overlays. Either Algol 60, or Lisp 1.5, would have been
quite sufficient for this kind of D/P task. (Fortran wouldn't have
been sufficient, because it didn't support recursion back then,
because it stored return addresses from subroutines in fixed
locations rather than on a stack. Likewise I don't believe COBOL
had recursion either.)

START: (plus x (times 3 y)), it's not atomic.
Recurse to: x, it's atomic, build atomic overlay[x] and return it.
Recurse to: (times 3 y), it's not atomic.
Recurse to 3, it's atomic, build atomic overlay[3],
and return it.
Recurse to y, it's atomic, build atomic overlay[y],
and return it.
Combine the two returned pieces for 3 and y per the product rule:
Build the atomic overlay for the multiplication symbol [Unicode 22C5].
Compute offsets based on partial sums of horizontal size of components:
0   5   10   15
[3] [*]  [y]
Build composite overlay:
CO1 = [ x= 0  y=0  [3]           ]
[ x= 5  y=0  [Unicode 22C5]]
[ x=10  y=0  [y]           ]
[ xsize=15  ysize=7]
Return that composite overlay.
Combine the two returned pieces for x and (times 3 y) per the sum rule:
Build the atomic overlay for the addition symbol [+],
and return it.
Build the atomic overlay for the thin space [Unicode 2009],
and return it.
Compute offsets based on partial sums of horizontal size of components:
0   5              8   13              16   31
[x] [Unicode 2009] [+]  [Unicode 2009]  CO1
Build composite overlay:
CO2 = [ x= 0  y=0  [3]  ]
[ x= 5  y=0  [Unicode 2009]  ]
[ x= 8  y=0  [+]  ]
[ x=13  y=0  [Unicode 2009]  ]
[ x=16  y=0  CO1  ]
[ xsize=31  ysize=7]
Return that composite overlay.

Hi,

rem642b@yahoo.com (Robert Maas, see http://tinyurl.com/uh3t) writes:

> However there are plenty of unpublished files/articles mentionning it:

Thanks, that's indeed a long list.  However, none of them seems to
be publicly accessible.

> ** Result of Google search I conducted tonight in response to your article
:
>
> <http://coding.derkeiler.com/Archive...
ntax-34689-6/>
> <http://www.interactivecode.com/soft... />
-26540-27/>
> <http://groups.google.co.il/group/co...=so
urce>
> <http://ctan.math.utah.edu/ctan/tex-...omm
ents>

Unfortunately, none of these articles (all by you AFAICS) really gives
an overview of the system, which is what I was looking for.
 
>
> I don't see any advantage of using functional languages, compared
> to using procedural or OO or even rule-driven coding style.

I guess these are the same as for any kind of application, notably
referential transparency, which eases reasoning, etc.

The research I had in mind is about Lout [0] and Nonpareil [1], both
designed and implemented by Jeff Kingston [2].  Lout is a lazy, purely
functional DSL, while Nonpareil is a lazy, OO, purely functional general
purpose programming language.  A significant departure from TeX' macro
system...

Thanks,
Ludovic.

[0] http://lout.sf.net/
[1] http://www.it.usyd.edu.au/~jeff/nonpareil/
[2] http://www.it.usyd.edu.au/~jeff/