home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   sci.lang      Natural languages, communication, etc      297,462 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 296,062 of 297,462   
   Kaz Kylheku to Aidan Kehoe   
   Re: "CDR down the list..."   
   11 Jul 24 07:24:19   
   
   XPost: comp.lang.lisp, alt.usage.english   
   From: 643-408-1753@kylheku.com   
      
   On 2024-07-11, Aidan Kehoe  wrote:   
   >   
   >  Ar an t-aonú lá déag de mí Iúil, scríobh Lawrence D'Oliveiro:   
   >   
   > > On Thu, 11 Jul 2024 15:57:57 +1000, Peter Moylan wrote:   
   > >   
   > > > On 11/07/24 15:50, HenHanna wrote:   
   > > >   
   > > >> Another  nostalgic  term is  to "CDR down the list..."   
   > > >   
   > > > It is indeed many years since I last used CAR and CDR in anger, but I   
   > > > don't remember it with nostalgia.   
   > >   
   > > Proper CompSci terms should not have such proprietary origins.   
   >   
   > “Contents of the decrement register,” wasn’t it? Not horrific on that   
   front.   
   > But yes, a more general word would be ideal.   
      
   John MacCarthy obviously cared about naming. The FLPL (Fortran List   
   Processing Language) had awful function names like XCARF and XCDRF.   
      
   He had the presence of mind to drop the gratuitous X and F.   
      
   However, he was fine with the names like CAR and CDR and used that in   
   papers before Lisp existed.   
      
   The two fields of a binary cell can be used in a myriad ways with   
   as many meanings. Therefore names for their parts which have no meaning   
   are fitting; they do not skew the interpretation of the program with   
   inappropriate connotations.   
      
   When you see nothing but a bunch of car and cdr in code, you know it's   
   just working with shape. Whatever meaning the shape has has is imposed   
   elsewhere.   
      
   > A (the) codebase I work on has a Lisp implementation as well as a lot of C.   
   The   
   > Lisp data types and related functions are easily available to the C code.   
   > Nonetheless there are loads of C structures that just incorporate their own   
   > next pointer and roll their own linked lists that way, requiring separate   
   list   
   > traversal, searching, sorting, cycle detection code ...   
      
   Inside a Lisp-in-C impementation, the garbage collected Lisp list are   
   not always the most efficient thing to use, and could even cause   
   problems in code that interacts with the memory mangement and GC.   
   When internal structures use their own links, it's a clean separation.   
      
   Another consideration is that in C we often use intrusive containers,   
   including lists. The objects contain the link node as part of their   
   representation, and so can be put on a list without having to allocate   
   a list cell. This constrains them to be one one list at a time   
   (if they have one link field) and that is actually enough in   
   many situations.   
      
   Intrusive lists and other data structures can be had in a generic way;   
   for instance with the BSD TAILQ macros. You don't have to write   
   multiple sort or cycle detection routines.   
      
   --   
   TXR Programming Language: http://nongnu.org/txr   
   Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal   
   Mastodon: @Kazinator@mstdn.ca   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca