[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
> `shared'.

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.
                        --Mark Liberman

Scheme-reports mailing list