Re: [racket-dev] DrDr - previous/next change buttons
On Jul 31, 2012, at 3:57 PM, Jay McCarthy wrote: > Done :) Thanks! John smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] DrDr - previous/next change buttons
Done :) Jay On Mon, Jul 30, 2012 at 5:57 PM, John Clements wrote: > > On Jul 30, 2012, at 5:42 PM, Jay McCarthy wrote: > >> DrDr now has green buttons to go between times the file's output has >> changed. Hopefully this will help you find problematic commits easier. > > Here's what I think is a super-minor request. When I view the diff of two > DrDr outputs; say: > > http://drdr.racket-lang.org/diff/25068/25067/collects/tests/stepper/automatic-tests.rkt > > I see the new one on the left, and the old one on the right, which is a bit > confusing to me. Perhaps what I'm really asking is that the link on the page > > http://drdr.racket-lang.org/25068/collects/tests/stepper/automatic-tests.rkt > > link to > > http://drdr.racket-lang.org/diff/25067/25068/collects/tests/stepper/automatic-tests.rkt > > instead (that is, with the old one appearing first in the URL). > > John > > >> >> Jay >> >> -- >> Jay McCarthy >> Assistant Professor / Brigham Young University >> http://faculty.cs.byu.edu/~jay >> >> "The glory of God is Intelligence" - D&C 93 >> _ >> Racket Developers list: >> http://lists.racket-lang.org/dev > -- Jay McCarthy Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket 5.2 on OpenBSD and --enable-backtrace
On 07/31/12 15:37, Matthew Flatt wrote: At Mon, 30 Jul 2012 01:50:22 +0200, Juan Francisco Cantero Hurtado wrote: Hi. I've a question about --enable-backtrace in the configure step. Is it useful for the users or only is useful for the racket developers?. This option affect to the performance of racket?. It's potentially useful to users, but it's expensive. You shouldn't include it in a normal build. OK. Disabled. I'm not a scheme/racket developer. I'm just the racket maintainer on OpenBSD [1]. I'm using this configure options: --enable-shared --enable-libffi --enable-gracket --enable-jit --enable-foreign --enable-places --disable-futures --enable-float --enable-docs --enable-backtrace --enable-pthread Unless you have a particular reason to disable futures, I'd enable that one. "make install" fails with "futures" enabled. My goal now is to create a stable package of Racket for OpenBSD. I'll open a bug related to "futures" when I finish the package. Thanks for the help! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)
At Tue, 31 Jul 2012 13:04:40 -0600, Matthew Flatt wrote: > > At Tue, 31 Jul 2012 14:08:16 -0400, Vincent St-Amour wrote: > > Mutable pair functions are in `racket/base', I didn't touch these and am > > not planning to. Mutable list functions, though, I moved. The name is > > misleading. > > Should `compatibility/mpair' be `compatibility/mlist' (while > `racket/mpair' keeps the misleading name)? Good idea. I'll do that. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)
At Tue, 31 Jul 2012 14:08:16 -0400, Vincent St-Amour wrote: > Mutable pair functions are in `racket/base', I didn't touch these and am > not planning to. Mutable list functions, though, I moved. The name is > misleading. Should `compatibility/mpair' be `compatibility/mlist' (while `racket/mpair' keeps the misleading name)? _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] A Const type constructor
At Tue, 31 Jul 2012 14:36:06 -0400, Matthias Felleisen wrote: > > On Jul 31, 2012, at 1:31 PM, Neil Toronto wrote: > > > To reiterate after my absence: I won't write a typed math/vector > > until using its exports in Typed Racket wouldn't be a huge friggin' > > PITA. > > Let me rephrase this ever so gently. Typed Racket has failed at least > one real test for now, namely, writing a highly usable math library. Agreed. The invariance of vectors is a pretty big usability problem here. > I think this is a fair judgment, and you are posing the obvious, not so > implied problem to the TR maintainers to fix this problem. They should > thank you on their knees, especially Vincent. Yes, Sam and I should fix this. Neil: I'll study your proposal in detail, and see how we could add it (or something similar) to TR. Thanks for taking the time to write it out. I'll have a look at what Scala does, too. AFAIK, they also have invariant vectors and more than one numeric type, so they probably have similar problems. > > To offer a carrot instead of a stick: There could be a short paper > > in this, titled "The Case for a Clean, Correct, Covariant Const". > > That is what I was thinking as I was reading your message. I have not > encountered such a proposal/language before, and I think it could be a > really neat extension of Vincent's PADL work. Agreed. > Perhaps the two of you > should work out the details together and submit follow-up to PADL > n+1. Oh never mind, D stands for declarative. So ship it to ICFP next > year, functional languages do include mutation. Sounds good to me. Neil: let's continue this discussion off-list. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] A Const type constructor
On Jul 31, 2012, at 1:31 PM, Neil Toronto wrote: > To reiterate after my absence: I won't write a typed math/vector until using > its exports in Typed Racket wouldn't be a huge friggin' PITA. Let me rephrase this ever so gently. Typed Racket has failed at least one real test for now, namely, writing a highly usable math library. I think this is a fair judgment, and you are posing the obvious, not so implied problem to the TR maintainers to fix this problem. They should thank you on their knees, especially Vincent. > To offer a carrot instead of a stick: There could be a short paper in this, > titled "The Case for a Clean, Correct, Covariant Const". That is what I was thinking as I was reading your message. I have not encountered such a proposal/language before, and I think it could be a really neat extension of Vincent's PADL work. Perhaps the two of you should work out the details together and submit follow-up to PADL n+1. Oh never mind, D stands for declarative. So ship it to ICFP next year, functional languages do include mutation. -- Matthias smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)
At Tue, 31 Jul 2012 07:42:53 -0600, Matthew Flatt wrote: > > At Mon, 30 Jul 2012 19:45:07 -0400, Vincent St-Amour wrote: > > At Mon, 30 Jul 2012 14:52:06 -0600, > > Matthew Flatt wrote: > > > If we really want to have two names for these things --- the > > > compatibility name and the "compatibility" name --- then I think we > > > should at least consolidate to a single compatibility manual by moving > > > the documentation for `racket/mpair' and `racket/package' to the > > > compatibility manual. > > > > To make sure I understand correctly, you're suggesting that: > > > > - We keep the `compatibility' collect. > > - We keep `compatibility/defmacro'. > > - We remove `compatibility/mpair' and `compatibility/package', and move > > them back to `racket/mpair' and `racket/package', respectively. > > - We leave the reference and the compatibility manual as is, with docs > > for `racket/mpair' and `racket/package' in the compatibility manual. > > > > If that's what you're suggesting, I'll implement it. > > I'm sorry that I've been so unclear! > > To start afresh, here are two suggestions, which are mutually > exclusive. The first is my preference: > > 1. Revert the addition of `compatibility/package' and > `compatibility/mpair', including the documentation changes (but > maybe add back some text to discourage misuse of these libraries). > > 2. Leave things as they are, but move the sections that document > `racket/package' and `racket/mpair' out of the Reference and into > the same "Compatibility" document that describes > `compatibility/package' and `compatibility/mpair'. I'll go with the second one. I think it makes it clearer that these features are not Rackety. Thanks for clarifying! Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)
At Tue, 31 Jul 2012 09:26:56 -0700, Sam Tobin-Hochstadt wrote: > > On Tue, Jul 31, 2012 at 6:42 AM, Matthew Flatt wrote: > > > > To start afresh, here are two suggestions, which are mutually > > exclusive. The first is my preference: > > > > 1. Revert the addition of `compatibility/package' and > > `compatibility/mpair', including the documentation changes (but > > maybe add back some text to discourage misuse of these libraries). > > I definitely think we should keep `mpair` as a more-than-compatibility > library. It's useful in real data structures, and it's nice not to > have to roll your own mutable linked list when it's the right choice. Mutable pair functions are in `racket/base', I didn't touch these and am not planning to. Mutable list functions, though, I moved. The name is misleading. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] A Const type constructor
On 07/25/2012 07:10 PM, D Herring wrote: On 07/25/2012 12:29 PM, Neil Toronto wrote: What if TR had a notion of const-ness, like in C? Suppose (Vectorof A) is a subtype of (Const-Vectorof B) when A is a subtype of B, and (Const-Vectorof A) is never a subtype of (Vectorof B). In C, "const" is a contract on the function type, not on the parameter data type. This can be a very useful contract. Once const applies to a variable, it becomes sticky and requires an explicit (and easily searched) const_cast downgrade to become mutable again. This can be useful and quite annoying. Using const in one spot often causes a snowball effect where it must be manually propagated to other function prototypes. C++ allows certain fields to be marked as mutable, even when the containing object is const. A more dynamic language might be able to decorate the value instead of the function, or at least infer const-ness where possible? Here's a possible way to make the "snowball"-ness less of an issue: have a Mutable constructor instead, and make (Vectorof A) mean (Const (Vectorof A)). Of course, that would mean functions should accept (Vectorof A) and return (Mutable (Vectorof A)), unless they actually return an immutable vector Here's a better idea. Let's say we want to type `vector-sqrt'. The best way using Const would be vector-sqrt : (Const (Vectorof Number)) -> (Vectorof Number) so that it could accept both kinds of vectors. If vectors were Const by default, it would be vector-sqrt : (Vectorof Number) -> (Mutable (Vectorof Number)) so that its return values could be used anywhere. What if, when a `Vectorof' were in an argument position, it was Const, and when in a return position, Mutable? The obvious type would be best: vector-sqrt : (Vectorof Number) -> (Vectorof Number) If a vector argument needed to be mutable, its type could be overridden: vector-set! : (All (a) (Mutable (Vectorof a)) Integer a -> Void) In the extremely rare case that a function returned an immutable vector, the return type could be overridden: vector->immutable-vector : (All (a) (Vectorof a) -> (Const (Vectorof a))) Making vector arguments Const by default could break existing code written in TR. I don't think a lot of code would break, though: 1. Racket is designed to discourage mutation. 2. Mutable data structures are hard to use in TR because they're not covariant, and ridiculously hard with numeric tower type parameters. 3. I found a nasty error: typed vector-ref indexes the wrong elements (often raising errors) on vectors from untyped code. I'm certain that because of this, there's no mixed typed/untyped code that uses vectors. To reiterate after my absence: I won't write a typed math/vector until using its exports in Typed Racket wouldn't be a huge friggin' PITA. To offer a carrot instead of a stick: There could be a short paper in this, titled "The Case for a Clean, Correct, Covariant Const". Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)
On Tue, Jul 31, 2012 at 6:42 AM, Matthew Flatt wrote: > > To start afresh, here are two suggestions, which are mutually > exclusive. The first is my preference: > > 1. Revert the addition of `compatibility/package' and > `compatibility/mpair', including the documentation changes (but > maybe add back some text to discourage misuse of these libraries). I definitely think we should keep `mpair` as a more-than-compatibility library. It's useful in real data structures, and it's nice not to have to roll your own mutable linked list when it's the right choice. -- sam th sa...@ccs.neu.edu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)
At Mon, 30 Jul 2012 19:45:07 -0400, Vincent St-Amour wrote: > At Mon, 30 Jul 2012 14:52:06 -0600, > Matthew Flatt wrote: > > If we really want to have two names for these things --- the > > compatibility name and the "compatibility" name --- then I think we > > should at least consolidate to a single compatibility manual by moving > > the documentation for `racket/mpair' and `racket/package' to the > > compatibility manual. > > To make sure I understand correctly, you're suggesting that: > > - We keep the `compatibility' collect. > - We keep `compatibility/defmacro'. > - We remove `compatibility/mpair' and `compatibility/package', and move > them back to `racket/mpair' and `racket/package', respectively. > - We leave the reference and the compatibility manual as is, with docs > for `racket/mpair' and `racket/package' in the compatibility manual. > > If that's what you're suggesting, I'll implement it. I'm sorry that I've been so unclear! To start afresh, here are two suggestions, which are mutually exclusive. The first is my preference: 1. Revert the addition of `compatibility/package' and `compatibility/mpair', including the documentation changes (but maybe add back some text to discourage misuse of these libraries). 2. Leave things as they are, but move the sections that document `racket/package' and `racket/mpair' out of the Reference and into the same "Compatibility" document that describes `compatibility/package' and `compatibility/mpair'. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket 5.2 on OpenBSD and --enable-backtrace
At Mon, 30 Jul 2012 01:50:22 +0200, Juan Francisco Cantero Hurtado wrote: > Hi. I've a question about --enable-backtrace in the configure step. Is > it useful for the users or only is useful for the racket developers?. > This option affect to the performance of racket?. It's potentially useful to users, but it's expensive. You shouldn't include it in a normal build. > I'm not a scheme/racket developer. I'm just the racket maintainer on > OpenBSD [1]. I'm using this configure options: > > --enable-shared > --enable-libffi > --enable-gracket > --enable-jit > --enable-foreign > --enable-places > --disable-futures > --enable-float > --enable-docs > --enable-backtrace > --enable-pthread Unless you have a particular reason to disable futures, I'd enable that one. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] DrDr - previous/next change buttons
Thanks, this is very helpful! Robby On Mon, Jul 30, 2012 at 4:42 PM, Jay McCarthy wrote: > DrDr now has green buttons to go between times the file's output has > changed. Hopefully this will help you find problematic commits easier. > > Jay > > -- > Jay McCarthy > Assistant Professor / Brigham Young University > http://faculty.cs.byu.edu/~jay > > "The glory of God is Intelligence" - D&C 93 > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)
I meant literal file copies (or links if that works everywhere). And I think that would satisfy Matthew too. _ Racket Developers list: http://lists.racket-lang.org/dev
