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
