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

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!