Re: [racket-dev] current-*-port
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04-05-12 05:03, Neil Van Dyke wrote: 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. How about prefixing a tilda (~) instead of current-? It looks like a current ;P and also like a snake (parameters could be thought to ``snake'' through the code). Alternatively the at-sign (@) to represent currentness. To make them stand out more (if that is desirable) the same symbol could be postfixed as well. In conclusion, some options are: ~error-port @error-port ~error-port~ @error-port@ Just some random thoughts, Marijn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+n4hUACgkQp/VmCx0OL2xyCgCfVhr3/gHu/n0bdRTaCPVaILz7 dOwAnjf1HbYc0nBy/hnqWax9C1AQE765 =qgJq -END PGP SIGNATURE- _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] current-*-port
Oh, man. Now I wish that Emacs temporary files didn't end with ~ (because seeing that makes me want to delete it) otherwise, I love this idea for a naming convention for parameters. (To fit in with other naming conventions, we should probably use a suffix, tho, and @, ^, %, and % have all been taken.) Robby On Mon, May 7, 2012 at 9:54 AM, Marijn hk...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04-05-12 05:03, Neil Van Dyke wrote: 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. How about prefixing a tilda (~) instead of current-? It looks like a current ;P and also like a snake (parameters could be thought to ``snake'' through the code). Alternatively the at-sign (@) to represent currentness. To make them stand out more (if that is desirable) the same symbol could be postfixed as well. In conclusion, some options are: ~error-port @error-port ~error-port~ @error-port@ Just some random thoughts, Marijn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+n4hUACgkQp/VmCx0OL2xyCgCfVhr3/gHu/n0bdRTaCPVaILz7 dOwAnjf1HbYc0nBy/hnqWax9C1AQE765 =qgJq -END PGP SIGNATURE- _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] current-*-port
Marijn wrote at 05/07/2012 10:54 AM: How about prefixing a tilda (~) instead of current-? It looks like a current ;P and also like a snake (parameters could be thought to ``snake'' through the code). Alternatively the at-sign (@) to represent currentness. To make them stand out more (if that is desirable) the same symbol could be postfixed as well. In conclusion, some options are: ~error-port @error-port ~error-port~ @error-port@ I don't mind having stdout, stderr, and stdin as aliases for their current names. As a naming convention for all parameters, however, I wouldn't mind keeping the existing one (current- prefix), although it is a little cumbersome. And even though it's a little cumbersome, a little cumbersome is good, considering that I think parameters are for special occasions only. I was thinking before about alphabetic naming convention, rather than using symbol characters. For one reason, I'd like to save the few remaining ASCII symbol characters for other linguistic purposes, especially considering that Racket is also a language experimenter's platform, and we should leave some characters for future expansion. For another reason, I think that alphabetic names can be less cryptic-looking (and easier to pronounce) than symbol characters, so I try to use symbol characters with hesitation only. I'm not in love with any of the alternative alphabetic naming conventions I've thought of: cur- prefix, -param suffix, -parm suffix, -parameter suffix. (And, if -parm suffix, I'd end up using chicken-parm as an example in language tutorials, making them gratuitously obtuse.) Thinking about this has me coming back around to thinking that current- is not so bad, after all. The main drawback is that one's demos look verbose, when one wants to win over the half-dozen people using Arc. Incidentally, starting an identifier with @ is a little bit problematic because of how the reader handles ,@ (unquote-splicing). Neil V. -- http://www.neilvandyke.org/ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] current-*-port
A few minutes ago, Neil Van Dyke wrote: I don't mind having stdout, stderr, and stdin as aliases for their current names. As a naming convention for all parameters, however, I wouldn't mind keeping the existing one (current- prefix), although it is a little cumbersome. And even though it's a little cumbersome, a little cumbersome is good, considering that I think parameters are for special occasions only. Yes, this is why I suggested only that. There are other parameters that are very popular in certain kinds of code -- for example, `current-directory' and `current-namespace' can appear a lot in code that deals with relative paths and meta-tools resp., but the three ports are the only thing that tend to be used in many contexts. I was thinking before about alphabetic naming convention, rather than using symbol characters. For one reason, I'd like to save the few remaining ASCII symbol characters for other linguistic purposes, especially considering that Racket is also a language experimenter's platform, and we should leave some characters for future expansion. For another reason, I think that alphabetic names can be less cryptic-looking (and easier to pronounce) than symbol characters, so I try to use symbol characters with hesitation only. BTW, don't forget unicode -- with good editor support it's an infinite source for such games. Thinking about this has me coming back around to thinking that current- is not so bad, after all. The main drawback is that one's demos look verbose, when one wants to win over the half-dozen people using Arc. (Almost exactly why I made this suggestion...) Incidentally, starting an identifier with @ is a little bit problematic because of how the reader handles ,@ (unquote-splicing). It's more problematic because of the at-exp syntax. -- ((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] current-*-port
On May 3, 2012, at 11:03 PM, Neil Van Dyke wrote: 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. General, off specific topic: Even in the presence of [on-line] type checking, naming conventions make programs readable, as do other conventions. -- Matthias _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] current-*-port
On Fri, May 4, 2012 at 4:04 PM, Matthias Felleisen matth...@ccs.neu.eduwrote: On May 3, 2012, at 11:03 PM, Neil Van Dyke wrote: 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. General, off specific topic: Even in the presence of [on-line] type checking, naming conventions make programs readable, as do other conventions. If I may add my opinion: They also make programs easier to write. And you've probably already been there several times, but: However, long names make programs both easier and harder to read: many symbols on the screen gives a lot of information to the eye, which then takes more time to see relevant info. As sad as I am to say this, arr[x] = 3 is read quicker by the eye than (vector-set! my-integer-array the-current-iterator the-number-three) (obviously exaggerating): for the reader to understand what the instruction/expression means the former only requires syntactic reading, i.e. quick pattern matching for the mind, whereas the latter requires semantic expansion of the words, although the ! here is helpful. I'm certainly not advocating very short names though (and I also like Racket's real words, although sometimes it is indeed too long), just stating some debatable thoughts. An interesting idea would be to count the number of times each identifier is used in the sources, and see how many characters would be saved by using different conventions. Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] current-*-port
On May 4, 2012, at 10:34 AM, Laurent wrote: As sad as I am to say this, arr[x] = 3 is read quicker by the eye than (vector-set! my-integer-array the-current-iterator the-number-three) I started saying this in 1988, when I requested from a Scheme implementor that arrays should be treated as (finite) functions: (arr x) ~ (vector-ref arr x) An interesting idea would be to count the number of times each identifier is used in the sources, and see how many characters would be saved by using different conventions. That sounds like a fantastic exercise for someone who is truly skilled at scripting the shell with all kinds of find/wc/add knowledge. Go for it. -- Matthias _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] current-*-port
On Fri, May 4, 2012 at 4:41 PM, Matthias Felleisen matth...@ccs.neu.eduwrote: On May 4, 2012, at 10:34 AM, Laurent wrote: As sad as I am to say this, arr[x] = 3 is read quicker by the eye than (vector-set! my-integer-array the-current-iterator the-number-three) I started saying this in 1988, when I requested from a Scheme implementor that arrays should be treated as (finite) functions: (arr x) ~ (vector-ref arr x) I would very much like that (for all kinds of containers, and this would even help programs be container-independent). What was the reason for not including this in Racket? An interesting idea would be to count the number of times each identifier is used in the sources, and see how many characters would be saved by using different conventions. That sounds like a fantastic exercise for someone who is truly skilled at scripting the shell with all kinds of find/wc/add knowledge. Go for it. I would certainly if I had time right now... (though using `read' and a hash might be easier). That will need to wait if no one else feels like doing it. Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] current-*-port
Matthias Felleisen wrote at 05/04/2012 10:41 AM: On May 4, 2012, at 10:34 AM, Laurent wrote An interesting idea would be to count the number of times each identifier is used in the sources, and see how many characters would be saved by using different conventions. That sounds like a fantastic exercise for someone who is truly skilled at scripting the shell with all kinds of find/wc/add knowledge. Heresy. Racket is actually well-suited for this task. (At the risk of stating the obvious... Well, you have to do some of the mechanics of directory tree traversal manually, unless someone's already written a directory-fold or similar. Other than that, just call the reader for each Racket file, building a hash of symbols to appearance counts, then run down that hash and another of some candidate renaming scheme, doing the arithmetic. A Unix shell script, on the other hand, would be kludgey even for an expert, and probably take one at least as long to write.) Neil V. -- http://www.neilvandyke.org/ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] current-*-port
On Fri, May 4, 2012 at 5:04 PM, Neil Van Dyke n...@neilvandyke.org wrote: Matthias Felleisen wrote at 05/04/2012 10:41 AM: On May 4, 2012, at 10:34 AM, Laurent wrote An interesting idea would be to count the number of times each identifier is used in the sources, and see how many characters would be saved by using different conventions. That sounds like a fantastic exercise for someone who is truly skilled at scripting the shell with all kinds of find/wc/add knowledge. Heresy. Racket is actually well-suited for this task. (At the risk of stating the obvious... Well, you have to do some of the mechanics of directory tree traversal manually, unless someone's already written a directory-fold or similar. in-directory does what you want. http://docs.racket-lang.org/reference/sequences.html?q=in-directory#%28def._%28%28lib._racket/private/base..rkt%29._in-directory%29%29 The main problem I recently had `read'ing scribble files was the #reader directives, which I had to remove by a regexp-replace before parsing the file (hoping that what follows the #reader is still in s-exp form). Not sure if there is a better solution(?). Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] current-*-port
I know I know. I can't script in anything but Racket. And I have written such scripts and better still I teach such directory traversals to freshmen :-) On May 4, 2012, at 11:11 AM, Laurent wrote: On Fri, May 4, 2012 at 5:04 PM, Neil Van Dyke n...@neilvandyke.org wrote: Matthias Felleisen wrote at 05/04/2012 10:41 AM: On May 4, 2012, at 10:34 AM, Laurent wrote An interesting idea would be to count the number of times each identifier is used in the sources, and see how many characters would be saved by using different conventions. That sounds like a fantastic exercise for someone who is truly skilled at scripting the shell with all kinds of find/wc/add knowledge. Heresy. Racket is actually well-suited for this task. (At the risk of stating the obvious... Well, you have to do some of the mechanics of directory tree traversal manually, unless someone's already written a directory-fold or similar. in-directory does what you want. http://docs.racket-lang.org/reference/sequences.html?q=in-directory#%28def._%28%28lib._racket/private/base..rkt%29._in-directory%29%29 The main problem I recently had `read'ing scribble files was the #reader directives, which I had to remove by a regexp-replace before parsing the file (hoping that what follows the #reader is still in s-exp form). Not sure if there is a better solution(?). Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] current-*-port
[Shuffled] Yesterday, Matthias Felleisen wrote: I don't think Eli is proposing an elimination of the old names but supplementing the code base with new ones. Yes, I'm suggesting something along the lines of a simple addition to `racket/base': (provide (rename-out [current-output-port stdout] ...)) so they even keep the old printed names. Yesterday, Ryan Culpepper wrote: FWIW, 'eprintf' has almost completely eliminated the need to ever type 'current-error-port' for me. Yeah, I suggested adding it for the same reason. (And because practically any program that I wrote had a definition of it anyway.) But it's still common enough to rewire ports, which makes the long names still used pretty often. A common example: (subprocess (current-output-port) (current-input-port) (current-error-port) ...) Yesterday, Neil Van Dyke wrote: 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!) Yes, I'm aware of that... There are two ways that I can think of to go around it: 1. Make the shorter names identifier macros that evaluate to the parameter value. This requires some further hacking so that the parameter can be used when needed. For example, add some syntactic form where the return-the-parameter-value behavior is suppressed. 2. Make the primitive layer for all functions that consume ports accept a parameter (or a thunk) that produces a port too, and apply it to get the value. (The idea is that if the port-consuming primitives change like that, then any abstractions built on them inherit the same.) The first is pretty bad IMO, since the names become more magical than the usual identifier macros. I view the second as a better approach, and one that I wouldn't mind either -- but that's a much deeper change. (At least for anything type-like it will be a headache.) Yesterday, David T. Pierson wrote: On Thu, May 03, 2012 at 03:48:17PM -0400, Eli Barzilay 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)]) 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. [...] It is doing just that -- it just happens that it's easy to redirect it (already) so that error messages go to a different port. It's pretty the same terminology as used in shell scripts, where you can redirect the IO of a single function call so FD number 2 is either the error stream of the whole script, or whatever it was redirected to in this call. [BTW, the analogy also holds wrt debugging code that makes heavy use of such redirections -- if do this kind of debugging in a shell script I'd use something like this to make the debugging show on the terminal: echo blah /dev/stderr and I do the same in Racket: (with-output-to-file /dev/stderr #:exists 'append (λ () (printf blah\n))) I think that CL solves this nicely: in addition to the standard input/output ports, you also have `*query-io*', `*debug-io*', `*terminal-io*', and `*trace-output*'.] Also, I see that these names appear to already be available as proposed via the preprocessor/mzpp and preprocessor/mztext modules. Heh, yes -- the author of that library happens to share many opinions with me, so he defined and provided exactly the same shorthands: (define stdin current-input-port) (define stdout current-output-port) (define stderr current-error-port) (define cd current-directory) (In case it's not clear, I wrote that code -- and I made these shorthands exactly because such redirections are something that you'd use extremely often with the kind of preprocessing that those libraries do.) -- ((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] 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
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
On Thu, May 3, 2012 at 3:58 PM, Danny Yoo d...@cs.wpi.edu 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
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
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
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
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
