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.
_______________________________________________
alexandria-devel mailing list
alexandria-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/alexandria-devel
