This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: swing.scm
On 02/16/2011 03:53 PM, Jamison Hope wrote:
Would you mind adding this check for #!void to the menu function in
swing.scm?
It would let me do things like this:
(menu label: "File"
...
(unless (mac-os-x?) (menuitem label: "Exit")))
I sympathize with the request, but I fear it would be a very ugly hack.
There are a number of complications.
Note in Kawa #!void is equivalent to (values). It is plausible reasonable
to define a #!void argument expression in a sequence as "no value" or
"skip this entry".
But that leads to the logical extension to allow multiple values:
(menu (values (menuitem label: "Exit") (menuitem label: "Quit")))
I.e. if an argument expression produces multiple values, then the
values should be spliced into the argument list, like an
implicit apply-with-values. (Somewhat like (begin a b) splices a and b
into a <body>.)
Of course this isn't very useful as written, but it can be very
useful if there is an expression that could evaluate to multiple values.
In fact the Q2 language
(http://per.bothner.com/blog/2010/Q2-extensible-syntax/)
does this value-splicing.
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.
Secondly, note that the model of
splicing-multiple-values-into-the-argument-list
is incompatible with testing whether a parameter is void - in the former
model,
all of the voids and multiple-values get elided before the apply happens.
Third, I'm considering similar functionality as part of a new
sequences/iteration
idea I'm working towards. It might require an explicit splicing
operation (to
make type inference easier and to make things more explicit and thus less
confusing). So I think it is best to not commit to changes in this area
until
my plans have gelled a bit more.
So I'm not saying no (I too would like something like what you're asking
for)
but I would like to put it off a bit.
--
--Per Bothner
per@bothner.com http://per.bothner.com/