Re: DSSSL side effect-freeness

Subject: Re: DSSSL side effect-freeness
From: Pierre Mai <dent@xxxxxxxxxxxxxxx>
Date: 28 Jan 1998 18:39:40 +0100
>>>>> "FAC" == Frank A Christoph <christo@xxxxxxxxxxxxxxxxxx> writes:

    FAC> So, recalling that laziness does not mix well with side
    FAC> effects, you can see that there are usually two extremes for
    FAC> a functional language: either it uses CBV and has
    FAC> side-effects, or it uses Need and has no side-effects.
    FAC> Clearly both alternatives have their advantages.

    FAC> But now consider the DSSSL expression language.  In the world
    FAC> I have just drawn, it is a very strange beast indeed: it
    FAC> isn't lazy and it hasn't got any side-effects.  This puts it
    FAC> smack in the middle of two Good Things, yet possessing
    FAC> neither, like a child at Christmas that can't make up its
    FAC> mind about which present to open first.

I'd just like to point out, that there are a number of pure
functional, yet non-lazy (i.e. eager) functional languages, e.g. Opal,
developed locally at the Technical University of Berlin, see

Apart from eagerness being easier to implement, it usually leads to
language implementations that have less state to carry around with
them.  Currently, this _can_ lead to faster execution times and/or
smaller memory footprints than implementations of lazy languages
achieve, although they should theoretically be faster/more

Especially the interaction possibilites with "current-*" in groves
might lead to much state being carried around, though this is only
speculation on my part...

On the whole I rather think, that the decission for eagerness was
probably mostly carried by the arguments for simplicity and/or
compatibility with the Scheme way of things, rather than by
theoretical considerations for speed and equivalence...

Also I wonder if it would not still be possible (even if not really
standard-conformant) to implement DSSSL in a lazy way, and probably
most Style-Sheets would continue to work unchanged...
    FAC> distributed, though -- and I can't imagine distributed groves
    FAC> being a typical case anyway.

Well, if we look at the corporate world, where large technical
document repositories are being maintained and deployed as IETMs for
example, I would rather think that distributed groves might be heavily

Just my two centieuros...

Regs, Pierre.

Pierre Mai <dent@xxxxxxxxxxxxxxx>
  "Such is life." -- Fiona in "Four Weddings and a Funeral" (UK/1994)

 DSSSList info and archive:

Current Thread
  • Re: DSSSL side effect-freeness, (continued)
      • Harald Hanche-Olsen - from mail1.ability.netby (8.8.5/8.6.12) with ESMTP id QAA03547Tue, 27 Jan 1998 16:26:24 -0500 (EST)
        • Paul Prescod - from mail1.ability.netby (8.8.5/8.6.12) with ESMTP id TAA10715Tue, 27 Jan 1998 19:42:59 -0500 (EST)
    • Paul Prescod - from mail1.ability.netby (8.8.5/8.6.12) with ESMTP id TAA10659Tue, 27 Jan 1998 19:42:27 -0500 (EST)
    • Frank A. Christoph - from mail1.ability.netby (8.8.5/8.6.12) with ESMTP id AAA12305Wed, 28 Jan 1998 00:06:25 -0500 (EST)
      • Pierre Mai - from mail1.ability.netby (8.8.5/8.6.12) with ESMTP id OAA22416Wed, 28 Jan 1998 14:15:53 -0500 (EST) <=
      • Paul Prescod - from mail1.ability.netby (8.8.5/8.6.12) with ESMTP id RAA24174Wed, 28 Jan 1998 17:19:24 -0500 (EST)
    • W. Eliot Kimber - from mail1.ability.netby (8.8.5/8.6.12) with ESMTP id OAA23003Wed, 28 Jan 1998 14:56:26 -0500 (EST)