If they become unreachable, they will be collected.

That is a more compact way ofnsaying what i just said. If you want to get
more technicalnread mine but this one is easier to understand
Am 17.12.2016 03:53 schrieb "John Duncan" <duncan.j...@gmail.com>:

> If they become unreachable, they will be collected.
>
> On Fri, Dec 16, 2016 at 1:28 PM, Bruno Franco <
> brunofrancosala...@gmail.com> wrote:
>
>> Hi John, Alex,
>>
>> Thank you for your explanations, I think I now understand how sort works:
>> So, for example, in
>>
>> : (setq A (3 1 2 4 5 6))
>> -> (3 1 2 4 5 6)
>> : (setq B (sort A))
>> -> (1 2 3 4 5 6)
>> : A
>> -> (3 4 5 6)
>> : B
>> -> (1 2 3 4 5 6)
>>
>> The symbol A points to the first cell of the list (3 1 2 3 4 5 6), and
>> each cell
>> points to the next cell in the list. When sort is applied, the pointing
>> order of the cells
>> is changed so that each cell is in the right order in the list. But, A is
>> still pointing to
>> the same cell as before, and if that cell has moved, then A ends up
>> pointing to the
>> middle of the list.
>>
>> In the case above, A points to the cell with CAR 3, and when that cell is
>> moved, A ends
>> up pointing to the 3rd element of the list. And so, the list that is
>> built as the value of A
>> starts at the 3rd element.
>>
>> My follow up question is, what happens to those first 2 cells, if they're
>> not assigned to
>> anything? Do they just stay there? Or are they deleted, perhaps by the
>> garbage collector?
>>
>> P.S.
>> I also wanted to apologise. When I reread my first mail I realised it was
>> arrogant of me to
>> imply that a feature of the language might be a bug.
>> You have put a lot of effort into this language, and it shows Several
>> design decisions that
>> first surprised me turned out to be awesome, because they let me write
>> code that was
>> shorter, easier to read, and prettier. And because they lead to a more
>> consistent language.
>>
>> Thank you for all your effort Alex. I like a lot the language you've made.
>>
>>
>>
>> On Thu, Dec 15, 2016 at 8:30 AM, Alexander Burger <a...@software-lab.de>
>> wrote:
>>
>>> Hi Bruno,
>>>
>>> > But that might be because with 'by, the operation is not destructive.
>>>
>>> This is correct. 'sort' is destructive, and 'by' is not, because it
>>> builds a
>>> fresh, private list.
>>>
>>>
>>> > Is this normal operation of picolisp? I assumed its not, because I
>>> didn't
>>> > catch any reference to it in the documentation.
>>>
>>> Every destructive function should be marked as such in the reference Let
>>> us
>>> know when you find a case where this is missing.
>>>
>>> - Alex
>>> --
>>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>>
>>
>>
>
>
> --
> John Duncan
>

Reply via email to