On Sun, Jan 16, 2011 at 8:58 PM, John Fremlin <j...@fremlin.org> wrote: > Liam Healy <l...@healy.washington.dc.us> writes: >> On Sun, Jan 16, 2011 at 1:17 AM, Daniel Herring <dherr...@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 _______________________________________________ alexandria-devel mailing list alexandria-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/alexandria-devel