Re: Lout, is it too late?

[Valeriy E. Ushakov]

On Fri, Sep 08, 2000 at 15:29:50 +0900, Paul Selormey wrote:

> The first thing that will put you off is the cryptic filenames.
> This is my first to see file names like "z01.c", "z02.c" etc.  How
> do you prefer this to "parser.c", "loutmain.c" for instance?

z* names had confused me for a short while, but since I use etags, I
don't really care anymore.  Is FixAndPrintObject in galley.c or is it
in print.c?  As long as etags takes care about it, filenames are not
that important: M-. FixAndPrintObject RET will take me to the right
place right away.  YMMV.


> 3. File extensions. Lout is really not strict about file extensions,
> why? I do not know how many here got to know the file extension, but
> I learnt about it from the externs.h source codes to be *.lt.

You would have learned it from the first page of the man lout ;-)


> We have
> @SysInclude{doc} for document,
> @SysInclude{tab} for table (not tabs!),
>  why not
> @SysInclude{rep} for report?

Why is it #include <stdio.h> and not <standardio.h>?  Not to mention
the infamous creat(2) ;-).



> We have
> @Section
>     @Tag{dfs}
>     @Title{Depth-first search}
> @Begin
> @PP
> This should be it...
> @End @Section
> 
> Is the use of @Section (same keyword, same format) at both the start
> and end not too inconsistent?

Some languages from the so called Algol family have similar feature.
Just check, say, Wirth "Algorithms..." book that uses Modula-2.

Repeating the name at the @End helps parser to recover from misplaced
parens.  If it sees @End @Section and it expects a closing curly for a
@Display - it knows something is wrong and can help user to locate the
problem.



> @SysInclude{fig}
> ...
> @Fig{
> @Box
>     margin{0c}
>     paint{black}
> @Ellipse
>     linestyle{noline}
>     paint{white}
> {Hello, World}
> }
> 
> In line with the @Section example above, why are the keywords
> margin, paint, linestyle not marked as @margin, @paint, and
> @linestyle?

Named parameters for "graphic" tuning use @-less lowercase naming
convention.  I guess this reduces visual clutter.  I.e. I think it's
good for parameters in

    @Figure
      @Location { PageTop }
      @Capture { Foo bar }

to stand out and I think that in

    @Box paint { gray } { Hello }

numerous named parameters that control shape and colour are not *that*
important to emphasize them with @.  My personal preference, anyway.



> Now, what I wish to see for a future Lout is a system redesigned to
> support the emerging documentation and database standard -- XML.
[...]
> This is the future, a common format for all.

<grumps> <censored size="15k" reason="I'd rather not show everyone how
this XML buzz pisses me off" /> </grumps>


> So my question is, is it too late to consider a redesign of the Lout
> to XML format?  Parsers are freely available and new onces are
> coming.

How much per ounce? ;-)
Though the real question is "why bother?".


> Where do you want to go today?

Well, my personal list is:

. Dynamic scoping support via inherited charactersitics a-la DSSSL.

  Currentluy only selected few paramters are dynamically scoped with
  an ad-hoc syntax.


. Real functional language with lambda.

  Destructuring on objects to be able to express @Meld, @Common, @Rump
  and @Insert.

  Real lambda - Lout currently have a very peculiar syntax for
  anonymous functions - named parameters with parameters, thus the
  names of bound variables are specified in one palce and the body
  (where those names are lambda-bound) is supplied in another.


> <lout filename = "Hello.lt">
> <sysinclude>
>     <file>document</file>
>     <file>figure</file>
> </sysinclude>
[...]

Just *why* would anyone in his right mind prefer this to, say, DocBook
or TEI or any other established DTD?


> With the XML-based Lout, the conversion from and to any
> wordprocessor could be easily done.

Why would you want to convert *to* any wordprocessor?  This reminds me
of people in comp.lang.postscript asking how to convert from
PostScript to Word.

My vision is that Lout main strength is its programmability, so I see
the future for Lout in the backend arena.  After all XML needs
something to print it, you still need *roff, TeX, Lout or something
else to actully lay things out.  Note that even DSSSL explicitely
requires a layout engine:

| This International Standard does not standardize a formatter nor
| does it standardize composition or other processing algorithms.
| Rather, it provides the means whereby an implementation may
| externalize 'style characteristics' and other techniques for
| associating style information with an SGML document.

I haven't checked its XML counterpart, but I would guess that the only
difference is the use of XML syntax instead on Scheme.

So it's the conversion *from* a wordprocessor that is interesting, but
in this case XML syntax for Lout is not that important.
Engineering-wise it's easier to write a simple converter (taht you
would need anyway) from internal wordprocessor format than to
introduce a major unstability into Lout by retrofitting an XML syntax
into it.

Also, I guess that for manually-written Lout, XML is far from ideal,
since XML introduces a lot of rigidity and redudancy - exactly to
simplify the job for parser writers.

Somehow I find, say,

  @Arrow from address@hidden ++ 2f atangle 135d} to address@hidden ylabel {r-1}

to be much more readble than its XML incarnation whatever it would be.
And as far as uniform syntax is concerned - I prefer Lisp to XML.


And don't make a commong mistake, Lout != standard packages, just like
TeX != plain.tex.  Moreover, it's generally not a very good idea to
target machine output to packages written for humans - that's why ease
of programming is important, so that one can write custom packages to
target machine output to (SDC, formerly known as Typeset, did exactly
this).


I hope I was not too rough.  I really didn't mean to attack you.
Sorry if I was, but that XML-everywhere stance (with emphasis on
'everywhere') *really* gets me going, as a quick inspection of list
archives readily demonstrates :-).

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