Re: [racket-dev] #true and #false
At Sun, 10 Oct 2010 11:27:36 -0400, Neil Van Dyke wrote: If #true and #false were just alternative read syntax for #t and #f, and they always printed as #t and #f (except perhaps in teaching languages), that would make me happiest. That's what we have now in v5.0.1.8. From the response in this thread, I guess it will stay that way. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] #true and #false
At Sun, 10 Oct 2010 01:03:57 -0400, Eli Barzilay wrote: An even more common use of `write', I think, is to print code. If we switch to `#true' and `#false' as the default forms of the constants, I think we want all those uses of ~.s that you recently fixed up to print with `#true' and `#false'. Sounds like this is a core question Yes. I suppose it was implicit in my mind with changing the way that true and false values print, but I should have made it explicit: What if we switch to using `#true' and `#false' in our code? then: I'd like to keep coding with #t and #f, so I prefer seeing them in ~.s messages. Two points that I see as emphasizing this: (a) it's a change that is motivated by the teaching languages, (b) it contradics the gradual shift to avoiding verbosity when possible (which is a direction that I very much like, and I get the feeling that I'm not alone). I would like to try using `#true' and `#false' and I think I will like it for the reason in my original message. So, that's two (conflicting) votes so far. Any other opinions? _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] #true and #false
I probably wasn't clear enough in my original message, but I meant that to be a vote for #true and #false. Robby On Sun, Oct 10, 2010 at 8:39 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Sun, 10 Oct 2010 01:03:57 -0400, Eli Barzilay wrote: An even more common use of `write', I think, is to print code. If we switch to `#true' and `#false' as the default forms of the constants, I think we want all those uses of ~.s that you recently fixed up to print with `#true' and `#false'. Sounds like this is a core question Yes. I suppose it was implicit in my mind with changing the way that true and false values print, but I should have made it explicit: What if we switch to using `#true' and `#false' in our code? then: I'd like to keep coding with #t and #f, so I prefer seeing them in ~.s messages. Two points that I see as emphasizing this: (a) it's a change that is motivated by the teaching languages, (b) it contradics the gradual shift to avoiding verbosity when possible (which is a direction that I very much like, and I get the feeling that I'm not alone). I would like to try using `#true' and `#false' and I think I will like it for the reason in my original message. So, that's two (conflicting) votes so far. Any other opinions? _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] #true and #false
On Sun, Oct 10, 2010 at 9:39 AM, Matthew Flatt mfl...@cs.utah.edu wrote: Any other opinions? Personally, I find #true and #false visually ugly, and I also agree with Eli's feelings on terseness. I don't think I've ever accidentally confused #t and #f personally, so I'm not in favor of changing outside of the student languages. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] #true and #false
I do wish that true and false had the same number of letters. (And there is such a parameter. See Matthew's original message for the exact name.) Robby On Sun, Oct 10, 2010 at 8:57 AM, Neil Van Dyke n...@neilvandyke.org wrote: Matthew Flatt wrote at 10/10/2010 09:39 AM: Any other opinions? No strong opinion, but misc. comments: * When working data in sexps a lot, #f taking a lot less space than #false can make things a lot more readable. Imagine, for example, a vector of 20 small integers and false values intermixed. * #f is often used to represent something like ``none'' or ``null'' rather than ``false'', so spelling it out as #false will take some readjustment for some people. * #true and #false do have the advantage of appearing more like a conventional friendly language. * Regarding friendly languages #true and #false have the unfriendly # (ugly, visually dominating, harder to type, longer). Some conventional programmers will prefer #f because, although not as friendly as false, it's more terse. * It's nice that #t and #f are the same length, for lining things up, such as in matrices. * #t and #f can be hard to distinguish from each other visually. Look at a vector of mixed #t and #f values, for example. * #t and #f should always be synonymous with #true and #false, for compatibility with other Racket and Scheme code. * There should be a print parameter to force printing as #t and #f, for interoperation with Schemes. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] #true and #false
1. I consider concise readability as superior to short unreadability. In this spirit, #true and #false are an improvement. I understand that more perfect people than myself will never conflate #t with #f, but since it happened to Matthew, I am happy not be alone. (And that happened before I turned 50 and are probably in the business for reading glasses soon.) 2. I agree that I dislike their unequal length. Before I requested these new constants from Matthew, I considered #tt and #ff instead, i.e., just an extra letter. In a matrix, this could look just fine and would be a nice compromise concerning 1. I also agree that # is, eh, unusual but nobody else has `(true ,true) in languages and things such as Welcome to DrRacket, version 5.0.1.8--2010-10-09(f35477b/g) [3m]. Language: Intermediate Student with lambda. (map boolean? `(true ,true)) (list false true) I am fine with keeping #t and #f around for the more perfect people but I definitely would like an alternative syntax. -- Matthias _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] #true and #false
I agree. As far as students go, I've found that my PLAI students (juniors) adapted very fast to #t and #f from the teaching languages and that even they accidentally try to quote true and false within the single week I teach them with the student languages. So overall I think that #true and #false are good there and I don't see any problem with them being available elsewhere... just not the default. Jay On Sun, Oct 10, 2010 at 8:12 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Sun, Oct 10, 2010 at 9:39 AM, Matthew Flatt mfl...@cs.utah.edu wrote: Any other opinions? Personally, I find #true and #false visually ugly, and I also agree with Eli's feelings on terseness. I don't think I've ever accidentally confused #t and #f personally, so I'm not in favor of changing outside of the student languages. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] #true and #false
Jay McCarthy wrote at 10/10/2010 10:58 AM: So overall I think that #true and #false are good there [in teaching languages] and I don't see any problem with them being available elsewhere... just not the default. FWIW, I would occasionally like to spell out #true and #false in my code. Mainly when giving a Boolean value, rather than #f as a ``none'' value; and in something non-cramped, like a default for a variable, rather than each value in a matrix. But for the majority of uses I would prefer to write #f in my code, and to also see that as the printed representation most of the time. If #true and #false were just alternative read syntax for #t and #f, and they always printed as #t and #f (except perhaps in teaching languages), that would make me happiest. I think it's not too bad if a new programmer types #true in their code and later sees the value printed as #t. They'll figure it out within 2 seconds the first time. (It's a lot more intuitive than how the printing of a pair changes when its CDR is another pair or a null.) -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] #true and #false
At Fri, 8 Oct 2010 23:11:21 -0400, Eli Barzilay wrote: Two hours ago, Matthew Flatt wrote: [Re-sending; an earlier post of this message seems to be delayed.] What if the default printing format for true and false values in Racket changed from `#t' and `#f' to `#true' and `#false'? The forms `#t', `#T', `#true', `#f', `#F', and `#false' would all be accepted as inputs forms. We could conceivably limit the change to `print' output and not change `write' or `display' output, but let's say for now that the proposal is to change the default for all output modes in Racket. [...] I'd prefer it if at least `write' keeps it as #t. IMO `write' as a quick way to serialize some data to a file in a way that is also readable is a very big win, and having a single character (in addition to the obligatory # syntax marker) used for booleans makes it fine in most cases, even up to pretty big files. I can see how making it much longer will encourage using some bad home-cooked serializations to avoid the extra size -- and that would be bad. I agree that serialization is a common use of `write', but if size is an issue, it seems like setting the `print-boolean-long-form' parameter would be easier than cooking a new serialization format. (Actually, `s-exp-fasl' and `fasl-s-exp' are better choices when size matters.) An even more common use of `write', I think, is to print code. If we switch to `#true' and `#false' as the default forms of the constants, I think we want all those uses of ~.s that you recently fixed up to print with `#true' and `#false'. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] #true and #false
Yesterday, Matthew Flatt wrote: At Fri, 8 Oct 2010 23:11:21 -0400, Eli Barzilay wrote: Two hours ago, Matthew Flatt wrote: [Re-sending; an earlier post of this message seems to be delayed.] What if the default printing format for true and false values in Racket changed from `#t' and `#f' to `#true' and `#false'? The forms `#t', `#T', `#true', `#f', `#F', and `#false' would all be accepted as inputs forms. We could conceivably limit the change to `print' output and not change `write' or `display' output, but let's say for now that the proposal is to change the default for all output modes in Racket. [...] I'd prefer it if at least `write' keeps it as #t. IMO `write' as a quick way to serialize some data to a file in a way that is also readable is a very big win, and having a single character (in addition to the obligatory # syntax marker) used for booleans makes it fine in most cases, even up to pretty big files. I can see how making it much longer will encourage using some bad home-cooked serializations to avoid the extra size -- and that would be bad. I agree that serialization is a common use of `write', but if size is an issue, it seems like setting the `print-boolean-long-form' parameter would be easier than cooking a new serialization format. The problem is that the number of hooks that you need to remember to control IO keeps changing (and usually grows), making it hard to find. (Actually, `s-exp-fasl' and `fasl-s-exp' are better choices when size matters.) (I should have added: in a way that is also human readable and editable. The fasl formats are great for saving space and read time (which is why I used that well before the fasl interface...), but I use them only when the data is large enough to justify it -- otherwise the editable format is a bigger win.) An even more common use of `write', I think, is to print code. If we switch to `#true' and `#false' as the default forms of the constants, I think we want all those uses of ~.s that you recently fixed up to print with `#true' and `#false'. Sounds like this is a core question then: I'd like to keep coding with #t and #f, so I prefer seeing them in ~.s messages. Two points that I see as emphasizing this: (a) it's a change that is motivated by the teaching languages, (b) it contradics the gradual shift to avoiding verbosity when possible (which is a direction that I very much like, and I get the feeling that I'm not alone). -- ((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] #true and #false
[Re-sending; an earlier post of this message seems to be delayed.] What if the default printing format for true and false values in Racket changed from `#t' and `#f' to `#true' and `#false'? The forms `#t', `#T', `#true', `#f', `#F', and `#false' would all be accepted as inputs forms. We could conceivably limit the change to `print' output and not change `write' or `display' output, but let's say for now that the proposal is to change the default for all output modes in Racket. Of course, there would be a parameter to pick the traditional format in any case, and we won't change the printer used for R5RS or R6RS. This proposal originates with the need to fix a problem in the HtDP teaching languages. The HtDP teaching languages currently use `true' and `false' for true and false, and the HtDP languages are configured to print booleans as `true' and `false'. That doesn't work with quoted lists. For example, '(true false) is a list of symbols, not a list of booleans. Using `#t' and `#f' in the teaching languages would avoid the problem, but those forms seem awfully terse. We'd like to try `#true' and `#false', instead. Then, to keep the HtDP and full Racket languages in sync as much as possible, we would like to add `#true' and `#false' to Racket. Along the same lines, consistent printing would be ideal. I'd like to switch to `#true' and `#false' because I often fail to look carefully enough to distinguish `#t' and `#f'. Just this morning, I tried out my prototype reader change in the REPL: Welcome to Racket v5.0.1.7. #true #t #false #t That looked right to me. Of course, new cases in the reader test suite immediately flagged the bug, but I was amused that testing in a REPL didn't make me see the problem in the first place. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] #true and #false
Sounds great to me, fwiw. Robby On Fri, Oct 8, 2010 at 8:12 PM, Matthew Flatt mfl...@cs.utah.edu wrote: [Re-sending; an earlier post of this message seems to be delayed.] What if the default printing format for true and false values in Racket changed from `#t' and `#f' to `#true' and `#false'? The forms `#t', `#T', `#true', `#f', `#F', and `#false' would all be accepted as inputs forms. We could conceivably limit the change to `print' output and not change `write' or `display' output, but let's say for now that the proposal is to change the default for all output modes in Racket. Of course, there would be a parameter to pick the traditional format in any case, and we won't change the printer used for R5RS or R6RS. This proposal originates with the need to fix a problem in the HtDP teaching languages. The HtDP teaching languages currently use `true' and `false' for true and false, and the HtDP languages are configured to print booleans as `true' and `false'. That doesn't work with quoted lists. For example, '(true false) is a list of symbols, not a list of booleans. Using `#t' and `#f' in the teaching languages would avoid the problem, but those forms seem awfully terse. We'd like to try `#true' and `#false', instead. Then, to keep the HtDP and full Racket languages in sync as much as possible, we would like to add `#true' and `#false' to Racket. Along the same lines, consistent printing would be ideal. I'd like to switch to `#true' and `#false' because I often fail to look carefully enough to distinguish `#t' and `#f'. Just this morning, I tried out my prototype reader change in the REPL: Welcome to Racket v5.0.1.7. #true #t #false #t That looked right to me. Of course, new cases in the reader test suite immediately flagged the bug, but I was amused that testing in a REPL didn't make me see the problem in the first place. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] #true and #false
Two hours ago, Matthew Flatt wrote: [Re-sending; an earlier post of this message seems to be delayed.] What if the default printing format for true and false values in Racket changed from `#t' and `#f' to `#true' and `#false'? The forms `#t', `#T', `#true', `#f', `#F', and `#false' would all be accepted as inputs forms. We could conceivably limit the change to `print' output and not change `write' or `display' output, but let's say for now that the proposal is to change the default for all output modes in Racket. [...] I'd prefer it if at least `write' keeps it as #t. IMO `write' as a quick way to serialize some data to a file in a way that is also readable is a very big win, and having a single character (in addition to the obligatory # syntax marker) used for booleans makes it fine in most cases, even up to pretty big files. I can see how making it much longer will encourage using some bad home-cooked serializations to avoid the extra size -- and that would be bad. (As for `print' -- seems fine to use the long forms, and I don't have any opinion on `display' (maybe in the name of just show some roughly readable stuff it should use the long forms too).) This proposal originates with the need to fix a problem in the HtDP teaching languages. The HtDP teaching languages currently use `true' and `false' for true and false, and the HtDP languages are configured to print booleans as `true' and `false'. That doesn't work with quoted lists. For example, '(true false) is a list of symbols, not a list of booleans. BTW, wasn't the whole sophisticated quoted printout part of a solution to this, so that those true/false would not print out as quoted? -- ((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] #true and #false
At Fri, 08 Oct 2010 23:10:05 -0400, David Van Horn wrote: On 10/8/10 9:12 PM, Matthew Flatt wrote: This proposal originates with the need to fix a problem in the HtDP teaching languages. The HtDP teaching languages currently use `true' and `false' for true and false, and the HtDP languages are configured to print booleans as `true' and `false'. That doesn't work with quoted lists. For example, '(true false) is a list of symbols, not a list of booleans. What about '(empty)? Seems like the same issue. Yes, so we are also looking at how to move away from `empty'. The answer isn't `#empty' --- at least not without breaking the correspondence between an expression E and `eval' of a `quote'd E. For example, we would want `#empty' by itself to mean the empty list, and quoting `#empty' should also mean the empty list, but `eval'ing the empty list should be an empty application, not the empty list. Maybe we have to use '() for the empty list, even in the teaching languages. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] #true and #false
Two minutes ago, Matthew Flatt wrote: At Fri, 8 Oct 2010 23:11:21 -0400, Eli Barzilay wrote: BTW, wasn't the whole sophisticated quoted printout part of a solution to this, so that those true/false would not print out as quoted? It's an expression issue, not a printing issue. We tell students that `true' and `false' are literals, and we later tell them that `quote' can be used to form lists of literals, and so they try to write the above. Ah, OK. (Just to mention the other kind of course -- in my class I explicitly make a point about the difference between the common `true'/`false' keywords and racket's identifiers literals. I think that most students still miss that point, and get confused over the quoted identifiers and using them in a `let'.) In any case, this seems to me like it weakens the case for the longer names being used globally rather than only in the teaching languages. (But I'm still not objecting, except for the same `write' point I made.) -- ((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
