Looking for AWEB

Looking for AWEB

[Nick Roberts]

I would like to find out more about AWEB (a literate programming tool for
Ada), but I can't get through to the literate programming archive, and I
can't find any reference to AWEB elsewhere.  Any help welcome.

-------------------------------------
Nick Roberts
-------------------------------------

Re: Looking for AWEB

[Georg Bauhaus]

Nick Roberts (Nick.Roberts@dial.pipex.com) wrote:
: I would like to find out more about AWEB (a literate programming tool for
: Ada), but I can't get through to the literate programming archive, and I
: can't find any reference to AWEB elsewhere.  Any help welcome.

You can obtain it from CTAN, web directory.
If it has not changed during the last 2 years, it covers Ada 83.
It is based on D.E.Knuth's WEB.
gnatchop is quite helpful for installation.

An alternative is Norman Ramseys spidery web, same place.

-#- georg

Re: Looking for AWEB; TeX in Ada?

[Nick Roberts]

Thanks Georg, I've managed to grab it.  The problem now is that, although it
is supplied as source code (Ada 83), it is supplied partially krunched (all
unnecessary whitespace removed, all upper case, no comments, etc.), which is
fine for compile-and-go, but nearly useless if someone wants to modify it
(as I do).  Grrrrrr.  I shall take a little look at Norm's spidery web, next
time I visit CTAN.

Next question: is there any kind of TeX implementation (partial, rough
sketches, anything) in Ada (openly available)?

Also, how outrageous/foolish/infeasible would it be to invent a new,
smoothly combined, text formatting and literate programming language for the
purpose of being: (a) a literate programming vehicle for Ada, where most
users are likely to be totally new to literate programming; (b) itself
written in Ada; (c) readily maintainable, adaptable, and portable?  Does
something already exist that would be well suited to (be adapted to) this
role?

-------------------------------------
Nick Roberts
-------------------------------------

Georg Bauhaus wrote in message <7c5up1$gf7$1@news-hrz.uni-duisburg.de> (in
comp.lang.ada) ...
|Nick Roberts (Nick.Roberts@dial.pipex.com) wrote:
|: I would like to find out more about AWEB (a literate programming tool for
|: Ada), but I can't get through to the literate programming archive, and I
|: can't find any reference to AWEB elsewhere.  Any help welcome.
|
|You can obtain it from CTAN, web directory.
|If it has not changed during the last 2 years, it covers Ada 83.
|It is based on D.E.Knuth's WEB.
|gnatchop is quite helpful for installation.
|
|An alternative is Norman Ramseys spidery web, same place.
|
|-#- georg

PS: it turns out AWEB is Ada (written in); perhaps there is another AWEB for
APL?

Re: Looking for AWEB; TeX in Ada?

[Nick Roberts]

Brief update: I've unpacked, gnatchopped, and compiled everything in sight;
ATANGLE compiles, and seems to run (I can't easily tell if correctly);
AWEAVE fails to compile miserably (there seems to be a lot either missing or
misnamed).  The source code I've tried to compile is the Ada source supplied
(partially krunched); it is also effectively supplied in the form of AWEB
files, but ATANGLE doesn't seem to produce any result (other than a deeply
cryptic --{31:} type comment all on its own).  Back to square one I think.
C'est la vie!

Getting gnatchop to work was an amusing little saga: On installing to
Windows 95, the installer does a wonderful job, but it does not amend
AUTOEXEC.BAT to set up the PATH variable, so for gnatchop  to be able to
find gnat1 (which it needs), PATH has got to have something incredibly
unlikely such as C:\GNAT\LIB\MING32XYZ\3.2.1 added to it; however, MS-DOS
has always had a severe limit on the amount of memory it allows for
environment variables -- including PATH -- so I altered AUTOEXEC.BAT as
needed, but my PATH was only getting partially set, because Windows (in DOS
mode) was running out of environment variable memory (with my so far?); so,
I have to be remming out other additions to PATH to allow the additions I
need to fit in there, and FINALLY it all worked.  It's a good job I've got a
sense of humour.  I don't blame GNAT/ACT (Windows' oddities are not their
fault); I don't really blame Microsoft (they've by and large done a clever
job providing upward compatibility); but you (almost) never get any of this
kind of silliness with the UNIX-based operating systems; I'm a great critic
of UNIX, but this is one of the things UNIX got really right from the start
(a simple, generally unrestricted memory model).  Enough waffle.

-------------------------------------
Nick Roberts
-------------------------------------

Re: Looking for AWEB; TeX in Ada?

[Sven Utcke]

"Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:

> unlikely such as C:\GNAT\LIB\MING32XYZ\3.2.1 added to it; however, MS-DOS
> has always had a severe limit on the amount of memory it allows for
> environment variables -- including PATH -- so I altered AUTOEXEC.BAT as
> needed, but my PATH was only getting partially set, because Windows (in DOS
> mode) was running out of environment variable memory (with my so
> far?); 

The latest DOS I used was 5.0, in which you had both a limit on the
amount of memory reserved for environment variables (which could be
increased by setting an argument to command.com, look there), and a
128 (127?) character-limit for the path.  There were tools to get a
longer path, but you did not have any guarantee that programs would
interpret that path correctly.

> job providing upward compatibility); but you (almost) never get any of this
> kind of silliness with the UNIX-based operating systems; I'm a great critic
> of UNIX, but this is one of the things UNIX got really right from the start

Actually they didn't.  It's just that the limit is 1024 characters (at
least under IRIX 6.3), so you're less likely to be bitten.

Not that this has anything to do with litprog...

Sven

PS: to make this somewhat more relevant to litprog, I would strongly
    urge you to try one of the language-independent tools.  I myself
    am using FWEB, which I like; but if I were starting all over again
    I would probably go for noweb, which is somewhat more powerfull
    (although more complicated to setup and use, quite the opposite of
    what Norman envisioned). 
-- 
 _       _   Lehrstuhl fuer Mustererkennung und Bildverarbeitung
| |_ __ | |__                                                        Sven Utcke
| | '  \| '_ \   phone:      +49 761 203 8274                   Am Flughafen 17
|_|_|_|_|_.__/   fax  :      +49 761 203 8262           79110 Freiburg i. Brsg.
mailto:utcke@informatik.uni-freiburg.de   www.informatik.uni-freiburg.de/~utcke

Re: Looking for AWEB; TeX in Ada?

[Niklas Holsti]

