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, ry...@racket-lang.org wrote:
745607a Ryan Culpepper<ry...@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
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
