No, that's a misunderstanding. class100 forces us to make contracts for class.ss unsound. We need to change the latter (a tiny bit) and most of the uses of 'bad' stuff is in class100
-- Matthias On Nov 23, 2009, at 6:39 AM, Robby Findler wrote: > I think they'd have to say that the contract system is unsound if > class100 is present. But perhaps it can just be treated the same was > as (require unsafe/...). > > Robby > > On Mon, Nov 23, 2009 at 2:41 AM, Michael Sperber > <sper...@deinprogramm.de> wrote: >> >> Stevie Strickland <sstri...@ccs.neu.edu> writes: >> >>> On Nov 23, 2009, at 2:09 AM, Michael Sperber wrote: >>>> You're saying that leaving class100 as-is (i.e. without contracts) is >>>> harder than zapping it, right? (I'm totally not interested in >>>> contracts >>>> for class100.) >>> >>> Right. The class100 forms rewrites into uses of class* from scheme/ >>> class, and some of the changes needed would also require extending the >>> class100 forms, which means they'd no longer be strictly the same >>> interface as the old PLT class system. Thus, this seemed like an >>> ideal time to just remove the deprecated interface, since there is no >>> reason of which I'm aware that classes written using mzlib/class100 >>> cannot be straightforwardly ported to scheme/class. >> >> I was hoping you could just copy the old code and leave it in place. >> But if it creates any amount of work, by all means delete it. >> >> -- >> Cheers =8-} Mike >> Friede, Völkerverständigung und überhaupt blabla >> _________________________________________________ >> For list-related administrative tasks: >> http://list.cs.brown.edu/mailman/listinfo/plt-dev >> > _________________________________________________ > For list-related administrative tasks: > http://list.cs.brown.edu/mailman/listinfo/plt-dev _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev