Re: Removing '@' ?

I went there too but inputs are like function arguments and outputs
are like returns.

I'll make the additional observation that our steps are more like
closures where we bind options to step invocations and make something
that operations on inputs and produces outputs.

On Thu, Feb 18, 2016 at 12:53 PM, James Fuller <jim@webcomposite.com> wrote:
> ok you've convinced me that named ports are the way forward ... though
> if ordering is preserved we could make conventions based on ordinal 1
> input/output.
>
> ignore my pre/post ideas ... I like ([],[]){}
>
> J
>
>
>
>
> On 18 February 2016 at 21:37, Alex Miłowski <alex@milowski.com> wrote:
>> I've been trying to avoid the idea of a primary input and output.
>> Without them, there is not obvious choice for the default context.
>>
>> When you generalize to have more than one input or output, there is no
>> right choice for a primary.  As such, it makes me inclined to think we
>> shouldn't have the idea at all.
>>
>> As far as the pre/post idea.  I thought about that too but I think
>> people have gravitated to the idea of a signature at the beginning.  I
>> think it lessens the risk of programmer error during modification
>> and/or cut-n-paste.
>>
>>
>> On Wed, Feb 17, 2016 at 2:28 PM, James Fuller <jim@webcomposite.com> wrote:
>>> Thanks, I feel like I more clearly understand the issue.
>>>
>>> If there is a primary input then I would expect the context of the
>>> expr to be that (I repeat myself). Most steps will have a primary
>>> input and output, so for the simple case the following could 'just
>>> work':
>>>
>>> $in → { if (./doc/cheese='cheddar')
>>>             then consume()
>>>             else reject() }
>>> ≫ $out
>>>
>>> Where we assume that 'what you see is what you mean'.
>>>
>>> If there is no primary input then the default context is ().
>>>
>>> If there is no primary output then we could throw an error on >>$out
>>> or set that to ().
>>>
>>> In the case of more inputs and outputs, I like your idea of naming
>>> (and typing) them:
>>>
>>> $in → ([$source,$someothersource],[$result,$someotheroutput]){
>>>              if ($source/doc/cheese='cheddar')
>>>              then consume() >>$result
>>>              else reject() >> $result }
>>> ≫ $out
>>>
>>> taking our canonical example we get:
>>>
>>> xproc version = "2.0";
>>>
>>> inputs $source as document-node();
>>> outputs $result as document-node();
>>>
>>> $source → ([$source],[$result]){ if (xs:decimal($source/*/@version) < 2.0)
>>>             then [$source,"v1schema.xsd"] → validate-with-xml-schema() ≫ $result
>>>             else [$source,"v2schema.xsd"] → validate-with-xml-schema()
>>> ≫ $result}
>>>         → [$source,"stylesheet.xsl"] → xslt()
>>> ≫ $result
>>>
>>> where ordinal 1 input and output are primary.
>>>
>>> ------------- beware, veering off into syntax vortex -----------
>>>
>>> probably best to ignore these suggestions but thought I would offer them
>>>
>>> * can we use pre and post [] for inputs and outputs
>>> * use ? to get ordinal of that input/output
>>> * get rid of arrow operator
>>>
>>> xproc version = "2.0";
>>>
>>> inputs $source as document-node();
>>> outputs $result as document-node();
>>>
>>> $source → [$source]{ if (xs:decimal($source/*/@version) < 2.0)
>>>             then [?,"v1schema.xsd"] validate-with-xml-schema()
>>>             else [?,"v2schema.xsd"] validate-with-xml-schema()
>>>             }[$result]
>>>         → [?,"stylesheet.xsl"] xslt()
>>> ≫ $result
>>>
>>> On 13 February 2016 at 14:57, Alex Miłowski <alex@milowski.com> wrote:
>>>> I think it needs to be a pair:
>>>>
>>>> ([$source],[$result]) { ... }
>>>>
>>>> If you omit it, you get the declaration "([$source],[$result])" as default.
>>>>
>>>> If you want no inputs or outputs, we'll need a placeholder (e.g., '_')
>>>>
>>>> So, a document generator would be declared as:
>>>>
>>>> (_,[$result as document-node()]){ ("d1.xml","d2.xml","d3.xml') ≫ $result }
>>>>
>>>> The addition of keywords would make it more verbose but it is an
>>>> alternative that does not require a placeholder:
>>>>
>>>> inputs $source outputs $result { ... }
>>>>
>>>> and the generator example:
>>>>
>>>> outputs $result as document-node() { ("d1.xml","d2.xml","d3.xml') ≫ $result }
>>>>
>>>>
>>>> On Fri, Feb 12, 2016 at 4:09 PM, Alex Miłowski <alex@milowski.com> wrote:
>>>>> We have the problem in the block expression that @1 is the output port
>>>>> and $1 is the input.  Everywhere else, we use variables for outputs
>>>>> (i.e., the right hand side of an append) and then to refer to their
>>>>> use as inputs.
>>>>>
>>>>> Keep in mind that inputs are always references to some outputs - even
>>>>> the ones declared as inputs to the overall flow.  We still have the
>>>>> confusing bits that inputs to the pipeline are readable outputs within
>>>>> the flow.
>>>>>
>>>>> Meanwhile, if we could name the inputs, the collision between $1 on
>>>>> the right hand side within a block expression would be removed.
>>>>> Syntax aside, we could just require block expressions to name the
>>>>> inputs:
>>>>>
>>>>> $in → [source]
>>>>>           { if ($source/doc/cheese='cheddar')
>>>>>             then consume() ≫ $1
>>>>>             else reject() ≫ $1 }
>>>>>        ≫ $out
>>>>>
>>>>> that would allow anonymous outputs as ordinals.
>>>>>
>>>>> $in → [source]
>>>>>           { if ($source/doc/cheese='cheddar')
>>>>>             then consume() ≫ $1
>>>>>             else reject() ≫ $1 }
>>>>>        ≫ $out
>>>>>
>>>>> Please keep in mind that I'm working more on the conceptual level and
>>>>> the syntax is something we'll need to decide later.  So, the issues
>>>>> are:
>>>>>
>>>>> 1. Do we have ordinal inputs and outputs?
>>>>>
>>>>> 2. Do we require users to name inputs to block expressions?  Is there
>>>>> a default name if they don't?
>>>>>
>>>>> 3. Do we require users to name outputs at all?
>>>>>
>>>>>
>>>>> So, we could say names default:
>>>>>
>>>>> $in → { if ($source/doc/cheese='cheddar')
>>>>>             then consume() ≫ $result
>>>>>             else reject() ≫ $result }
>>>>>        ≫ $out
>>>>>
>>>>> --
>>>>> --Alex Miłowski
>>>>> "The excellence of grammar as a guide is proportional to the paucity of the
>>>>> inflexions, i.e. to the degree of analysis effected by the language
>>>>> considered."
>>>>>
>>>>> Bertrand Russell in a footnote of Principles of Mathematics
>>>>
>>>>
>>>>
>>>> --
>>>> --Alex Miłowski
>>>> "The excellence of grammar as a guide is proportional to the paucity of the
>>>> inflexions, i.e. to the degree of analysis effected by the language
>>>> considered."
>>>>
>>>> Bertrand Russell in a footnote of Principles of Mathematics
>>>>
>>
>>
>>
>> --
>> --Alex Miłowski
>> "The excellence of grammar as a guide is proportional to the paucity of the
>> inflexions, i.e. to the degree of analysis effected by the language
>> considered."
>>
>> Bertrand Russell in a footnote of Principles of Mathematics
>>



-- 
--Alex Miłowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics

Received on Thursday, 18 February 2016 23:54:07 UTC