Re: [plt-dev] Objections to removing class100?
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
Re: [plt-dev] Objections to removing class100?
On Nov 23, 2009, at 6:39 AM, Robby Findler wrote: On Mon, Nov 23, 2009 at 2:41 AM, Michael Sperber sper...@deinprogramm.de wrote: 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. 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/...). Just in case I didn't make it clear earlier, the class system represented by mzlib/class100 is not a separate implementation, but rather a thin veneer over scheme/class that merely allows for the same syntactic interface as that of the earlier, v103-era class system. To keep mzlib/class100 around and completely unaltered in both syntax and semantics, I would need to preserve an older version of scheme/class and thus maintain two large implementations of class systems that differed only in slight, but important, ways. To then allow the two class systems to interoperate, which is currently the case, all operations on objects and classes of each would need to be aware of implementation details of the other, which would add much complexity to both. Stevie_ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] Objections to removing class100?
What changes to scheme/class do you need to be able to have the right contract system? Robby On Monday, November 23, 2009, Stevie Strickland sstri...@ccs.neu.edu wrote: On Nov 23, 2009, at 6:39 AM, Robby Findler wrote: On Mon, Nov 23, 2009 at 2:41 AM, Michael Sperber sper...@deinprogramm.de wrote: 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. 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/...). Just in case I didn't make it clear earlier, the class system represented by mzlib/class100 is not a separate implementation, but rather a thin veneer over scheme/class that merely allows for the same syntactic interface as that of the earlier, v103-era class system. To keep mzlib/class100 around and completely unaltered in both syntax and semantics, I would need to preserve an older version of scheme/class and thus maintain two large implementations of class systems that differed only in slight, but important, ways. To then allow the two class systems to interoperate, which is currently the case, all operations on objects and classes of each would need to be aware of implementation details of the other, which would add much complexity to both. Stevie_ 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
Re: [plt-dev] Objections to removing class100?
Stevie Strickland sstri...@ccs.neu.edu writes: On Nov 23, 2009, at 6:39 AM, Robby Findler wrote: On Mon, Nov 23, 2009 at 2:41 AM, Michael Sperber sper...@deinprogramm.de wrote: 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. 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/...). Just in case I didn't make it clear earlier, the class system represented by mzlib/class100 is not a separate implementation, but rather a thin veneer over scheme/class that merely allows for the same syntactic interface as that of the earlier, v103-era class system. To keep mzlib/class100 around and completely unaltered in both syntax and semantics, I would need to preserve an older version of scheme/class and thus maintain two large implementations of class systems that differed only in slight, but important, ways. To then allow the two class systems to interoperate, which is currently the case, all operations on objects and classes of each would need to be aware of implementation details of the other, which would add much complexity to both. As I said: As far as I'm concerned, zap it. Thanks for explaining the rationale! -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] Objections to removing class100?
Stevie Strickland sstri...@ccs.neu.edu writes: Well, I've been thinking, and I have a question for you: do you ever pass super-init any arguments in your uses of class100? Yes. If you don't, then I can likely provide something that'll work for you with no changes at all. If you do, and that use of super-init is not at the class top-level, then I still may be able to do so with only a couple changes needed to your code (an example of how you use it might be useful for determining whether this is the case). It really isn't worth your effort: If I'm going to make any changes at all, I might as well convert to the new classes. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] Objections to removing class100?
Stevie Strickland sstri...@ccs.neu.edu writes: We're interested in finally removing class100 from PLT Scheme. Are there any objections? I'm a user, but not a heavy one. Is it significant work to keep it in? -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] Objections to removing class100?
On Nov 20, 2009, at 2:53 PM, John Clements wrote: On Nov 20, 2009, at 11:37 AM, Stevie Strickland wrote: We're interested in finally removing class100 from PLT Scheme. Are there any objections? Are you planning on asking plt-edu, as well? I'm guessing that's where you'll find the holdouts. A good point. I'm not on plt-edu, though. Matthias? Stevie_ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
