Ryan, thanks for writing this library. I completely understand why you wanted it.
I have used the name ++ in the past. I find the many options a bit confusing, so I do understand some of Eli's concerns. But it is always more productive to start from something concrete to discuss than to discuss non-existent vaporware. [At the same time, as I am reading the documentation, I understand why you want the options.] -- Matthias On May 9, 2012, at 1:08 AM, Eli Barzilay wrote: > An hour ago, Ryan Culpepper wrote: >> On 05/08/2012 08:29 PM, Eli Barzilay wrote: >>> 5 hours ago, [email protected] wrote: >>>> >>>> 745607a Ryan Culpepper<[email protected]> 2012-04-18 14:58 >>>> : >>>> | added unstable/cat >>> >>> Why? > > This was too implicit -- there's a rationale missing from either the > source or the documentation. Probably some of your explanation below > should be added to either/both places. > > >>> and not even for a good reason since `cat' is a pretty bad name >>> for something that is supposed to be used to print stuff. >>> "Consider as text" is not really helping in making the name any >>> better, and it's worse when it gets to obscure names like `catne' >>> and `catnp'. >> >> 'cat' is memorable ("hey, like the unix command"!) and it's short. > > I should have mentioned the unix command as the main thing that makes > this confusing... (When I first read the commit on my phone, all I > say was "cat" and some stuff about printing -- you can see how I > interpreted this.) > >> The others names are reasonable variations on the central theme and >> also short. I admit 'catnp' and 'catne' are stretching it; maybe we >> can find better names for them. But I wanted to have a concrete >> starting point for discussion. >> >> "Consider as text", BTW, is a pure Backronym. > > (Even though it's obviously retrofitted, I think that removing it > would help...) > > >> My main idea is that Racket lacks---and needs---a quick way of >> turning values into text and conCATenating them. Java has '+', PHP >> has '.', SQL has '||', and so on. You can make good arguments that >> none of those is well-named, but once it's The Way, that doesn't >> matter at all. > > (This is the missing rationale, BTW. (One of the things that puzzled > me was why make it take any number of arguments... so I was way off.)) > > If this is the intention, then (I'm guessing) you started with just a > short name for the awfully-long-for-its-utility `string-append', and > then added a bunch of configurations, right? > > If so, then I think that using parameters works better for two > reasons: it makes the core `cat' function be more like `string-append' > which just "happens" to also accept any non-string values. The other > reason is that the huge advantage of a short name is kind of lost with > the very verbose keywords. > > >>> But there's also the issue of how it's used to print things: IIUC, >>> this is intended to be used only for converting values to strings, >>> so there's a good point in having this kind of thing if it's part >>> of a proper library for formatted output. And there's obviously a >>> desperate need for something that does that. >>> >>> So, more concrete suggestions: >>> >>> 1. Rename all of the `cat*'s (unless they end up being used >>> internally) to some better name. >> >> I'm open to suggestions, as long as they're short. (I considered >> stealing the name 'echo' from you instead of 'cat' from srfi/54, but >> it's not particularly better and it's a letter longer.) > > Yeah, given the rationale that you've now filled in, `echo' is a bad > name since it implies doing the output. (It's more like `echos' from > swindle, a name that I never liked but couldn't find anything better.) > So for this purpose, `cat' makes a bit more sense, but the unix thing > is still very strongly in the way, IMO, as well as the fact that it > does more than just concatenate strings. > > So, given that a proper full name for this would be something like > `string-coerce/append', how about a very short `s+'? (This goes > directly in the direction of this thing having the very short names > you mention above in other languages.) A slightly longer variant is > `str+' -- I think that it makes it very clear that this is doing the > coerce+concatenate (`s+' too, more weakly). > > >>> 2. Implement a proper library formatting library that uses this >>> for basic values. >>> 2a. This might mean that this code is used only indirectly, hence >>> the comment in #1. >>> 2b. It should also be extensible. >> >> More formatting capabilities would be nice, but I don't want to >> widen the scope of this discussion. I know I've wanted 'cat' and >> 'catn' many times before, and I'm pretty sure I want 'catp'. Beyond >> that it's design by speculation (for me, anyway)---and possibly the >> numeric formatting needs to be scaled back some anyway. > > I think that given the above, less formatting options would be > good... How about this: > > * Remove the padding, trimming, etc from it > * Rename `catp', `catw', etc with more fitting names, maybe things > like `as-print', `as-write', `as-number' etc. Or maybe `printed' > `written'. This rename seems to be desirable since they're > already have a very different use from `cat' (doesn't really do > the concatenation). > * Use a keyword argument (or parameter) to distinguish what is now > known as `catn', `catnp', and `catne'. > * Add a different function for the trim/pad/whatever. > > Just to try it, I think that this looks much more readable: > > (pad 30 #:direction 'right #:char #\. > (s+ "blah " (as-number x) " blah " (as-printed y))) > > >>> The #2 item is of course a big job here, [...] >> >> Way too much. I think you're overestimating the intended scope of this >> library. [...] > > I did, and I think that the above tweaks are desperately needed given > that it's easy to think it was intended to do more. > > But in any case, since you've bothered reading about these other > things, how about doing that anyway? > > -- > ((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
