[racket-dev] current-*-port

From: David T. Pierson (dtp at mindstory.com)
Date: Thu May 3 23:34:31 EDT 2012

On Thu, May 03, 2012 at 03:48:17PM -0400, Eli Barzilay wrote:
> With the trend of having shorter names, I'll try suggesting it again.
> Looking at some random slides (the ones from Matthew's talk), one
> thing that is -- still -- very strikingly inconvenient is code like
>   (parameterize ([current-error-port (current-output-port)])
>     ...)
> IMO, anyone who is not coming from some kind of Scheme background
> would view this as ridiculously long.  If they're renamed to the usual
> names, things look much better:
>   (parameterize ([stderr (stdout)])

My first thought is that the names current-error-port and stderr suggest
different concepts.

stderr is the standard error stream corresponding to POSIX file
descriptor 2.

current-error-port is an abstraction mechanism that allows you to
control where error messages are directed.

If stderr were to be bound in #lang racket, based on the above I'd
expect it to be bound to a port corresponding to the standard error
stream, not bound to a parameter controlling which port error messages
go to.

I realize such a stderr binding would not be particularly useful for
most Racket programs, so I'm not advocating having such a binding. I'm
just saying the name "stderr" implies something different than
"current-error-port", that "current-error-port" better denotes the
purpose of the parameter, and that in this case I like the more accurate
name is better than the short name.  If parameterize forms like your
example are the main motivation, perhaps a new function or syntax would
be more to the point?  e.g. something called with-errors-to-output...

Also, I see that these names appear to already be available as proposed
via the preprocessor/mzpp and preprocessor/mztext modules.

Finally, It occurs to me that this is the second time in several weeks
I'm responding to a thread about changing names.  Hopefully my comments
are thoughtful and not just reactionary.


Posted on the dev mailing list.