Of parameters, maps, and variables

Hello world,

I still feel that maps offer a way forward to simplifying parameters
without sacrificing flexibility. (I say "feel" because I haven't been
able to articulate a clear proposal yet.)

Trouble is, changing the value associated with a key in a map is a
side effect. Unless the only way to do that is with a first-class
step, we don't have a story about the order in which the expressions
will be evaluated.

And even if the only way to do it is with a first-class step, we'll
still have the problem of expressing dependencies among those steps
(since they're not likely to have outputs that are consumed).

I think we're going to have to make implementors work harder. I think
implementors are going to have to do static analysis on expressions
and use variable def/use when calculating the order of evaluation.

This will have the pleasant consequence that it will be ok to put
p:variable anywhere in the pipeline instead of requiring users to
create a new p:group just to allow a variable definition at the top of
that group.

The only gaping hole I see is what to do about instructions that
don't have a clear order:

  <p:set-param map="mymap" name="key" value="{2+3}"/>
  <p:set-param map="mymap" name="key" value="{3+4}"/>

I guess we use document order to disambiguate those. So the value
of the key in mymap is 7, not 5.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
Lead Engineer
MarkLogic Corporation
Phone: +1 413 624 6676
www.marklogic.com