because it pointed out a bug in my implementation where we weren't getting
the right version of the super method (which gets the projection).
svn: r18180
For example, if we're in the java part of a beta-java chain, can we still add
an inner contract? If so, it should affect each java-style overriding method
until we reach the next beta-style augmenting method.
It can just be confusing, because one might thing that inner in a
contract => needs an augmenting method in the subclass, super => needs
an overriding method in the subclass. The latter is true, since only
the next immediate method can reach the super class's implementation,
but inner jumps to the next augmenting method, so the former isn't
necessarily true.
svn: r18179
an overrideable method (augride is okay), whereas override contracts require
a method which has never been augmentable (i.e. no pubments or overments).
svn: r18162
Eventually the latter will become a table to vectors of methods instead, but
until I start handling override/augment contracts, we can use the simplified
version.
svn: r18153
Scheme) to look for the appropriate method to wrap, which makes Robby's
object-contracts appropriately translucent during contract wrapping.
svn: r18102
if it's coming from a file -- not when it's a string. In that case, use
`#f' for the name, so other code (specifically, `input->code') will use
'program.
svn: r17987
generator. This will make this:
(generator (yield 1) (yield))
also repeat #<void> when it's done which will be very confusing. Better
just add a note in the docs on (generator (yield 1)) returning no values
when it's done.
Also, remove some of the `case-lambda' optimizations...
svn: r17983
generator. (Also considered making it an error when the generator is
called while it is running, but that doesn't allow (yield (yield X))
fun.)
svn: r17982
For example,
(define g (generator (yield (yield (yield 1)))))
(list (g) (g 2) (g 3) (g 4) (g) (g))
evaluates to '(1 2 3 4 4 4). This is something that Python does (as a
generator.send method), which might be useful for using generators as
co-routines, and it is actually easy to implement since sending values
is exactly what we get when the generator call is actually calling the
saved continuation. So most of the change is dealing with the
technicalities of throwing an error when the generator is called with
some arguments, when that's done after it's terminated (at the stage
where it's repeating the last value for ever).
A few tests added for this.
svn: r17979
return any number of values. They will be collected and used as the
repeat-forever result of calling the generator again.
Note: there's an exception for using no values -- instead of returning
no values forever, use void, since no values can be more surprising, and
it can happen when someone uses something like
(generator (yield 1) (yield 2) (yield 3))
since the result of `yield' is (values). (This will change in a
following commit, but even then it will be popular since people will
usually invoke the generator with no arguments which leads to the zero
values. Could be solved if you use (g (void)) -- but that's awkward, I
think.)
svn: r17978
