Re: Left field

comments inline:

On 22 April 2016 at 14:40, Norman Walsh <ndw@nwalsh.com> wrote:
> James Fuller <jim@webcomposite.com> writes:
>> I think you had some typos in some of the examples.
>
> Quite possibly.

first listing $result output is then referred to as $output

>> We could use a variable to set expression language, like
>>
>>    $p:expression-language = "'com.marklogic:xquery:1.0-ml"
>
> Maybe. It feels more like a declaration than a variable to me, but
> setting it to a possibly structured string value like that makes
> sense.

Also, in the rare instances one may have too it would mean one can
switch expr language in the body of the xproc.

>> The logic branching reminds me that boolean logic is just a
>> constrained case of fuzzy logic ... there is some attraction to having
>> a more rules based approach and I wonder if we could not achieve that
>> here.
>
> That’s an interesting idea.

not sure if its too cute.

>> Lastly, your examples reinforce (for me) the need to delineate between
>> pipes and variables.
>
> I was trying to finesse my way around that issue, actually. The proposal
> has, I think, only one kind of variable in the language: names for
> binding contexts.

ah ok, your following explanation clarifies and I see how your are
proposing treating everything as a (special) variable ... I am all for
minimisation of productions and it does seem to address known
concerns.

> Binding contexts in turn are just hashes of names to values. The
> values can be anything. One thing they can be is a pipe. If you use
> the pipe in a context where some value is needed, then you’re going to
> have to stop and wait and collect the values at that point. As long as
> you don’t, the implementation is free to stream them any way it likes.
>
> Take a linear pipe:
>
>   a() -> b() -> c()
>
> The implementation can run all three of these in parallel. It can even
> run b() on a different node in the network, as long as it passes
> everything that a() puts in its output binding context to b() and
> everything b() outputs to c().
>
> Making that work requires that the steps read from their ports ordinally
> becaues the names will be wrong.
>
>   a() -> [$source=ref("result") ]
>       -> b()
>       -> [$source=ref("result") ]
>       -> c()
>
> is probably still streamable as long as the implementation is clever
> enough to recognize that all that’s going on is a little shuffling of
> names in the binding context.
>
>   a() -> [$source=ref("result") ]
>       -> ( $source instanceof Object ) { something() -> [$source=ref("result")] }
>       -> c()
>
> Naively, irrespective of the expression language, whenever a binding
> set feeds into a conditional or {{ }} block, the implementation has to
> collect all of the outputs together and put them in the *expression*
> context for the following expression. (Meaning, generally, that ports
> have to be realized into sequences of objects.)
>
> Less naively, if the implementation can do sufficient static analysis
> of the expression to assure that some port value isn’t used, it can
> just pass that through without stalling.
>
>                                         Be seeing you,
>                                           norm
>
> --
> Norman Walsh
> Lead Engineer
> MarkLogic Corporation
> Phone: +1 512 761 6676
> www.marklogic.com

Received on Friday, 22 April 2016 13:02:05 UTC