Re: [Chicken-users] with-*-*-port

[felix]

Joerg F. Wittenberger wrote:
> > What about
> >
> > (current-input-port <PORT>)
> >
> > ?
> >
> > It may be questionable (from a language lawyerly point of view), but
> > it's pretty handy...
>
>
> Really bad practice.  (Said with bitter sound from 20 year of
> experience. ;-)

Oh. But it does interact nicely with `parameterize', though.
Conceptually I see `current-input-port' as a parameter
(And PLT actually defines it as one. And SRFI-39 does in fact
require it to be a parameter).

But, to be frank, I don't really try to make a statement
about "the right way" of coding practice. I leave that to
the users. If one finds it useful, use it. If one finds it
offensive, then don't use it.

> Sorry, this was actually not the main argument.  I argue against
> error _correction_ code.  People have a tendency to rely on it.  They
> would assign to global variables...  Hell would break loose.

So we don't tell them about ##sys#standard-input and make
sure the other forms can handle `(current-input-port X)'.
Everything is under control.

> Still, I might be wrong altogether, but if I'm right, then we should
> at most have error _detection_ code like this:
>
> (define with-input-from-port
>   (let ((values values))
>     (lambda (inner thunk)
>       (let ((outer '*))
>         (##sys#dynamic-wind
>          (lambda ()
>            (set! outer ##sys#standard-input)
>            (set! ##sys#standard-input inner))
>          thunk
>          (lambda ()
>            (unless (eq? inner ##sys#standard-input)
>                    (error "bad code broke the program"))
>            (set! ##sys#standard-input outer)))))))
>
> This way it would catch the errors instead of hiding them.

Sorry, that costs too many processor cycles... ;-)

But seriously: It's not the job of an implementation to teach
people how to code. If someone wants to use the side-effecting
form of `current-input-port', then let them. And I want to be
able to use `parameterize' on it.


cheers,
felix