On Sun, Jan 16, 2011 at 8:58 PM, John Fremlin john@fremlin.org wrote:
Liam Healy lnp@healy.washington.dc.us writes:
On Sun, Jan 16, 2011 at 1:17 AM, Daniel Herring dherring@tentpost.com wrote:
[...]
Isn't that the same as (defun mkstr (&rest args) "Make a string out of the printed representations of the arguments." (format nil "~{~A~}" args)) ?
Is this complicated enough to be a standalone, documented function?
- Daniel
I think your form of the function would indeed do the same thing.
I don't think complexity is a point on which a utility should be judged, but rather how useful it is, essentially, how much people have to repeat its functionality (see for instance ensure-symbol, already in alexandria, which is simpler than this). I use mkstr all the time, and imagine it would be useful to others. And, since symbolicate is just the symbol form of the output, it seems that it's useful to others.
I think that it is generally useful to have such a stringify function: "mkstr" will inevitably be reinvented countless times in all sorts of projects.
However, I suppose the point of Alexandria is to provide such generally useful functionality in a carefully thought out and coherent way: should the mkstr depend on the various *print-...* variables? I think this is a debatable question -- especially when combined with the symbolicate use case.
Then there is the point that
A string is a specialized vector whose elements are of type character or a subtype of type character. When used as a type specifier for object creation, string means (vector character).
by the hyperspec there are (potentially) numerous different types of string. Could it be useful to return a specific subtype of string?
In tpd2 this function is called strcat (if I remember rightly) and attempts to do as much work as possible (coalescing of constant arguments) as early as possible. I'd be happy to donate or rewrite this code for the Alexandria project.
While the functionality of a complete mkstr is indeed roughly replicable in a short implementation, that short implementation is probably lacking in terms of performance, features and semantic guarantees -- all of which it would be useful for Alexandria to sensibly tackle.
For precedent, it is possible to implement the factorial function in Alexandria quite trivially, but a trivial implementation cannot achieve the higher performance behaviour of the careful %multiply-range which Alexandria provides.
Sounds good. I'm not fond of the name "strcat", but come to think of it, I'm not fond of "mkstr" either -- they're more in a C naming tradition. I don't have a good suggestion for a name though.
I hadn't really thought about efficiency; my usage is very simple so efficiency is irrelevant. I guess I assumed everyone else's would be too. The string type is also something I hadn't thought about. I'm not sure how you would specify what type you want. Because of the &rest args, there isn't a place to add an optional argument, and a required (but I think seldom needed) argument at the beginning is kind of awkward.
Good point about the *print.. * variables option, I hadn't thought of it. I guess I'd say no, I'd like to see it produce the same result regardless of what those are set to.
Liam