Nick Roberts wrote:
> 
> Brief update: I've unpacked, gnatchopped, and compiled everything in sight;
> ATANGLE compiles, and seems to run (I can't easily tell if correctly);
> AWEAVE fails to compile miserably (there seems to be a lot either missing or
> misnamed).

I have a compiling copy; I can email it to you if you like. I've not
used it
seriously, but I played with it a little some time ago. I don't recall
making
any major changes; there are some warnings about variables that are
never
assigned a value.

> The source code I've tried to compile is the Ada source supplied
> (partially krunched); it is also effectively supplied in the form of AWEB
> files, but ATANGLE doesn't seem to produce any result (other than a deeply
> cryptic --{31:} type comment all on its own).  Back to square one I think.
> C'est la vie!

You found the AWEB files -- good. ATANGLE seems to expect its input AWEB
file to be named "input.aweb". It creates an output file "web_output.a",
which contains just the weird comment you quote. However, it also
generates
a number of .a files that contain the Ada code. Didn't you get these? 

Personally, I would look for a tool that generates HTML, but this may
be just a prejudice against TeX. There are tools that generate HTML
from straight Ada, but they don't give you the reordering (weaving and
tangling) of the Web tools. Then again, I don't feel a great need to
reorganise Ada code in this way; the Ada package structure seems to
give me what I need, contrary to Pascal (the original Web target)
with its strict ordering and lack of modularisation. YMMV.

> -------------------------------------
> Nick Roberts
> -------------------------------------

Niklas Holsti
Working at but not speaking for Space Systems Finlan Ltd.

Re: Looking for AWEB; TeX in Ada?

[Niklas Holsti]

Nick Roberts wrote:
> 
> Thanks Georg, I've managed to grab it.  The problem now is that, although it
> is supplied as source code (Ada 83), it is supplied partially krunched (all
> unnecessary whitespace removed, all upper case, no comments, etc.), which is
> fine for compile-and-go, but nearly useless if someone wants to modify it
> (as I do).  Grrrrrr.

The primary source is, of course, not in Ada but in the literary web
form. In my copy, the source files are called atangle.aweb and
aweave.aweb. They came combined in one file, which was confusingly named
"texfiles.src". Modifications should of course be made in the .aweb
files,
if you wish to follow the literary programming idea.

The "partially krunched" files are probably AWEB output, which is not
nicely
formatted. Oh well, just pipe it via a pretty-printer.

> -------------------------------------
> Nick Roberts
> -------------------------------------

Hope this eases your irritation,

Niklas Holsti
Working at but not speaking for Space Systems Finland Ltd.

Re: AWEB; Enhanced Document Encoding

[Mike Harrison]

