Mark H Weaver <m...@netris.org> writes: > I'm sorry David, but _everything_ that you wrote below is incorrect.
Well, let me try again. It's not all that easy to understand. > David Kastrup <d...@gnu.org> writes: > >> Chris Marusich <cmmarus...@gmail.com> writes: >> >>> I think I'm missing something here. In (list (f)), the call to f >>> certainly looks like it's happening at a position that one might >>> intuitively call a "tail" position. >> >> It is, > > No it isn't. > >> but list does not take multiple values > > Yes it does. 'list' accepts an arbitrary number of values > (arguments). In my book, multiple values/arguments are different things but I admit that this is a quagmire to me and strictly speaking what I call "multiple values" (namely the unmitigated return value from calling values) never occurs in the position of an argument (at least when not looking at the C API and/or Guile 1.x). dak@lola:/usr/local/tmp/lilypond$ guile-2.0 GNU Guile 2.0.13 Copyright (C) 1995-2016 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)> (list (values 1 2 3)) $1 = (1) scheme@(guile-user)> >> and thus discards additional values returned by f. > > 'list' does not discard anything. The additional values are discarded > before 'list' is called. Ok. Because a function call cannot take multiple values. It does take multiple _arguments_. A function call can appear to return multiple values by using call/cc (which is essentially what (values ...) does) and the construct call-with-values can salvage them as long as they are only passed through tail calls (or rather tail returns): (call-with-values (lambda () (call/cc (lambda (c) (c 1 2 3)))) list) => (1 2 3) Basically call-with-values is a mechanism that lets the continuation delivered by call/cc be a function accepting multiple arguments. An ordinary function call doesn't. > I will try to clarify all of this in another message. Well, I probably messed up things a whole lot more now. But at least it should be an excellent opportunity for correcting the half-truths and misconceptions that Scheme's procedure/continuation model might inspire in people (like me) without a firm grasp of its concepts. -- David Kastrup