Re: Adjusting Syntax & Semantics - removing the need for port variables, block expressions, and other declarations

apologies for the delay - I found it hard to enumerate and keep track
of this (and the previous thread) and wanted to try and understand
things before commenting.

If we go back to our simplifying assumptions eg. model 'everything as
a step' it might mean we can defer sticky syntax decisions for now.

This means that logic branching and block construction could be
represented as a step for now and then I absolutely agree that its a
good time to discuss flow declarations.

Going back to Norm's previous example

xproc version = "2.0";
inputs  $source as document-node();
outputs $result as document-node();
options $minver as xs:decimal := 2.0,
        $v1schema := "v1schema.xsd",
        $v2schema := "v2schema.xsd";

[$source] → λ($vertest as xs:decimal := $minver,
              $v1 as xs:string := $v1schema,
              $v2 as xs:string := $v2schema)
            [$in;$out]
            { if (xs:decimal($in/*/@version) < $vertest)
                            then [$in,$v1] → validate-with-xml-schema() ≫ $out
                            else [$in,$v2] → validate-with-xml-schema() ≫ $out }
          → [$out,"stylesheet.xsl"] → xslt()
≫ $result

I think the anonymous flow satisfies the 'everything is a step' trajectory where

     λ()[]{ ..... }

could also do

   function()[]{....}

and a named function decl follows

 declare my:flow()[]{.......}

As a prototype I think this is a pretty good default position and lets
us move onto block and logic armed with a powerful idiom.

Sorry that I was late to the party coming to this conclusion.

J


On 20 April 2016 at 15:14, Norman Walsh <ndw@nwalsh.com> wrote:
> Alex Miłowski <alex@milowski.com> writes:
>> On Tue, Apr 19, 2016 at 5:33 PM, Norman Walsh <ndw@nwalsh.com> wrote:
>>> Alex Miłowski <alex@milowski.com> writes:
>>>> Here are some random and possibly radical thoughts ...
>>>> 1. The condition operates on the current readable port (and whatever
>>>> is lexically in scope).
>>>
>>> Do we still have a “current readable port”? I thought we had a set of
>>> ports that came from the preceding step or port set expression.
>>
>> We have "current - readable ports" ... plural.  Section 4.3 that we
>> reviewed last week uses that term in a few places but in the sense of
>> "there is currently a set of readable ports" at a particular position
>> in a chain sequence.
>
> Ok. That makes sense. It was your use of the singular in point 1 that
> confused me.
>
>>>>        then [schema="v1schema.xsd"] → validate-with-xml-schema()
>>>
>>> I don’t understand this at all. I could understand
>>>
>>>          then [$source, schema="v1schema.xsd"] → validate-with-xml-schema()
>>
>> It should be:
>>
>> $source
>>   → if (xs:decimal($source/*/@version) < 2.0)
>>       then [port(), schema="v1schema.xsd"] → validate-with-xml-schema()
>>       else [port(), schema="v2schema.xsd"] → validate-with-xml-schema()
>
> Ok. I can understand that.
>
>>>> source
>>>>   → if (xs:decimal(/*/@version) < 2.0)
>>>
>>> Ok. I think I see. But just to be clear, I could still do this if
>>> I wanted to, right?
>>>
>>>   source >> $src
>>>   source -> if (xs:decimal($src/*/@version) …
>>
>> Yes, assuming we have a way to make in-scope variable and expression
>> all work together.
>
> I don’t think the language works without that ability.
>
>>>>        then [schema="v1schema.xsd"] → validate-with-xml-schema()
>>>
>>> But I still really, really don’t understand how the default context is
>>> implicitly being inserted into the port bindings for
>>> validate-with-xml-schema(). What’s more, I don’t think you necessarily
>>> always want it to be the first one. What if what was being passed in
>>> was the schema and what varied was the document that I wanted to
>>> parse?
>>
>> You seem to be stuck on the expression language problem.  I am
>
> No, I was stuck on the missing “port()” in the example :-)
>
>>>> # No Options
>>>>
>>>> Because we have no pipeline declaration, if you want options, you need
>>>> to wrap things in a flow:
>>>>
>>>> xproc version = "2.0";
>>>>
>>>> [ source : document-node() ] flow($mode : xs:string = '') [ result :
>>>> document-node() ]
>>>> {
>>>> source
>>>>   → if (xs:decimal(/*/@version) < 2.0)
>>>>        then [schema="v1schema.xsd"] → validate-with-xml-schema()
>>>>        else [schema="v2schema.xsd"] → validate-with-xml-schema()
>>>>   → [port(),"stylesheet.xsl"]
>>>>   → xslt(mode=$mode)
>>>>   ≫ result
>>>> }
>>>>
>>>> Now an implementation needs a parameter to invoke the flow.  This also
>>>> presumes it would pick the last flow.
>>>
>>> Uuuuuhhhmmmmm. I see the mathematical elegance, but I’m not sure it’s
>>> exactly user friendly.
>>
>> It isn't about elegance.  Options at the top-level are exactly like
>> parameters to flows.  If you need top-level options, then we should
>> re-use an existing mechanism rather than have two of them.
>
> I see your point, but I think that’s pushing a lot of complexity on the
> author for what the author is likely to view as something very simple.
>
>>> and, for example,
>>>
>>>    [ source : document-node(); result : document-node()]
>>>    flow($mode : xs:string = '') { … }
>>>
>>> I find the former more of a challenge.
>>
>> That semicolon makes it look like a syntax error.  We've been using
>> semicolons as a delimiter for "end of a declaration".
>
> Fair enough. Pick a different delimiter? The point I was trying to make
> was about the large scale aesthetics of “[] my:flow() [] {}”
> vs “[] my:flow() { }”.
>
>>>>    [ ] → flow(...) → []
>>>
>>> That strikes me as potentially confusing. It’s just too easy to read
>>> that as some kind of flow in parenthesis. Maybe a different delimiter:
>>>
>>>      [ ] :: flow(...) :: []
>>
>> I could live with double colons but that is a new delimiter.  I find
>> re-use of the arrow easier.
>
> Okaaaay. I’m probably not going to lie down in the road over the choice
> of delimiters, but do you see my point:
>
>   [portsetexpr] -> step() -> [pse] -> step() >> output
>   ([portsetexpr] -> flow() -> [pse]) {
>     …
>   }
>
> The visual distinction between those two quite different things is
> awfully subtle to me.
>
>                                         Be seeing you,
>                                           norm
>
> --
> Norman Walsh
> Lead Engineer
> MarkLogic Corporation
> Phone: +1 512 761 6676
> www.marklogic.com

Received on Wednesday, 20 April 2016 19:33:31 UTC