Re: Loosing elements in a sorted list

[Bruno Franco]

cool, thanks

On Fri, Dec 16, 2016 at 1:55 PM, Joh-Tob Schäg  wrote:

> 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" :
>
>> 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 
>>> wrote:
>>>
 Hi Bruno,

 > But that might be because with 'by, the operation is not destructive

Re: Loosing elements in a sorted list

[Joh-Tob Schäg]

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" :

> 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 
>> 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
>

Re: Loosing elements in a sorted list

[Joh-Tob Schäg]

Assuming
( 1 . Pointertotheonecontaining(2)) and
( 2 . Pointertotheonecontaining(3))
are no longer referenced by a node referenced by the global name space.
They will be reclaimed during next gabarage collection and added to the
free cell list.
Am 17.12.2016 03:33 schrieb "Bruno Franco" :

> 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 
> 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
>>
>
>

Re: Loosing elements in a sorted list

[Alexander Burger]

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

Re: Loosing elements in a sorted list

[Alexander Burger]

On Wed, Dec 14, 2016 at 10:01:27PM -0500, John Duncan wrote:
> This is because A still points at the cons that was the head of the list
> before sorting. If you want to update it, you have to set A to the result
> of sort.

Yes. The point is that 'sort' is a "destructive" operation. See the reference of
'sort'.

- Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Loosing elements in a sorted list

[John Duncan]

This is because A still points at the cons that was the head of the list
before sorting. If you want to update it, you have to set A to the result
of sort.

On Dec 14, 2016 8:37 PM, "Bruno Franco" 
wrote:

> Hi list, I have a problem.
>
> Whenever I sort a list stored in a symbol, some elements are erased
> from the original list. Look:
>
> : (setq A (3 2 5 4 1 1 1 1 0 1 2 4 5 ))
> -> (3 2 5 4 1 1 1 1 0 1 2 4 5)
> : (sort A)
> -> (0 1 1 1 1 1 2 2 3 4 4 5 5)
> : A
> -> (3 4 4 5 5)
>
> The pattern that I've noticed is that any element that is smaller than the
> CAR of the original list is lost in the sorting.
>
> Its not limited to numbers either:
>
> : (setq A '(a 3 2 5 4 1 1 1 1 0 1 2 4 5 ))
> -> (a 3 2 5 4 1 1 1 1 0 1 2 4 5)
> : (sort A)
> -> (0 1 1 1 1 1 2 2 3 4 4 5 5 a)
> : A
> -> (a)
>
> If its used with 'by, there is no loss:
>
> : (setq A '(a 3 2 5 4 1 1 1 1 0 1 2 4 5 ))
> -> (a 3 2 5 4 1 1 1 1 0 1 2 4 5)
> : (by > sort A)
> -> (0 1 1 1 1 1 2 2 3 4 4 5 5 a)
> : A
> -> (a 3 2 5 4 1 1 1 1 0 1 2 4 5)
>
> But that might be because with 'by, the operation is not destructive.
>
> Is this normal operation of picolisp? I assumed its not, because I didn't
> catch any reference to it in the documentation.
>
> I'd quite appreciate any help, and if you have any questions let me know
>
> P.S.
> I'm using version 16.6.0, on Ubuntu 16.04
>