[Larceny-users] writing values writes the first value only

[Marco Maggi]

Ciao,

using Larceny checkout 6282 on i686-pc-linux-gnu I see:

(write (values 123 456))
=> 123

while Ikarus raises an "incorrect number of values returned
to single value context" error, and Ypsilon prints "#<values
123 456>". Larceny's behaviour is confusing when WRITE is
used for debugging purposes. Can something be done?

I do not want to enter a debate over the True Semantic
Meaning of things, I just want some help when debugging.

TIA

P.S. Sorry if this has been discussed before. Is there a
way to search the mailing list archive better than a row
google search on "larceny-users write values"?

[w***@ccs.neu.edu]

Post by Marco Maggi
(write (values 123 456))
=> 123

That is correct behavior for Larceny, whose semantics for
multiple values is mostly compatible with Common Lisp, which
provided the original model for Scheme's multiple values.

Post by Marco Maggi
while Ikarus raises an "incorrect number of values returned
to single value context" error, and Ypsilon prints "#<values
123 456>". Larceny's behaviour is confusing when WRITE is
used for debugging purposes. Can something be done?

Ikarus and some other systems are incompatible with both
Ypsilon and Larceny in this respect. Similarly, Ypsilon's
behavior is incompatible with both Ikarus and with Larceny.
All of those behaviors are permitted by both the R5RS and by
the R6RS. The bottom line is that passing zero values or more
than one value to an ordinary continuation (which expects one
value) has undefined semantics. (As of the R6RS, command
continuations are no longer ordinary continuations, but R5RS
command continuations are ordinary, so there is a definite
incompatibility between the R5RS and R6RS here also.)

Post by Marco Maggi
I do not want to enter a debate over the True Semantic
Meaning of things, I just want some help when debugging.

This has long been a source of contention within the Scheme
community, and it is unlikely that consensus will be achieved
within the forseeable future. To detect non-portable code,
your best bet is to define your own abstractions for multiple
values and to give them your own favored semantics. In short,
you may want to deprecate multiple values within your own code.

The R6RS library system gives you the power to define your own
base library absent multiple values, and you can wrap your own
abstractions around all inter-library calls to perform whatever
run-time checking you consider appropriate (if you distrust
libraries that may use multiple values internally).

Post by Marco Maggi
P.S. Sorry if this has been discussed before. Is there a
way to search the mailing list archive better than a row
google search on "larceny-users write values"?

Not that I know.

Will

[David Rush]

Post by w***@ccs.neu.edu
To detect non-portable code,
your best bet is to define your own abstractions for multiple
values and to give them your own favored semantics.  In short,
you may want to deprecate multiple values within your own code.

What he said. Doubled and Squared. This is one of those things where
the explicit use of a continuation function is both conceptually
cleaner and easier to use than the built-in solution (CALL_WITH_VALUES
? !! ick...)

DISCLAIMER: I am part of the multiple-values is evil camp

david rush

[Abdulaziz Ghuloum]

Post by David Rush
This is one of those things where
the explicit use of a continuation function is both conceptually
cleaner and easier to use than the built-in solution

This is self-contradictory. If you believe continuations should take
a single value only, then you should apply the same principle to your
continuations too. If your continuations take multiple values, then
why do you feel icky when built-in continuations do the same?

Aziz,,,

[with apologies to the original poster who explicitly did intend to
start this argument]

[David Rush]

Post by Abdulaziz Ghuloum

Post by David Rush
This is one of those things where
the explicit use of a continuation function is both conceptually
cleaner and easier to use than the built-in solution

This is self-contradictory.

No it isn't.

Post by Abdulaziz Ghuloum
If you believe continuations should take
a single value only, then you should apply the same principle to your
continuations too.

An explicit continuation is simply a function called in tail-position.
There's nothing at all wrong with such a function having multiple
arguments. The problem is with Scheme's *hack* involving
CALL-WITH-VALUES, which leads to the OP's confused situation.

Post by Abdulaziz Ghuloum
If your continuations take multiple values, then
why do you feel icky when built-in continuations do the same?

Because they are inconsistent. In point of fact, I feel that all
functions should only take a single argument, whether they be
system-reified continuation functions or user functions. Of course,
some additional machinery would be required for destructuring
anonymous aggregates, but people keep reinventing ML pattern matching
for the Scheme environment anyway...

[with apologies to anyone who thinks there is an argument brewing here]

david rush

[Felix Klock]

Will (cc'ing Marco and larceny-users)-

Post by w***@ccs.neu.edu

Post by Marco Maggi
(write (values 123 456))
=> 123

That is correct behavior for Larceny, whose semantics for
multiple values is mostly compatible with Common Lisp, which
provided the original model for Scheme's multiple values.

Post by Marco Maggi
while Ikarus raises an "incorrect number of values returned
to single value context" error, and Ypsilon prints "#<values
123 456>". Larceny's behaviour is confusing when WRITE is
used for debugging purposes. Can something be done?

Ikarus and some other systems are incompatible with both
Ypsilon and Larceny in this respect. Similarly, Ypsilon's
behavior is incompatible with both Ikarus and with Larceny.
All of those behaviors are permitted by both the R5RS and by
the R6RS. The bottom line is that passing zero values or more
than one value to an ordinary continuation (which expects one
value) has undefined semantics. (As of the R6RS, command
continuations are no longer ordinary continuations, but R5RS
command continuations are ordinary, so there is a definite
incompatibility between the R5RS and R6RS here also.)

So I was just musing... if we throw portability across different
schemes out the window, but still wish to retain backwards
compatibility with past variants of Larceny... how hard do you think
it would be to make procedure-arity "work" on first class
continuations in Larceny?

Post by w***@ccs.neu.edu
(call-with-values (lambda () (call-with-current-continuation

(lambda (k) (values (procedure-
arity k) 'ignored))))
(lambda (x y) (list x y)))
(0.0 ignored)

But I do not see an immediate reason why the continuation could not
sometimes stash away the number of values it expects (particularly for
the case when that information is directly derivable from the
procedure-arity of the second argument to call-with-values).

If procedure-arity (or really, call-with-current-continuation, right?)
were thus enhanced, one could then write a (slower, variant)
replacement for the values procedure that attempts to check for when
the wrong number of values are passed in.

Thoughts?

-Felix

[w***@ccs.neu.edu]

Post by Felix Klock
So I was just musing... if we throw portability across different
schemes out the window, but still wish to retain backwards
compatibility with past variants of Larceny... how hard do you think
it would be to make procedure-arity "work" on first class
continuations in Larceny?

As Larceny is currently constructed, I don't think there's
any reliable way to distinguish ordinary one-argument
continuations from command continuations. This is wired
deeply into the system, at the level of Twobit's A-normal
form.

Since the R6RS requires command continuations to accept
any number of arguments, Larceny's ordinary continuations
have to accept any number of arguments also. To change
that, we'd have to change some of Larceny's basic
invariants and one of Twobit's primary intermediate
languages.

Will