take! 0==1?

take! 0==1?

[Jan Nieuwenhuizen]

Hi,

Reading the documentation of take!

    -- Scheme Procedure: take lst i
    -- Scheme Procedure: take! lst i
        Return a list containing the first I elements of LST.

        `take!' may modify the structure of the argument list LST in order
        to produce the result.

its behaviour surpsises me.

For list LST, (take! lst 0) leaves LST in the same state
as (take! lst 1) does.  Worse, the return value suggests
that it worked

    scheme@(guile-user)> (use-modules (srfi srfi-1))
    scheme@(guile-user)> (define lst '(a))
    scheme@(guile-user)> (take! lst 0)
    $4 = ()
    scheme@(guile-user)> lst
    $5 = (a)
    scheme@(guile-user)> (take! lst 1)
    $6 = (a)
    scheme@(guile-user)> lst
    $7 = (a)
    scheme@(guile-user)>

How are you doing such things?  Is anyone using take! at all to reduce a
list to n elements?  Using list-cdr-set! and set!/list-set! also seems a bit
clumsy.

Greetings, Jan

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

Re: take! 0==1?

[William ML Leslie]

On 12 July 2013 17:14, Jan Nieuwenhuizen <janneke@gnu.org> wrote:
> Hi,
>
> Reading the documentation of take!
>
>     -- Scheme Procedure: take lst i
>     -- Scheme Procedure: take! lst i
>         Return a list containing the first I elements of LST.
>
>         `take!' may modify the structure of the argument list LST in order
>         to produce the result.
>
> its behaviour surpsises me.
>
> For list LST, (take! lst 0) leaves LST in the same state
> as (take! lst 1) does.  Worse, the return value suggests
> that it worked

Well, there's no pair that can be mutated in (take! lst 0), and (take!
lst n) where n is the length of the list is just like setting the nth
cdr to nil, which it already is.  Have I understood this correctly?

>     scheme@(guile-user)> (use-modules (srfi srfi-1))
>     scheme@(guile-user)> (define lst '(a))
>     scheme@(guile-user)> (take! lst 0)
>     $4 = ()
>     scheme@(guile-user)> lst
>     $5 = (a)
>     scheme@(guile-user)> (take! lst 1)
>     $6 = (a)
>     scheme@(guile-user)> lst
>     $7 = (a)
>     scheme@(guile-user)>
>
> How are you doing such things?  Is anyone using take! at all to reduce a
> list to n elements?  Using list-cdr-set! and set!/list-set! also seems a bit
> clumsy.
>
> Greetings, Jan
>
> --
> Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
> Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl

--
William Leslie

Notice:
Likely much of this email is, by the nature of copyright, covered
under copyright law.  You absolutely may reproduce any part of it in
accordance with the copyright law of the nation you are reading this
in.  Any attempt to deny you those rights would be illegal without
prior contractual agreement.

Re: take! 0==1?

[William ML Leslie]

On 12 July 2013 17:14, Jan Nieuwenhuizen <janneke@gnu.org> wrote:
> Hi,
>
> Reading the documentation of take!
>
>     -- Scheme Procedure: take lst i
>     -- Scheme Procedure: take! lst i
>         Return a list containing the first I elements of LST.
>
>         `take!' may modify the structure of the argument list LST in order
>         to produce the result.
>
> its behaviour surpsises me.
>
> For list LST, (take! lst 0) leaves LST in the same state
> as (take! lst 1) does.  Worse, the return value suggests
> that it worked

Actually, I should clarify a few things, but this discussion probably
belongs on guile-user.

Whenever the documentation says 'may', it really means it.  You
absolutely cannot rely on the side-effecting behaviour, because an
implementation that does no mutation whatsoever is a valid
implementation of (take!), according to the documentation.  All you're
saying by using (take!) is, if it is more efficient to do so by
altering the list, then please do.

However, what it does is very simple to determine by looking at a box
diagram for the following.

scheme@(guile-user)> (use-modules (srfi srfi-1))
scheme@(guile-user)> (define xs '(a b c))
scheme@(guile-user)> (define ys (cdr xs))
scheme@(guile-user)> (define zs (cdr ys))
scheme@(guile-user)> (take! xs 3) ;; writes a nil at the end of the
list, ie does nothing
$3 = (a b c)
scheme@(guile-user)> (take! xs 2) ;; replaces the reference to the
last pair with nil
$11 = (a b)
scheme@(guile-user)> xs
$12 = (a b)
scheme@(guile-user)> ys
$13 = (b)
scheme@(guile-user)> zs ;; the last pair still exists, although it is
not reachable from xs/ys
$14 = (c)

--
William Leslie

Notice:
Likely much of this email is, by the nature of copyright, covered
under copyright law.  You absolutely may reproduce any part of it in
accordance with the copyright law of the nation you are reading this
in.  Any attempt to deny you those rights would be illegal without
prior contractual agreement.

Resolved: ! often means may, not will [WAS: Re: take! 0==1?]

[Jan Nieuwenhuizen]

William ML Leslie writes:

> Actually, I should clarify a few things, but this discussion probably
> belongs on guile-user.

I realise that now, reading below...

> Whenever the documentation says 'may', it really means it.  You
> absolutely cannot rely on the side-effecting behaviour, because an
> implementation that does no mutation whatsoever is a valid
> implementation of (take!), according to the documentation.  All you're
> saying by using (take!) is, if it is more efficient to do so by
> altering the list, then please do.

Thank you for this clue-bat.

Wow, I never realised that !/_x is only a performance/ugliness thingy,
except when used with set!.  I somehow assumed `!' meant: will alter
in-place.  My bad.

Is there really a good reason for exposing such performance
considerations to the user; can't the compiler [often] tell whether it's
safe to modify in place?

Greetings, Jan

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl