Re: port-with-print-state doesn't create a port? Or, when is a port not a port? :-)

[Doug Evans]

On Wed, May 21, 2014 at 7:24 AM, Ludovic Courtès <address@hidden> wrote:
> Hi!
>
> Doug Evans <address@hidden> skribis:
>
>> The problem can be succinctly represented by the following:
>>
>> scheme@(guile-user)> (port? (port-with-print-state (current-output-port)))
>> $3 = #f
>
> I think the short answer is that it’s a very old API that’s essentially
> unused internally.  For instance, make check passes with this patch:
>
>
>
> I think the problem it was trying to solve has been solved differently
> (by explicitly passing the print state in the print.c code, for
> instance), and can easily be solved differently.
>
>> In the meantime, I can make struct printers be aware of the
>> distinction and handle being passed port-with-print-state ports.
>
> Do you actually need this associated state?

Nope.

The point of my message is that if a struct printer written in C
blindly calls scm_puts ... boom.
That, plus it's a bit odd that port-with-print-state doesn't create
something that satisfies port?.

> My first feeling is that we should deprecate and eventually remove this
> API, given that it’s essentially unused and non-functional.
>
> What do people think?
>
>> P.S. How come scm_put[cs]_unlocked are inlined in ports.h?
>
> What’s wrong with that?  (It probably doesn’t help much because
> scm_lfwrite_unlocked isn’t inlined.)

AFAICT there can be no measurable speed up from having them there, so
their presence is at least odd: The astute reader of the file will ask
why they're there, and there is no good answer.