Re: [Scheme-reports] Question about R6RS standard-{input, output, error}-port

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 <per@x> 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
per@x http://per.bothner.com/

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports

--
http://codeplex.com/IronScheme
http://xacc.wordpress.com