[alexandria-devel] Add mkstr and simplify of 'symbolicate

[Liam Healy]

On Sun, Jan 16, 2011 at 8:58 PM, John Fremlin <john at fremlin.org> wrote:
> Liam Healy <lnp at healy.washington.dc.us> writes:
>> On Sun, Jan 16, 2011 at 1:17 AM, Daniel Herring <dherring at 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