{"action":"created","issue":{"url":"https://api.github.com/repos/plt/racket/issues/928","labels_url":"https://api.github.com/repos/plt/racket/issues/928/labels{/name}","comments_url":"https://api.github.com/repos/plt/racket/issues/928/comments","events_url":"https://api.github.com/repos/plt/racket/issues/928/events","html_url":"https://github.com/plt/racket/pull/928","id":72878646,"number":928,"title":"Add expansions for and/or to permit higher-order usage","user":{"login":"lexi-lambda","id":759911,"avatar_url":"https://avatars.githubusercontent.com/u/759911?v=3","gravatar_id":"","url":"https://api.github.com/users/lexi-lambda","html_url":"https://github.com/lexi-lambda","followers_url":"https://api.github.com/users/lexi-lambda/followers","following_url":"https://api.github.com/users/lexi-lambda/following{/other_user}","gists_url":"https://api.github.com/users/lexi-lambda/gists{/gist_id}","starred_url":"https://api.github.com/users/lexi-lambda/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/lexi-lambda/subscriptions","organizations_url":"https://api.github.com/users/lexi-lambda/orgs","repos_url":"https://api.github.com/users/lexi-lambda/repos","events_url":"https://api.github.com/users/lexi-lambda/events{/privacy}","received_events_url":"https://api.github.com/users/lexi-lambda/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":9,"created_at":"2015-05-03T22:53:45Z","updated_at":"2015-06-22T16:58:26Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/plt/racket/pulls/928","html_url":"https://github.com/plt/racket/pull/928","diff_url":"https://github.com/plt/racket/pull/928.diff","patch_url":"https://github.com/plt/racket/pull/928.patch"},"body":"This is a work in progress experiment I've implemented based on a discussion I started on the IRC channel. Effectively, this modifies how `and` and `or` expand to permit them to be used as functions.\r\n\r\n```racket\r\n(apply and 1 #f 3) ; => #f\r\n```\r\n\r\nObviously, using `and` or `or` as functions disables their short-circuting functionality, but using them as before retains it. Importantly, all usages of these forms in a higher-order manner would have previously been a syntax error, so no working code can possibly be affected by this change.\r\n\r\nI *personally* believe this is a worthwhile change, but obviously these are two fairly important forms, so I think a discussion of the pros and cons is needed. I think think the benefits are straightforward:\r\n\r\n- Using these operations in a higher-order manner can frequently be useful, and it is not uncommon to have new users unfamiliar with how the macros operate ask questions on IRC after running into a syntax error from a bare use of `and` or `or`.\r\n- Implementing these as alternative expansions of the existing macros makes using them seamless, and follows the principle of least astonishment.\r\n- Any higher-order use of these logical functions wouldn't be able to take advantage of short-circuiting evaluation, anyway (assuming a strict evaluation model), so it is unlikely to cause any surprise in that regard.\r\n\r\nThe possible downsides I've considered are as follows:\r\n\r\n- The \"magical\" behavior could be even more confusing to new users if they were to accidentally stumble into it. Trying to use `and` as a higher-order function currently just throws a syntax error, which is annoying, but at least the user is prompted to figure out why. On the other hand, if the user expects short-circuit evaluation with this implementation, it will silently \"misbehave\".\r\n- Introducing this kind of change in `racket/base` could likely have effects on other `#lang`s that make use of the base language's `and` and `or` forms. For example, `r5rs` just uses `and` and `or` from `scheme/base`, so it would need to be modified to use the old behavior.\r\n\r\nThere are also topics of consideration that aren't necessarily benefits *or* downsides.\r\n\r\n- Should these be a part of `racket/base`, `racket/bool`, or some other package? Having them in the standard library would be very nice, but maybe this sort of change isn't suitable for the core language.\r\n- If these did end up in `racket/base`, would there be any easy way to access the legacy behavior? Since this is a superset of the old behavior, it is unlikely that it would really be necessary, but for languages like `r5rs`, it might be useful.\r\n\r\nFinally, if moving forward is determined to be a good idea, there are things I'd need to do to get this to an acceptable state.\r\n\r\n- [ ] Update reference and guide to adequately explain and document behavior\r\n- [ ] Add tests!\r\n- [ ] Fix the rnrs langs, maybe by changing their behavior in `scheme/base`?"},"comment":{"url":"https://api.github.com/repos/plt/racket/issues/comments/114178536","html_url":"https://github.com/plt/racket/pull/928#issuecomment-114178536","issue_url":"https://api.github.com/repos/plt/racket/issues/928","id":114178536,"user":{"login":"stamourv","id":854429,"avatar_url":"https://avatars.githubusercontent.com/u/854429?v=3","gravatar_id":"","url":"https://api.github.com/users/stamourv","html_url":"https://github.com/stamourv","followers_url":"https://api.github.com/users/stamourv/followers","following_url":"https://api.github.com/users/stamourv/following{/other_user}","gists_url":"https://api.github.com/users/stamourv/gists{/gist_id}","starred_url":"https://api.github.com/users/stamourv/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/stamourv/subscriptions","organizations_url":"https://api.github.com/users/stamourv/orgs","repos_url":"https://api.github.com/users/stamourv/repos","events_url":"https://api.github.com/users/stamourv/events{/privacy}","received_events_url":"https://api.github.com/users/stamourv/received_events","type":"User","site_admin":false},"created_at":"2015-06-22T16:58:26Z","updated_at":"2015-06-22T16:58:26Z","body":"(add1 @samth)"}}