Type information seems to be erased in macros

Type information seems to be erased in macros

[Panicz Maciej Godek]

Hi,
I have defined a macro:

(define-syntax-rule (with-translation screen (x y) . actions)
  (let ((x! x)
        (y! y))
    (screen:translate! x! y!)
    (let ((result (begin . actions)))
      (screen:translate! (- x!) (- y!))
      result)))

which (presumably) operates on Screen interface, which provides translate!
method.

I use it in a context which makes it clear that the type of the first
argument passed to with-translation is Screen:

(define (draw! object #!optional (screen::Screen (current-screen)))::Extent
  ...
  (with-translation screen (left top) ...)
  ...)

However, when I import (to the REPL) a module containing this code, I get
the following complaint near the use of the with-translation macro:

warning - no known slot 'translate!' in java.lang.Object

Does the macro system erase type information from objects?

If I add explicit casts in the macro, is it likely to cause some
performance penalty?

Re: Type information seems to be erased in macros

[Per Bothner]

On 12/29/21 14:12, Panicz Maciej Godek via Kawa wrote:
> Does the macro system erase type information from objects?

Not in general, but it is possible that a compond name
like screen:translate! might not survive the macro-expansion process.

The --debug-print-expr flag may be useful to see what is happening.
It prints out the syntax tree after name lookup and macro-expansion,
but before type analysts and optimizations.

It you post a short self-contained program I can take a look.

There is a good chance you might have better luck with:

     (invoke screen 'translate! x! y!)

That should avoid any issues with compound symbols.

> If I add explicit casts in the macro, is it likely to cause some
> performance penalty?

Almost certainly nothing you'd notice: Probably just an extra checkcast
instruction in the bytecode.  Which means some extra work, but pretty minor.

If end up needing run-time reflection (which is what you get if
you ignore the warning), that is a lot more expensive.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: Type information seems to be erased in macros

[Panicz Maciej Godek]

Hi! Thanks for quick reply!

czw., 30 gru 2021 o 00:30 Per Bothner <per@bothner.com> napisał(a):

>
>
> On 12/29/21 14:12, Panicz Maciej Godek via Kawa wrote:
> > Does the macro system erase type information from objects?
>
> Not in general, but it is possible that a compond name
> like screen:translate! might not survive the macro-expansion process.
>
> The --debug-print-expr flag may be useful to see what is happening.
> It prints out the syntax tree after name lookup and macro-expansion,
> but before type analysts and optimizations.
>
> It you post a short self-contained program I can take a look.
>
> Actually, this turned out to be a trivial mistake on my part -- the name
"screen" wasn't visible as I thought it was.


> There is a good chance you might have better luck with:
>
>      (invoke screen 'translate! x! y!)
>
> That should avoid any issues with compound symbols.
>
> > If I add explicit casts in the macro, is it likely to cause some
> > performance penalty?
>
> Almost certainly nothing you'd notice: Probably just an extra checkcast
> instruction in the bytecode.  Which means some extra work, but pretty
> minor.
>
> If end up needing run-time reflection (which is what you get if
> you ignore the warning), that is a lot more expensive.
>
>
Thanks, that's good to know!

BTW I've been working on a touch-based Scheme editor for Android called
GRASP, and I managed
to hook up Kawa to it, which gave a nice effect:

https://www.youtube.com/watch?v=oOHg74HYau4

I also gave an overview of GRASP during this year's Scheme Workshop (before
integrating with Kawa)

https://www.youtube.com/watch?v=FlOghAlCDA4

The source is available here (the structure of the repo is a bit tricky, so
I can explain it if anyone's interested)

https://github.com/panicz/grasp-android

Currently, I am in the process of rewriting GRASP to Kawa, because I find
it much more comfortable to program in.

Thanks again!