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

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