[Versa] statements function

[Uche Ogbuji]

On Thu, 2005-09-15 at 11:27 -0600, Michael Olson wrote:
> 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.

Not to me.  Many languages have syntax level support that is similar to
functional equivalents.  They don't mangle function semantics just to
have the syntactic variant exactly correspond to the function variant in
some strange way.

Python, for example, has list comprehensions that are syntax level, and
thus have special semantics.  There are also the map and filter
functions, which have regular function semantics.  There was never a
call to mangle map and filter function semantics just so that they could
correspond to list comprehensions.  People just understand that they are
different.

Same in Versa ~1.0.  traversal expressions are different from functions
such as traverse and filter, and I've never had trouble explaining the
difference (the difference is even mentioned in the spec).

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

I don't think so.  There are different ways of "filter"ing something.
They don't all have to be in lockstep.

I wouldn't fight a change of name from "filter expression" to "predicate
expression" or such like, but I don't think it's necessary.  "filter
expression" and "filter function" make perfect sense to me as different
things with somewhat different behavior.

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

No.  Never was.  And never was implemented that way, for sure.  FWIW,
the difference came up when the rdflib folks were looking to implement
Versa for rdflib, and no one had any trouble with it.


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

No need.


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

Maybe it could go away, but I wouldn't be in a hurry to get rid of it.
Maybe if someone comes up with a convincing set of examples, and
demonstrates that it's no longer necessary for Versa 2.0...


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

I don't think we should play games with argument-passing semantics for
any function.  All function invocations should evaluate the expression
provided for the argument, and pass the result.


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