Re: [racket-dev] current-*-port
On Thu, May 03, 2012 at 03:48:17PM -0400, Eli Barzilay wrote: > With the trend of having shorter names, I'll try suggesting it again. > Looking at some random slides (the ones from Matthew's talk), one > thing that is -- still -- very strikingly inconvenient is code like > > (parameterize ([current-error-port (current-output-port)]) > ...) > > IMO, anyone who is not coming from some kind of Scheme background > would view this as ridiculously long. If they're renamed to the usual > names, things look much better: > > (parameterize ([stderr (stdout)]) My first thought is that the names current-error-port and stderr suggest different concepts. stderr is the standard error stream corresponding to POSIX file descriptor 2. current-error-port is an abstraction mechanism that allows you to control where error messages are directed. If stderr were to be bound in #lang racket, based on the above I'd expect it to be bound to a port corresponding to the standard error stream, not bound to a parameter controlling which port error messages go to. I realize such a stderr binding would not be particularly useful for most Racket programs, so I'm not advocating having such a binding. I'm just saying the name "stderr" implies something different than "current-error-port", that "current-error-port" better denotes the purpose of the parameter, and that in this case I like the more accurate name is better than the short name. If parameterize forms like your example are the main motivation, perhaps a new function or syntax would be more to the point? e.g. something called with-errors-to-output... Also, I see that these names appear to already be available as proposed via the preprocessor/mzpp and preprocessor/mztext modules. Finally, It occurs to me that this is the second time in several weeks I'm responding to a thread about changing names. Hopefully my comments are thoughtful and not just reactionary. David _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] current-*-port
Matthias Felleisen wrote at 05/03/2012 10:57 PM: I don't think Eli is proposing an elimination of the old names but supplementing the code base with new ones. I am in favor -- Matthias Would be good to have a shorter naming convention for all parameters. The "current-" prefix is not short, but it's what I've been using when coding new parameters, because that's the convention. Of course, a naming convention is much less important when we have static checking of argument types, but we usually don't. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] current-*-port
I don't think Eli is proposing an elimination of the old names but supplementing the code base with new ones. I am in favor -- Matthias _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] current-*-port
On 05/03/2012 02:09 PM, Neil Van Dyke wrote: Eli Barzilay wrote at 05/03/2012 03:48 PM: (parameterize ([stderr (stdout)]) ...) I'm not sure how I feel about shortening these, but an additional consideration is that a naming convention for parameters (so far, prefixing with "current-") has been useful. I think a naming convention can help remind people that this won't work with renaming alone: (fprintf stderr "Oops!") FWIW, 'eprintf' has almost completely eliminated the need to ever type 'current-error-port' for me. Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] current-*-port
On Thu, May 3, 2012 at 3:58 PM, Danny Yoo wrote: > > IMO, anyone who is not coming from some kind of Scheme background > > would view this as ridiculously long. If they're renamed to the usual > > names, things look much better: > > > > (parameterize ([stderr (stdout)]) > >...) > > > Definitely +1. > add1 --Carl _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] current-*-port
Eli Barzilay wrote at 05/03/2012 03:48 PM: (parameterize ([stderr (stdout)]) ...) I'm not sure how I feel about shortening these, but an additional consideration is that a naming convention for parameters (so far, prefixing with "current-") has been useful. I think a naming convention can help remind people that this won't work with renaming alone: (fprintf stderr "Oops!") Neil V. -- http://www.neilvandyke.org/ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] current-*-port
> IMO, anyone who is not coming from some kind of Scheme background > would view this as ridiculously long. If they're renamed to the usual > names, things look much better: > > (parameterize ([stderr (stdout)]) > ...) Definitely +1. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] current-*-port
With the trend of having shorter names, I'll try suggesting it again. Looking at some random slides (the ones from Matthew's talk), one thing that is -- still -- very strikingly inconvenient is code like (parameterize ([current-error-port (current-output-port)]) ...) IMO, anyone who is not coming from some kind of Scheme background would view this as ridiculously long. If they're renamed to the usual names, things look much better: (parameterize ([stderr (stdout)]) ...) Another point in favor: looking through my mailbox, it was very clear that when people are talking about `current-error-port' etc, they already use `stderr' etc in emails. Another point for doing that in this case but not in others: it is particularly bad in that it's three words, and it's something that is much more common to deal with. They could be provided as the old names too, for compatibility. [Disclosure: I remembered suggesting it once, and finally found it -- I did this about 4 years ago. The discussion didn't go beyond "use M-/ in emacs", which is still very inconvenient.] -- ((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] implicit begin for define-syntax-rule
I would say no, since a "syntax rule" is a single rewrite rule. Perhaps you want a simple shim around syntax-rules? Like: (define-syntax-rules [(id . pat) rhs] ...+) where id must be the same in all templates? Simple implementation: (define-syntax (define-syntax-rules stx) (syntax-case stx () [(_ [(id0 pat0 ...) rhs0] [(ids pats ...) rhss] ...) (and (identifier? #'id0) (andmap (λ (i) (and (identifier? i) (free-identifier=? i #'id0))) (syntax->list #'(ids ... (syntax/loc stx (define-syntax (id0 stx) (syntax-rules stx () [(_ pat0 ...) rhs0] [(_ pats ...) rhss] ...)))])) -Ian - Original Message - From: "Marijn" To: dev@racket-lang.org Sent: Thursday, May 3, 2012 5:39:10 AM GMT -05:00 US/Canada Eastern Subject: [racket-dev] implicit begin for define-syntax-rule -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, would it make sense for define-syntax-rule to have an implicit begin such that it could accept multiple forms for the template? Marijn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+iUj4ACgkQp/VmCx0OL2zrmACfQ18nV7BoxV2wm4SrPyCSD0rY z54An3Kd24mFWFVuCxQ95J1Z6I5EuEJy =fmgP -END PGP SIGNATURE- _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] implicit begin for define-syntax-rule
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, would it make sense for define-syntax-rule to have an implicit begin such that it could accept multiple forms for the template? Marijn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+iUj4ACgkQp/VmCx0OL2zrmACfQ18nV7BoxV2wm4SrPyCSD0rY z54An3Kd24mFWFVuCxQ95J1Z6I5EuEJy =fmgP -END PGP SIGNATURE- _ Racket Developers list: http://lists.racket-lang.org/dev
