Re: Scheme for DSSSL Back Ends?

Subject: Re: Scheme for DSSSL Back Ends?
From: James Clark <jjc@xxxxxxxxxx>
Date: Wed, 02 Apr 1997 21:39:40 +0700
At 17:26 01/04/97 -0500, Paul Prescod wrote:
>Most DSSSL implementations that are intended to produce textual output
>(RTF, TeX, Mif, etc.) will have a concept of a "back end": an API that
>maps make-expressions to constructs in the target language. Every full
>DSSSL implementation will also have an implementation of the Expression
>Language, which is basically Scheme.

The expression language differs from Scheme in some very important respects,
notably it's absence of side-effects.  Unless an implementation is reusing
an existing Scheme implementation, it is unlikely to support side-effects.

>It seems to me that we could define (informally) a common set of
>functions for creating new back-ends in Scheme.

I think it would be hard to to do this without side-effects.

>Those back-ends would be
>faster to write for non-C++ or non-Java programmers, and portable
>between DSSSL implementations. These back-ends would not replace the
>current ones (they might be much slower), but would augment them to make
>the set of DSSSL targets as large (and as portable) as possible. Many
>back-ends could be prototyped in Scheme, but "mere mortals" and then
>recoded in Java or C++ after they have proven themselves.

I think I would find it easier for "mere mortals" to write a backend in Java
than in Scheme.

>What do implementors think?

It would be nice to have a way to use higher level languages to write
backends, but Jade's FOT backend already gives you this to some extent.  If
I wanted more than this I would probably create a binding between Jade's
FOTBuilder backend and some other scripting language.  On Windows, an OLE
automation interface would probably be the way to go.


Current Thread