[Versa] statements function

Michael Olson Mike.Olson at fourthought.com
Thu Sep 15 11:27:02 MDT 2005 

On Sep 15, 2005, at 10:57 AM, Uche Ogbuji wrote:

> On Tue, 2005-09-13 at 19:33 -0600, Michael Olson wrote:
>>>
>>>> Though you would be able to express it as
>>>>
>>>> statements( type (rss:item), ns:age, . > 18)
>>>
>>> I don't see how this would work.  Do you mean:
>>>
>>> statements( type (rss:item), ns:age, ". > 18")
>>>
>>
>> No, the quotes make it a constant.  Without quotes it is a filter
>> expression, which is a valid argument to a function call.
>
> I think this is odd semantics, and confusing.  Expressions as arguments
> to a function call are usually evaluated, with the results forming the
> argument.  I don't like having statements so radically different from
> other functions.  Besides, what if I really wanted to evaluate a filter
> expression and pass the result as an argument?  I'd be stuck, right?
>
> I think we need support for subexpressions in the syntax, not in magic
> function semantics.

>
>> Just like it works with
>>
>> type(rss:item) - ns:stage -> . > 18
>>
>> the . > 18 portion is evaluated once per result statement.
>
> This is syntax-level support.  I think your function invocation example
> is a very different beast, and one I'm not comfortable with.
>

I guess I don't see the difference.  In my mind

x - y -> z

should be directly translated into
filter(x,y,z)

with the same results.

If not, then I think that having a function called "filter" may be what  
is confusing.

I know I would have assumed in V-1.0 that the above was the case.

Maybe we call it "almost-filter()" :)

Seriously, I think the function should go away.  I imagine it was there  
so that you could "filter" in places where the grammar did not support  
a filter.  Now with variable definitions and a more expansive grammar I  
don't think it is needed.

We still have the same problems with the "statement" function though.

Mike


>
>>>>> Basically
>>>>>
>>>>> anon-function ::= '(!' param-list ':' expr ')'
>>>>>
>>>>> Or to give an example using the statements function:
>>>>>
>>>>> statements(type(rss:item), dc:creator, (!x: $x - ns:age -> gt(18))
>>>>>
>>>>> I prefer naming the parameter (functional macro-like) rather than
>>>>> using
>>>>> the magic "." particle.  We also then get the flexibility of
>>>>> functions
>>>>> with multiple parameters, etc.
>>>>
>>>> I like this better then currying, though I don't see how you would
>>>> specify an anon function with more then one parameter.  Maybe
>>>>
>>>> ( !x = ., !y = "foo" :  $x - ns:age -> gt($y)
>>>>
>>>> and the default of (!x : query) would default "x" to the current
>>>> context.
>>>
>>> Well, based on the grammar snippet above:
>>>
>>> anon-function ::= '(!' param-list ':' expr ')'
>>>
>>> You wouldn't have a ! in front of each parameter.  For 2 parameters:
>>>
>>> (! x, y:  $x - ns:age -> gt($y))
>>>
>>> You're right that I haven't accounted for a syntax for "defaulting" a
>>> parameter, but considering that anon functions will probably only be
>>> passed in at the spot they're used, is this such a big deal?
>>>
>>> What I mean is that in every spot you might want to type
>>>
>>> (! x, y=18:  $x - ns:age -> gt($y))
>>>
>>> Wouldn't you already know well enough to just write
>>>
>>> (! x:  $x - ns:age -> gt(18))
>>>
>>
>> Only if it was a constant, like 18.  What if it is the results of a  
>> sub
>> query?
>>
>> (!x,y = all() - rdf:type -> rdfs:Class : $y - rdfs:subClassOf -> * |
>> all() - rdfs:subClassOf -> $y)
>
> I still don't get it.  For the above example I'd write
>
> (!x: $x - rdfs:subClassOf -> * |   all() - rdfs:subClassOf -> (all() -
> rdf:type -> rdfs:Class))
>
> I'm assuming that in your first $y you meant $x?
>
>>> When I was talking about multiple parameters, I honestly didn't have  
>>> a
>>> use case for it, but I guess I should think that through as part of
>>> this
>>> whole exercise.
>>>
>>> I did consider that if you did want to do such things as defaulting
>>> functions, you could go back to the state (formerly known as
>>> context? :-) ) operations we've been discussing:
>>>
>>> @def f(x, y=18): $x - ns:age -> gt($y)
>>>
>>
>> Right, and maybe this is the case for multi params and anon-functions
>> just take a single argument, dot, and are soley used to clean up
>> quotes.  I'm OK with that.
>
> Perhaps.  I would like to continue the exploration above, though, just
> to be sure I'm not missing anything.  I agree that we could cover at
> least 80% of the cases with
>
> (! . - ns:age -> gt(18) )
>
> or
>
> { . - ns:age -> gt(18) }
>
> So I do agree that's probably where we'll end up.
>
>>>> In the current grammar, I supported something similar to this with  
>>>> the
>>>> reuse of the "{}" symbols.  It just did not support parameters.
>>>
>>> OK.  I kind of wondered whether these two uses were compatible, but I
>>> wasn't sure, so I went with new symbols.  Maybe we should generalize  
>>> {}
>>> a bit and also use it for the anon funct syntax:
>>>
>>> {x: $x - ns:age -> gt(18)}
>>>
>>
>> I'm OK with either.  However if anon-functions are going to always be
>> single parameter, and the parameter value is always DOT, then I think
>> it should just be DOT.
>
> Perhaps (likely), as I say above.
>
>
> --  
> Uche Ogbuji                               Fourthought, Inc.
> http://uche.ogbuji.net                    http://fourthought.com
> http://copia.ogbuji.net                   http://4Suite.org
> Use CSS to display XML, part 2 -  
> http://www-128.ibm.com/developerworks/edu/x-dw-x-xmlcss2-i.html
> XML Output with 4Suite & Amara -  
> http://www.xml.com/pub/a/2005/04/20/py-xml.html
> Use XSLT to prepare XML for import into OpenOffice Calc -  
> http://www.ibm.com/developerworks/xml/library/x-oocalc/
> Schema standardization for top-down semantic transparency -  
> http://www-128.ibm.com/developerworks/xml/library/x-think31.html
>
> _______________________________________________
> Versa mailing list
> Versa at lists.fourthought.com
> http://lists.fourthought.com/mailman/listinfo/versa
>
------------------------------------------------------------------------ 
-----------------
Mike Olson                                                Principal  
Consultant
mike.olson at fourthought.com                +1 720 253 4662
Fourthought, Inc.                                       
http://Fourthought.com
PO Box 270590,                                       http://4Suite.org
Louisville, CO 80027-5009, USA
XML strategy, XML tools, knowledge management

More information about the Versa mailing list