- From: James Fuller <jim@webcomposite.com>
- Date: Wed, 20 Apr 2016 20:56:40 +0100
- To: Murray Maloney <murray@muzmo.com>
- Cc: XProc WG <public-xml-processing-model-wg@w3.org>, Henry Thompson <ht@inf.ed.ac.uk>
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 19:57:10 UTC