[racket-dev] [plt] Push #24674: master branch updated

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, ryanc at racket-lang.org wrote:
>>>> 
>>>> 745607a Ryan Culpepper<ryanc at racket-lang.org>  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