Re: [alexandria-devel] Add mkstr and simplify of 'symbolicate
On Sun, Oct 30, 2011 at 1:50 PM, Attila Lendvai attila.lend...@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 mailing list alexandria-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/alexandria-devel
Re: [alexandria-devel] Add mkstr and simplify of 'symbolicate
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 ___ alexandria-devel mailing list alexandria-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/alexandria-devel
Re: [alexandria-devel] Add mkstr and simplify of 'symbolicate
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
Re: [alexandria-devel] Add mkstr and simplify of 'symbolicate
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
___
alexandria-devel mailing list
alexandria-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/alexandria-devel
Re: [alexandria-devel] Add mkstr and simplify of 'symbolicate
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
