[Qexo-general] Re: Calling my own Kawa functions from Qexo

[Jocelyn Paine]

I've done some experiments. It seems that the Qexo symbol operator will,
when applied to the names of Kawa standard functions, return their values:
  {--72--} $"+"
   #<procedure +>
and
  {--73--} $"null?"
   #<procedure null?>

This allows me to call Kawa functions from Qexo when their names are not
valid Qexo identifiers:
  {--76--} apply( $"null?", list( list() ))
   true
  [The extra call to list() here is to make apply's argument into a list,
  as required by its spec. The call above is the equivalent of Kawa's 
  (apply null? (list)) . ]

And similarly
  {--78--} apply( $"+", list(1,2,3) )
   6

Qexo appears to detest non-primitive function-valued expressions in place
of a function name:
  {--79--} $"+"(1,2,3)
  <stdin>:79:6: missing ')' - saw  @:5
so you have to use apply or eval to get round that. (Not liking the item
in the function-name position to be other than an identifier is a common
failure to generalise in programming languages.)

The symbol operator fails to retrieve type and class values,
oddly:
  {--81--} $"<java.lang.String>"
  gnu.mapping.UnboundSymbol: Unbound symbol <java.lang.String>
even though (note switch to Kawa top-level):
  #|kawa:3|# <java.lang.String>
  ClassType java.lang.String

It also fails to recognise special lexical forms such as #!null, probably
not surprisingly.

So to call my own function make-term which I export from my own module
b7.mm3.general.Terms, how can I do it? I try loading the module via
  eval( list( $require, "<kb7.mm3.general.Terms>") )
but the effect is lost:
  {--60--} $make-term
  gnu.mapping.UnboundSymbol: Unbound symbol make-term
probably because eval does not affect the environment around it.

What does work is the less than convenient
  {--71--} invoke-static( "kb7.mm3.general.Terms", "make-term", "add", 
list(1,2) )
   address@hidden
  [where the list(1,2) packages up the two arguments expected by my
  make-term.]

But I presume that the Qexo compiler won't be able to do type analysis,
optimisation etc. on a call expressed like this. Are there any better
ways?

Oh, and by the way, we also have 'make' and 'invoke', as shown in Per's
Java One presentation:
  {--84--} invoke( make("java.util.Date"), "getYear" )
   102

Apologies if you all knew this, or if it's already documented somewhere.

Jocelyn Paine
http://www.ifs.org.uk/~popx/
+44 (0)7768 534 091