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, 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'.
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.
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.
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.
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.
--
((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
