[Versa] first class functions

Michael Olson Mike.Olson at fourthought.com
Mon Sep 26 11:53:19 MDT 2005


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)


Also, I guess I see using a qname "magic" function call being used more  
in a query then function references.  For one thing, if we  
remove/"don't add" the new functions to support all of the different  
rdf/rdfs/owl properties then the fall back function approach we have  
been discussing will be used quite heavily.  Secondly, I see most  
function references will be for anonymous functions which avoid this  
issue.

With that, even though it is a functional language, I think we should  
add the "&" to a function reference.

Mike



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



More information about the Versa mailing list