In article <7cooqo$mdf$1@murdoch.acc.Virginia.EDU>, Nick Roberts
<Nick.Roberts@dial.pipex.com> writes
.
'snip'
>
>I have to agree that TeX -- to be completely blunt about it -- really creaks
>these days.  It was designed at a time when even really big computers
>(mainframes) had only a few MB of memory, and were generally batch-mode.
>Nowadays, even cheapo PCs have 64MB as a minimum (seems bizarre to us old
>hackers, but that's progress).
>
>I think it would be fair to say that a lot of the assumptions that the
>design of TeX (and other 'formatting languages') were based on just don't
>apply any more: there is no such thing as batch processing; personal
>computers can reformat and redisplay even a moderate big and complex
>document in (near as dammit) real time; the vast majority of word processing
>users -- for whatever reasons, right or wrong -- won't tolerate having to
>learn a complex language (call it a 'formatting' language if you like, but
>it's effectively a programming language), and many now expect an interface
>which they can just use 'straight off'.  Besides which, TeX is a weird
>language, and some of its 'quirks' are just bizarre.
>
...
>
>-------------------------------------
>Nick Roberts
>-------------------------------------
>
OK, I know this is miles 'off-topic', but:

I still use TeX (or rather LaTeX - which is a little less quirky!) for
letters and serious technical papers, because I just prefer the look and
feel - especially the Computer Modern Roman typeface and because it's
easier to format maths text etc.

I learned to use it many years ago at Inmos, who used it for all tech
documents (including books published by commercial publishers).

Also, I remember when you were lucky to have 16K of memory on a
mainframe ... (memories of living in a shoebox come to mind ;-) ).

------------------------------------------------------------------
  (mapcar 'standard_disclaimers (my_opinions))

  Change 'devil' to 'demon' for my real email address.

    Mike H.

Re: AWEB; Enhanced Document Encoding

[Michael F Brenner]

In addition to complex math equations (and tables of math
equations and commutative diagrams of math equations) LaTex is 
also useful as machine generated textual tables or math tables,
which can then be converted to RTF or some other target format,
or simply used as in, typesetting them in LaTeX.

Re: AWEB; Enhanced Document Encoding

[Sven Utcke]

"Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:

> I have to agree that TeX -- to be completely blunt about it -- really creaks
> these days.  

Strange.  I usually refer to it as "TeX flys", especially when
comparing it to the 8086 4.77MHz I used to use it on.

> I think it would be fair to say that a lot of the assumptions that the
> design of TeX (and other 'formatting languages') were based on just don't
> apply any more: there is no such thing as batch processing; personal
> computers can reformat and redisplay even a moderate big and complex
> document in (near as dammit) real time; the vast majority of word processing
> users -- for whatever reasons, right or wrong -- won't tolerate having to
> learn a complex language (call it a 'formatting' language if you like, but
> it's effectively a programming language), and many now expect an interface
> which they can just use 'straight off'.  

Well, I'm mainly using TeX because it's ease of use and high-quality
output is still unsurpassed.  I have never yet lost one of these two
bets:
a) given any moderately complicated formula, I can create a printout
   of it (using LaTeX) faster than the other guy can using WinWord
   (even though I'm batch-processing, while he's WYSIAYG).
b) The typeset result produced by (La)TeX will look better (as in: ask
   10 people, see what the majority will opt for).

By the way, ktalk still offers the MathEdit challenge
(http://www.ktalk.com/challenge.html):

--- snip ---
We created a letter containing over 50 equations in less than 4 hours
using MathEdit and popular word processors. Can you recreate the
letter in less than 44 hours with the same typeset-level quality,
using just WordPerfect, Word, or AmiPro? Our challenge letter is
available in the following files
--- snip ---

I'm confident that with TeX it could have been done in less than 4
hours... 

> Besides which, TeX is a weird
> language, and some of its 'quirks' are just bizarre.

No denying that.

> Add to that the coming of Unicode, which effectively solves (in theory :-)
> quite a few of the problems formatting languages grappled with in
> the past,

I think we should not confuse formatting (what should it look like)
with _input_-encoding.  Two different things entirely.

> plus the fact that the reasons for having a plain-text source file format
> have now pretty well gone away, and it all makes traditional formatting
> languages look a bit obsolete.  

Hardly.  Using Emacs I can manipulate text in ways simply not possible
with a word-processor (one of the simplest examples being that in this
sentence I wrote word-processor only once, and wrote "Beispiel"
instead of example.  Emacs wrote the second and third word-processor
after I typed wo<shift><TAB>, and translated the German word Beispiel
into it's English equivalent.  Erik Naggum once reported that he got
functions to turn first person sentences into third person, or
statements into questions and vice versa.)  Emacs also reminded me to
close the parenthesis (bracket?) above...

And of course I can easily create (La)TeX from a program, so if I'm
making 100 tests on something all I need to do is write a batch-file
(see!) and go home, and the next morning I've got I typeset tabular
plus graph of my measurements (using gnuplot).

> However, there is, now more than ever, a need for a truly standard
> 'enhanced' document format, that would provide for the standard encoding of
> a document's 'logical' structure (paragraphs, headings, list items,
> (floating) table rows and columns, etc.).  

This sound pretty much like a description of LaTeX, which somehow
makes me doubt that:

> (The fine details of the
> implementation of that structure would, of necessity, be non-standard.)

After all, LaTeX is pretty standard indeed...

> I think it would be incumbent on such a standard to have a reasonably
> efficient coding (for typical use), and I reckon it should be based on
> Unicode or ISO 10646 (regardless of actual character encoding).  It could
> take the opportunity to clear up the ambiguity surrounding the use of CR and
> LF (and SUB at the end), 

This would indeed be most welcome, I guess.

> and redefine a lot of presently useless or
> ambiguous control characters (BS, HT, LF, VT, FF, CR, ESC, DEL, and maybe
> others) for useful purposes.

Why?  It's not as if they really got any place in a decent text-file
anyway...

Not that I know what all this has to do with litprog, never mind Ada...

Sven, who rather likes LaTeX and plain ASCII.
-- 
 _       _   Lehrstuhl fuer Mustererkennung und Bildverarbeitung
| |_ __ | |__                                                        Sven Utcke
| | '  \| '_ \   phone:      +49 761 203 8274                   Am Flughafen 17
|_|_|_|_|_.__/   fax  :      +49 761 203 8262           79110 Freiburg i. Brsg.
mailto:utcke@informatik.uni-freiburg.de   www.informatik.uni-freiburg.de/~utcke

Re: AWEB; Enhanced Document Encoding

[Nick Roberts]

Sven Utcke wrote in message <36f04969.0@pfaff.ethz.ch>...
|"Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:
|
|> I have to agree that TeX -- to be completely blunt about it -- really
creaks
|> these days.
|
|Strange.  I usually refer to it as "TeX flys", especially when
|comparing it to the 8086 4.77MHz I used to use it on.


Oh no!  I _didn't_ mean to start a flame war!  Help!  I feel compelled
(maybe I shouldn't :-) to answer Sven's post, but from an objective point of
view I think, not a hostile one.

[...]
|Well, I'm mainly using TeX because it's ease of use and high-quality
|output is still unsurpassed.

TeX is easy to use, and very, very powerful, once you have learned how to
use it.  But, it is not easy to learn!  To find out if a particular command
works, or works as you expect, you have to go through the whole
process-and-view cycle.  With a WYSIWYG* program, you get a menu of
commands, and you can try them out immediately.  The same is true of LaTeX,
which is a little less flexible than plain TeX, but does have the benefit of
being (by an order of magnitude) easier to learn.

|I have never yet lost one of these two
|bets:
|a) given any moderately complicated formula, I can create a printout
|   of it (using LaTeX) faster than the other guy can using WinWord
|   (even though I'm batch-processing, while he's WYSIAYG).

Which (presumably) proves TeX is better than Word at formulae.  Fair enough,
but Word, I suspect, is better than TeX at a great many things!

Experiment (hypothetical).  Seat a young secretary in front of a computer
with: (A) LaTeX and (say) noweb; (B) Word 7.0.  Ask the secretary to
copy-type: (1) a letter to a disgruntled client; (2) some documentary notes
on a program I am writing, including copious mathematical formulae; (3) a
small literate program I have drafted.  Now consider the following
scenarios: (A1) the secretary resigns in tears; (B1) all done in half an
hour; (A2) after offering a raise, it still takes two half-day computer
courses and a week to complete; (B2) all done in five hours, with a certain
amount of swearing, and a (cosmetically) nasty result; (A3) after offering
another raise, it takes a further two half-day computer courses and another
week, but the result is fine; (B3) no chance.  In other words, horses for
courses.  (Bearing in mind that some courses are only used once a year.)
Oh, and the secretary likes the paperclip best (apparently).

|b) The typeset result produced by (La)TeX will look better (as in: ask
|   10 people, see what the majority will opt for).


Better than Word, maybe.  Better than _any_ document processing system?  Not
necessarily!

[...]
|> Add to that the coming of Unicode, which effectively solves (in theory
:-)
|> quite a few of the problems formatting languages grappled with in
|> the past,
|
|I think we should not confuse formatting (what should it look like)
|with _input_-encoding.  Two different things entirely.


Not entirely.  There are certain problems which had to be solved by
formatting languages or word processors in the past that are completely (or
partially) obviated by Unicode.  Unicode all but solves the problems of:
special characters and foreign scripts; combinative forms; code space for
user-defined characters or codes.

|> plus the fact that the reasons for having a plain-text source file format
|> have now pretty well gone away, and it all makes traditional formatting
|> languages look a bit obsolete.
|
|Hardly.  Using Emacs I can manipulate text in ways simply not possible
|with a word-processor (one of the simplest examples being that in this
|sentence I wrote word-processor only once, and wrote "Beispiel"
|instead of example.  Emacs wrote the second and third word-processor
|after I typed wo<shift><TAB>, and translated the German word Beispiel
|into it's English equivalent.  Erik Naggum once reported that he got
|functions to turn first person sentences into third person, or
|statements into questions and vice versa.)  Emacs also reminded me to
|close the parenthesis (bracket?) above...


Ridiculous!  How are any of these things not possible in a word processor?
Indeed, Word actually does most of these things.

What I was getting at was: in the past (thirty years ago?), special (rather
than plain-text) editors would rarely be a practical proposition, because
computers were time-shared, had little memory (and storage), and were slow;
communications very often assumed only 7-bit ASCII text was being sent.  By
comparison, nowadays nearly all computers are desktops, have oodles of
memory and storage, and are extremely fast, and have a GUI; nearly all
communications today is binary.  Thus, special editors (e.g. semi-WYSIWYG)
which use a non-ASCII character set are a much more practical proposition.

|And of course I can easily create (La)TeX from a program, so if I'm
|making 100 tests on something all I need to do is write a batch-file
|(see!) and go home, and the next morning I've got I typeset tabular
|plus graph of my measurements (using gnuplot).


