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?
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/
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!