[Versa] Re: statements function

[Chimezie Ogbuji]

> I think I lost track somewhere.  Why put a traversal expression within
> the statements function?  Why not just
> 
> statements(type(rss:item), dc:creator, <mailto:foo at yahoo.com>)

That's what I had in mind originally, but I wasn't quite clear on how
the proposed function would work or how to account for the redundancy
it introduces (since most of what you would need it for would be
accounted for completely by traversal expressions, but traversal
expressions return statements parts not statements).
 
> 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..
 
> 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.

> 
> 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.

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?

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.