[Versa] statements function

[Uche Ogbuji]

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.


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