Converting a list to a string
Francesco Moi
My name is Francesco. I would like to convert
my list ("Files Program" "Application" "Folder") to
this string: "Files Program>Application>Folder"
Is it possible? I tried with "list-to-string" but
it does not work (Perhaps my interpreter does not
count with "list-to-string")....
Tijs van Bakel
I have never heard of list-to-string. Is it Common Lisp you are
using? If so, the following uses functions that you can all find back
in the HyperSpec:
(reduce #'(lambda (x y)
(concatenate 'string x ">" y))
'("Files Program" "Application" "Folder"))
Hope this helps, and does not spoil any homework.
--
Tijs van Bakel, <sm...@wanadoo.nl>
Lieven Marchand
Assuming you use Common Lisp, which is the default assumption in this
newsgroup, use format.
(format nil "~{~A~@[>~]~}" '("Files Program" "Application" "Folder"))
Otherwise, you will have to be more precise about the Lisp dialect
you're working in.
--
Lieven Marchand <m...@wyrd.be>
She says, "Honey, you're a Bastard of great proportion."
He says, "Darling, I plead guilty to that sin."
Cowboy Junkies -- A few simple words
Drew McDermott
(cond ((null sl) ">") ;; I'm guessing
(t
(reduce #'(lambda (s1 s2)
(concatenate
'string s1 ">" s2))
sl))))
You could be slightly more efficient by avoiding concatenating the same string over and over, but it's probably not worth it in this application.
-- Drew McDermott
Tim Bradshaw
>
> (format nil "~{~A~@[>~]~}" '("Files Program" "Application" "Folder"))
I'd do this as "~{~A~^>~}". I guess it doesn't matter which. It
doesn't look like homework, does it? if it did I reckon there has to
be a solution involving exploding the strings into lists and then
using a serious lot of line-noise in FORMAT to iterate over the lists
in turn...
(incidentally, I wonder why we don't see so many anti-FORMAT rants as
we do anti-LOOP rants? If LOOP is hard to read, what is FORMAT? I
just wrote a report method for a parse error which prints the obvious
Bad thing happened: expecting something but got :END-SET
"fff,}"
^ here
type message, and it's a good half a line of lots-of-tildes.)
--tim
Francesco Moi
If I try what you suggest, I get:
LISP error:
Format error: arguments exhausted.
V
"~{~A~@[>~]~}"
---------------------------
Lieven Marchand <m...@wyrd.be> wrote in message news:<m3pu64n...@localhost.localdomain>...
Erik Naggum
| incidentally, I wonder why we don't see so many anti-FORMAT rants as
| we do anti-LOOP rants? If LOOP is hard to read, what is FORMAT?
It is because loop is actually _too_ easy to read and does unexpected
things for those who do not understand that it is a formal language. In
contrast to this, format is pure magic and not understood by the whiners.
///
--
The past is not more important than the future, despite what your culture
has taught you. Your future observations, conclusions, and beliefs are
more important to you than those in your past ever will be. The world is
changing so fast the balance between the past and the future has shifted.
Lieven Marchand
> Hi. Thank you for answering.
>
> If I try what you suggest, I get:
>
> LISP error:
> Format error: arguments exhausted.
> V
> "~{~A~@[>~]~}"
> ---------------------------
>
If you've entered it correctly it should work.
Lispworks/Linux:
CL-USER 1 > (format nil "~{~A~@[>~]~}" '("Files Program" "Application" "Folder"))
"Files Program>Application>Folder"
Allegro/Linux:
USER(1): (format nil "~{~A~@[>~]~}" '("Files Program" "Application" "Folder"))
"Files Program>Application>Folder"
What implementation are you using?
Lieven Marchand
> (incidentally, I wonder why we don't see so many anti-FORMAT rants as
> we do anti-LOOP rants? If LOOP is hard to read, what is FORMAT? I
> just wrote a report method for a parse error which prints the obvious
>
> Bad thing happened: expecting something but got :END-SET
> "fff,}"
> ^ here
>
> type message, and it's a good half a line of lots-of-tildes.)
I think because the esoteric features of FORMAT are less used.
Pierre R. Mai
> If you've entered it correctly it should work.
>
> Lispworks/Linux:
>
> CL-USER 1 > (format nil "~{~A~@[>~]~}" '("Files Program" "Application" "Folder"))
> "Files Program>Application>Folder"
>
> Allegro/Linux:
>
> USER(1): (format nil "~{~A~@[>~]~}" '("Files Program" "Application" "Folder"))
> "Files Program>Application>Folder"
>
> What implementation are you using?
All of CMU CL, CLISP and ECLS have problems with the format control as
given. As it stands, I fail to see why it should work the way you
think it should. Quoting from Section 22.3.7.2 Tilde Left-Bracket:
Conditional Expression:
"~@[consequent~] tests the argument. If it is true, then the
argument is not used up by the ~[ command but remains as the next
one to be processed, and the one clause consequent is processed. If
the arg is false , then the argument is used up, and the clause is
not processed. The clause therefore should normally use exactly one
argument, and may expect it to be non-nil."
At the end of the list, only one argument remains, which is consumed
by the ~A. Therefore no argument remains that could be tested for the
~@[>~] directive, and hence an error is signalled.
If my interpretation is correct, then no implementation is required to
work the way you expect it to work. If you think otherwise, I'd be
interested in the reasoning behind your expectation.
Regs, Pierre.
--
Pierre R. Mai <pm...@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Tim Bradshaw
> * Tim Bradshaw
> | incidentally, I wonder why we don't see so many anti-FORMAT rants as
> | we do anti-LOOP rants? If LOOP is hard to read, what is FORMAT?
>
> It is because loop is actually _too_ easy to read and does unexpected
> things for those who do not understand that it is a formal language. In
> contrast to this, format is pure magic and not understood by the whiners.
I can feel a macro coming on here... Erm, say:
(£ // x >= 1 < 10 & // y = (* x 2)
? (evenp x) => ! (print x)
? (oddp x) => ! (print (* x y))
_ ^ 3)
It's not really obscure enough, I guess.
Gareth McCaughan
> I can feel a macro coming on here... Erm, say:
>
> (£ // x >= 1 < 10 & // y = (* x 2)
> ? (evenp x) => ! (print x)
> ? (oddp x) => ! (print (* x y))
> _ ^ 3)
>
> It's not really obscure enough, I guess.
No, but it might just fit right in to Paul Graham's new
dialect. *That*'s why he had such an impoverished set of
looping constructs: he was waiting for £ to come along!
--
Gareth McCaughan Gareth.M...@pobox.com
.sig under construc
Lieven Marchand
> If my interpretation is correct, then no implementation is required to
> work the way you expect it to work. If you think otherwise, I'd be
> interested in the reasoning behind your expectation.
Thanks for setting me straight. I think you're right. I've constructed
this from memory without checking the spec and got misled by the
behaviour of both implementations. Grepping through my code showed a
few places where I'd done this. Earlier in the thread someone gave the
correct ~^ solution.