[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Proposed new SRFI for immutable lists
Alex Shinn scripsit:
> The naive approach would be to define ipairs with setters
> and simply not export those setters to the user. This runs
> into problems with future extensions for record introspection.
Hopefully such extensions will make provision for opaque record types
on which `record-rtd?` does not work (and `record?` returns #f).
> However, using lazy evaluation one could have truly
> immutable, portable records and still provide such
> utilities as `circular-ilist' and the equivalent of Racket's
Sure. But the question is whether such polymorphism is useful, or whether
it's better to have a distinct type of immutable cycles, either one-way
or (per CyclesMedernach) two-way. The only SRFI 1 procedures that apply
equally to circular and normal lists are list-ref, length+ (aka R7RS
length), zip, count, fold(-right), pair-fold(-right), map, for-each,
append-map, map-in-order, pair-for-each, filter-map, find(-tail),
take-while, drop-while, span, break, any, every, list-index. Most of
these accept multiple lists, of which at least one must be finite, so
for example you cannot map a procedure over a circular list and get a
circular list. Having to be prepared to handle promises at any point
will make all these functions slower on normal ilists.
John Cowan http://www.ccil.org/~cowan cowan@x
Most people are much more ignorant about language than they are about
[other subjects], but they reckon that because they can talk and read and
write, their opinions about talking and reading and writing are as well
informed as anybody's. And since I have DNA, I'm entitled to carry on at
length about genetics without bothering to learn anything about it. Not.
Scheme-reports mailing list