This is the mail archive of the kawa@sourceware.org mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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/



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]