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. James
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Scheme for DSSSL Back Ends?, Alex Milowski | Thread | New Jade snapshot available, James Clark |
Re: Cross-referencing, James Clark | Date | Re: Jade specific - Re: Semantics o, James Clark |
Month |