srfi-1 take and drop seriously broken

srfi-1 take and drop seriously broken

[Jan Synáček]

Hi,

scheme@(guile-user)> ,use (srfi srfi-1)
scheme@(guile-user)> (take (list 1 2 3) 4)
ERROR: In procedure list-head:
ERROR: In procedure list-head: Wrong type argument in position 1
(expecting pair): ()

scheme@(guile-user) [1]> (drop (list 1 2 3) 4)
ERROR: In procedure list-tail:
ERROR: In procedure list-tail: Wrong type argument in position 1
(expecting pair): ()

Please, tell me that this is just a mistake... This can't be true. I
still can't believe it. This is from 2.0.11. Please, tell me that the
implementation is fixed in 2.2.

Yours truly puzzled,
-- 
Jan Synáček

Re: srfi-1 take and drop seriously broken

[Jan Nieuwenhuizen]

Jan Synáček writes:

> scheme@(guile-user)> ,use (srfi srfi-1)
> scheme@(guile-user)> (take (list 1 2 3) 4)
> ERROR: In procedure list-head:
> ERROR: In procedure list-head: Wrong type argument in position 1
> (expecting pair): ()

That's expected.

> scheme@(guile-user) [1]> (drop (list 1 2 3) 4)
> ERROR: In procedure list-tail:
> ERROR: In procedure list-tail: Wrong type argument in position 1
> (expecting pair): ()

That too.

> Please, tell me that this is just a mistake...

It's just a mistake!

> This can't be true. I still can't believe it. This is from
> 2.0.11. Please, tell me that the implementation is fixed in 2.2.

You'd have to give me more clues about what it is that puzzles you
and why.

> Yours truly puzzled,

