[Top][All Lists]

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

Re: [Chicken-hackers] [PATCH] Move port procedures out of toplevel and d

From: John Cowan
Subject: Re: [Chicken-hackers] [PATCH] Move port procedures out of toplevel and drop most "chicken" imports
Date: Thu, 25 Jan 2018 17:49:17 -0500

On Thu, Jan 25, 2018 at 3:37 PM, Evan Hanson <address@hidden> wrote:

The following procedures, however, are now in chicken.base instead:
get-output-string, open-input-string, open-output-string, port?
input-port-open?, output-port-open?, and flush-output. I've done this to
more closely match the R7RS library layout, which has those first six
procedures in scheme.base, as well as flush-output-port, which
corresponds to our flush-output. Incidentally, we might want to rename
our procedure to match.

I put them there because every Scheme, however nano, should have ports even if it doesn't have conventional I/O, if only to be able to build up strings efficiently.

I wasn't totally sold on port?, actually, so I put it in chicken.base
since that's what the R7RS does, and that's also where many of the other
type predicates for built-ins have gone, e.g. fixnum? and promise?.

If there is a library, then foo? should probably go there.  If not, then chicken.base is fine.  Port? is a special case: it wasn't supposed to exist in R5RS at all (see the R5RS errata at <>, but so many implementers provided it anyway that it was made official in R7RS.

John Cowan        address@hidden
The competent programmer is fully aware of the strictly limited size of his own
skull; therefore he approaches the programming task in full humility, and among
other things he avoids clever tricks like the plague.  --Edsger Dijkstra

reply via email to

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