Hi list,
Mark Weaver writes in to say that his mail server crashed. The heavens
conspire against us! I'm mailing the list and bccing Mark at his
webmail (in case he is concerned about it leaking into the archives).
So this mail is really to Mark.
***
Very sorry to hear of your filesystem disasters! It never happens at a
convenient time, does it? Best of luck in pulling things together
again.
Indeed, I was reading too fast, and I guess I swallowed the second
paragraph without chewing ;) You are right, I had not considered all of
the ramifications.
I think that if I were fully reconciled to having values objects in our
API I would have no qualms with applying your patches. As it is, it
would make sense if the quotient and remainder operators were
implemented in terms of the division operators, but there are
performance problems there if we shunt things through value objects.
I am primarily concerned with the amount of work maintaining this
(excellent!) code will cause in the future. If it could be smaller
while exhibiting the same functionality and good performance that would
be great. Also, if we had an API which returned values in SCM*
arguments would be more amenable for use in the VM.
But, that's not possible now. I am just wondering if there is a
sensible way to make some kind of infrastructure investment here -- a
scm_c_call_with_n_values (SCM proc, size_t nargs, size_t nvals, SCM
*vals, SCM arg0...) that would remove the distortion that performance
concerns make on the structure of our code.
Even given all this, it might still be the right thing to do to apply
these patches, but I would like to hold off, pending Wednesday's 2.0
release. I am sorry that I am objecting to your code because of a
problem in Guile itself, but there it is.
Thanks again for your work; I hope we can reach the more perfect scheme
implementation that we dream of :) And good luck with that mail
server...
Peace,
Andy
On Sat 12 Feb 2011 20:00, Mark Weaver writes:
> Regarding your suggestion that I make versions of _divide that return
> two values via output arguments: please re-read my post. I talked
> about how I had originally started to do that, but found that it opened
> up a whole new can of worms, regarding what to do when I have to
> dispatch into GOOPS. Basically, all those calls to SCM_WTA_DISPATCH_2
> return a values object directly to the caller. We'd need to write
> new versions of those macros that unpack the values object and return
> the components via the output parameters. I'm not saying that it
> can't be done, and certainly it _should_ be done, but until we have better
> support for handling of multiple values from C, it's going to
> be a mess.
>
>
> Best,
> Mark
--
http://wingolog.org/
