I'd like to suggest adding Paul Graham's very useful function #'mkstr, and his #'symb can greatly simplify symbolicate
(defun mkstr (&rest args) "Make a string out of the printed representations of the arguments." (with-output-to-string (s) (dolist (a args) (princ a s))))
(defun symb (&rest args) "Make a symbol out of the printed representations of the arguments." (intern (apply #'mkstr args)))
(I'd prefer this name, but this definition could just replace symbolicate's.)
Thanks, Liam
On Sat, 15 Jan 2011, Liam Healy wrote:
(defun mkstr (&rest args) "Make a string out of the printed representations of the arguments." (with-output-to-string (s) (dolist (a args) (princ a s))))
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
On Sun, Jan 16, 2011 at 1:17 AM, Daniel Herring dherring@tentpost.com wrote:
On Sat, 15 Jan 2011, Liam Healy wrote:
(defun mkstr (&rest args) "Make a string out of the printed representations of the arguments." (with-output-to-string (s) (dolist (a args) (princ a s))))
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.
Liam
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.
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
Just to weigh on this quickly:
Given that we have PRINC-TO-STRING, PRIN1-TO-STRING, and WRITE-TO-STRING, an N-argument version should probably exist in these variants too, and be named along those lines.
Contracted names will not be added to Alexandria, though, unless supported by existing tradition (Zetalisp, etc -- PG doesn't count.)
(And sorry for the delay on this -- as well as other -- Alexandria issues.)
Cheers,
-- nikodemus
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.
+1
On Sun, Oct 30, 2011 at 1:50 PM, Attila Lendvai attila.lendvai@gmail.comwrote:
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.
+1
-- attila
I like Nikodemus' suggestion. I'm even wondering about versions of the functions without the -TO-STRING, as I've wanted to princ multiple items before, I think it would be handy to have.
Liam
alexandria-devel@common-lisp.net
-
Attila Lendvai -
Daniel Herring -
John Fremlin -
Liam Healy -
Nikodemus Siivola