Re: [racket-dev] Removing Xexpr preference from Web Server
On Saturday, Neil Van Dyke wrote: BTW, SXML and xexprs are a big win for Web development. For one large system in PLT Scheme, the architects have repeatedly mentioned the productivity benefits of SXML for HTML pages as one of the major advantages of using Scheme. They also have problems. The ones I ran into, at least with xexprs: they rely on lots of quasi/quotes etc and it's easy to end up with things like quotenbsp/quote. A related problem is the difference between contexts that expect a single value and contexts that expect a list of values -- with one solution of changing an `unquote' to `unquote-splicing' and the usual problems that this can lead to, or going with the bad spanstuff/span hack. -- ((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] Removing Xexpr preference from Web Server
Eli Barzilay wrote at 11/30/2010 06:36 AM: The ones I ran into, at least with xexprs: they rely on lots of quasi/quotes etc and it's easy to end up with things like quotenbsp/quote. I make errors of not getting my quotes, backquotes, and commas in the right place sometimes, but those errors tend to be discovered quickly. BTW, in SHTML, my old SXML derivative for HTML, one does ( nbsp) instead of xexpr's just nbsp for an entity reference. Perhaps there is a little less risk of confusion. I think there would be even less risk of confusion if DrRacket syntax coloring assumed that the quote and backquote characters always introduced a normal Scheme quote/quasiquote context, and colored the literal parts green. A related problem is the difference between contexts that expect a single value and contexts that expect a list of values -- with one solution of changing an `unquote' to `unquote-splicing' and the usual problems that this can lead to, or going with the bad spanstuff/span hack. I ran into this potential pitfall when I was doing PLT servlets with xexprs. It's not so much an issue in SXML, since (for better or worse) SXML permits unnecessary paren nesting, so you never have to splice. Other solutions/workarounds: * Just be careful, and test. * When I was doing PLT servlets, I just had a naming convention for procs that produced xexprs, so foo-bar-xexpr-elem would get unquote and blort-baz-xexpr-content would get unquote-splicing. * Ideally, I'd want static type checking of my HTML/SXML forms. This might have been some of the attraction of Haskell to Oleg. * My template language doesn't use unquote or unquote-splicing, and instead uses constructs that I think are less error-prone. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
On Tue, Nov 30, 2010 at 5:18 AM, Eli Barzilay e...@barzilay.org wrote: Yesterday, Robby Findler wrote: This kind of thing has happened many times for other parts of the system (the class system is a good example). We have generally tried to avoid so much breakage and I think we should here. One technique is to have a new name for the new version (or a new name for the old one if that is more appropriate; that still breaks everything but porting is very easy). The problem here is that there is no name to change -- it's the implicit coercion of xexpr values to a response. Why can't there be two libraries, one that coerces and one that doesn't? More generally, one that acts the same as the current library and one that is intended for new code? Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
Two hours ago, Neil Van Dyke wrote: Eli Barzilay wrote at 11/30/2010 06:36 AM: The ones I ran into, at least with xexprs: they rely on lots of quasi/quotes etc and it's easy to end up with things like quotenbsp/quote. I make errors of not getting my quotes, backquotes, and commas in the right place sometimes, but those errors tend to be discovered quickly. (The above errors were all over the old pages for years without being discovered...) A related problem is the difference between contexts that expect a single value and contexts that expect a list of values -- with one solution of changing an `unquote' to `unquote-splicing' and the usual problems that this can lead to, or going with the bad spanstuff/span hack. I ran into this potential pitfall when I was doing PLT servlets with xexprs. It's not so much an issue in SXML, since (for better or worse) SXML permits unnecessary paren nesting, so you never have to splice. Yeah, that was my conclusion too, and `scribble/html' does just that (actually it inherits it from `scribble/text'). BTW, another minor disadvantage with xexprs is that you need a separate rendering pass if you want to have references such as a TOC. The `scribble/html' thing allows promises and thunks which makes it easier to deal with. -- ((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] Removing Xexpr preference from Web Server
On Nov 30, 2010, at 9:01 AM, Eli Barzilay wrote: (The above errors were all over the old pages for years without being discovered...) Berkeley would have asked if they are really errors then :-) _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
On Tue, Nov 30, 2010 at 8:04 AM, Eli Barzilay e...@barzilay.org wrote: Two hours ago, Robby Findler wrote: On Tue, Nov 30, 2010 at 5:18 AM, Eli Barzilay e...@barzilay.org wrote: The problem here is that there is no name to change -- it's the implicit coercion of xexpr values to a response. Why can't there be two libraries, one that coerces and one that doesn't? More generally, one that acts the same as the current library and one that is intended for new code? That would require a new `web-server' module, as well as a whole bunch of other modules. I know. Even worse, writing a module using one web server library, and using it in the other won't work, since it's a dynamic property of how the result is getting used. (I think it may be possible to be creative to avoid these things being errors when you mix; but maybe it is better to have an error when you mix; I don't have a strong opinion here but I'd try to make mixing work so people can migrate piecemeal.) --- As I said before, we have done this with the class system many times. We have done this with other parts of the system as well (not as many times tho). It is not a simple thing. That said, massive backwards incompatibility as Jay is proposing seems wrong. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
On Nov 30, 2010, at 9:58 AM, Robby Findler wrote: That said, massive backwards incompatibility as Jay is proposing seems wrong. + a lot _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
Three hours ago, Robby Findler wrote: On Tue, Nov 30, 2010 at 8:04 AM, Eli Barzilay e...@barzilay.org wrote: Two hours ago, Robby Findler wrote: On Tue, Nov 30, 2010 at 5:18 AM, Eli Barzilay e...@barzilay.org wrote: The problem here is that there is no name to change -- it's the implicit coercion of xexpr values to a response. Why can't there be two libraries, one that coerces and one that doesn't? More generally, one that acts the same as the current library and one that is intended for new code? That would require a new `web-server' module, as well as a whole bunch of other modules. I know. Even worse, writing a module using one web server library, and using it in the other won't work, since it's a dynamic property of how the result is getting used. (I think it may be possible to be creative to avoid these things being errors when you mix; but maybe it is better to have an error when you mix; I don't have a strong opinion here but I'd try to make mixing work so people can migrate piecemeal.) [I don't see a way to do that.] As I said before, we have done this with the class system many times. We have done this with other parts of the system as well (not as many times tho). It is not a simple thing. That said, massive backwards incompatibility as Jay is proposing seems wrong. I'll leave this Jay, but I think that there are some important points: * Doing the same for the web server will be much more problematic since there are many interface modules that do the implicit coercion. It looks to me like the only way to do that will be a new toplevel `web-server' collection. * Even in the case of the class system, one of the transitions was going the other way -- renaming the old one (still available as `mzlib/class100') instead of having the new one under a new name. * The fact that this is much more problematic in the web server's case, combined with the fact that the change itself is much more minor (compared to the class system changes), is -- IMO -- a strong indication that a backward-compatible change via a parameter is the right way to go (defaulting to the same as it does now). -- ((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
[racket-dev] A game using scheme !
Hello, I'm a french student, and I'd like to create a game, using scheme : a race for 2 players (computer or real person). What i've got to do is to creat a grid, where there is a start line, a finish line and, between them, a random number of lines... In this grid, we have walls, as in crosswords I think ;) Well, they are cases you can't go in with your car. Also, we have checkpoints, for each player. The thing is that they have to drive on each checkpoint and then go to the finish line to win. The checkpoints are, of course, different for player 1 and player 2... For example, you've got a grid 10x20. There are approx. 36 walls and 8+8 checkpoints. So, I was wondering if you could help me realising this, cause it would be great to show to people that scheme is not only a basic-programming-language but a complete language with which you can do amazing things :D If you accept, just tell me ! :) And, if you want to know what I already did, ask me too (cause it's a little bit long, so I thought you would be bored too quickly if I had put it here lol) Thanks for reading ! MALHORE Patricia _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
Going back to a point I'm sure others have made already... Perhaps you guys have a good sense of how many people would be affected by any incompatibilities in this case? Most people use open-output-file and hash tables, so you wanted to migrate all those people gently somehow. A relatively small percentage of people used mutable pairs, at least outside of textbooks, so a harsh migration path was more acceptable there. I assume that the Web Server is somewhere between open-output-file and mutable pairs in popularity. If the tradeoff costs of backward-compatibility work and moving the platform forward expeditiously are unclear, perhaps you could poll the stakeholders. Neil Van Dyke wrote at 11/30/2010 01:11 PM: I don't have any important dependencies on the Web Server right now, but just wanted to add that even small backwards-incompatibilities in PLT/Racket have ruffled feathers of consulting clients of mine in the past. When there are backward-incompats, it's *much* better that they be detected at compile time. Example: renaming the hash table procedures was an annoyance when code wouldn't compile, but the changes to open-output-file and friends to use keyword arguments resulted in much more insidious runtime errors. (BTW, Not using Typed Racket yet. Large code base that has been evolving since PLT 1xx/2xx.) When thinking about how you want people to be alerted to incompats, also remember that not everyone reads the release notes. A few times I've seen a programmer install the latest version of PLT to try, which happens to constitute a jump of several versions, and s/he smoke-tests their code with the new version *before* going and reading the release notes for all the intermediate versions. I think that having the platform inform them of incompatibilities through compile-time error messages or compile-time Java-like deprecation warnings gives more confidence in the platform than errors that occur significantly after time T0 in run-time. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] planet package dependencies (was: Re: code base metrics)
While you're in meta-programmer mode, any interest in automatically computing planet dependencies? I'd *love* to know what packages a planet package depends on. I understand that in the presence of dynamic-require, you can only do so well, but even a first approximation could be incredibly useful. No? John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] REPL crash
5 hours ago, Dmitry Chestnykh wrote: The following example from docs (11.9) crashes console REPL (but not gracket or DrRacket): (define-namespace-anchor anchor) (parameterize ([current-namespace (namespace-anchor-namespace anchor)]) (expand (datum-syntax #f '(delay (+ 1 2) Namespace anchors are intended to be used from modules, when you're in the REPL you don't really need to use them -- since you already have the `current-namespace'. The bug is still a bug, of course, just happens to be code that nobody would try... Here's a shorter version: (define-namespace-anchor anchor) (eval 1 (namespace-anchor-namespace anchor)) and in more primitive terms: (define tmp #f) (define r (#%variable-reference tmp)) (eval 1 (variable-reference-namespace r)) -- ((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
