Splicing lists and vectors into argument lists

[Per Bothner <per at bothner dot com>]

Please try out this new experimental Kawa feature:
The form '@EXPRESSION' (which is reader syntax
for ($splice$ EXPRESSION)) can be used in a
function application.  The EXPRESSION must evaluate
to a list or vector (more generally a java.util.List)
*or* a native Java array.  The effect is that each
element becomes a separate argument.

For example if lst is a list, then
  (fun x y @lst)
is the same as:
  (apply fun x y lst)

To sum the elements of list/vector/array lst, do:
  (+ @lst)

To concate vectors vec1 and vec2 separated by a single value x, do:
  [@vec1 x @vec2]

Splice notation isn't optimized much so far. If an application contains
a splice argument then we just create an array of the elements and
invoke the applyN method.  This means there is no function-specific
optimization.  Which also means if inlined compilation behaves
differently from run-time application you get the latter behavior.
(This can happen when resolving overloaded methods, for example.)

The plan is to do some optimization, starting with array/list
constructors.  Calling varargs methods can also be optimized: If all
the splice arguments correspond to a varargs array, then the compiler
should generate code to create the varargs array and then emit a regular
'invoke' instruction.

Right now Kawa follows Java when handling varargs, in that
you can optionally in the final argument pass an explicit array
which is treated as a varargs array.  This will be deprecated
soon, and ultimately disallowed.  E.g. the following is currently
allowed:
  (define args (object[] 4 5 6))
  (java.lang.String:format "<x: %s y: %s z: %s>" args) ; DEPRECATED
      ;; as equivalent to:
  (java.lang.String:format "<x: %s y: %s z: %s>" 4 5 6)
In the future this will have to be written:
  (java.lang.String:format "<x: %s y: %s z: %s>" @args)

Note that the syntax (@TYPE ARG ...) is also used for annotations.
That usage don't conflict for a number of reasons:
- The @TYPE syntax for an annotation is only allowed in function
call position, while a slice is *not* allowed in function call position.
- The "expression" following @ for an annotation must be a class or type,
while for a slice it must be a list/vector/array.
- Annotations are only supported in restricted contexts.

The old syntax (TYPE:@ VALUE) for coercions still works,
but deprecated.  Use (->TYPE VALUE) instead.

However, there is *some* compatibility breakage, since '@' no longer starts
a symbol.  Thus for example I had to quote |Q| in syntaxutils.scm.  This
macro could presumably be replaced by colon notation.

Finally: Don't use keyword values in the elements of splice.
This will soon stop working, but that is a topic for another email.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/