[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] [PATCH] Fix #1294 by mentioning in the docs that d

From: Peter Bex
Subject: Re: [Chicken-hackers] [PATCH] Fix #1294 by mentioning in the docs that define-record-printer is not a definition
Date: Fri, 12 Jul 2019 10:45:22 +0200
User-agent: Mutt/1.10.1 (2018-07-13)

On Fri, Jul 12, 2019 at 08:29:58PM +1200, Evan Hanson wrote:
> On 2019-06-30 19:25, Peter Bex wrote:
> > I had another look at #1294 and decided that, while we *could* fake the
> > record type printer as a definition by wrapping it in a (define) call
> > with a gensym, I think it doesn't make much sense.
> This actually makes good sense to me. Why don't you like this approach?

Like I said, it isn't a definition.  The name is just unfortunate.

> In any case, I think we should try to address the issue one way or the
> other rather than keep a potential pitfall around. If we don't make it a
> "real" (i.e. fake) definition, could we at least introduce a new name
> and encourage its use? Perhaps `set-record-printer!', maybe even with a
> SRFI 17 setter on the type descriptor? Unfortunately, we probably can't
> remove the old name, since it comes from SRFI 99. But again, making it
> an actual definition seems OK to me.

It's not from SRFI-99 (or SRFI-9) AFAICT.  We can rename it, but that's
a breaking change.  Of course we could keep around the old one during a
deprecation phase.

> As a sidenote, this issue also applies to `define-reader-ctor', and
> perhaps others; I didn't review the lot.

hm, I didn't think of that one.  That's a procedure, which is even


Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]