With the high-level encoding I am suggesting, it would be easier still to do
the same thing.  Codes can be written by a program just as easily as visible
text.  My encoding would be high-level, so this technique would generally be
a whole load simpler than plain TeX, and simpler, even, than LaTeX.

|> However, there is, now more than ever, a need for a truly standard
|> 'enhanced' document format, that would provide for the standard encoding
of
|> a document's 'logical' structure (paragraphs, headings, list items,
|> (floating) table rows and columns, etc.).
|
|This sound pretty much like a description of LaTeX,

Yes, the idea is something similar to LaTeX, but slicker, and slightly
higher-level.  The trade-off would be that you would need a special,
hand-holding, editor to edit these files, but the encoding would be more
efficient (most commands carried out by a single 16-bit code), and errors
less likely (because the codes are generated by the editor, not directly by
the user).  The editor would probably be 'semi-WYSIWYG'.

|which somehow
|makes me doubt that:
|
|> (The fine details of the
|> implementation of that structure would, of necessity, be non-standard.)
|
|After all, LaTeX is pretty standard indeed...


My suggested encoding would be higher-level than LaTeX.  This would have the
benefit of simplifying the encoding, at the cost of de-standardising the
details of the implementation (e.g. fonts used, paragraph indentation and
spacing, numbering style, etc.).  The user would certainly be able to
specify these things, it's just that the way in which they would be
specified would be non-standard.  Again, this is a trade-off.

[...]
|> and redefine a lot of presently useless or
|> ambiguous control characters (BS, HT, LF, VT, FF, CR, ESC, DEL, and maybe
|> others) for useful purposes.
|
|Why?  It's not as if they really got any place in a decent text-file
|anyway...


An odd statement (or an apparently irrational one, at least).  These
character codes (and plenty of others, thinking about it) could be re-used
for useful and well-defined purposes, instead of being the total dead weight
most of them are now.

|Not that I know what all this has to do with litprog, never mind Ada...


It has to do with document processing, which is important to literate
programming, and literate programming is potentially of significance to Ada
(and most programming languages).

|Sven, who rather likes LaTeX and plain ASCII.
|--
| _       _   Lehrstuhl fuer Mustererkennung und Bildverarbeitung
|| |_ __ | |__                                                        Sven
Utcke
|| | '  \| '_ \   phone:      +49 761 203 8274                   Am
Flughafen 17
||_|_|_|_|_.__/   fax  :      +49 761 203 8262           79110 Freiburg i.
Brsg.
|mailto:utcke@informatik.uni-freiburg.de
www.informatik.uni-freiburg.de/~utcke

I hope nobody considers it too objectionable that I (again) cross-post this
article.

-------------------------------------
Nick Roberts
-------------------------------------

*Sven prefers the WYSIAYG alternative, as in "what you see is all you get",
a Kernighanism I believe.  This was to do with a different argument (about
WYSIWYG word processors not encoding information about the logical structure
of a document.  Of course, nowadays, they all do, or can do, this.)

Re: AWEB; Enhanced Document Encoding

[Sven Utcke]

"Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:

> Sven Utcke wrote in message <36f04969.0@pfaff.ethz.ch>...
> |"Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:
> |
> |> I have to agree that TeX -- to be completely blunt about it -- really creaks
> |> these days.
> |
> |Strange.  I usually refer to it as "TeX flys", especially when
> |comparing it to the 8086 4.77MHz I used to use it on.
> 
> Oh no!  I _didn't_ mean to start a flame war!  Help!  I feel compelled
> (maybe I shouldn't :-) to answer Sven's post, but from an objective point of
> view I think, not a hostile one.

Nah, you cna't objectively discuss TeX (or Emacs, for that matter)
without to acknowledge that they are simply the best...

> |I have never yet lost one of these two
> |bets:
> |a) given any moderately complicated formula, I can create a printout
> |   of it (using LaTeX) faster than the other guy can using WinWord
> |   (even though I'm batch-processing, while he's WYSIAYG).
> 
> Which (presumably) proves TeX is better than Word at formulae.  Fair enough,
> but Word, I suspect, is better than TeX at a great many things!

I suppose so.  Hmm.  I mean, it must be, after all, it's the
market-leader.  It's just I can't think of anything.  Do you think it
would qualify that WinWord can change the layout of your document
because you changed your printers resolution from 1200DPI to 600DPI
(and usually will)?

> Experiment (hypothetical).  Seat a young secretary in front of a computer
> with: (A) LaTeX and (say) noweb; (B) Word 7.0.  

They actually performed that experiment back in, uh, beginning of the
nineties, using Word 5.0 (I think) and LaTeX on secretaries who had
never before worked on a computer.  It turned out that the ones using
LaTeX were actually learning faster(*).  Our own secretary (well, from
about 3 years ago) always used LaTeX and could never get to grips with
Winword. 

> Ask the secretary to
> copy-type: (1) a letter to a disgruntled client; (2) some documentary notes
> on a program I am writing, including copious mathematical formulae; (3) a
> small literate program I have drafted.  Now consider the following
> scenarios: (A1) the secretary resigns in tears; (B1) all done in half an
> hour; 

I'm writing all my letters in LaTeX, and it rarely takes 30minutes.  I
think this comparison is only fair if you assume that the secretary
does know as much about LaTeX as she does about WinWord.  In WinWord
it would boil down to:
* This is how you load a document-template (or whatever they called in
  WinWord) and this is how you fill it in.
And in LaTeX
* This is how you load a document-template, and this is how you fill
  it in.
Not much of a difference, as far as I can tell...

> (A2) after offering a raise, it still takes two half-day computer
> courses and a week to complete; (B2) all done in five hours, with a certain
> amount of swearing, and a (cosmetically) nasty result; 

No, it won't work that way.  Chances are your secretary doesn't know
an integral from a sum, so in order to have her typeset any formula in
any software you'll have to spend a considerable amount of time
explaining what is what, and what it should look like.  Otherwise the
results will not be cosmetically nasty, but simply plain unuseable.
To many things in mathematics depend on the _exact_ look.  

What is more, once you have explainde the difference between a sum and
an integral sign, there is very little to stop your secretary from
typing \sum.  And since LaTeX knows a lot about what mathematics
should look like, she is actually quite likely to get good results.
Which is completely unlikely with WinWord, since WinWord requires you
to know how it should look like in order to make it look that way.

> (A3) after offering
> another raise, it takes a further two half-day computer courses and another
> week, but the result is fine;  (B3) no chance.  

I don't think your secretary will ever make a good job of a literate
program, no matter what tool she is using.

> In other words, horses for courses.

