Re: [Scheme-reports] Formal Comment: R7RS 'eqv?' cannot be used for reliable memoization

[Ray Dillinger <bear@x>]

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

On 11/21/2012 06:34 PM, Vassil Nikolov wrote:
> 
> On Tue, 20 Nov 2012 00:57:19 -0800, Ray Dillinger <bear@x>
> said:
>> ... Branch cut selectors are strictly unnecessary in a language
>> that has the ability to return multiple values from a function;
>> the alternative is to simply return both (or all) answers at
>> non-continuous points.
> 
> I wonder if this road doesn't lead further along to returning 
> infinitely many values.  There are (probably) ways to handle that
> as well, but beyond the remit of the R7RS working groups...
> 

There's a semantic difference between returning multiple values
and returning multivalences as values.

A function like integer-division may return multiple values;
the quotient and the remainder.  But these values have different
semantic loading, and it's important that the continuation, if it
captures and binds both values, remembers a different meaning for
each.

A function like square-root, OTOH, may return a multivalence;
2 and -2 for example are both equally true answers for the square
root of 4.  These values have the same semantic loading; they are
both answers to the same question.  The same is true of, eg,
database queries, etc.

In Lispy languages, we tend to fake both by using lists.  But
that is, IMO, not quite right.  Sometimes the difference is
important and we'd like to know more about the meaning conveyed.
Using the same abstraction for both tends to lose information.

As Mark Weaver pointed out, if you have multivalences, you will
usually be required to select *one* of them because some client
somewhere won't want to know their question had more than one
answer.  And in fact, will demand to be kept in ignorance, treating
additional correct answers as a bug.


				Bear
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQsDRnAAoJEAOzWkqOibfNFLkH+gM5FN0pnJPkf06x5tJtVdRS
WISJzHJeBir4J0GL5ifECYmVkShugg0KQGWeSlAJGQMENHIxrd9cY1yc+QCy1vBS
CNGQX3gPJ/oIFqYFWXWds5pzfJX4PG7oRc6TnLVIPLuvejNn18oLPZMj4OgWAQNo
E+apB3+eF9XpWLNe1fNMjL/fq/Z+OHyKK8xxYDWN4Dg+F9IUowigdHebESFOfP7b
VvdytFNWSGBho3C0okSZ5GuPf0GgKM7xR1MwbCSe5aNk09kMxfVgILqHBXLT5fIq
ZQXcniGmyE3Osx/Dvj2H2hbtABwdHJXQKItu49zXzXZZM/3iKunTI3tFRthcM1w=
=evtU
-----END PGP SIGNATURE-----

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports