I know that with lists of characters, you can coece the lists to a
string.
For example:
(coerce '(#\a #\b) 'string) => "ab"
Can you do something similar with an array?
For example:
Converting #(97 97 97) => "aaa"
+ "skibud2" <·············@gmail.com>:
| Converting #(97 97 97) => "aaa"
(map 'string #'code-char #(97 98 99)) => "abc"
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
This works for me. Thanks!
Harald Hanche-Olsen wrote:
> + "skibud2" <·············@gmail.com>:
>
> | Converting #(97 97 97) => "aaa"
>
> (map 'string #'code-char #(97 98 99)) => "abc"
>
> --
> * Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
> - It is undesirable to believe a proposition
> when there is no ground whatsoever for supposing it is true.
> -- Bertrand Russell
"skibud2" <·············@gmail.com> writes:
> I know that with lists of characters, you can coece the lists to a
> string.
>
> For example:
>
> (coerce '(#\a #\b) 'string) => "ab"
>
>
>
> Can you do something similar with an array?
>
> For example:
>
> Converting #(97 97 97) => "aaa"
Well, what happens when you type this into your lisp?
--
Thomas A. Russ, USC/Information Sciences Institute
"skibud2" <·············@gmail.com> writes:
> I know that with lists of characters, you can coece the lists to a
> string.
>
> For example:
>
> (coerce '(#\a #\b) 'string) => "ab"
>
>
>
> Can you do something similar with an array?
Of course, there's no difference between a vector and a list: they're
both sequences!
C/USER2[1183]> (coerce #(#\a #\b) 'string)
"ab"
> For example:
>
> Converting #(97 97 97) => "aaa"
This is something entirely different! Here you need two steps, since
you want to convert numbers to characters (WHAT ENCODING???) and you
want to convert a vector into a string (a vector of characters).
If you want to consider the ASCII code, you could write:
(defparameter *ASCII-CHARS*
#.(concatenate 'string
" !\"#$%&'()*+,-./"
"0123456789:;<=>?"
·@ABCDEFGHIJKLMNO"
"PQRSTUVWXYZ[\\]^_"
"`abcdefghijklmno"
"pqrstuvwxyz{|}~"))
(map 'string (lambda (code)
(cond ((<= 32 code 126)
(aref *ASCII-CHARS* (- code 32)))
((= 10 code) #\newline)
(t (error "~D is not the ASCII code of a character." code))))
#(97 97 97))
--
__Pascal Bourguignon__ http://www.informatimago.com/
"A TRUE Klingon warrior does not comment his code!"
Pascal Bourguignon a �crit :
> (defparameter *ASCII-CHARS*
> #.(concatenate 'string
> " !\"#$%&'()*+,-./"
> "0123456789:;<=>?"
> ·@ABCDEFGHIJKLMNO"
> "PQRSTUVWXYZ[\\]^_"
> "`abcdefghijklmno"
> "pqrstuvwxyz{|}~"))
>
> (map 'string (lambda (code)
> (cond ((<= 32 code 126)
> (aref *ASCII-CHARS* (- code 32)))
> ((= 10 code) #\newline)
> (t (error "~D is not the ASCII code of a character." code))))
> #(97 97 97))
Ouch !
What about this :
(map 'string #'code-char #(97 98 99))
Works well with Unicode too...
Jacques.
--
| ·······@ \ Resistance is futile / ...by the Net |
|-----------------\ |�| \�\/�/ |�| /------Collective-|
|-You will be-----/ |�|_| | \ / | |_|�| \-----------------|
| assimilated... / |_____| \/ |_____| \ janville.Borg |
From: Richard M Kreuter
Subject: Re: Casting array to string
Date:
Message-ID: <873b6hv281.fsf@progn.net>
Kojak <·······@janville.Borg.invalid> writes:
> Pascal Bourguignon a écrit :
>> (defparameter *ASCII-CHARS*
>> #.(concatenate 'string
>> " !\"#$%&'()*+,-./"
>> "0123456789:;<=>?"
>> ·@ABCDEFGHIJKLMNO"
>> "PQRSTUVWXYZ[\\]^_"
>> "`abcdefghijklmno"
>> "pqrstuvwxyz{|}~"))
>>
>> (map 'string (lambda (code)
>> (cond ((<= 32 code 126)
>> (aref *ASCII-CHARS* (- code 32)))
>> ((= 10 code) #\newline)
>> (t (error "~D is not the ASCII code of a character." code))))
>> #(97 97 97))
>
> Ouch !
>
> What about this :
>
> (map 'string #'code-char #(97 98 99))
>
> Works well with Unicode too...
Yes, because extant implementations happen to support character
repertoires that are supersets of ASCII, but they conforming
implementations not required to do so. Bourguignon's implementation
is portable standard Common Lisp.
--
RmK
Richard M Kreuter a écrit :
> Yes, because extant implementations happen to support character
> repertoires that are supersets of ASCII, but they conforming
> implementations not required to do so. Bourguignon's implementation
> is portable standard Common Lisp.
Well, You're right. It's not CL compliant (nor portable) but
sometimes, when these two criteria are not required, it can
be useful to use these kind of features.
Jacques.
--
| ·······@ \ Resistance is futile / ...by the Net |
|-----------------\ |°| \°\/°/ |°| /------Collective-|
|-You will be-----/ |°|_| | \ / | |_|°| \-----------------|
| assimilated... / |_____| \/ |_____| \ janville.Borg |
From: Richard M Kreuter
Subject: Re: Casting array to string
Date:
Message-ID: <87fyagj6bx.fsf@progn.net>
Kojak <·······@janville.Borg.invalid> writes:
> Richard M Kreuter a écrit :
>> Yes, because extant implementations happen to support character
>> repertoires that are supersets of ASCII, but they conforming
>> implementations not required to do so. Bourguignon's implementation
>> is portable standard Common Lisp.
>
> Well, You're right. It's not CL compliant (nor portable) but
> sometimes, when these two criteria are not required, it can
> be useful to use these kind of features.
AFAICT, in fact just using CHAR-CODE and CODE-CHAR is /portable/ in a
de facto sense (all extant implementations seem to be using character
repertoires that are supersets of ASCII, and I think of ISO-8859-1,
too), but it's still non-standard.
Maybe it'd be nice if a couple of feature names could be agreed on to
indicate these sorts of convergences.
--
RmK
Kojak <·······@janville.Borg.invalid> writes:
> Pascal Bourguignon a �crit :
>> (defparameter *ASCII-CHARS*
>> #.(concatenate 'string
>> " !\"#$%&'()*+,-./"
>> "0123456789:;<=>?"
>> ·@ABCDEFGHIJKLMNO"
>> "PQRSTUVWXYZ[\\]^_"
>> "`abcdefghijklmno"
>> "pqrstuvwxyz{|}~"))
>>
>> (map 'string (lambda (code)
>> (cond ((<= 32 code 126)
>> (aref *ASCII-CHARS* (- code 32)))
>> ((= 10 code) #\newline)
>> (t (error "~D is not the ASCII code of a character." code))))
>> #(97 97 97))
>
> Ouch !
>
> What about this :
>
> (map 'string #'code-char #(97 98 99))
>
> Works well with Unicode too...
No, it doesn't.
Read CLHS CODE-CHAR, there's no guarantee about ASCII, or ISO-8859-1
or Unicode. There couldn't be any, since Unicode didn't exist when
Common Lisp was defined.
What you _could_ do, is:
(defparameter *we-have-ascii-p*
(loop :for code :from 32
:for ch :across *ascii-chars*
:every (= code (char-code ch))))
(map 'string
(if *we-have-ascii-p*
(lambda (code)
(cond ((<= 32 code 126) (code-char code))
((= code 10) #\newline)
(t (error "~D is not the ASCII code of a character." code))))
(lambda (code)
(cond ((<= 32 code 126)
(aref *ASCII-CHARS* (- code 32)))
((= 10 code) #\newline)
(t (error "~D is not the ASCII code of a character." code)))))
#(97 98 99))
--
__Pascal Bourguignon__ http://www.informatimago.com/
HEALTH WARNING: Care should be taken when lifting this product,
since its mass, and thus its weight, is dependent on its velocity
relative to the user.
Pascal Bourguignon a �crit :
> Read CLHS CODE-CHAR, there's no guarantee about ASCII, or ISO-8859-1
> or Unicode. There couldn't be any, since Unicode didn't exist when
> Common Lisp was defined.
Absolutely, it depends on implementation. I've missed this point.
That said, in some case for specific applications intended to be
run locally and will never be ported, as I noticed in an another
post, this implementation dependent version should work fine,
even if I agree that generally it's not a good way to code...
And what about your DEFPARAMETER if the OP have asked for whole
Unicode set ? :-)
> (defparameter *we-have-ascii-p*
> (loop :for code :from 32
> :for ch :across *ascii-chars*
> :every (= code (char-code ch))))
CLHS, you said ? Hmmm...
Jacques.
--
| ·······@ \ Resistance is futile / ...by the Net |
|-----------------\ |�| \�\/�/ |�| /------Collective-|
|-You will be-----/ |�|_| | \ / | |_|�| \-----------------|
| assimilated... / |_____| \/ |_____| \ janville.Borg |
Kojak <·······@janville.Borg.invalid> writes:
> Pascal Bourguignon a �crit :
>> Read CLHS CODE-CHAR, there's no guarantee about ASCII, or ISO-8859-1
>> or Unicode. There couldn't be any, since Unicode didn't exist when
>> Common Lisp was defined.
>
> Absolutely, it depends on implementation. I've missed this point.
>
> That said, in some case for specific applications intended to be
> run locally and will never be ported, as I noticed in an another
> post, this implementation dependent version should work fine,
> even if I agree that generally it's not a good way to code...
>
> And what about your DEFPARAMETER if the OP have asked for whole
> Unicode set ? :-)
Of course, it would have to be programmed differently.
The important point, IMO, is that it depends on where these numbers
come from.
If they come from CHAR-CODE, obviously there's no prevention to use
CODE-CHAR to get back to the characters, CHAR-CODE and CODE-CHAR
should be inverses.
But if they're specifically specified to be ASCII codes, then some
decoding should be implemented. And vice versa, if you want to
produces integers from characters, you can always use CHAR-CODE, if
the encoding doesn't matter. But if the application asks specifically
for ASCII codes, then you should implement the encoding.
If you're lazy, you can alway use #+clisp ext:convert-string-to-bytes
and #+clisp ext:convert-string-from-bytes (and the similar in the
other implementations), not forgetting a #-clisp (error
"encoding/decoding not implemented for this implementation").
>> (defparameter *we-have-ascii-p*
>> (loop :for code :from 32
>> :for ch :across *ascii-chars*
>> :every (= code (char-code ch))))
>
> CLHS, you said ? Hmmm...
s/every/always/ ; sorry.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Logiciels libres : nourris au code source sans farine animale."