* srfi-1 take and drop seriously broken @ 2016-11-19 18:34 Jan Synáček 2016-11-19 21:18 ` Jan Nieuwenhuizen 2016-11-19 22:55 ` Panicz Maciej Godek 0 siblings, 2 replies; 12+ messages in thread From: Jan Synáček @ 2016-11-19 18:34 UTC (permalink / raw) To: guile-devel 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: srfi-1 take and drop seriously broken 2016-11-19 18:34 srfi-1 take and drop seriously broken Jan Synáček @ 2016-11-19 21:18 ` Jan Nieuwenhuizen 2016-11-19 21:52 ` tomas 2016-11-20 10:39 ` Jan Synáček 2016-11-19 22:55 ` Panicz Maciej Godek 1 sibling, 2 replies; 12+ messages in thread From: Jan Nieuwenhuizen @ 2016-11-19 21:18 UTC (permalink / raw) To: Jan Synáček; +Cc: guile-devel 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: srfi-1 take and drop seriously broken 2016-11-19 21:18 ` Jan Nieuwenhuizen @ 2016-11-19 21:52 ` tomas 2016-11-20 3:32 ` Eli Zaretskii 2016-11-20 10:39 ` Jan Synáček 1 sibling, 1 reply; 12+ messages in thread From: tomas @ 2016-11-19 21:52 UTC (permalink / raw) To: guile-devel -----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----- ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: srfi-1 take and drop seriously broken 2016-11-19 21:52 ` tomas @ 2016-11-20 3:32 ` Eli Zaretskii 2016-11-20 10:18 ` tomas 0 siblings, 1 reply; 12+ messages in thread From: Eli Zaretskii @ 2016-11-20 3:32 UTC (permalink / raw) To: tomas; +Cc: guile-devel > 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: srfi-1 take and drop seriously broken 2016-11-20 3:32 ` Eli Zaretskii @ 2016-11-20 10:18 ` tomas 0 siblings, 0 replies; 12+ messages in thread From: tomas @ 2016-11-20 10:18 UTC (permalink / raw) To: Eli Zaretskii; +Cc: guile-devel -----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----- ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: srfi-1 take and drop seriously broken 2016-11-19 21:18 ` Jan Nieuwenhuizen 2016-11-19 21:52 ` tomas @ 2016-11-20 10:39 ` Jan Synáček 1 sibling, 0 replies; 12+ messages in thread From: Jan Synáček @ 2016-11-20 10:39 UTC (permalink / raw) To: Jan Nieuwenhuizen; +Cc: guile-devel 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: srfi-1 take and drop seriously broken 2016-11-19 18:34 srfi-1 take and drop seriously broken Jan Synáček 2016-11-19 21:18 ` Jan Nieuwenhuizen @ 2016-11-19 22:55 ` Panicz Maciej Godek 2016-11-20 10:42 ` Jan Synáček 1 sibling, 1 reply; 12+ messages in thread From: Panicz Maciej Godek @ 2016-11-19 22:55 UTC (permalink / raw) To: Jan Synáček; +Cc: guile-devel [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: srfi-1 take and drop seriously broken 2016-11-19 22:55 ` Panicz Maciej Godek @ 2016-11-20 10:42 ` Jan Synáček 2016-11-20 11:23 ` Panicz Maciej Godek 0 siblings, 1 reply; 12+ messages in thread From: Jan Synáček @ 2016-11-20 10:42 UTC (permalink / raw) To: Panicz Maciej Godek; +Cc: guile-devel 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: srfi-1 take and drop seriously broken 2016-11-20 10:42 ` Jan Synáček @ 2016-11-20 11:23 ` Panicz Maciej Godek 2016-11-20 18:31 ` dsmich 0 siblings, 1 reply; 12+ messages in thread From: Panicz Maciej Godek @ 2016-11-20 11:23 UTC (permalink / raw) To: Jan Synáček; +Cc: guile-devel [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: srfi-1 take and drop seriously broken 2016-11-20 11:23 ` Panicz Maciej Godek @ 2016-11-20 18:31 ` dsmich 2016-11-21 7:34 ` Jan Synáček 0 siblings, 1 reply; 12+ messages in thread From: dsmich @ 2016-11-20 18:31 UTC (permalink / raw) To: Panicz Maciej Godek, Jan Synáček; +Cc: guile-devel ---- 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: srfi-1 take and drop seriously broken 2016-11-20 18:31 ` dsmich @ 2016-11-21 7:34 ` Jan Synáček 2016-11-21 10:21 ` Panicz Maciej Godek 0 siblings, 1 reply; 12+ messages in thread From: Jan Synáček @ 2016-11-21 7:34 UTC (permalink / raw) To: dsmich; +Cc: guile-devel 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: srfi-1 take and drop seriously broken 2016-11-21 7:34 ` Jan Synáček @ 2016-11-21 10:21 ` Panicz Maciej Godek 0 siblings, 0 replies; 12+ messages in thread From: Panicz Maciej Godek @ 2016-11-21 10:21 UTC (permalink / raw) To: Jan Synáček; +Cc: guile-devel [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2016-11-21 10:21 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-11-19 18:34 srfi-1 take and drop seriously broken Jan Synáček 2016-11-19 21:18 ` Jan Nieuwenhuizen 2016-11-19 21:52 ` tomas 2016-11-20 3:32 ` Eli Zaretskii 2016-11-20 10:18 ` tomas 2016-11-20 10:39 ` Jan Synáček 2016-11-19 22:55 ` Panicz Maciej Godek 2016-11-20 10:42 ` Jan Synáček 2016-11-20 11:23 ` Panicz Maciej Godek 2016-11-20 18:31 ` dsmich 2016-11-21 7:34 ` Jan Synáček 2016-11-21 10:21 ` Panicz Maciej Godek
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).