I agree that there is no reason why one shouldn't use WinWord for
letters.  As a matter of fact, it's perfectly fine for letters.
Nothing I couldn't do with LaTeX too, and probably faster (with a
little Help from Emacs), but it's absolutely adequate.  If it comes to
series letters (or whatever they are called.  Sending the same letter
to 200 people), WinWord might even be a tat easier.

The point is, while both WinWord and LaTeX are perfectly adequate for
writing letters, LaTeX will also produce beautiful books with lovely
maths.  WinWord will crash.  Or wont print.  Or will reformate your
entire 200-page book (this is of course hypothetical.  You can not
write 200-page books in WinWord if you need only even a moderate
amount of crossreferencing, pictures and formulas) if you changed your
printers resolution --- never mind changing the printer (say for 4
colour pages).  I've seen students do this on their first thesis-like
asignment.  Trust me:  I know of no student who has used WinWord for
his first assignment who has also used it for his second.  The
experience is just to horrible.

Not that I remeber why I felled compelled to make that point.
Probably something to do with restarting Windows all morning (trying
to get the very same network-card to work which worked flawlessly one
month ago.  All Windows ever does unfortunately is to tell my:  It's
plug and play, don't worry, all is fine.  Well, it's not...).

> Oh, and the secretary likes the paperclip best (apparently).

So do I.  Everything else about WinWord is a pile of ...., but the
paperclip is undeniably cute.

> |b) The typeset result produced by (La)TeX will look better (as in: ask
> |   10 people, see what the majority will opt for).
> 
> Better than Word, maybe.  Better than _any_ document processing system?  Not
> necessarily!

Of course not.  But very likely better than any WYSIAYG-system.  Doing
the markup with LaTeX means the system actually knows what the
different entitys stand for, which it usually doesn't with WYSIAYG.

> [...]
> |> Add to that the coming of Unicode, which effectively solves (in theory
> :-)
> |> quite a few of the problems formatting languages grappled with in
> |> the past,
> |
> |I think we should not confuse formatting (what should it look like)
> |with _input_-encoding.  Two different things entirely.
> 
> Not entirely.  There are certain problems which had to be solved by
> formatting languages or word processors in the past that are completely (or
> partially) obviated by Unicode.  

As in: how do you write \"a.  True.  But that's just a problem of
input-encoding, nothing to do with typesetting.

> Unicode all but solves the problems of:
> special characters and foreign scripts; combinative forms; code space for
> user-defined characters or codes.

Yeah, but that's not what typesetting is all about.  It's about types
(fonts, the layout on a printed page).  Having more boxes for more
types might make it easier to find a particular type, but ultimately
it's all about selecting that type in the right font / size / shape,
and to position it correctly.

> |> plus the fact that the reasons for having a plain-text source file format
> |> have now pretty well gone away, and it all makes traditional formatting
> |> languages look a bit obsolete.
> |
> |Hardly.  Using Emacs I can manipulate text in ways simply not possible
> |with a word-processor (one of the simplest examples being that in this
> |sentence I wrote word-processor only once, and wrote "Beispiel"
> |instead of example.  Emacs wrote the second and third word-processor
> |after I typed wo<shift><TAB>, and translated the German word Beispiel
> |into it's English equivalent.  Erik Naggum once reported that he got
> |functions to turn first person sentences into third person, or
> |statements into questions and vice versa.)  Emacs also reminded me to
> |close the parenthesis (bracket?) above...
> 
> 
> Ridiculous!  How are any of these things not possible in a word processor?

Well, what about: currently not implemented?

> Indeed, Word actually does most of these things.

Translating words?  Expanding words from a few letters or a
user-defined abbreviation?  Changing the structure of sentences?  Not
my word, it doesn't.

> What I was getting at was: in the past (thirty years ago?), special (rather
> than plain-text) editors would rarely be a practical proposition, because
> computers were time-shared, had little memory (and storage), and were slow;
> communications very often assumed only 7-bit ASCII text was being sent.  By
> comparison, nowadays nearly all computers are desktops, have oodles of
> memory and storage, and are extremely fast, and have a GUI; nearly all
> communications today is binary.  Thus, special editors (e.g. semi-WYSIWYG)
> which use a non-ASCII character set are a much more practical proposition.

Oh, any decent editor can use non ASCII charactersets, and could do so
for years.  How else would my chinese colleagues send and receive
their emails?

But it's still text-based, even if it isn't ASCII.

> |And of course I can easily create (La)TeX from a program, so if I'm
> |making 100 tests on something all I need to do is write a batch-file
> |(see!) and go home, and the next morning I've got I typeset tabular
> |plus graph of my measurements (using gnuplot).
> 
> With the high-level encoding I am suggesting, it would be easier still to do
> the same thing.  Codes can be written by a program just as easily as visible
> text.  

No.
Every Unix-tool knows how to handle plain text.  Shell-scripts, awk,
sed, perl, everyone.  You can easily edit it in a text-editor if
something didn't go exactly right.

With your setup, unless every single program translates from binary to
text and back to binary, all you'll ever see is gibberish.  If you do
the translation, however (so that you are still able to use awk), then
you could just as well have used plain-text to begin with.

> My encoding would be high-level, so this technique would generally be
> a whole load simpler than plain TeX, and simpler, even, than LaTeX.

Why?

> |> However, there is, now more than ever, a need for a truly standard
> |> 'enhanced' document format, that would provide for the standard encoding of
> |> a document's 'logical' structure (paragraphs, headings, list items,
> |> (floating) table rows and columns, etc.).
> |
> |This sound pretty much like a description of LaTeX,
> 
> Yes, the idea is something similar to LaTeX, but slicker, and slightly
> higher-level.  The trade-off would be that you would need a special,
> hand-holding, editor to edit these files, but the encoding would be more
> efficient (most commands carried out by a single 16-bit code), 

Sounds like it's going to conflict with the use of unicode.

> |which somehow
> |makes me doubt that:
> |
> |> (The fine details of the
> |> implementation of that structure would, of necessity, be non-standard.)
> |
> |After all, LaTeX is pretty standard indeed...
> 
> 
> My suggested encoding would be higher-level than LaTeX.  This would have the
> benefit of simplifying the encoding, at the cost of de-standardising the
> details of the implementation (e.g. fonts used, paragraph indentation and
> spacing, numbering style, etc.).  The user would certainly be able to
> specify these things, it's just that the way in which they would be
> specified would be non-standard.  Again, this is a trade-off.
> 
> [...]
> |> and redefine a lot of presently useless or
> |> ambiguous control characters (BS, HT, LF, VT, FF, CR, ESC, DEL, and maybe
> |> others) for useful purposes.
> |
> |Why?  It's not as if they really got any place in a decent text-file
> |anyway...
> 
> 
> An odd statement (or an apparently irrational one, at least).  These
> character codes (and plenty of others, thinking about it) could be re-used
> for useful and well-defined purposes, instead of being the total dead weight
> most of them are now.

