Re: [racket-dev] Release Announcement for v5.0.1 -- final version
On Mon, Aug 2, 2010 at 4:31 AM, Eli Barzilay e...@barzilay.org wrote: On Aug 2, Matthias Felleisen wrote: On Aug 2, 2010, at 6:11 AM, Eli Barzilay wrote: And for the (near) future -- figure out what's happenning in the teaching languages. I get the impression that things are moving there almost randomly. No, this isn't random; it is unsynchronized: (Yeah, I used random in a random sense...) -- Shriram asked Jay to add define-datatype (and hashes? was there more?) define-datatype, match, hashes These are the commits: http://github.com/plt/racket/commit/407dcee206678785b4b87bb513d7ba5f55ad8ab5 http://github.com/plt/racket/commit/eeada45868d73c02b59f5c1ecd16e414d5a114ac http://github.com/plt/racket/commit/9eb053d4db1efd2881e1f749ad6b1eb12a6e8152 -- Robby, Mike, and I decided to move signatures into BSL, ... but I underestimated when I'd get to the translation of the documentation So: 1. I propose to release as is: no addition to ASL, no docs for signatures 2. I propose to sync at PLT Day, in person. OK -- that leaves messes #1 (are Jay's changes included or not?) and #2 (test it properly) to sort out. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release Announcement for v5.0.1 -- final version
At Mon, 2 Aug 2010 04:42:41 -0600, Jay McCarthy wrote: These are the commits: Those are from July 22, one week after the branch for 5.0.1, so they would not normally be considered candidates for the 5.0.1 release. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Typed Racket and eq?
I'm not talking about behavior, I'm talking about the intended semantics of observations in the language. Shriram On Mon, Aug 2, 2010 at 9:47 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Mon, Aug 2, 2010 at 9:40 AM, Shriram Krishnamurthi s...@cs.brown.edu wrote: If I export map (w/out change to type) from typed/racket and eq? it against the map from racket, the two are eq?. This feels like a violation of abstraction: typed map is a different thing from untyped map. TR doesn't put additional contracts on the implementation of Racket primitives, since they already come with error-checking. I'm not sure what you would want the difference in behavior to be between the two versions of `map'. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Typed Racket and ADTs
On Aug 2, 2010, at 9:39 AM, Shriram Krishnamurthi wrote: 1. doesn't have a counterpart for *untyped* code; ... Overall, the status of representation-hiding in Typed Racket seems rather weird. These two lines together explain it all. TR is about moving code from the untyped world into the typed world. It's not about ML with parentheses. I find it odd that even programming entirely in Typed Racket, representations leak by default. Yeap, just like Racket. If you want to hide things, use opaque structs, then type them. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Typed Racket and eq?
Sam, this is an interesting question and you should look into it because the answer isn't obvious: (module A typed/racket (provide map)) passes map from 'somewhere' through A to two contexts: typed and untyped modules. Given that all provides slap on contracts in TR -- that's what the manual says or should say -- it is surprising that this map should ever be the same as the map that came from 'somewhere'. It certainly wouldn't be the case in a contract world. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Typed Racket interaction
On Aug 2, 2010, at 10:43 AM, Sam Tobin-Hochstadt wrote: This is the same code as above. Did you mean something different? See my message. I had fixed it. Cap t in first line! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Typed Racket and importing polymorphic code
On Mon, Aug 2, 2010 at 9:58 AM, Shriram Krishnamurthi s...@cs.brown.edu wrote: 1'. That seems unlikely given that if I instead add insert to the above (#lang racket) source file and run Check Syntax, I get the same error -- so it is indeed a static error. (Well, maybe not static, there are probably three or four times at work here.) This is a different issue - it shouldn't work to use `insert' in an untyped context, since there's no way to generate a contract for its type. This is also what's happening with the REPL, but that shouldn't be treated as a untyped context (that's the bug). Sorry, I misread your initial question, and thought something else was happening. The bug I was referring to is irrelevant here. The reason that you don't get an error until you use `insert' is that the error is only detected when you *use* `insert', not when it's defined. This is intentional - otherwise, typed modules would be much less useful from the untyped side. It's just as safe, since the error is still at expansion time. 2. Why does the same not happen with map? I can use map freely; if I put it in the #lang racket file and Check Syntax, it draws an arrow from map to the required (typed) file. Yet in the typed file: `insert' is defined in typed code, and `map' is not. Depends on how you want to define the term. I imported a language with map and explicitly provided it. I mean defined in the sense of where the original `define-values' form is. BUT: That's beside the point. map has just as much a polymorphic type as insert. You said earlier, it shouldn't work to use `insert' in an untyped context, since there's no way to generate a contract for its type. Why does this statement not apply to map? No contract is needed for `map' at all - it (like all Racket primitives) is known to protect itself. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Typed Racket and importing polymorphic code
Arjun just pointed out to me that the inability to contract base values can lead to much harder-to-understand problems in higher-order contexts. (Not surprising, but I hadn't thought that that would make it much worse.) On Mon, Aug 2, 2010 at 11:44 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Mon, Aug 2, 2010 at 11:14 AM, Shriram Krishnamurthi s...@cs.brown.edu wrote: Okay, so here's another scenario. This time, TR will NOT just pass the value through, as it did map. a.rkt #lang racket (define foo 4) (provide foo) ;; NOTE: a has not done a good job of protecting foo, ;; whatever the heck that means b.rkt #lang typed/racket (require/typed a.rkt [foo Number]) (provide foo) ;; Now I'm going to put an explicit TYPE on foo c.rkt #lang racket (require b.rkt) (string-length foo) -- The error message is string-length: expects argument of type string; given 4 Nothing that looks like a contract violation. I was willing to live with your previous explanation re. map (whether or not it was primitive, the idea that something just passed through). But the idea that the typed intermediation above seems to do nothing is much harder to defend on similar grounds. I think this (and your second example, which is the same) presents an interesting issue with contracts. It's not peculiar to types: #lang racket/load (module m racket (define foo 4) (provide/contract [foo number?])) (module n racket (require 'm) (string-length foo)) Again, no contract error. Right now, this isn't treated as an abuse of the protected value `4', but as an abuse of `string-length'. Whether primitive values should treat function calls on them as message sends and thus be able to respond, potentially with contract errors, is a really interesting question. This relates to Cormac's ideas about proxies for primitive values [1]. [1] http://wiki.ecmascript.org/doku.php?id=harmony:proxies at the bottom of the page -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release Announcement for v5.0.1 -- final version
We should try to make sure that only commit messages from commits in the release branch are considered for the release notes process. Do we a script that does it or does someone pick through them manually? Jay On Mon, Aug 2, 2010 at 1:14 PM, Robby Findler ro...@eecs.northwestern.edu wrote: Eli: are you saying that those commits were not included in the testing bundles? If so, why do we need to re-run the release tests? (Or is there something else?) Robby On Mon, Aug 2, 2010 at 2:12 PM, Eli Barzilay e...@barzilay.org wrote: On Aug 2, Jay McCarthy wrote: On Mon, Aug 2, 2010 at 4:31 AM, Eli Barzilay e...@barzilay.org wrote: On Aug 2, Matthias Felleisen wrote: On Aug 2, 2010, at 6:11 AM, Eli Barzilay wrote: And for the (near) future -- figure out what's happenning in the teaching languages. I get the impression that things are moving there almost randomly. No, this isn't random; it is unsynchronized: (Yeah, I used random in a random sense...) -- Shriram asked Jay to add define-datatype (and hashes? was there more?) define-datatype, match, hashes These are the commits: http://github.com/plt/racket/commit/407dcee206678785b4b87bb513d7ba5f55ad8ab5 http://github.com/plt/racket/commit/eeada45868d73c02b59f5c1ecd16e414d5a114ac http://github.com/plt/racket/commit/9eb053d4db1efd2881e1f749ad6b1eb12a6e8152 (For future references, the sha1 is all that is needed.) None of these commits are included. This leaves the last mess: running proper tests. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Typed Racket and ADTs
Pardon me for mentioning ML. Yes, Jim Morris suggested ADTs without using the name and the Clu people in their paper on infinitely high-level languages (yeap!) introduced the terms. That doesn't change a thing about the content of my statement. On Aug 2, 2010, at 11:38 AM, Shriram Krishnamurthi wrote: ADTs have nothing to do with ML. They're an older and basic computer science concept. So why do you have an opaque require? Just on simple duality grounds you should have both or neither. Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] status of the new `racket/gui'
On Mon, Aug 2, 2010 at 1:09 PM, Matthew Flatt mfl...@cs.utah.edu wrote: The `racket/gui' re-implementation is starting to come into focus. DrRacket mostly works, although lots and lots of problems remain. It looks very nice on my machine. One question: the open/save file dialogs on Gtk are using the old GRacket dialogs, rather than the Gtk-native ones. Is this planned to change in the future? -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] status of the new `racket/gui'
At Mon, 2 Aug 2010 19:12:40 -0400, Sam Tobin-Hochstadt wrote: On Mon, Aug 2, 2010 at 7:08 PM, Matthew Flatt mfl...@cs.utah.edu wrote: One question: the open/save file dialogs on Gtk are using the old GRacket dialogs, rather than the Gtk-native ones. Is this planned to change in the future? Yes, I just haven't gotten to the file dialog, yet. Great! If there are dialogs like this that need filling in, I bet you could get volunteers on this list. I'd be happy to help with Gtk. Back-ends for `get-file', `get-file-list', `put-file', and `get-directory' would be welcome. The implementations would go in collects/mred/private/wx/gtk or collects/mred/private/wx/cocoa. All of those dialogs currently go to the back-end function `file-selector', which is defined as a stub in procs.rkt. You'd have to infer the API for `file-selector' by looking at collects/mred/private/filedialog. I have no objecting to changing the API --- especially throwing out the marshaling of file-extension mappings into a string. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] LLVM
I may have missed a post on this topic, but has anyone built an LLVM back-end for mzc? -- Paul _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] LLVM
On Aug 2, 2010, at 8:38 PM, Paul Steckler wrote: I may have missed a post on this topic, but has anyone built an LLVM back-end for mzc? Eli and an undergraduate (Alex Friedman) started on this a few years ago and got reasonably far. They could compile a bunch of small stuff, and the LLVM developer was highly responsive to requests back then (still at UIUC). But Matthew's effort on jitting via gnu lightning was better and so the llvm project was abandoned. -- Matthias _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] LLVM
On Tue, Aug 3, 2010 at 10:41 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: Eli and an undergraduate (Alex Friedman) started on this a few years ago and got reasonably far. They could compile a bunch of small stuff, and the LLVM developer was highly responsive to requests back then (still at UIUC). But Matthew's effort on jitting via gnu lightning was better and so the llvm project was abandoned. Interesting; I wasn't aware of GNU lightning. Does that mean that mzc currently targets lightning, or is that just used in the JIT? -- Paul _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
