Re: [Scheme-reports] multiple values module

[Eli Barzilay <eli@x>]

50 minutes ago, Andy Wingo wrote:
> On Wed 25 May 2011 08:41, Eli Barzilay <eli@x> writes:
> 
> > optimization details that are irrelevant as far as justifying a
> > language semantics
> 
> Surely they are somewhat relevant, or at least have been in the
> past.  Recall the opposition to an N**2 expansion algorithm...

Yeah, you're right -- I should have qualified that optimizations that
are overall as minor as this are not relevant.


> > (You can see that also in the fact that (IIRC) the paper properly
> > checks for the right number of values, a requirement that John is
> > eager to ignore as long as r5rs is not explicity requiring.)
> 
> It's not just John, it's at least me and Peter as well ;-)

To make John's point: would you similarly want to ignore (car #f) and
(cons 1 2 3) throwing errors?  More importantly, is there any point to
an implementation that would do something else?  In the context of
multiple values, not throwing an error when a continuation is applied
to the right number of arguments greatly reduces their utility (as far
as a common convention goes).  Chibi's problem, in a more direct piece
of code:

  (call-with-values
    (lambda ()
      (call-with-current-continuation (lambda (k) (k 1 2 3))))
    (lambda (x y z) 'ok))

is more serious -- it passes the right number of values and you still
get an error.  R5RS does dictate a specific semantics for this:

  Calls its producer argument with no values and a continuation that,
  when passed some values, calls the consumer procedure with those
  values as arguments.

BTW, you all (you, John, Peter) represent different ranges of how you
want to break things: Peter talked about chicken's behavior of
dropping extra values but there's no reification; guile breaks (I*M*O)
things further and reifies values but still respects the above; John
doesn't care what happens at all, and even referred directly to C
demons.


> (Seriously though Eli: you are usually right, but you don't always
> make your point well.  If your goal is to influence the standard,
> then antagonizing the editors probably isn't the right strategy.)

In all seriousness,

* I really have no intention to influence the standard in any way what
  so ever.

* I intentionally avoided the whole thing because I take this whole
  thing of "it didn't say that this *must* throw an error" as
  unproductive hair splitting.  Specifically, in *my* opinion, the
  story of multiple values wrt continuations makes sense, and any
  wording that allows chibi's implementation is something that *I*
  take as a bug that should be fixed.

  If you want to allow it, say it explicitly.  Make it very clear that
  there's this gaping hole in the functionality.  But telling the
  whole MV & cont. story and then allowing chibi's implementation
  implicitly, by omissions of some random "should"s or "must"s is
  weaseling out.  MV's utility is reduced just the same, but you have
  to use a magnifying glass to realize that you've been cheated.  This
  kind of fine-print cheating is something that I consider obnoxious
  in legal documents (eg, leases or EULAs), but in a language
  specification it's worse.

* But again, that's just my opinion.  I've said in the past that I
  hated seeing Scheme loses time after time for all kinds of bad
  languages -- it'll be sad to see r7rs taking the language further
  back.  It'll also be sad to see Scheme becoming more of a "Scheme".
  But at this point it looks to me like this is all inevitable,
  which is why I don't have any expectations.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!

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