In some implementations like IronScheme and I think Chez, current-output-port and friends are defined as 'parameters'.
I think the reasoning here was that in case the current-xxx-port was parameterized or changed, some other part of the application could still get a default port in case something has changed on it (buffering, colors, etc). This again would just a be a fresh instance of the port, but not actually the underlying system file handle. This is how I see it being done on .NET (I would guess Java is similar). Cheers leppie On Sun, Nov 24, 2013 at 9:54 PM, Per Bothner <[email protected]> wrote: > This is an R6RS question, not R7RS - though it might be relevant for > future standards. > > R6RS specifies for (standard-output-port) and (standard-error-port) > that they: > > "Returns a fresh binary output port connected to > the standard output or standard error respectively." > > and similarly for (standard-input-port). > > Why a *fresh* port? When would it ever make sense to create > multiple distinct objects for (say) the standard output? > > This isn't purely an academic question: I just checked in changes > to Kawa so the initial values of (current-{output,error}-port) are > hybrid textual/binary ports. It is tempting to add Scheme access > to these ports using (standard-{output,error}-port), but I'm not > sure it would appropriate given that R6RS demands a fresh port > on each call. > -- > --Per Bothner > [email protected] http://per.bothner.com/ > > _______________________________________________ > Scheme-reports mailing list > [email protected] > http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports > -- http://codeplex.com/IronScheme http://xacc.wordpress.com
_______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
