Re: NIL -- Undefined
On Sun, Apr 25, 2010 at 01:30:49PM +0200, Alexander Burger wrote: > So let me explain a little more, because I think this is a central issue > ... > NIL is a very fundamental piece of data. It has a dual nature, being > ... I find this useful. So I edited a little, and posted it to the Wiki. Please excuse if it triggers a déjà-vu. -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: NIL -- Undefined
Hi Jon, > Thanks for the useful information! And thanks for using Sunday mornings > for things that matters. ;-) No Problem. Sunday morning is an ideal time for that :-) So let me explain a little more, because I think this is a central issue in PicoLisp: NIL is a very fundamental piece of data. It has a dual nature, being both a symbol _and_ a cell of the form (NIL . NIL). From the beginning, this has been a basic design requirement of PicoLisp. If you recall from "doc64/structures" (similar also in "doc/structures"): NIL: / | V +-+-+-+-+ |'LIN'| / | / | / | +-+--+--+-+-+ Physically, the pointer to NIL (shown with the 'V' in the above diagram) is a true symbol, as it points at an offset of a pointer size into the memory heap. Taken as such, 'NIL' is a normal symbol, NIL: / | V +-+-+ |'LIN'| / | +-+--+--+ having a tail with the characters "N", "I" and "L" (the name), and a value cell which in turn points to NIL (symbolized with the "/"). However, when this pointer is boldly used as a cell pointer (by ignoring the pointer tags caused by the pointer size offset) NIL: / | V +-+-+ | / | / | +--+--+-+ then it is a normal cell, with NIL in its CAR and NIL in its CDR, which just happens to be misaligned in memory (i.e. at the place of a symbol). This structure has great advantages. Any proper list (ending with NIL) becomes sort of "infinite", allowing to take the CDR as often as possible and still obtain NIL again and again. Therefore, a function (like the discussed 'list') doesn't need to check whether it actually received an argument or not. It can simply take the next argument with CDR from the argument list, and doesn't see any difference between (list NIL) and (list). This makes interpretation both simpler and faster. Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: NIL -- Undefined
Hi Alex, Thanks for the useful information! And thanks for using Sunday mornings for things that matters. ;-) /Jon > On Sun, Apr 25, 2010 at 10:15:16AM +0200, Jon Kleiser wrote: >> > : (list) >> > -> (NIL) >> > >> > That's fine, ... >> >> Or is it? Why doesn't (list) evaluate to the same as () ? > > This is a matter on how 'list' is defined. We had some time ago a > similar discussion with 'on' and 'off', I think. > > Many functions which expect at least one argument take "no argument" as > NIL. This is consistent with other situations where (optional) > non-supplied arguments are handled as 'NIL'. > > And it is a matter of efficiency, if the interpreter doesn't have to > check if there is really an argument or not. Pure pragmatism ;-) > > > A better example for that might be 'cons'. It is supposed to create a > new cell. 'cons' is the basic cell-building function. So the call might > be > >(cons NIL NIL) > > This is, however, equivalent (and consistent) with > >(cons NIL) > > or even just > >(cons) > > This is short and practical. I never write (cons NIL NIL) when I want to > create an empty call, but always (cons). > > To be true, in case of 'list' this doesn't make much sense, but still > (list) might be called to create a single empty cell. > > Cheers, > - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: NIL -- Undefined
On Sun, Apr 25, 2010 at 10:15:16AM +0200, Jon Kleiser wrote: > > : (list) > > -> (NIL) > > > > That's fine, ... > > Or is it? Why doesn't (list) evaluate to the same as () ? This is a matter on how 'list' is defined. We had some time ago a similar discussion with 'on' and 'off', I think. Many functions which expect at least one argument take "no argument" as NIL. This is consistent with other situations where (optional) non-supplied arguments are handled as 'NIL'. And it is a matter of efficiency, if the interpreter doesn't have to check if there is really an argument or not. Pure pragmatism ;-) A better example for that might be 'cons'. It is supposed to create a new cell. 'cons' is the basic cell-building function. So the call might be (cons NIL NIL) This is, however, equivalent (and consistent) with (cons NIL) or even just (cons) This is short and practical. I never write (cons NIL NIL) when I want to create an empty call, but always (cons). To be true, in case of 'list' this doesn't make much sense, but still (list) might be called to create a single empty cell. Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: NIL -- Undefined
Hi Jon, > : (NIL) > !? (NIL) > NIL -- Undefined This is analog to : (a) !? (a) a -- Undefined Neither 'a' nor 'NIL' are functions. Cheers, - Aelx -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: NIL -- Undefined
> Hi, > > : (list) > -> (NIL) > > That's fine, ... Or is it? Why doesn't (list) evaluate to the same as () ? I see that : (length (list)) -> 1 : (length (list 'A)) -> 1 : (length ()) -> 0 /Jon -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
NIL -- Undefined
Hi, : (list) -> (NIL) That's fine, but why is this a problem then: : (NIL) !? (NIL) NIL -- Undefined /Jon -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