Do you possibbly mean something like

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> (use-modules (srfi srfi-1))
scheme@(guile-user)> (take '(list 1 2 3) 4)
$1 = (list 1 2 3)
scheme@(guile-user)> (drop '(list 1 2 3) 4)
$2 = ()
--8<---------------cut here---------------end--------------->8---

Greetings,
Jan

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

Re: srfi-1 take and drop seriously broken

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Nov 19, 2016 at 10:18:21PM +0100, Jan Nieuwenhuizen wrote:
> Jan Synáček writes:
> 
> > scheme@(guile-user)> ,use (srfi srfi-1)
> > scheme@(guile-user)> (take (list 1 2 3) 4)
> > ERROR: In procedure list-head:
> > ERROR: In procedure list-head: Wrong type argument in position 1
> > (expecting pair): ()
> 
> That's expected.
> 
> > scheme@(guile-user) [1]> (drop (list 1 2 3) 4)
> > ERROR: In procedure list-tail:
> > ERROR: In procedure list-tail: Wrong type argument in position 1
> > (expecting pair): ()
> 
> That too.
> 
> > Please, tell me that this is just a mistake...
> 
> It's just a mistake!
> 
> > This can't be true. I still can't believe it. This is from
> > 2.0.11. Please, tell me that the implementation is fixed in 2.2.
> 
> You'd have to give me more clues about what it is that puzzles you
> and why.
> 
> > Yours truly puzzled,
> 
> Do you possibbly mean something like
> 
> --8<---------------cut here---------------start------------->8---
> scheme@(guile-user)> (use-modules (srfi srfi-1))
> scheme@(guile-user)> (take '(list 1 2 3) 4)
> $1 = (list 1 2 3)
> scheme@(guile-user)> (drop '(list 1 2 3) 4)
> $2 = ()
> --8<---------------cut here---------------end--------------->8---

Hm. Jan's example should work, nevertheless. And it does work for me:

  tomas@rasputin:~$ guile
  GNU Guile 2.0.11.133-d680
  Copyright (C) 1995-2014 Free Software Foundation, Inc.
  
  Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
  This program is free software, and you are welcome to redistribute it
  under certain conditions; type `,show c' for details.
  
  Enter `,help' for help.
  scheme@(guile-user)> (use-modules (srfi srfi-1))
  scheme@(guile-user)> (take (list 1 2 3 4) 4)
  $1 = (1 2 3 4)
  
Hmmm.

(note my Guile version, which is a tad beyond "plain" 2.0.11;
but FWIW it works for me in Guile 1.8 too)

regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlgwyYsACgkQBcgs9XrR2kZKGwCfdjI4+zOQFWgaM+WMZb95v22x
gi8An10EyxTJ+NAgO/FWqwjcQ3CiuMWC
=EXVs
-----END PGP SIGNATURE-----

Re: srfi-1 take and drop seriously broken

[Panicz Maciej Godek]

[-- Attachment #1: Type: text/plain, Size: 1253 bytes --]

2016-11-19 19:34 GMT+01:00 Jan Synáček <jan.synacek@gmail.com>:

> Hi,
>
> scheme@(guile-user)> ,use (srfi srfi-1)
> scheme@(guile-user)> (take (list 1 2 3) 4)
> ERROR: In procedure list-head:
> ERROR: In procedure list-head: Wrong type argument in position 1
> (expecting pair): ()
>
> scheme@(guile-user) [1]> (drop (list 1 2 3) 4)
> ERROR: In procedure list-tail:
> ERROR: In procedure list-tail: Wrong type argument in position 1
> (expecting pair): ()
>
> Please, tell me that this is just a mistake... This can't be true. I
> still can't believe it. This is from 2.0.11. Please, tell me that the
> implementation is fixed in 2.2.
>
> Yours truly puzzled,


I don't know why you find it so puzzling. You can't take or drop something
that "isn't there" (you can't take a car or cdr from an empty list as well,
although e.g. in the language of "The Little Prover" (car '()) and (cdr
'()) both evaluate to '() to assure their totality). If you need, you can
define your own variants that take/drop at most n elements of list.

Or you could use the take-upto/drop-upto functions from the (grand scheme)
library that I maintain:
https://github.com/plande/grand-scheme
(check the grand/list.scm file for the definition)

[-- Attachment #2: Type: text/html, Size: 1811 bytes --]

Re: srfi-1 take and drop seriously broken

[Eli Zaretskii]

> Date: Sat, 19 Nov 2016 22:52:12 +0100
> From: <tomas@tuxteam.de>
> 
> On Sat, Nov 19, 2016 at 10:18:21PM +0100, Jan Nieuwenhuizen wrote:
> > Jan Synáček writes:
> > 
> > > scheme@(guile-user)> ,use (srfi srfi-1)
> > > scheme@(guile-user)> (take (list 1 2 3) 4)
> > > ERROR: In procedure list-head:
> > > ERROR: In procedure list-head: Wrong type argument in position 1
> > > (expecting pair): ()
> > 
> > That's expected.
> > 
> > > scheme@(guile-user) [1]> (drop (list 1 2 3) 4)
> > > ERROR: In procedure list-tail:
> > > ERROR: In procedure list-tail: Wrong type argument in position 1
> > > (expecting pair): ()
> > 
> > That too.
> > 
> 
> Hm. Jan's example should work, nevertheless. And it does work for me:
> 
>   tomas@rasputin:~$ guile
>   GNU Guile 2.0.11.133-d680
>   Copyright (C) 1995-2014 Free Software Foundation, Inc.
>   
>   Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
>   This program is free software, and you are welcome to redistribute it
>   under certain conditions; type `,show c' for details.
>   
>   Enter `,help' for help.
>   scheme@(guile-user)> (use-modules (srfi srfi-1))
>   scheme@(guile-user)> (take (list 1 2 3 4) 4)
>   $1 = (1 2 3 4)

Your example has 4 members in the list, while the original one had
only 3.

Re: srfi-1 take and drop seriously broken

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Nov 20, 2016 at 05:32:25AM +0200, Eli Zaretskii wrote:
> > Date: Sat, 19 Nov 2016 22:52:12 +0100
> > From: <tomas@tuxteam.de>
> > 
> > On Sat, Nov 19, 2016 at 10:18:21PM +0100, Jan Nieuwenhuizen wrote:
> > > Jan Synáček writes:
> > > 
> > > > scheme@(guile-user)> ,use (srfi srfi-1)
> > > > scheme@(guile-user)> (take (list 1 2 3) 4)

[...]

> >   scheme@(guile-user)> (take (list 1 2 3 4) 4)
> >   $1 = (1 2 3 4)
> 
> Your example has 4 members in the list, while the original one had
> only 3.

Ahem. Juxtaposing, and now that you say it :-)

To be honest, the first example was Jan's, the second mine. In between
there must have been some funky spell checker in my wetware (if you're
taking four there's got to be at least four, right?).

Thanks for pointing that out
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlgxeJEACgkQBcgs9XrR2kbcWgCfWMSWwVkOCoscrSpwirlDZ0gz
MEAAn2QG43XO8UE0HtN1S574jY5J0FaF
=6wCA
-----END PGP SIGNATURE-----

Re: srfi-1 take and drop seriously broken

[Jan Synáček]

On Sat, Nov 19, 2016 at 10:18 PM, Jan Nieuwenhuizen <janneke@gnu.org> wrote:
> Jan Synáček writes:
>
>> scheme@(guile-user)> ,use (srfi srfi-1)
>> scheme@(guile-user)> (take (list 1 2 3) 4)
>> ERROR: In procedure list-head:
>> ERROR: In procedure list-head: Wrong type argument in position 1
>> (expecting pair): ()
>
> That's expected.
>
>> scheme@(guile-user) [1]> (drop (list 1 2 3) 4)
>> ERROR: In procedure list-tail:
>> ERROR: In procedure list-tail: Wrong type argument in position 1
>> (expecting pair): ()
>
> That too.
>
>> Please, tell me that this is just a mistake...
>
> It's just a mistake!
>
>> This can't be true. I still can't believe it. This is from
>> 2.0.11. Please, tell me that the implementation is fixed in 2.2.
>
> You'd have to give me more clues about what it is that puzzles you
> and why.
>
>> Yours truly puzzled,
>
> Do you possibbly mean something like
>
> --8<---------------cut here---------------start------------->8---
> scheme@(guile-user)> (use-modules (srfi srfi-1))
> scheme@(guile-user)> (take '(list 1 2 3) 4)
> $1 = (list 1 2 3)
> scheme@(guile-user)> (drop '(list 1 2 3) 4)
> $2 = ()
> --8<---------------cut here---------------end--------------->8---

Yes, this is exactly how it should work, thank you. For some reason, I
thought that was clear, but apparently wasn't. What's the point of
using take/drop when you have to know the length of the list?

Cheers,
-- 
Jan Synáček

Re: srfi-1 take and drop seriously broken

[Jan Synáček]

On Sat, Nov 19, 2016 at 11:55 PM, Panicz Maciej Godek
<godek.maciek@gmail.com> wrote:
>
>
> 2016-11-19 19:34 GMT+01:00 Jan Synáček <jan.synacek@gmail.com>:
>>
>> Hi,
>>
>> scheme@(guile-user)> ,use (srfi srfi-1)
>> scheme@(guile-user)> (take (list 1 2 3) 4)
>> ERROR: In procedure list-head:
>> ERROR: In procedure list-head: Wrong type argument in position 1
>> (expecting pair): ()
>>
>> scheme@(guile-user) [1]> (drop (list 1 2 3) 4)
>> ERROR: In procedure list-tail:
>> ERROR: In procedure list-tail: Wrong type argument in position 1
>> (expecting pair): ()
>>
>> Please, tell me that this is just a mistake... This can't be true. I
>> still can't believe it. This is from 2.0.11. Please, tell me that the
>> implementation is fixed in 2.2.
>>
>> Yours truly puzzled,
>
>
> I don't know why you find it so puzzling. You can't take or drop something
> that "isn't there" (you can't take a car or cdr from an empty list as well,
> although e.g. in the language of "The Little Prover" (car '()) and (cdr '())
> both evaluate to '() to assure their totality). If you need, you can define
> your own variants that take/drop at most n elements of list.

Not only that you "can", it's also IMHO a fool-proof implementation
and I can't see any reason why it should behave differently.

https://hackage.haskell.org/package/base-4.8.2.0/docs/Data-List.html#v:take

Cheers,
-- 
Jan Synáček

Re: srfi-1 take and drop seriously broken

[Panicz Maciej Godek]

[-- Attachment #1: Type: text/plain, Size: 1379 bytes --]

2016-11-20 11:42 GMT+01:00 Jan Synáček <jan.synacek@gmail.com>:

>
> >> Please, tell me that this is just a mistake... This can't be true. I
> >> still can't believe it. This is from 2.0.11. Please, tell me that the
> >> implementation is fixed in 2.2.
> >>
> >> Yours truly puzzled,
> >
> >
> > I don't know why you find it so puzzling. You can't take or drop
> something
> > that "isn't there" (you can't take a car or cdr from an empty list as
> well,
> > although e.g. in the language of "The Little Prover" (car '()) and (cdr
> '())
> > both evaluate to '() to assure their totality). If you need, you can
> define
> > your own variants that take/drop at most n elements of list.
>
> Not only that you "can", it's also IMHO a fool-proof implementation
> and I can't see any reason why it should behave differently.
>

Because someone might think that if he took 7 elements, then he has 7
elements, so it is good that he knows earlier that this is not the case. I
don't see a point in referring to Haskell documentation when discussing
Scheme functions, though (if you try Racket, you'll note that although its
take has a reversed order of arguments compared to srfi-1, it still doesn't
allow to take or drop a positive number of elements from an empty list)

I agree though that the srfi-1 document isn't explicit enough about this
point.

[-- Attachment #2: Type: text/html, Size: 1890 bytes --]

Re: srfi-1 take and drop seriously broken

[dsmich]

---- Panicz Maciej Godek <godek.maciek@gmail.com> wrote: 
> 2016-11-20 11:42 GMT+01:00 Jan Synáček <jan.synacek@gmail.com>:
> 
> >
> > >> Please, tell me that this is just a mistake... This can't be true. I
> > >> still can't believe it. This is from 2.0.11. Please, tell me that the
> > >> implementation is fixed in 2.2.
> > >>
> > >> Yours truly puzzled,
> > >
> > >
> > > I don't know why you find it so puzzling. You can't take or drop
> > something
> > > that "isn't there" (you can't take a car or cdr from an empty list as
> > well,
> > > although e.g. in the language of "The Little Prover" (car '()) and (cdr
> > '())
> > > both evaluate to '() to assure their totality). If you need, you can
> > define
> > > your own variants that take/drop at most n elements of list.
> >
> > Not only that you "can", it's also IMHO a fool-proof implementation
> > and I can't see any reason why it should behave differently.
> >
> 
> Because someone might think that if he took 7 elements, then he has 7
> elements, so it is good that he knows earlier that this is not the case. I
> don't see a point in referring to Haskell documentation when discussing
> Scheme functions, though (if you try Racket, you'll note that although its
> take has a reversed order of arguments compared to srfi-1, it still doesn't
> allow to take or drop a positive number of elements from an empty list)
> 
> I agree though that the srfi-1 document isn't explicit enough about this
> point.

Yes.   Srfi-1 ( http://srfi.schemers.org/srfi-1/srfi-1.html ) says that drop 
"is exactly equivalent to performing i cdr operations on x", and notes that for
car and cdr "it is an error to apply them to the empty list"

Also for take and drop: "For a legal i, take and drop partition the list in a manner which can be inverted with append"
Implying that not all i are "legal".

-Dale

Re: srfi-1 take and drop seriously broken

[Jan Synáček]

On Sun, Nov 20, 2016 at 7:31 PM,  <dsmich@roadrunner.com> wrote:
>
> ---- Panicz Maciej Godek <godek.maciek@gmail.com> wrote:
>> 2016-11-20 11:42 GMT+01:00 Jan Synáček <jan.synacek@gmail.com>:
>>
>> >
>> > >> Please, tell me that this is just a mistake... This can't be true. I
>> > >> still can't believe it. This is from 2.0.11. Please, tell me that the
>> > >> implementation is fixed in 2.2.
>> > >>
>> > >> Yours truly puzzled,
>> > >
>> > >
>> > > I don't know why you find it so puzzling. You can't take or drop
>> > something
>> > > that "isn't there" (you can't take a car or cdr from an empty list as
>> > well,
>> > > although e.g. in the language of "The Little Prover" (car '()) and (cdr
>> > '())
>> > > both evaluate to '() to assure their totality). If you need, you can
>> > define
>> > > your own variants that take/drop at most n elements of list.
>> >
>> > Not only that you "can", it's also IMHO a fool-proof implementation
>> > and I can't see any reason why it should behave differently.
>> >
>>
>> Because someone might think that if he took 7 elements, then he has 7
>> elements, so it is good that he knows earlier that this is not the case. I
>> don't see a point in referring to Haskell documentation when discussing
>> Scheme functions, though (if you try Racket, you'll note that although its
>> take has a reversed order of arguments compared to srfi-1, it still doesn't
>> allow to take or drop a positive number of elements from an empty list)
>>
>> I agree though that the srfi-1 document isn't explicit enough about this
>> point.
>
> Yes.   Srfi-1 ( http://srfi.schemers.org/srfi-1/srfi-1.html ) says that drop
> "is exactly equivalent to performing i cdr operations on x", and notes that for
> car and cdr "it is an error to apply them to the empty list"
>
> Also for take and drop: "For a legal i, take and drop partition the list in a manner which can be inverted with append"
> Implying that not all i are "legal".

Ok. Apart from the fact that it's written in srfi, I wonder what the
reasoning for such behavior is. I mean, what makes the "i" bigger than
the length of the list so illegal that you have to bail out? When is
such behavior useful? On the other hand, not having to worry about the
list length is very useful. Because now my code is littered with
things like

;; Let's hope that string-length is O(1).
(if (>= width (string-length item))
    item
    (string-take item width))

or

(if (string-null? text)
    ""
    (string-drop-right text 1))

Maybe I'm just doing something wrong?

Cheers,
-- 
Jan Synáček

Re: srfi-1 take and drop seriously broken

[Panicz Maciej Godek]

[-- Attachment #1: Type: text/plain, Size: 1696 bytes --]

2016-11-21 8:34 GMT+01:00 Jan Synáček <jan.synacek@gmail.com>:

>
> Ok. Apart from the fact that it's written in srfi, I wonder what the
> reasoning for such behavior is. I mean, what makes the "i" bigger than
> the length of the list so illegal that you have to bail out? When is
> such behavior useful? On the other hand, not having to worry about the
> list length is very useful. Because now my code is littered with
> things like
>
> ;; Let's hope that string-length is O(1).
> (if (>= width (string-length item))
>     item
>     (string-take item width))
>
> or
>
> (if (string-null? text)
>     ""
>     (string-drop-right text 1))
>
> Maybe I'm just doing something wrong?
>

The variants of take and drop that you'd like to have would need
to perform additional checks in order to find out whether the object
that you are trying to drop or take is a pair.
When it comes to your code, it's really hard to say if you're doing
something wrong or not, because it doesn't say why you're doing
what you're doing. But in the case of string operations it is often more
convenient to use regular expressions. (However, I admit that I rarely
have the need to use take-upto and drop-upto functions. I ofen use
the split-at function, and I really appreciate that it throws an error
when invoked with an index that lies beyond a given list; otherwise, I'd
have to worry about silent errors that could appear in my code.
Likewise, you could have (car '()) and (cdr '()) return an empty list,
which would make your code "fool proof", but I don't think it would
have good implications in the long run. Anyway, even Haskell's head
and tail don't work like that)

[-- Attachment #2: Type: text/html, Size: 2311 bytes --]