RE: About the declare-flow-object-class

["Frank A. Christoph" <christo@xxxxxxxxxxxxxxxxxx>]

Didier wrote:
> I do not mean in the actual Jade implementation which is like you
> said. I am
> trying to find the intent of the editors that just said very little about
> this construct. Actually, you are right, they do not specify that the
> implementation to be in a DSSSL script but it may be in a script or in
> whatever the implementer decides.
>
> I think that we need to clarify the expansion mechanism for DSSSL-2.
> actually, it is not clear enough.
>
> I'll start a discussion thread specific to expansion mechansim. My own
> opinion is that the library is a better tool for this and it also
> provide a
> package for any expansions. Also, if we specify that a library
> could be made
> in any language as long as a set of procedure and flow objects
> are exported,
> we increase the versatility and also simplify the expansion
> mechsnaism to a
> single entity. We would then have to manage libraries and libraries would
> contain different implementations.

If the library can be written in any language, how do you specify that a
procedure or flow object is "exported"? You can't even specify the signature
of a procedure, and there is no notion of data layout for flow objects. To
do this, you would need to appeal to some interoperability standard like
CORBA or COM.

Personally, I think what is urgently needed is an additional API layer
expressed in native DSSSL (Scheme), implementing some of the semantics of
the flow objects themselves. It amounts to a layout engine, I suppose; you
would lose the ability to delegate so much formatting responsibility to the
existing backends, because many of them wouldn't be able to preserve the
additional semantics (except maybe TeX), but at least  it would provide a
portable, standard backend (which would go a long way towards clearing up
some of the semantics of those mysterious characteristics like
line-composition:, and the interactions among characteristics), and it would
be much easier to connect it to page description languages like PS and PDF
(and DVI).

With the appropriate hooks, you could use this API to implement new flow
objects. I think a better idea, though, is to add Scheme-style macros
(expansion-passing style macros, not that syntax-rules stuff); then it is
possible to turn some of the weirdo forms like "make" into macros and make
them amenable to extension directly without any magic. I think crud like
"element" and "mode" can be turned into macros which explicitly thread
(currently implicit) "current-node" and "inherited-characteristics"
variables through their bodies; if you add some new primitives, it can be
done in a uniform, purely functional way by a CPS transformation (or monad),
or just in an ad hoc fashion. For example,

  (element (X Y) (make paragraph (literal (gi (current-node)))))

becomes something like

  (cons '(X Y) (lambda (curnode inh-c) (make-para inh-c (literal inh-c (gi
(curnode))))))

A mode would be translated into a function which compiles a pattern-matcher
using the car of this pair, and then passes the current node and inheriteds
to the thunk in the cdr. At this level of abstraction, you can parametrize
the function representing the mode and pass it around, so you get "first
class modes" for free.
One problem, though, is that parts of a single mode can be scattered around
your stylesheet; for example, how many people knew you could write code like
this?:

  (mode X
    (element A ...)
    (element B ...))

  (element A ...)

  (mode X
    (element C ...))

i.e., you can resume the definition of a mode later on. This happens to be
useful, but only because you can't put a "define" inside a mode definition,
i.e.,

  (mode X
    (define (f x) ...))

is a no-no. Speaking of which, the fact that you can use things like
(current-node) outside of a rule body (like in a definition) is also
problematic, since it isn't in the scope of a macro.

--FC


 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist