This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: swing.scm
On 02/17/2011 11:29 AM, Jamison Hope wrote:
I suppose that would be one option, yes. Another would be to go the
Common Lisp route, and implicitly drop all but the first returned
value when the caller is expecting only one:
(list 1 2 (values 3 4) 5) => (1 2 3 5)
[And of course in CL, "(values)" in a context expecting a single value
evaluates to NIL, but #!void strikes me as more expressive.]
If #!void is the same as (values), then #!void can't be a single value.
In fact the Q2 language
(http://per.bothner.com/blog/2010/Q2-extensible-syntax/)
does this value-splicing.
Well, unless you introduce some compiler directives that let us change
languages mid-file, I think I'll stick to Scheme for now. ;-)
Q2 is hardly complete or stable enough for actual programming,
but I mention it to show some of my thinking in terms of programming
language design in the area of "multiple values" - if one was
unconstrained by compatibility. Some of those idea may show up
in Kawa-Scheme.
So I agree this could be very nice - but there are some awkward
consequences.
First, performance and type inference can be hurt because it becomes
harder
to match up argument expressions to formal parameters at compile-time.
OTOH
perhaps this isn't a big problem if it easy to determine which
expressions
always returns exactly one value.
That sounds like a reason to go the Common Lisp route and only take
the first return value.
Yes - though that route has its own problems, including too easily hiding
programming errors. Plus I don't think it's as expressive/useful.
Actually, I'm testing for #!void because I know that I'll either get
that or a valid menu item, but really the swing-gui menu function
just needs to test that arg is actually a JMenuItem before calling
(invoke menu 'add (as <javax.swing.JMenuItem> arg))
so maybe this would be a more agreeable patch without opening up the
multiple-values can of worms?
Index: gnu/kawa/slib/swing.scm
===================================================================
--- gnu/kawa/slib/swing.scm (revision 6900)
+++ gnu/kawa/slib/swing.scm (working copy)
@@ -136,9 +136,10 @@
(as <String>
((primitive-array-get <object>) args (+ i 1))))
(loop (+ i 2)))
- (else
+ ((<javax.swing.JMenuItem>? arg)
(invoke menu 'add (as <javax.swing.JMenuItem> arg))
- (loop (+ i 1)))))))
+ (loop (+ i 1)))
+ (else (loop (+ i 1)))))))
menu))
I really don't like the idea of silently ignoring values
that don't have the correct type.
In the case of (javax.swing.JMenu (unless #t mi1) mi2 mi3), right now
Kawa prints the warning
more than one possibly applicable method 'add' in javax.swing.JMenu
candidate: javax.swing.JMenuItem
javax.swing.JMenu.add(javax.swing.JMenuItem)
candidate: javax.swing.JMenuItem javax.swing.JMenu.add(javax.swing.Action)
candidate: void javax.swing.JMenu.add(java.awt.PopupMenu)
candidate: javax.swing.JMenuItem javax.swing.JMenu.add(java.lang.String)
candidate: java.awt.Component javax.swing.JMenu.add(java.awt.Component)
and then calls.. one of them, not sure which at the moment, but it results
in an unlabeled JMenuItem being added to the menu. It looks like it's
coercing to a String? That's what appears to happen for other random
non-JMenuItem objects.
I got lost trying to step through visitor.visit() to figure out where/how
the conversion to String takes place. Is that something special that
happens
since JMenu has an add(String) and all objects can be converted to one via
toString()?
Not sure - but usually that indicates that it defers overload resolution to
compile-time. You can tell by looking at the output from
--debug-print-final-expr.
--
--Per Bothner
per@bothner.com http://per.bothner.com/