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

I was going to wait to start a discussion until I could at least point 
to the nightly build docs, but for people who haven't built from source 
in the last few hours, here's the library under discussion:

   http://www.cs.utah.edu/~ryan/tmp/cat.html

(more below)

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 library uses `cat' which is a name that is used by srfi-54, yet
> it looks like it's completely unrelated to it.  In addition, the same
> name is also bound by Shinn's `fmt' library, where it's doing
> something else.  So `cat' manages to collide with two libraries that
> do something similar,

I don't get the impression that either of those libraries are 
particularly entrenched in Racket usage.

 > 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. 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.

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.

> 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.)

> 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.

BTW, it's also extensible via prop:custom-write. Beyond that, no. The 
goal isn't to do everything; it's to do some things more conveniently.

> 3. Pay much more attention to efficiency.  Some quick things that I
>     see in the code:
>     - `round*' could be much simpler (eg, (floor (+ x 1/2)))
>     - `get-digit' should be a quick lookup
>     - There are three `make-string's that should all be memoized
>     This is important because some people do use libraries to print
>     large amounts of texts.
>     - Another side-point is that the code is a good demonstration for
>       the lack of a way to easily compose functions with keyword
>       arguments.

I agree with some of this (see TO DO comments in source), but it should 
wait until later.

> The #2 item is of course a big job here, but without it I see little
> point in having such a library in the first place.
>
> To do this, there's the obvious format-string-language which is bad
> when it gets to powerful CL-style format strings (since they're a new
> sub-language), and it's worse in that it's impossible to make it
> extensible without resorting to ugly CL-style tricks.  Another
> approach that I've played with is replace the format string by a
> mixture of strings, values, and keywords that replace the
> format-string language -- it was a good experiment in that it can deal
> with all of the complexities that you can do with CL format strings,
> but it was bad in showing that it's not really making things better;
> also, extensibility is now possible (no need to resort to identifiers-
> in-string hacks), but it's still hard to get right.  (BTW, this is all
> done as `echo' in swindle.)
>
> Another approach is the `fmt' library that I mentioned
> (http://synthcode.com/scheme/fmt/) which Alex even packaged for
> Racket.  I think that this is the most promising approach --
> especially since extensions are obviously possible, and the whole
> thing can still work fine even when you want to generate huge amounts
> of output.  A potential downside is the description language for the
> formats is still complicated -- but at least you're now in plain
> racket rather than remembering weird character combinations.  If the
> functions that are constructed for these "templates" are simple enough
> (eg, if they can be used outside of a `fmt' call), then it would be
> easy to play with things.

Way too much. I think you're overestimating the intended scope of this 
library. I have three goals in mind:

1. Replace 'string-append' with something shorter.

2. Replace (format "~[asv]" _) with something shorter. I counted 435 
occurrences of this pattern in the Racket tree. And it bothers me for 
some reason.

   find -name '*.rkt' -or -name '*.scrbl' \
     | xargs egrep '\(format "~[asv]"' \
     | wc -l

3. Make basic numeric formatting convenient.

Beyond that it's all negotiable. #:pad-to and #:limit seem just common 
enough and useful enough to warrant inclusion, but maybe not.

Ryan