Well, they _are_ controll characters.  You would need them in order to
connect your terminal to your computer (use your modem, whatever), so
you can't really get rid of them without a replacement.

> |Not that I know what all this has to do with litprog, never mind Ada...
> 
> 
> It has to do with document processing, which is important to literate
> programming, and literate programming is potentially of significance to Ada
> (and most programming languages).
> 
> |Sven, who rather likes LaTeX and plain ASCII.

> *Sven prefers the WYSIAYG alternative, as in "what you see is all you get",
> a Kernighanism I believe.  This was to do with a different argument (about
> WYSIWYG word processors not encoding information about the logical structure
> of a document.  Of course, nowadays, they all do, or can do, this.)

No doubt they could, if you entered it beforehand.  Which somehow
defies the idea of WYSIAYG.  And since the above is now out of
context, I would like to clarify:  I _hate_ WYSIAYG (or WYSIWYG).

Well, back to reinstalling Windows...

Sven

(*) Urban legend alert!
-- 
 _       _   Lehrstuhl fuer Mustererkennung und Bildverarbeitung
| |_ __ | |__                                                        Sven Utcke
| | '  \| '_ \   phone:      +49 761 203 8274                   Am Flughafen 17
|_|_|_|_|_.__/   fax  :      +49 761 203 8262           79110 Freiburg i. Brsg.
mailto:utcke@informatik.uni-freiburg.de   www.informatik.uni-freiburg.de/~utcke

Re: AWEB; Enhanced Document Encoding

[Nick Roberts]

Well, I think to quite a large extent Sven and I are arguing at cross
purposes, and to quite a large extent I agree with what he is saying anyway.
I also suspect, perhaps, he is not being deeply serious, and I am, after
all, only throwing an idea into the wind!

Forgive me for not requoting his post as appropriate, but I think the size
of our articles could start getting a bit too big (does that sound funny?
You know what I meant! :-).  Again, I hope I'm forgiven for cross posting.

Firstly: MS Word is clearly not the market leader through technical
superiority alone.  I don't think anyone's going to disagree with that!
It's neat in some ways, and it's certainly 'feature-rich', but it sure has
its problems.  I wouldn't want to use it for any large work (for fear of it
crashing or just being too slow); I might well use TeX for such a project,
instead.

