Re: Mixing reproducible and non-reproducible code
> Date: Sat, 01 Dec 2012 19:25:19 -0500
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> From: Michel Hack <mhack@xxxxxxx>
> Subject: Mixing reproducible and non-reproducible code
Perhaps I'm missing something here.
Just what IS "non-reproducible code"?
And why are we considering it?
Much less defining it?
And, CAN one define it?
Just curious... :-)
Dan
>
> As usual, trying to be specific about reproducibility raises various
> tricky issues. I'm referring now to clause 1.8 item (8) in John's
> 20121130Clauses1-2forVote.pdf, currently under discussion.
>
> In my earlier comments I wrote:
> > 1.8 item (8): This needs to be qualified. It might be necessary to
> > invoke a "reproducible transformation unit" though a wrapping
> > interface ("glue module") to incorporate it in a non-reproducible
> > environment, as the level 3 representations might differ.
>
> There may be more at stake than representation issues. Reproducible mode
> may affect global properties, such as forcing single-threaded execution.
> So what do we expect to happen when modes are mixed?
>
> (1) The interface module could force single-threaded execution while the
> reproducible-mode component is running. Is that generally feasible?
>
> (2) The reproducibility properties of the reproducible-mode component
> could be voided, as basic assumptions of that mode don't pertain.
>
> I understand the motivations behind requirement (8): one would like to
> be able to debug components in reproducible mode, and then incorporate
> the debugged code in a larger program. But given that reproducible mode
> typically requires a number of programming rules to be obeyed, validation
> in reproducible mode becomes meaningless unless those restrictions are
> maintained. That may be ok if the effect is relatively small when not
> actually running in reproducible mode, but if it involves re-partitioning
> for single-threaded execution this may not be so.
>
> Michel.
> ---Sent: 2012-12-02 00:46:30 UTC