[Versa] first class functions

[Uche Ogbuji]

On Mon, 2005-09-26 at 11:53 -0600, Michael Olson wrote:
> On Sep 26, 2005, at 11:28 AM, Uche Ogbuji wrote:
> 
> > On Mon, 2005-09-26 at 11:14 -0600, Michael Olson wrote:
> >> On Sep 26, 2005, at 11:09 AM, Jeremy Kloth wrote:
> >>
> >>> On Monday 26 September 2005 11:04 am, Michael Olson wrote:
> >>>>> I see them being differentiated by bindings alone.  If the qname  
> >>>>> (in
> >>>>> expanded
> >>>>> form) is bound to a function where a function-reference is allowed,
> >>>>> use it.
> >>>>> There may be other issues I'm missing, but this doesn't seem
> >>>>> difficult
> >>>>> for an
> >>>>> implementation to do.
> >>>>
> >>>> There is, because "rdf:type(all())" is a valid function call.  We
> >>>> discussed it on some thread on the list, but basically it translates
> >>>> to
> >>>> a traverse expression of all() - rdf:type -> *.  So, in the case of
> >>>> rdf:type it is _always_ a bound function call, and it is always a
> >>>> valid
> >>>> qname-constant.
> >>>>
> >>>> It would even be valid not in the special case as a function can
> >>>> always
> >>>> be defined with a qname, and can always conflict with a
> >>>> qname-constant.
> >>>>
> >>>> @function ext:name = all();
> >>>> list (ext:name)
> >>>
> >>> So, you are saying a *function-reference* is a valid input to the  
> >>> list
> >>> function?
> >>>
> >>
> >> If a "function-reference" is a first class datatype, then from a
> >> grammars point of view it is.  It would return
> >>
> >> [ ext:name ]
> >>
> >> as a results which could then be passed to a different function the
> >> expects a list of function references, ie distribute() could
> >> conceivably take a list of function references as an argument.
> >
> > Yes, and I see the problem Mike's illustrating.  However, I still
> > advocate the opposite disambiguation:
> >
> > http://lists.fourthought.com/pipermail/versa/2005-September/000221.html
> >
> > To me, interpretation of a qname resource as a function is more magic
> > than first-class functions (after all, Versa is intended to have a lot
> > of the character of a functional language), so I'd rather put the
> > greater syntax where the greater magic is.
> 
> So just to make sure I'm clear on all of the use cases
> 
> a)  rdf:type     :== a qname-constant, always
> b)  @rdf:type(all())  :== is short hand for "all() - rdf:type -> *"
> c)  @rdf:type :== a reference to the above function
> d)  function_name(all()) :== a call to the function "function_name"
> e)  function_name :== a reference to the function "function_name"
> 
> If so, we still cannot differentiate between a and e which is the core  
> of my argument (regardless of whether or not the function being  
> referenced is a fallback function or a defined function)

OK.  Thanks for the elaboration.  It cleared up my thinking, too.  I
agree with the necessity, which, as Jeremy pointed out, is as ugly as
requiring $ for variable names in XPath.  I'll just have to get used to
that as well.

I still prefer '@' to '&' for function reference marker:

a)  rdf:type     :== a qname-constant, always
b)  rdf:type(all())  :== is short hand for "all() - rdf:type -> *"
c)  @rdf:type :== a reference to the above function
d)  function_name(all()) :== a call to the function "function_name"
e)  @function_name :== a reference to the function "function_name"


-- 
Uche Ogbuji                               Fourthought, Inc.
http://uche.ogbuji.net                    http://fourthought.com
http://copia.ogbuji.net                   http://4Suite.org
Articles: http://uche.ogbuji.net/tech/publications/