Re: DSSSL extensions for XSL

[James Clark <jjc@xxxxxxxxxx>]

Paul Prescod wrote:

> As I understand the iterative extensions, they do not really alleviate
> the difficulty with passing information between construction rules.

Right.  I think first-class modes are the solution to that problem, and
I believe they are compatible with these extensions.

> In
> other words they don't seem to add much functionality to the language.
> They just present a more familiar language interface to people who are
> used to imperative languages.

Right.  They also allow some things to be done significantly more
efficiently.

> If this is the case, I would also like to
> suggest that the imperative extensions include "do" which is not
> currently documented as being available.

I agree.  I'm not a big fan of "do" myself -- I find named let more
powerful and easier to use -- but I can't see any good reason to exclude
it.
 
> Is an upwards-only call/cc very valuable.

It's useful for all things you would use return/break/continue for in C,
Java or JavaScript.

> I know that it can be used to
> implement exception handling, but I think it may be more confusing than
> helpful. A catch/throw special form might be more appropriate. Are there
> other uses of an upwards-only call/cc?

Like you, I would find a catch/throw style syntax more natural for this,
but that has to be balanced against the incompatibility with Scheme. 
There are several Scheme implementations that provide upwards-only
call/cc (Kawa for example).

> Flow object macros seem like they will be very nice syntactically. Can
> the flow object macro inspect the inherited characteristics in contexts
> other than characteristic specifications or do we still have to wait for
> first class modes for that??

The inherited characteristics are packaged up into a style object and
there's no way at the moment to look inside style objects.  First-class
modes wouldn't help with that.

James

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