Re: [racket-dev] Internal definitions in `define'
I was against it for similar reasons, but the question is whether there's a technical point that makes it a bad choice. As for making errors: I changed my mind when I though about the symmetry argument -- using the same argument, I'd expect to do the exact same kind of mistakes with functions, but I don't think that I've ever had one. Another factor is that if you think about possible mistakes, then I take it as a point in favor of doing this, since it reduces the number of parens as well as getting rid of the familiar (define foo (let () ...stuff...)) thing which should result in less mistakes. 8 hours ago, Robby Findler wrote: I'm mildly against it, since it seems too easy to make parenthesis errors that are very confusing (ie if you move a paren from the end of one define to the end of a following define, the errors will get strange). Robby On Thu, Dec 29, 2011 at 1:08 PM, Eli Barzilay e...@barzilay.org wrote: Does anyone know of a reason to not have an implicit `begin' in a plain definition, translated into an implicit (let () ...) in racket? When I see things like this: http://stackoverflow.com/questions/8667403 I think that people expect the syntax of `define' to be uniform, so if you can switch these: (define (foo x) (+ x 1)) (define foo (+ 8 1)) then the expectation is for the same to work when there are multiple expressions. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] no capturing groups in regexp-split? [was Re: [PATCH] add regexp-split]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 30-12-11 09:32, Eli Barzilay wrote: This doesn't look like an issue that is related to guile, just that he chose python as the goal... The first other random example I tried was `split-string' in Emacs, which did the same thing as Racket. They may choose python's version as the goal. It doesn't look like they have looked very hard as of yet at what else is out there. Probably because they are expecting compatibility between most implementations. Welcome to Racket v5.2.0.7. (regexp-split ([^0-9]) 123+456*/) '(123 456 ) should it be considered a bug in racket that it doesn't support capturing groups in regexp-split? No. Without the capturing group the results are identical: [...] Which is expected. Good, just establishing a baseline here, but it is good that some compatibility is *expected*. How nice is that? Since we're expecting compatibility between python and racket, I guess it goes without saying that racket's and guile's regexp-split should be compatible as well. R7RS Large may standardize a regular expression library, and we can make that easier by reducing incompatibilities between schemes. We can all grow from examining our incompatibilities, discussing them and sometimes resolving them. Python does something which is IMO very weird: re.split(([^0-9]), 123+456*/) ['123', '+', '456', '*', '', '/', ''] It's even more confusing with multiple patterns: re.split(([^0-9]([0-9])), 123+456*/) ['123', '+4', '4', '56*/'] There's probably uses for that -- at least for the simple version with a single group around the whole regexp, but that's some hybrid of `regexp-split' and `regexp-match*': it returns something that interlevase them, which can be useful, but I'd rather see it with a different name. Yes, I agree that I find it a bit weird as well. You don't lose anything by supporting this though, since you can always use a non-capturing group, but I do agree that it can be considered an inappropriate extension of the meaning of regexp-split. I'll be sure to raise these issues on the guile list. We've talked semi-recently about adding an option to `regexp-match*' so it can return the lists of matches for each pattern, perhaps add another option for returning the unmatched sequences between them, and give the whole thing a new name? (Something that indicates it being the multitool version of all of these.) Interesting. Marijn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk79i1QACgkQp/VmCx0OL2zI4gCgtLLd3b6vgzaksYSA7wsZksHA yeIAoJJ6G7AcimN3OhtxFMvN8Xf7TdrH =1+Ax -END PGP SIGNATURE- _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] no capturing groups in regexp-split? [was Re: [PATCH] add regexp-split]
7 hours ago, Marijn wrote: On 30-12-11 09:32, Eli Barzilay wrote: Without the capturing group the results are identical: [...] Which is expected. Good, just establishing a baseline here, but it is good that some compatibility is *expected*. I meant that getting the same results is the thing that is expected. There's probably uses for that -- at least for the simple version with a single group around the whole regexp, but that's some hybrid of `regexp-split' and `regexp-match*': it returns something that interlevase them, which can be useful, but I'd rather see it with a different name. Yes, I agree that I find it a bit weird as well. You don't lose anything by supporting this though, since you can always use a non-capturing group, but I do agree that it can be considered an inappropriate extension of the meaning of regexp-split. I'll be sure to raise these issues on the guile list. We do have an important loss -- all current code that will break because it assumes the current behavior. This is why I suggested a different name -- the new function could be used to return the gaps (as split does), the matches (as match*), the matches including groups, or all of these. We've talked semi-recently about adding an option to `regexp-match*' so it can return the lists of matches for each pattern, perhaps add another option for returning the unmatched sequences between them, and give the whole thing a new name? (Something that indicates it being the multitool version of all of these.) Interesting. BTW, one thing that I think it should do is avoid the splicing of the group matches that python is doing. In any case, any suggestions for a name? -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Internal definitions in `define'
Now that I'm a whiny junior dev, does that mean I can do the +/-1 thing? Because after reading Eli's argument - particularly the symmetry arguments - I'm totally +1-ing his proposal. This is one of the last places I find myself using the (let () ...) idiom. (The others are `define-syntax-rule', `syntax-rules' and `syntax-case', but I don't think those should change.) Neil T On 12/30/2011 01:36 AM, Eli Barzilay wrote: I was against it for similar reasons, but the question is whether there's a technical point that makes it a bad choice. As for making errors: I changed my mind when I though about the symmetry argument -- using the same argument, I'd expect to do the exact same kind of mistakes with functions, but I don't think that I've ever had one. Another factor is that if you think about possible mistakes, then I take it as a point in favor of doing this, since it reduces the number o ff parens as well as getting rid of the familiar (define foo (let () ...stuff...)) thing which should result in less mistakes. 8 hours ago, Robby Findler wrote: I'm mildly against it, since it seems too easy to make parenthesis errors that are very confusing (ie if you move a paren from the end of one define to the end of a following define, the errors will get strange). Robby On Thu, Dec 29, 2011 at 1:08 PM, Eli Barzilaye...@barzilay.org wrote: Does anyone know of a reason to not have an implicit `begin' in a plain definition, translated into an implicit (let () ...) in racket? When I see things like this: http://stackoverflow.com/questions/8667403 I think that people expect the syntax of `define' to be uniform, so if you can switch these: (define (foo x) (+ x 1)) (define foo (+ 8 1)) then the expectation is for the same to work when there are multiple expressions. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] dependencies and racket
Another variation, if you're thinking about cloud infrastructure today: you could pretty easily make your own faux PLaneT server that either is for a single app or takes the identity/profile of the app as part of the URL the app uses to access the PLaneT server. The faux server can be a tiny HTTP server process, as it only has to perform a single, simple REST operation. This faux PLaneT server would *enforce* the same profile of PLaneT package versions for the app, and also serve the packages from a trusted cache at app compile time. Or you can use the careful-crafted ~/.racket/ directory approach. I suppose the choice depends on which is easier to do well in your existing infrastructure. It's good to see interest in Racket from cloud people. Feel free to ask lots of questions on the Racket users and dev email lists as you work through your solution. -- http://www.neilvandyke.org/ _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Small typo in scribble/core docs
I'm not set up to make a pull request on this computer, but core.scrbl needs to add an s to make contents the field name for multiarg-element, not content. -Ian _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Small typo in scribble/core docs
Thanks! At Fri, 30 Dec 2011 17:45:01 -0500 (EST), J. Ian Johnson wrote: I'm not set up to make a pull request on this computer, but core.scrbl needs to add an s to make contents the field name for multiarg-element, not content. -Ian _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] dependencies and racket
On Fri, Dec 30, 2011 at 9:45 AM, Neil Van Dyke n...@neilvandyke.org wrote: It's good to see interest in Racket from cloud people. Feel free to ask lots of questions on the Racket users and dev email lists as you work through your solution. Well, this a side-interest for personally, but *anyone* can make a 'build pack' for Heroku, and they can be simple. Take the Python build pack for instance, which is little more than three bash files in the 'bin' directory: https://github.com/heroku/heroku-buildpack-python And one for Go: https://github.com/kr/heroku-buildpack-go The Go one, in particular, is not baked into the platform (one must set BUILDPACK_URL to use it, and it downloads its own preferred version of the compiler) and yet does what it needs to do in about 50 lines of not-very-dense bash -- downloads and installs the compiler and dependencies , and that's it. There is nothing particularly 'cloudy' about these, and the most simple Racket buildpack would do little more than download Racket, or maybe run raco distribute. I came to this list because it appears to me that such a distributed binary would download dependencies on the fly per invocation of the Racket program, and that would be a lousy property for the software being written, and could also have a negative impact on PlaneT as an infrastructure (it also might just not work, depending if writes were attempted to a read-only part of the file system). I also wanted to seek out idioms already in the wild for handling this problem. I do not see this as a cloud problem, but rather a tooling or communication gap in packaging and distributing Racket applications that make use of anything except libraries included in the Racket distribution. -- fdr _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] dependencies and racket
On Thu, Dec 29, 2011 at 8:07 PM, Robby Findler ro...@eecs.northwestern.edu wrote: I think that a minor variation on Neil's strategy should not be too difficult to do (but I'll certainly agree that it is not an ideal situation). What you'd do is first just download (via the Bam method below :) the planet packages you want. Then, if you look inside this directory: (build-path (find-system-path 'addon-dir) planet 300) you should find some files with extensions .plt. Re-build that same portion of the directory structure to contain those files in the deployment environment, and then set the PLTPLANETURL environment variable to something bogus. That looks like a pretty reasonable way to get started. Thanks for telling me about the build-path and find-system-path operators, and the bogusifying of the PLT URL to prevent accidental hammering. Also, FWIW, I maintain, in the weakest sense of the word, the current planet service. (All I really do is react to emergencies that break things.) Jay and Eli are looking into a whole new thing and have been talking about it for more than a year, I believe, so hopefully plans are firming up. Their system should be able to support this kind of use-case much more effectively. I think that kind of thing is designed in for them. I'd be interested in reading their current thoughts. Having used now a small stable of dependency management systems, my favorite, by far, is bundler for Ruby. It can handle upgrades, version pinning, allowing for auditing in upgrades of packages, preventing an executed program from using libraries that are not in its manifest (to prevent 'accidental' dependency), bin-directory generation for packages that install command line programs, and it will transitively consider all version requirements of all libraries to try and select the latest version -- should any one version exist -- that can satisfy all the constraints. Above all, it does that without being burdensome to use or understand. One could do worse than implementing the same thing, but for Racket. -- fdr _ Racket Developers list: http://lists.racket-lang.org/dev