The example I gave with the secretary was, of course, not a very serious
one, and I agree with Sven on every point he makes about it (apart from the
paperclip, which I find abominable ;-).  He is particularly right about
secretaries not knowing enough about maths to typeset formulae correctly (of
course, some secretaries will, but I think the truth is most will not).
(And as for Windows crashing: my Windows 95 PC crashed yesterday, losing me
a large e-mail I was just about to send.  It's a fairly regular occurrence.
'Nuff said.)

The typesetting problems that Unicode solves are only a few; this was a very
minor point.

Sven points out that, for a lot of programming tools (e.g. sed, awk, perl,
shells), outputting normal text will indeed be easier than numbered codes.
He is, of course, quite right.  I tend not to use such tools, so this was
simply a case of biased thinking on my part.  He also questions why
outputting codes would be 'much easier' than outputting, say, LaTeX
directives, and on reflection, I must admit, there would probably be no
great difference between the two (in most programming languages, and an
advantage to LaTeX in some languages).

I think Sven must misunderstand my point about the control characters.  Yes,
you need them (and even then, not all) for old-style character
communications, but you don't need them, except a few, for anything else.  A
text document file could certainly get away with using the control
characters (or most of them) for other purposes.  If you needed to
communicate such a file somewhere, you'd send it as a binary file.  No
problem!  (If you need to process it as plain text, you must put it through
an appropriate filter; also not really a problem.)

Finally, Sven confirms his hatred of all things WYSIWYG.  Might projects
such as LyX change his mind?  I used to be pretty contemptuous myself of
typical WYSIWYG word processors*, most of which were suitable only for
letters and trivial documents, once.  But I observe and listen to many other
computer users in my job (roving consultant), and most of them love WYSIWYG,
and the immediacy of typical GUIs.  As a programmer, I feel I must bow to
the needs of the majority.  Also, I must admit, I like it a lot -- if I am
trying to use a program I have never used before and will never use often --
when I can get the program to do what I want straight away by just pulling
down a menu or two.  (Of course, only the best 5% odd of GUI programs are
this well designed, in reality; but the principle stands.)  Anyway, what I
am proposing is not to replace TeX, but to augment it (and maybe, one day
long from now, supercede it), as a standard format for text documents.  I'm
not trying to take TeX away from anybody!

-------------------------------------
Nick Roberts
-------------------------------------

*apart from the wonderful WordStar [sheds a sad tear], way back when
graphics screens were unknown, when WordStar was the only serious
semi-WYSIWYG word processor for microcomputers, and the world worshipped at
its feet.  Whatever happened to WordStar?  Why wasn't there an enquiry?

Re: AWEB; Enhanced Document Encoding

[Sven Utcke]

"Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:

> I also suspect, perhaps, he is not being deeply serious, 

Me?  Never!

> (And as for Windows crashing: my Windows 95 PC crashed yesterday, losing me
> a large e-mail I was just about to send.  It's a fairly regular occurrence.
> 'Nuff said.)

About 30 minutes ago...

> I think Sven must misunderstand my point about the control characters.  Yes,
> you need them (and even then, not all) for old-style character
> communications, but you don't need them, except a few, for anything else.  A
> text document file could certainly get away with using the control
> characters (or most of them) for other purposes.  If you needed to
> communicate such a file somewhere, you'd send it as a binary file.  No
> problem!  (If you need to process it as plain text, you must put it through
> an appropriate filter; also not really a problem.)

Granted.  But why do you want to get rid of them?  With unicode, it's
not as if there were a shortage of characters available...

> Finally, Sven confirms his hatred of all things WYSIWYG.  Might projects
> such as LyX change his mind?  

Nope.  I realise we will have to install it in order to get students
to use (La)TeX, but it's really not the right way to do things.  About
95% of all TeX-related questions I answer have to do with the fact
that people try do to WYSIWYG things in LaTeX, things that seem to
look good (to the untrained eye) but are really just breaking the
internal logic of the document (independent from the wordprocessor).
LaTeX usually tries hard to stop them, hence the problems...

> I used to be pretty contemptuous myself of
> typical WYSIWYG word processors*, most of which were suitable only for
> letters and trivial documents, once.  

As far as I can tell WinWord still isn't ueable for any longer or more
complicated documents...

> But I observe and listen to many other
> computer users in my job (roving consultant), and most of them love WYSIWYG,
> and the immediacy of typical GUIs.  

It gives a person the feeling to be "in control" --- certainly not
something you'll ever get from (La)TeX.  The problem is that this will
put people in control of typesetting (which, after all, is a real job
which it takes three years to learn) who have absolutely no clue, and
with the results you would expect...

> As a programmer, I feel I must bow to
> the needs of the majority.  Also, I must admit, I like it a lot -- if I am
> trying to use a program I have never used before and will never use often --
> when I can get the program to do what I want straight away by just pulling
> down a menu or two.  (Of course, only the best 5% odd of GUI programs are
> this well designed, in reality; but the principle stands.)  

I don't think so.  for any moderately complex program you'll usually
have to understand the basic concepts before being able to do any
usefull work with it.  Which requires you to read, at least, a short
introduction... 

Sven
-- 
 _       _   Lehrstuhl fuer Mustererkennung und Bildverarbeitung
| |_ __ | |__                                                        Sven Utcke
| | '  \| '_ \   phone:      +49 761 203 8274                   Am Flughafen 17
|_|_|_|_|_.__/   fax  :      +49 761 203 8262           79110 Freiburg i. Brsg.
mailto:utcke@informatik.uni-freiburg.de   www.informatik.uni-freiburg.de/~utcke

Re: AWEB; Enhanced Document Encoding

[Sven Utcke]

"Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:

> I also suspect, perhaps, he is not being deeply serious, 

Me?  Never!

> (And as for Windows crashing: my Windows 95 PC crashed yesterday, losing me
> a large e-mail I was just about to send.  It's a fairly regular occurrence.
> 'Nuff said.)

About 30 minutes ago...

> I think Sven must misunderstand my point about the control characters.  Yes,
> you need them (and even then, not all) for old-style character
> communications, but you don't need them, except a few, for anything else.  A
> text document file could certainly get away with using the control
> characters (or most of them) for other purposes.  If you needed to
> communicate such a file somewhere, you'd send it as a binary file.  No
> problem!  (If you need to process it as plain text, you must put it through
> an appropriate filter; also not really a problem.)

Granted.  But why do you want to get rid of them?  With unicode, it's
not as if there were a shortage of characters available...

> Finally, Sven confirms his hatred of all things WYSIWYG.  Might projects
> such as LyX change his mind?  

Nope.  I realise we will have to install it in order to get students
to use (La)TeX, but it's really not the right way to do things.  About
95% of all TeX-related questions I answer have to do with the fact
that people try do to WYSIWYG things in LaTeX, things that seem to
look good (to the untrained eye) but are really just breaking the
internal logic of the document (independent from the wordprocessor).
LaTeX usually tries hard to stop them, hence the problems...

> I used to be pretty contemptuous myself of
> typical WYSIWYG word processors*, most of which were suitable only for
> letters and trivial documents, once.  

As far as I can tell WinWord still isn't ueable for any longer or more
complicated documents...

> But I observe and listen to many other
> computer users in my job (roving consultant), and most of them love WYSIWYG,
> and the immediacy of typical GUIs.  

It gives a person the feeling to be "in control" --- certainly not
something you'll ever get from (La)TeX.  The problem is that this will
put people in control of typesetting (which, after all, is a real job
which it takes three years to learn) who have absolutely no clue, and
with the results you would expect...

> As a programmer, I feel I must bow to
> the needs of the majority.  Also, I must admit, I like it a lot -- if I am
> trying to use a program I have never used before and will never use often --
> when I can get the program to do what I want straight away by just pulling
> down a menu or two.  (Of course, only the best 5% odd of GUI programs are
> this well designed, in reality; but the principle stands.)  

I don't think so.  for any moderately complex program you'll usually
have to understand the basic concepts before being able to do any
usefull work with it.  Which requires you to read, at least, a short
introduction... 

Sven
-- 
 _       _   Lehrstuhl fuer Mustererkennung und Bildverarbeitung
| |_ __ | |__                                                        Sven Utcke
| | '  \| '_ \   phone:      +49 761 203 8274                   Am Flughafen 17
|_|_|_|_|_.__/   fax  :      +49 761 203 8262           79110 Freiburg i. Brsg.
mailto:utcke@informatik.uni-freiburg.de   www.informatik.uni-freiburg.de/~utcke

Re: AWEB; Enhanced Document Encoding

[Patrick Mérissert-Coffinières]

But doesn't LyX purport to be WYSIWYM? I think this not just a cute pun.
I discovered TeX (with enthusiasm) about 12 years ago. I used to be a
mathematician longer ago than that, but already at the time I was developping
software. But you do not need to write math. software to need notation, you often
want to use summation signs, underscript indexes, etc... An if you are into design
with assertions, you may want quantifiers and logical symbols. And anyway there
are a lot of areas other than maths where TeX is, from the engineering point of
view, totally unapproachable by any other tool. Of course the language is quite
hard, and even though this kind of puzzle, it was time consuming to use, and I
wished for some kind of WYSIWYGness, though I was already a little wary of it.
Then Leslie Lamport made the very point that Sven Utcke is making: that pure
wysiwyg encouraged people to forget the structure of what they were doing, So I
thing LyX, with the wysiwyM idea is a wonderful approach. In a way it is a
compromise of course, since it is still possible to twist the structure, but at a
higher level, and this is in my mind analogous to high-level languages that do not
prevent totally the programmer from doing unnatural thins, just make it easier for
the willing programmer to resist the temptation of doing so. So I was just as
enthusiastic about discovering LyX (only a few months ago!) that I had been
discovering TeX in the first place.

Sven Utcke wrote:

> "Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:
>
> > Finally, Sven confirms his hatred of all things WYSIWYG.  Might projects
> > such as LyX change his mind?
>
> Nope.  I realise we will have to install it in order to get students
> to use (La)TeX, but it's really not the right way to do things.  About
> 95% of all TeX-related questions I answer have to do with the fact
> that people try do to WYSIWYG things in LaTeX, things that seem to
> look good (to the untrained eye) but are really just breaking the
> internal logic of the document (independent from the wordprocessor).
> LaTeX usually tries hard to stop them, hence the problems...

Re: AWEB; Enhanced Document Encoding

[Martin Kew]

Patrick M�rissert-Coffini�res wrote:

>  ... Then Leslie Lamport made the very point that Sven Utcke is making: that pure
> wysiwyg encouraged people to forget the structure of what they were doing, So I
> thing LyX, with the wysiwyM idea is a wonderful approach. In a way it is a
> compromise of course, since it is still possible to twist the structure, but at a
> higher level, and this is in my mind analogous to high-level languages that do not
> prevent totally the programmer from doing unnatural thins, just make it easier for
> the willing programmer to resist the temptation of doing so.

Patrick, I whole heartily agree and would like to extend the statement by saying that:
The act of diminishing or removing the translation step from desired structure to
concrete ASCII syntax (with the use of the wysiwyM concept).  Places the author at a
higher semantic level in a document's generation, i.e. the author does not have to
think about hand translating the desired structure to the required LaTeX syntax, but
can concentrate on the document's form and structure.
--

Regards

Martin Kew

Vision Abell Pty Ltd
Second Avenue, Technology Park
Mawson Lakes SA 5095 Australia
Tel +61 8 8300 4544
Fax +61 8 8349 7420
email Martin.Kew@vsl.com.au
http://www.vsl.com.au

Re: AWEB; Enhanced Document Encoding

[nospam!bob]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]

In article <7eu9tm$4nc$1@news.interlog.com>, Martin says...
>
>
>
>Patrick M�rissert-Coffini�res wrote:
>
>>  ... Then Leslie Lamport made the very point that Sven Utcke is making: 
>> that pure wysiwyg encouraged people to forget the structure of what 
>> they were doing, So I thing LyX, with the wysiwyM idea is a wonderful
>> approach. 

scientific word does the best job at this (better than Lyx, but not free,
and I don't think it is even available on Linux.

But it works similar to LyX, and of course, it generates Latex as
output. Which then one can use to generate .ps, which one can use to generate
PDF, and also Latex can be used to generate HMTL using Latex2HTML.

I agree that writing in pure Latex is like low level programming. When I did
it, I used to spend much time fixing synatx errors, unmatched {}, etc.., and
it was a pain. If I can use an Object Oriented flexible document layout
system, it is much easier and faster as long as I still get the Latex/Tex
output from it. 

Bob

Re: AWEB; Enhanced Document Encoding

[Simon Wright]

Sven Utcke <utcke@tu-harburg.de> writes:

> So do I.  Everything else about WinWord is a pile of ...., but the
> paperclip is undeniably cute.

What I particularly liked was the flat spin the paperclip went into
when I asked it how to delete itself ..

Re: AWEB; Enhanced Document Encoding

[Michael F Brenner]

> ... which (presumably) proves TeX is better than Word at formulae
> ... Word, I suspect, is better than TeX at a great many things
> ... Experiment (hypothetical). Seat a ... secretary in front 
> of a computer with ... LaTeX ... 
  doing complex formulae...
> the secretary resigns in tears.

Since I have done this experiment on numerous papers, theses, 
computer programs, and charts, I would like to point out from
my experience that the secretary will resign in Word quicker
than in LaTex, and that less training is needed to do tables of
formulas in LaTex than in Word. However, in either language,
it takes a certain kind of desire to do technical typing,
and I often wind up doing the typing myself. 

You are right, though, that a secretary can do a letter faster
in Word than in LaTex, but just imagine which the world would be
better without: letters or technical documents.

I have some Ada programs that use LaTex as the output language,
and it would be quite difficult to generate Word output. Even
using Microsoft Components, the format of the RTF (rich text
file) transfer file underneath the Microsoft Word format,
changes as the operating systems evolve. 

Re: AWEB; Enhanced Document Encoding

[Laurent Gasser (CSCS)]

Nick Roberts wrote:
> I have to agree that TeX -- to be completely blunt about it -- 
> really creaks these days.  

Having discovered the TeX processing system for my research in 
mathematics, I end up appreciating one feature of TeX over all 
others: source code is ASCII 7 bits.

If you know of a text editor with such advanced feature for scientific 
notation and such a permanent propriatary format, I would be happy 
to learn about it.

However, I would always recommend someone to use the processing 
system adopted by one's coworkers and people one's has to interact
with. Data conversion is never easy or completely faithful. And
there is always a situation in which the local expert helps you 
to realize what you want.
____________________________________________________________________

 Dr. Laurent GASSER               | E-mail : lgasser@cscs.ch
 CSCS/SCSC, PES                   | WWW    : <http://www.cscs.ch/>
 Galleria 2, Via Cantonale        | voice  : ++41 91 610 82 02
 CH-6928 Manno / TI (Switzerland) | fax    : ++41 91 610 82 82
____________________________________________________________________

Re: AWEB; Enhanced Document Encoding

[FREDERICK LONG]

"Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:
> However, there is, now more than ever, a need for a truly standard
> 'enhanced' document format, that would provide for the standard encoding of
> a document's 'logical' structure (paragraphs, headings, list items,
> (floating) table rows and columns, etc.).  

SGML (Standard Generalized Markup Language, ISO 8879:1986).

> I think it would be incumbent on such a standard to have a reasonably
> efficient coding (for typical use), and I reckon it should be based on
> Unicode or ISO 10646 (regardless of actual character encoding).  It could
> take the opportunity to clear up the ambiguity surrounding the use of CR and
> LF (and SUB at the end), 

SGML (actually, SGML just depends on ISO 646).

> and redefine a lot of presently useless or
> ambiguous control characters (BS, HT, LF, VT, FF, CR, ESC, DEL, and maybe
> others) for useful purposes.

SGML.

I've said it three times, so it must be true.  :-)

(Sorry to c.l.a people, this has very little to do with Ada.)
[moderator note: it's also oblique to comp.programming.literate,
 but I've set follow-ups to go there]

	Fred Long.

--------------------------------------------------------------------

Dr Fred Long,                           Email: fwl@aber.ac.uk
Department of Computer Science,         Tel: +44 1970 622440
University of Wales, Penglais,          Fax: +44 1970 622455
Aberystwyth, SY23 3DB, UK.

Re: Looking for AWEB; TeX in Ada?

[Laurent Gasser (CSCS)]

Nick Roberts wrote:
> 
> Thanks Georg, I've managed to grab it.  The problem now is that, although it
> is supplied as source code (Ada 83), it is supplied partially krunched (all
> unnecessary whitespace removed, all upper case, no comments, etc.), which is
> fine for compile-and-go, but nearly useless if someone wants to modify it
> (as I do).  

Not being an expert in AWEB (or any of its language flavour) I remember
that Donald Knuth intended it to be used this way. You never change
the (krunched, hard to read) code, you never update the documentation.

You only write the mix of them both in AWEB, and automatically produce 
from the same document both a compilable source code and the TEX-able 
documentation.

Please correct me if I got Knuth's intent to synchronize code and
documentation wrong.
____________________________________________________________________

 Dr. Laurent GASSER               | E-mail : lgasser@cscs.ch
 CSCS/SCSC, PES                   | WWW    : <http://www.cscs.ch/>
 Galleria 2, Via Cantonale        | voice  : ++41 91 610 82 02
 CH-6928 Manno / TI (Switzerland) | fax    : ++41 91 610 82 82
____________________________________________________________________