On Wed, May 21, 2014 at 7:24 AM, Ludovic Courtès <l...@gnu.org> wrote: > Hi! > > Doug Evans <xdj...@gmail.com> 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.
