- From: James Fuller <jim@webcomposite.com>
- Date: Wed, 20 Apr 2016 21:34:17 +0100
- To: Murray Maloney <murray@muzmo.com>
- Cc: XProc WG <public-xml-processing-model-wg@w3.org>, Henry Thompson <ht@inf.ed.ac.uk>
after discussion with Alex/Norm ... I think my suggestion is a bit discordant eg. we have a fully fledged concept of named pipe which does not map onto what I was thinking. need to cogitate more. J On 20 April 2016 at 20:56, James Fuller <jim@webcomposite.com> wrote: > to be clear (thx to Norm for pointing this out) ... I am not actually > proposing we expose functions as such ... but this illustrated for me > a kind of 'land bridge' where we can make the difference between >> > and ->. > > J > > On 20 April 2016 at 20:48, James Fuller <jim@webcomposite.com> wrote: >> I think the confusion revolves around the fact that we have yet to >> decide the divide between variables and ports. >> >> My personal preference is to model everything internally as a function >> which gives us deferred processing and a lot of flexibility: >> >> I wonder if we could decide that >> >> -> is a promise and >> means to atomise down to value >> >> this then allows for both constructions, where >> >> [ $stdin, $stylesheet ] -> mystep() -> $result >> >> sets $result to contain a function that when invoked returns the value >> (but does not give it a name) >> >> eg. doing $result() invokes (like a step no?) >> >> and >> >> [ $stdin, $stylesheet ] -> mystep() >> $result >> >> where >> is equal to $result() and placing the value into variable $result. >> >> this 'collapsing' has implications in terms of streaming, etc but it >> seems to follow our current set of assumptions. >> >> thoughts ? >> >> J >> >> On 20 April 2016 at 20:16, Murray Maloney <murray@muzmo.com> wrote: >>> Sorry I missed today’s call. We were celebrating. >>> >>>> On Apr 20, 2016, at 2:25 PM, Henry S. Thompson <ht@inf.ed.ac.uk> wrote: >>>> >>>> If my way of thinking of variables as having an input port and an output >>>> port, i.e. as a way of giving a pipe of flowing data a name for later >>>> reuse, then it becomes a lightweight way of specifying the identity step. >>>> >>>> That is, I claim that >>>> >>>> ... -> ... >>>> >>>> is equivalent to >>>> >>>> ... -> identity() -> ... >>>> >>>> is equivalent to >>>> >>>> ... >> $foo >>>> [$foo] -> ... >>>> >>>> with an added name for later reuse. >>> >>> FWIW, I agree with Henry, intuitively. I might add that there is cost associated with instantiating $foo. >>> >>>> >>>> Which brings me back to thinking that the -> vs. >> distinction is >>>> misleading at best, and I should just be able to write >>>> >>>> ... -> $foo -> … >>> >>> Yes, just so. And why isn’t it > instead of ->? And why don’t we call stdin, $stdin, and use ‘-‘ as shorthand? >>> >>> [ $stdin, $stylesheet ] >>> [ -, $stylesheet ] >>> >>> I find >> confusing again. The >> operator has always meant that the left side would be appended (added to at its endpoint) to whatever was already present in the file, as opposed to the > operator which just steps on the previous contents of the right hand side (re-initializes the file and then appends). >>> >>> The proposed use of >> does not ‘append’ so much as it just throws the left side into a bag on the right side. >>> >>> So, in this processing context in which there is no sense of order, where chain sequences ‘append’ results onto a URI in timeless harmony, the >> really means ’throw into bag’ named by the URI, where; the bag may have other content, and the order of top-level content is indeterminate. So, we can only create unordered lists of documents with the >> operator, is that correct? (I can see the value in being able to rapidly create, use, and destroy document universes.) >>> >>> How does one create ordered lists of documents? Is there a convenient operator to perform file append, in the classic sense? >>> >>> >>> >>>
Received on Wednesday, 20 April 2016 20:34:46 UTC