Re: [racket-dev] LLVM
On Tue, Aug 3, 2010 at 10:41 AM, Matthias Felleisen 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
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
[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] 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 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
Re: [racket-dev] status of the new `racket/gui'
On Mon, Aug 2, 2010 at 7:08 PM, Matthew Flatt 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. -- 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 17:51:11 -0400, Sam Tobin-Hochstadt wrote: > On Mon, Aug 2, 2010 at 1:09 PM, Matthew Flatt 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? Yes, I just haven't gotten to the file dialog, yet. _ 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 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] 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] Typed Racket and importing polymorphic code
The problem isn't that you can't contract base values, the problem is that they are checked when the values crosses the boundary and that's that. It's too eager. Matthew added chaperons a while back and we will use those to change the world. Perhaps. On Aug 2, 2010, at 1:18 PM, Shriram Krishnamurthi wrote: > 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.) _ 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 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 wrote: >> On Aug 2, Jay McCarthy wrote: >>> On Mon, Aug 2, 2010 at 4:31 AM, Eli Barzilay 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 Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release Announcement for v5.0.1 -- final version
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 wrote: > On Aug 2, Jay McCarthy wrote: >> On Mon, Aug 2, 2010 at 4:31 AM, Eli Barzilay 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
Re: [racket-dev] Release Announcement for v5.0.1 -- final version
On Aug 2, Jay McCarthy wrote: > On Mon, Aug 2, 2010 at 4:31 AM, Eli Barzilay 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
Re: [racket-dev] Typed Racket and ADTs
Why not provide the flip? You're already willing to wrap things (in contracts). Couldn't you do the wrapping that I have to do by hand? (Maybe I'm missing something.) It would make the language more symmetric, and the result of this symmetry would be not only symmetry but an actual nameable virtue (ADTs). [To repeat: maybe I'm missing something.] Shriram On Mon, Aug 2, 2010 at 11:51 AM, Sam Tobin-Hochstadt wrote: > On Mon, Aug 2, 2010 at 11:38 AM, Shriram Krishnamurthi > wrote: >> So why do you have an opaque require? > > The opaque form of `require/typed' is to allow requiring operations on > an ADT for which only a predicate is known. It supports using > `require/typed' with ADTs defined in exactly the way Matthias > suggests. For example, if there was no built-in `String' type, then > the opaque form of `require/typed' would be the way to specify it. > -- > 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 wrote: > On Mon, Aug 2, 2010 at 11:14 AM, Shriram Krishnamurthi > 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 ; 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
[racket-dev] status of the new `racket/gui'
The `racket/gui' re-implementation is starting to come into focus. DrRacket mostly works, although lots and lots of problems remain. The code is still hosted here: http://github.com/mflatt/gr2 The GUI libraries do not work well enough that it's time to submit bug reports, but DrRacket works well enough that you could try to run it as a preview. If GRacket or DRacket fails to start up due to issues finding/loading Gtk or related libraries, please let me know. The drawing part of the toolbox is in good shape, and bug reports on that part are welcome. Slideshow programs should run well; let me know if you have an example that renders incorrectly. See below for a list of changes to the drawing library compared to v5.0.x, so far. We'll eventually add support for gradients. Currently supported platforms: * Unix variants using Gtk (32 and 64 bits) * Windows (32 bits) * Mac OS X (32 and 64 bits; use --enable-mac64 to build the latter) * The drawing portion of the old GUI toolbox is now available as a separate layer: `racket/draw'. This layer can be used from plain Racket independent of the `racket/gui' library, although `racket/gui' re-exports `racket/draw'. The `racket/draw' library is built on top of the widely used Cairo drawing library and Pango text-rendering library. * A color bitmap can have an alpha channel, instead of just a mask bitmap. When drawing a bitmap, alpha channels are used more consistently and automatically than mask bitmaps. More significantly, drawing into a bitmap with an alpha channel preserves the drawn alphas; for example, drawing a line in the middle of an empty bitmap produces an image with non-zero alpha only at the drawn line. Create a bitmap with an alpha channel by supplying #t as the new `alpha?' argument to the `bitmap%' constructor, or by loading an image with a type like 'unknown/alpha insteda of 'unknown or 'unknown/mask. A newly created `bitmap%' has an empty content (i.e., white with zero alpha), insteda of unspecified content. Images can be read into a `bitmap%' from from input ports, instead of requiring a file path. * A `dc<%>' supports additional drawing transformations: a rotation (via `set-rotation') and a general transformation matrix (via `set-initial-matrix'). Scaling factors can be negative, which corresponds to flipping the direction of drawing. A transformation matrix has the form `(vector xx xy yx yy x0 y0)', where a point (x1, y1) is transformed to a point (x2, y2) with x2 = xx*x1 + yx*y1 + x0 and y2 = xy*x1 + yy*y1 + y0, which is the usual convention. New methods `translate', `scale', `rotate', and `transform' simplify adding a further translation, scaling, rotation, or arbitrary matrix transformation on top of the current transformation. The new `get-translation' and `set-translation' methods help to capture and restore transformation settings. The old translation and scaling transformations apply after the initial matrix. The new rotation transformation applies after the other transformations. This layering is redundant, since all transformations can be expressed in a single matrix, but it is backward-compatibile. Methods like `get-translation', `set-translation', `scale', etc. help hide the reundancy. The alpha value of a `dc<%>' (as set by `set-alpha') is used for all drawing operations, including drawing a bitmap. The `draw-bitmap' and `draw-bitmap-section' methods now smooth bitmaps while scaling, so the `draw-bitmap-section-smooth' method of `bitmap-dc%' simply calls `draw-bitmap-section'. * A `region%' can be created as independent of any `dc<%>', in which cases it uses the drawing context's current transformation at the time that it is installed as a clipping region. * The old 'xor mode for pens and brushes is no longer available (since it is not supported by Cairo). _ 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 11:46 AM, Shriram Krishnamurthi wrote: > Yep, I figured this is where you'd go with this. So if I converted > everything to functions, I'd get just the behavior I want? I'm not certain of the behavior you want, but I think so. -- 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 Mon, Aug 2, 2010 at 11:38 AM, Shriram Krishnamurthi wrote: > So why do you have an opaque require? The opaque form of `require/typed' is to allow requiring operations on an ADT for which only a predicate is known. It supports using `require/typed' with ADTs defined in exactly the way Matthias suggests. For example, if there was no built-in `String' type, then the opaque form of `require/typed' would be the way to specify it. -- 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
Yep, I figured this is where you'd go with this. So if I converted everything to functions, I'd get just the behavior I want? _ 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 11:14 AM, Shriram Krishnamurthi 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 ; 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] Typed Racket and ADTs
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] Typed Racket and eq?
On Mon, Aug 2, 2010 at 11:07 AM, Matthias Felleisen wrote: > > > Now, you will say but TR wraps only defined identifiers. I think that is a > SUBTLE and INTENSIONAL difference that in principle, a client such as C > shouldn't even see. Modules are not supposed to be inspected for who defines > what and so on. They are supposed to be service providers will well-defined > interfaces. > Your interface says that all provided identifiers went thru typing and went > thru a typed provide interface. I don't believe that there are any extensional observations that can be made to distinguish these. `eq?' is a special case, here as in many other places. -- 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
This is related to the other thread, on eq?. I'll follow-up here. >> 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. I think this is a bad explanation. What you said in your other thread makes more sense -- TR passes through things and assumes that they protect themselves: Other modules protect their own code. The fact that map is a primitive does not strike me as relevant here. 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 ; 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. In fact, let's go a step farther, since apparently what matters is whether something is defined in the module. Here is an alternate version of b.rkt: b.rkt #lang typed/racket #lang typed/racket (require/typed "a.rkt" [foo Number]) (: my-foo Number) (define my-foo foo) (provide my-foo) c.rkt #lang racket (require "b.rkt") (string-length my-foo) -- and I get the same run-time error. Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Typed Racket and eq?
On Aug 2, 2010, at 10:53 AM, Sam Tobin-Hochstadt wrote: > On Mon, Aug 2, 2010 at 10:36 AM, Matthias Felleisen > wrote: >> >> 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'. > > The identifier you get for `map' outside this module is the same > identifier you would have from `racket'. `provide' adds contracts for > identifiers *defined in this module* (including those defined by > `require/typed'). Other modules protect their own code. > >> It certainly wouldn't be the case in a contract world. > > Can you make this more precise? Let's say 'provide' is a macro in a language L that is specified to add contracts to all names specified, say, (provide/L x) == (provide/contract [x (lambda (x) false)]) ; silly, I know When A exports x to B, written in L, and C imports x from B, you get blame for B. > > (module A racket > (provide/contract [x integer?]) > (define x 10)) > > (module B racket > (require 'A) > (provide/contract [x (lambda (x) false)])) > > (module C racket > (require 'B) > (printf "~s\n" x)) > > (require 'C) ;; Now, you will say but TR wraps only defined identifiers. I think that is a SUBTLE and INTENSIONAL difference that in principle, a client such as C shouldn't even see. Modules are not supposed to be inspected for who defines what and so on. They are supposed to be service providers will well-defined interfaces. Your interface says that all provided identifiers went thru typing and went thru a typed provide interface. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Typed Racket interaction
Yes, sorry, I pasted the same thing twice. Matthias caught it. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Typed Racket and eq?
On Mon, Aug 2, 2010 at 10:36 AM, Matthias Felleisen wrote: > > 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'. The identifier you get for `map' outside this module is the same identifier you would have from `racket'. `provide' adds contracts for identifiers *defined in this module* (including those defined by `require/typed'). Other modules protect their own code. > It certainly wouldn't be the case in a contract world. Can you make this more precise? -- 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
On Mon, Aug 2, 2010 at 9:58 AM, Shriram Krishnamurthi 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 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 interaction
On Mon, Aug 2, 2010 at 9:37 AM, Shriram Krishnamurthi wrote: > Here is a sequence of steps to do something that seems extremely > simple. I want to create a binary tree of T. > > First, I have no idea what this documentation means: > > (struct:n (t ...)) > is the type of structures named n with field types t. > > All of "struct", "n" and "t" are italicized, suggesting they're all > meta-variables. But only "n" and "t" are explained in the document. > Perhaps "struct:" is meant literally? This documentation is written confusingly, I'll fix that. > The next few things I do fail miserably, until I get this far: > > (define-struct: (T) Node ([v : T] [l : (BinTreeof t)] [r : (BinTreeof t)])) > (define-type (BinTreeof t) > (U 'empty > [Node t])) > > Now we get a classic impenetrable error message: > > Type Checker: Structure type constructor Node applied to non-regular > arguments (Error) in: (Node t) > > Whatever that means. I rename the two "t"'s in Node to "T"'s: > > (define-struct: (T) Node ([v : T] [l : (BinTreeof t)] [r : (BinTreeof t)])) > (define-type (BinTreeof t) > (U 'empty > [Node t])) This is the same code as above. Did you mean something different? -- sam th sa...@ccs.neu.edu _ 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 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 interaction
This sounds like material for a bug report. I think the lowercase t in On Aug 2, 2010, at 9:37 AM, Shriram Krishnamurthi wrote: > (define-struct: (T) Node ([v : T] [l : (BinTreeof t)] [r : (BinTreeof t)])) > (define-type (BinTreeof t) > (U 'empty > [Node t])) the first line should be an unbound variable and reported as such. _ 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 wrote: > On Mon, Aug 2, 2010 at 9:40 AM, Shriram Krishnamurthi > 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 importing polymorphic code
I'm glad this is considered a bug. >> 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). I don't understand why this is a "different issue". The Check Syntax behavior looks just right to me. I don't see an "issue" at all. Did you mean that the REPL *should* (not "shouldn't") be treated as an untyped context? >> 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. 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? Shriram _ 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:42 AM, Shriram Krishnamurthi wrote: > Here's a typed module: > > (module A typed/racket (provide insert map) (define insert cons)) > > Here are two clients, which behave inconsistently: > >> (module B racket (require 'A) insert) > . Type Checker: The type of insert cannot be converted to a contract in: > insert >> (module C racket (require 'A) map) > > Let's instead save A to a file, and write these clients as: > > - > > #lang racket > (require "typed-set-impl.rkt") > > - > > F5 executes fine. Running works: > >> (map + '(1 2 3) '(4 5 6)) > '(5 7 9) > > But if I now type at the REPL: > >> insert > > I get the same error: > > Type Checker: The type of insert cannot be converted to a contract in: insert > > I have two issues with this: > > 1. Why is this discovered only when I "touch" insert and not sooner? > Is there some kind of lazy contract creation happening at run-time? This is because of strange interaction between the implementation of the "Module" language and the implementation of Typed Scheme. There's been discussion of how to extend the DrRacket API to fix this bug, but nothing has come of it yet. > 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). > 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. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Typed Racket and eq?
On Mon, Aug 2, 2010 at 9:40 AM, Shriram Krishnamurthi 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
[racket-dev] Typed Racket and importing polymorphic code
Here's a typed module: (module A typed/racket (provide insert map) (define insert cons)) Here are two clients, which behave inconsistently: > (module B racket (require 'A) insert) . Type Checker: The type of insert cannot be converted to a contract in: insert > (module C racket (require 'A) map) Let's instead save A to a file, and write these clients as: - #lang racket (require "typed-set-impl.rkt") - F5 executes fine. Running works: > (map + '(1 2 3) '(4 5 6)) '(5 7 9) But if I now type at the REPL: > insert I get the same error: Type Checker: The type of insert cannot be converted to a contract in: insert I have two issues with this: 1. Why is this discovered only when I "touch" insert and not sooner? Is there some kind of lazy contract creation happening at run-time? 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.) 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 - : (All (a b) (case-lambda (a (Listof a) -> (Listof a)) (a b -> (Pairof a b # > map - : (All (c a b ...) (case-lambda ((a -> c) (Pairof a (Listof a)) -> (Pairof c (Listof c))) ((a b ... b -> c) (Listof a) (Listof b) ... b -> (Listof c # so map does not look any less polymorphic than insert So what on earth is going on? _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Typed Racket and eq?
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. Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Typed Racket and ADTs
How do I define an ADT? Eg, I want to provide this: (provide insert check empty-set) (define-type RealSet (Listof Real)) (: empty-set RealSet) (define empty-set empty) (: insert (Real RealSet -> RealSet)) (define insert cons) (: check (Real RealSet -> Boolean)) (define (check e s) (if (member e s) true false)) I see that using the opaque form of require/typed I can import RealSet as, say, type RS and truly hide its representation. However, this: 1. doesn't have a counterpart for *untyped* code; 2. seems very ugly to do from a typed module: I seem to need to define the new opaque type, then enumerate everything (that I want) exported from the typed module. Surely there's an easy way of saying import SetADT renaming RealSet to RS making it opaque ? It seems natural, but I can't figure out how to say this. Overall, the status of representation-hiding in Typed Racket seems rather weird. I find it odd that even programming entirely in Typed Racket, representations leak by default. Worse, If I'm writing a module whose representations I expect to frequently change, and would like user code to avoid inadvertently relying on them, there appears to be nothing I can do (without providing a wrapper that simply re-exports everything with the type made opaque -- and even then, it's not clear how to hide access to the original). Just as there's an opaque require, why isn't there dually an opaque provide, so the creator can decide to hide reps? Even if opaque provide only worked for other typed clients, that would be a big step up. Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Typed Racket interaction
Here is a sequence of steps to do something that seems extremely simple. I want to create a binary tree of T. First, I have no idea what this documentation means: (struct:n (t ...)) is the type of structures named n with field types t. All of "struct", "n" and "t" are italicized, suggesting they're all meta-variables. But only "n" and "t" are explained in the document. Perhaps "struct:" is meant literally? After several tries, I figure out no, it doesn't. Okay, now I know the basic syntax. The next few things I do fail miserably, until I get this far: (define-struct: (T) Node ([v : T] [l : (BinTreeof t)] [r : (BinTreeof t)])) (define-type (BinTreeof t) (U 'empty [Node t])) Now we get a classic impenetrable error message: Type Checker: Structure type constructor Node applied to non-regular arguments (Error) in: (Node t) Whatever that means. I rename the two "t"'s in Node to "T"'s: (define-struct: (T) Node ([v : T] [l : (BinTreeof t)] [r : (BinTreeof t)])) (define-type (BinTreeof t) (U 'empty [Node t])) Now everything is fine...?!? TR uses cpp to inline aliases? Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release Announcement for v5.0.1 -- final version
Just to make sure: Signatures are included because they were merged into the trunk before the branch was done. For example, (define int (signature Real)) (: x int) (define x 3) works in Beginner. It turns out however that even the German docs are broken. I should have explored more when Mike merged this in. Then again, I doubt we will have many Americans reading these docs. ;; --- Pragmatics: While I am sure one can get very close to define-datatype, the docs don't suggest it's easy. Here is how you equip structures with signatures: (define-struct S (x y)) (define int (signature Integer)) (: make-S (int int -> S)) (: S-x (S -> int)) (: S-y (S -> int)) And that seems to be the simplest way. I doubt Shriram will be happy with this. What am I overlooking, Mike? -- Matthias _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release Announcement for v5.0.1 -- final version
That's fine with me. I wrote the release note addendum because the original email contained the blurb, not because I'm stressing about putting it in. Jay On Mon, Aug 2, 2010 at 6:06 AM, Matthew Flatt wrote: > 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. > > -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 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] Release Announcement for v5.0.1 -- final version
On Mon, Aug 2, 2010 at 4:31 AM, Eli Barzilay 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 Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release Announcement for v5.0.1 -- final version
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?) > -- 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! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release Announcement for v5.0.1 -- final version
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: -- Shriram asked Jay to add define-datatype -- 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. -- Matthias _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release Announcement for v5.0.1 -- final version
Signatures are documented but in German. It is on my list to 'translate' this for the next release. -- Matthias On Aug 2, 2010, at 5:57 AM, Jay McCarthy wrote: > I don't know anything about signatures, since they're not documented > or advertised. > > I don't know why it isn't included... I thought the patch was cherry > picked. I didn't test it in the release because I added the tests for > the feature to tests/racket/advanced.rktl > > Jay > > On Mon, Aug 2, 2010 at 1:49 AM, Michael Sperber > wrote: >> >> Eli Barzilay writes: >> >>> I don't know of any plan for signatures, but if it would be bad to >>> advertise it if it's not included... Jay/Ryan--?? >> >> Signatures are already in there (look in the log in collects/lang) - >> they're just not documented yet. They already give you this, for >> example: >> >> (define-struct foo (a b)) >> (define-struct bar (c d)) >> (define foo-or-bar >> (signature (mixed foo bar))) >> >> At the very least, `define-datatype' should also define a signature. >> >> -- >> Cheers =8-} Mike >> Friede, Völkerverständigung und überhaupt blabla >> > > > > -- > Jay McCarthy > Assistant Professor / Brigham Young University > http://teammccarthy.org/jay > > "The glory of God is Intelligence" - D&C 93 > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release Announcement for v5.0.1 -- final version
On Aug 2, Jay McCarthy wrote: > I don't know anything about signatures, since they're not documented > or advertised. > > I don't know why it isn't included... I thought the patch was cherry > picked. I didn't test it in the release because I added the tests > for the feature to tests/racket/advanced.rktl So to conclude the messes that need to be sorted out: * Figure out if the changes are included or not, if not, figure out if they should be added or not, if yes, then figure out if retesting should be done or not. * Especially given that there were changes in the teaching languages and the web server, it would be good to retest properly, using the release candidate. (The test email has instructions on getting the tests -- either to add to the installed tree or use the "full" build.) * 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. -- ((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
Re: [racket-dev] Release Announcement for v5.0.1 -- final version
I don't know anything about signatures, since they're not documented or advertised. I don't know why it isn't included... I thought the patch was cherry picked. I didn't test it in the release because I added the tests for the feature to tests/racket/advanced.rktl Jay On Mon, Aug 2, 2010 at 1:49 AM, Michael Sperber wrote: > > Eli Barzilay writes: > >> I don't know of any plan for signatures, but if it would be bad to >> advertise it if it's not included... Jay/Ryan--?? > > Signatures are already in there (look in the log in collects/lang) - > they're just not documented yet. They already give you this, for > example: > > (define-struct foo (a b)) > (define-struct bar (c d)) > (define foo-or-bar > (signature (mixed foo bar))) > > At the very least, `define-datatype' should also define a signature. > > -- > Cheers =8-} Mike > Friede, Völkerverständigung und überhaupt blabla > -- Jay McCarthy Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release Announcement for v5.0.1 -- final version
Eli Barzilay writes: > I don't know of any plan for signatures, but if it would be bad to > advertise it if it's not included... Jay/Ryan--?? Signatures are already in there (look in the log in collects/lang) - they're just not documented yet. They already give you this, for example: (define-struct foo (a b)) (define-struct bar (c d)) (define foo-or-bar (signature (mixed foo bar))) At the very least, `define-datatype' should also define a signature. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release Announcement for v5.0.1 -- final version
On Aug 2, Michael Sperber wrote: > Sorry, I'm just seeing this now: > > Eli Barzilay writes: > > > Final version, after some edits and reorganization. > > * The Advanced Student Language now supports hash-table > > primitives, `define-datatype' for defining sets of related > > structs, and `match' for pattern matching. > > Is it a good idea to advertise `define-datatype', given the > impending introduction of signatures? Is it even needed? > > Also, it does not seem to have been merged to the release branch: > > define-datatype: name is not defined, not a parameter, and not a > primitive name I don't know of any plan for signatures, but if it would be bad to advertise it if it's not included... Jay/Ryan--?? -- ((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
Re: [racket-dev] Release Announcement for v5.0.1 -- final version
Sorry, I'm just seeing this now: Eli Barzilay writes: > Final version, after some edits and reorganization. > * The Advanced Student Language now supports hash-table primitives, > `define-datatype' for defining sets of related structs, and > `match' for pattern matching. Is it a good idea to advertise `define-datatype', given the impending introduction of signatures? Is it even needed? Also, it does not seem to have been merged to the release branch: define-datatype: name is not defined, not a parameter, and not a primitive name -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
