Re: Alternate syntax for field access/method calls

[Per Bothner <per at bothner dot com>]

Dominique Boucher wrote:
> Agreed. I also use namespaces a lot, as well as the latter technique (but
> not
> as often, since it's so verbose). But if my variables are already typed,
> it's a shame
> having to "type" the method calls too, 

I'm leary of "borrowing" square brackets for method calls.
One reason is some Scheme code uses it as equivalent to parens,
for clarity.  Also, BRL/KRL uses it for "anti-quotation",
and I'd like to have them available for alternative syntaxes.

Some alternative ideas:

(1) We have (ClName:method arg ...) for static method calls.
We could extend this to (*:method receiver arg ...) for
instance calls.  This would be syntactic sugar for
(invoke receiver 'method arg ...)

(2) Extend the 'dot' notation:
E.g.:
  (. someObject (method1) (method2 a b))
instead of Dominque's:
  [someObject (method1) (method2 a b)
This somewhat breaks compatibility, since currently (. foo)
is equivalent to foo.  However, this an extension not in R5RS
that few if anybody uses.  (It's just the logical extension
of (x1 x2 ... xn . rest) to the case n==0.)  It is even
possible to maintain compatibility since the new syntax
requires two or more forms after the dot, while the dotted
pair notation requies exactly one form after the dot.
However, the interaction between the reader and the "parser"
might be a little tricky.

(3) An even more radical extension of the dot notation:
  (someObject . (method1) . (method2 a b))
This is of course even trickier, since:
  (someObject . (method1))
is normally the same as:
  (someObject method1)
However, do note that the former is *not* a valid R5RS expression,
though it is a valid <datum> (i.e. external representation).
So it is possible to assign a different meaning to the two.
In Kawa, we use the class PairWithPosition for lists read
as form of an expression, for line number info, and so it would
be easy to add a bit indicating which of the two above forms
was read.  However, properly preserving that bit during macro
expansion and eval might be tricky - I haven't pondered it.

(4) We can define a default meaning to names that start with
dot, just as we define a default meaning to <name>.  Thus:
  (.method someObject args ...)
or even:
  (someObject .method args ...)
(We'd have to define ".method" as syntax rather than a predefined
identifier in the latter case.  Otherwise  we get into the morass
of infix operators, which I don't think would be a good idea.)

I think (1) is simplest and most elegant, though it doesn't
handle field accesses.

> Also, for classes defined using "define-simple-class", the namespace thing
> is not
> as convenient since I have to put the fully qualified name of the class, not
> simply the
> class name. So I have to write:
>
> (module-name <com.nuecho.mypackage.mymodule>)
> (define-simple-class <AClass> (<Object>) ...)
>
> (define-namespace classA <com.nuecho.mypackage.AClass>)

Thanks to work funded by Merced, you should now be able to do:

(define-name classA <AClass>)
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/