[Versa] Re: statements function

[Michael Olson]

>> If I recall correctly, what we'd discussed is that each argument to  
>> the
>> function can be a pattern or a predicate?  A list is a pattern by
>> enumeration?
>> But we lose some of the functional power of traversal expressions if  
>> so.
>>
>> type(rss:item) - ns:age -> gt(18)
>>
>> No way to express this in statements() form as discussed so far.  One
>> approach would be to have currying:
>
> Yes.  So, I guess my question is what is the motivation for having
> such a function if not only to account for the fact that traversal
> expressions currently only return statements parts and making them
> return statements instead would make the difference between forward
> traversal operators and forward traversal filters irrelevant as well
> as require functions to extract statements parts: subjects,
> predicates, objects, etc..
>

For me the motivation is that I like the current traverse and filter  
operators.  I like how, for a majority of the queries, it (the query)  
expresses a "graph query" just by looking at it. To me

all() - ns:type -> rdfs:Class

is very clear in meaning (when taken in the context of RDF).

So, I don't want to see these operators go (maybe their functional  
equivalents though as these are very redundant with the statements  
function)

>> I think this is a good time to bring up what I think is a need in  
>> Versa
>> for less clumsy first-class functions.
>
> I agree, that's the first critisicm I have about current Versa (too
> much reliance on functions where syntax constructs - such as boolean
> operators and such - are more readible and less messy)
>
>> filter(type(ns:Person), (!x: $x - ns:age -> gt(18))
>>
>> Basically
>>
>> anon-function ::= '(!' param-list ':' expr ')'
>
> I like that.  Honestly, mostly because I think *something* has to be
> done about the ugliness of having to escape expressions passed around
> as strings.

That sounds like "I like my brother because he is my brother and I have  
too" :)

Do you have an alternative?  What about python "lambda" syntax?

>
>>
>> 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.
>>
>> Then again, I recall Chime thought even named functions were  
>> confusing.
>> Chime, what about the above anonymous function idea?
>
> I really like it, because it opens up the door for the kinds of
> filtering you can express with functions such as filter / distribute
> (and statements, if it's arguments are treated in the same way) if
> they were allowed to work with anonymous functions instead of
> expressions passed around as strings.  Also, being able to define
> anonymous functions relieves the need to define or use too many
> first-class functions.
>

I agree.  Would distribute, map, etc then take only anon functions (and  
not sub queries as strings)?

> So, what would this require of the grammar and the way current
> functions work? Simply to allow anonymous functions to be arguments to
> functions and expand how filtering functions work to include the use
> of anonymous functions?
>

I'll take another swing at the grammar if no one objects.

Mike

> If the statements function was allowed to work this way , it would
> make a whole lot more useful than just a 'stand-in' to cover the
> current inability to create statements from traversal expressions.
> _______________________________________________
> 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