Re: [racket-dev] [plt] Push #29023: master branch updated

2014-07-14 Thread Sam Tobin-Hochstadt
This seems like a situation where the new error message is potentially more confusing, even though it's technically more correct. There are lots of other caveats we could add (assuming there isn't a compiler bug, etc) but I think adding them would make Racket harder to use. Sam On Mon, Jul 14,

Re: [racket-dev] [plt] Push #29023: master branch updated

2014-07-14 Thread Robby Findler
I do not buy this argument: the user didn't write the compiler but they wrote the contract. Robby On Monday, July 14, 2014, Sam Tobin-Hochstadt sa...@cs.indiana.edu wrote: This seems like a situation where the new error message is potentially more confusing, even though it's technically more

Re: [racket-dev] [plt] Push #29023: master branch updated

2014-07-14 Thread Robby Findler
Sorry-- I replied on my phone and too tersely the first time. What I'm trying to say is that I do not agree that compiler bugs or ffi bugs that corrupt memory or things along these lines are analogous. I do agree that those things do not deserve lines in our contract error messages. Contracts

Re: [racket-dev] [plt] Push #29023: master branch updated

2014-07-14 Thread Sam Tobin-Hochstadt
I think the vast majority of contract errors that Racket programmers see will be from contracts that the particular programmer didn't write. For example: standard library contracts, or contracts from packages they install, or contracts generated by Typed Racket, or other such. For example, here's

Re: [racket-dev] [plt] Push #29023: master branch updated

2014-07-14 Thread Matthias Felleisen
Unfortunately, it is impossible to distinguish the two kinds of contracts. Even if we introduced two different linguistic mechanisms, we would simply confuse programmers more. Let's try this experiment for a while and see what happens. On Jul 14, 2014, at 9:46 AM, Sam Tobin-Hochstadt

[racket-dev] FOOL 2014 Call for Papers

2014-07-14 Thread Asumu Takikawa
Call For Papers 21th International Workshop on Foundations of Object-Oriented Languages (FOOL 2014) A Workshop of SPLASH (OOPSLA) 2014 Portland, Oregon, United States.

[racket-dev] Questions about the GC code

2014-07-14 Thread Juan Francisco Cantero Hurtado
I've been reading the code of the files gc/os_dep.c and gc/include/private/gcconfig.h. I've some questions related to OpenBSD. --- In the X86_64 config, the file defines STACKBOTTOM and HEURISTIC2 (unused because racket picks STACKBOTTOM). What's the preferred?. I'm asking because I don't

Re: [racket-dev] Questions about the GC code

2014-07-14 Thread Matthew Flatt
The gc directory is Boehm's GC. We've modified it a little (grep for PLTSCHEME), but we try not to maintain the GC itself, except to upgrade every once in a while. See http://www.hboehm.info/gc/ for the latest version, the mailing list, etc. I should look again at making Racket work with a