Warnes, Gregory R
2003-Feb-14 16:58 UTC
[R] pairlists (was: data manipulation function descriptions)
> -----Original Message----- > From: Luke Tierney [mailto:luke at stat.uiowa.edu]> R does not provide a pairlist data structure. This creates a dilemma > when translating some list-based xlispstat code, or, more > importantly, when implementing an algorithm for which parilists are > the natural data structure to use. > ... > Pairlists were and still are used internally for many things. > ...Wouldn't it, therefore, make sense to provide a 'pairlist' package which exposes the internal pairlist structure and provides appropriate functions (car, cdr, ...), instead of expecting people to keep re-implementing these features? -Greg LEGAL NOTICE\ Unless expressly stated otherwise, this message is ... [[dropped]]
Peter Dalgaard BSA
2003-Feb-14 18:28 UTC
[R] pairlists (was: data manipulation function descriptions)
"Warnes, Gregory R" <gregory_r_warnes at groton.pfizer.com> writes:> > -----Original Message----- > > From: Luke Tierney [mailto:luke at stat.uiowa.edu] > > > R does not provide a pairlist data structure. This creates a dilemma > > when translating some list-based xlispstat code, or, more > > importantly, when implementing an algorithm for which parilists are > > the natural data structure to use. > > ... > > Pairlists were and still are used internally for many things. > > ... > > Wouldn't it, therefore, make sense to provide a 'pairlist' package which > exposes the internal pairlist structure and provides appropriate functions > (car, cdr, ...), instead of expecting people to keep re-implementing these > features?Some ancient consideration pops up here. We do actually expose pairlists in a few places (try mode(.Options)). Some people consider that this is a remnant and should be stamped out, but we might also consider doing what you suggest. The big problem with old R was not so much the pairlists but that they were used for representing objects of mode "list" so to get to X[[n]] you had to count through the list from the beginning which killed performance in some important cases. Then again, adding elements to a generic vector requires copying the whole thing. Of course all the legacy S code tended to do the former and not the latter, so generic vectors ended up winning. One or two reservations: With full lisp style access, could we end up with (circular) data structures that confuse the garbage collector? And might we -- supposing we allowed destructive list modifications -- end up with strange semantics a la the .Alias mess we had for a while? Of course Luke would be the first to know about this. Then of course there is the question of reverse compatibility. I don't consider it much of a loss if R code doesn't run in Splus, but others might. -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907
Seemingly Similar Threads
- struggling with pairlists
- Possible bug in 'relist()' and/or 'as.relistable()'
- How to assign NULL value to pairlist element while keeping it a pairlist?
- How to assign NULL value to pairlist element while keeping it a pairlist?
- How to assign NULL value to pairlist element while keeping it a pairlist?