In CL, if you have a list which you can then turn into a string like
this:
> (setf my-list '(this is a list)) ;make a list
> (setf my-string (write-to-string my-list)) ;convert the list to a string
In Perl, if I wanted to go the other way, I'd write:
> my $str = 'This is a string'; #make a string
> my $list = split $str; #convert the string to a list
How do you convert a string to a list in CL? Is there a CL equivalent
to Perl's split() function, or Java's StringTokenizer class?
Thanks, CC.
ccc31807 <········@gmail.com> writes:
> In CL, if you have a list which you can then turn into a string like
> this:
>> (setf my-list '(this is a list)) ;make a list
>> (setf my-string (write-to-string my-list)) ;convert the list to a string
>
> In Perl, if I wanted to go the other way, I'd write:
>> my $str = 'This is a string'; #make a string
>> my $list = split $str; #convert the string to a list
>
> How do you convert a string to a list in CL? Is there a CL equivalent
> to Perl's split() function, or Java's StringTokenizer class?
You can use READ-FROM-STRING to read from the string you created with
WRITE-TO-STRING.
I use CL-PPCRE:SPLIT to split things on whitespace:
http://weitz.de/cl-ppcre/#split
Zach
ccc31807 wrote:
> In CL, if you have a list which you can then turn into a string like
> this:
>> (setf my-list '(this is a list)) ;make a list
>> (setf my-string (write-to-string my-list)) ;convert the list to a string
>
> In Perl, if I wanted to go the other way, I'd write:
>> my $str = 'This is a string'; #make a string
>> my $list = split $str; #convert the string to a list
>
> How do you convert a string to a list in CL? Is there a CL equivalent
> to Perl's split() function, or Java's StringTokenizer class?
>
> Thanks, CC.
It's not part of the standard, but SPLIT-SEQUENCE [1] might be what
you're looking for. It splits a sequence on some elements which are the
same as a given delimiter, or which satisfy some given predicate (in the
case of SPLIT-SEQUENCE-IF, and SPLIT-SEQUENCE-IF-NOT). I think this is
similar to Java's StringTokenizer (but that's just from a very quick
glance at the StringTokenizer doc).
If that's not enough, e.g., if you want a delimiter to possibly be more
than that just a single element in the original sequence, you might look
at SPLIT [2] in Edi Weitz's CL-PPCRE [3]. It is more like Perl's split
in that it takes a regular expression, and gives the subsequences
between subsequences matching the regexp. From its documentation:
"This function also tries hard to be Perl-compatible - thus the somewhat
peculiar behaviour."
And, of course, implementations might provide similar functionality:
Lispworks:
* LISPWORKS:SPLIT-SEQUENCE
(exported, but undocumented?)
Allegro:
* SPLIT-RE
http://www.franz.com/support/documentation/7.0/doc/operators/excl/split-re.htm
* SPLIT-REGEXP
http://www.franz.com/support/documentation/7.0/doc/operators/excl/split-regexp.htm
//JT
[1] http://www.cliki.net/SPLIT-SEQUENCE
[2] http://weitz.de/cl-ppcre/#split
[3] http://weitz.de/cl-ppcre/
On Tue, 14 Jul 2009 06:17:35 -0700 (PDT), ccc31807 <········@gmail.com> said:
> ...
> How do you convert a string to a list in CL? Is there a CL equivalent
> to Perl's split() function, or Java's StringTokenizer class?
As a partial answer, if you are quite sure the string contains just
readable S-expressions (such as symbols), you can do something along
the lines of this example:
((lambda (s)
(with-input-from-string (s s)
(loop for x = (read s nil s)
while (not (eql x s))
collect x)))
"foo bar baz")
=> (FOO BAR BAZ)
---Vassil.
--
"Even when the muse is posting on Usenet, Alexander Sergeevich?"
On Jul 14, 9:17 am, ccc31807 <········@gmail.com> wrote:
> In CL, if you have a list which you can then turn into a string like
> this:
>
> > (setf my-list '(this is a list)) ;make a list
> > (setf my-string (write-to-string my-list)) ;convert the list to a string
>
> In Perl, if I wanted to go the other way, I'd write:
>
> > my $str = 'This is a string'; #make a string
> > my $list = split $str; #convert the string to a list
>
> How do you convert a string to a list in CL? Is there a CL equivalent
> to Perl's split() function, or Java's StringTokenizer class?
>
> Thanks, CC.
Here's the more straight up back and forth answer, I mean going
backwards straight from WRITE-TO-STRING's output. I don't know if you
meant the question within the scope of Lisp data representation, which
is my answer here, or to be parsing from strings formatted as they are
in your PERL example, which is what everyone else answered.
[16]> (write-to-string '(a b c))
"(A B C)"
[17]>
[18]> (read-from-string "(a b c)")
(A B C) ;
7
[19]>
On Jul 14, 4:56 pm, fortunatus <··············@excite.com> wrote:
> On Jul 14, 9:17 am, ccc31807 <········@gmail.com> wrote:
>
> > In CL, if you have a list which you can then turn into a string like
> > this:
>
> > > (setf my-list '(this is a list)) ;make a list
> > > (setf my-string (write-to-string my-list)) ;convert the list to a string
>
> > In Perl, if I wanted to go the other way, I'd write:
>
> > > my $str = 'This is a string'; #make a string
> > > my $list = split $str; #convert the string to a list
>
> > How do you convert a string to a list in CL? Is there a CL equivalent
> > to Perl's split() function, or Java's StringTokenizer class?
>
> > Thanks, CC.
>
> Here's the more straight up back and forth answer, I mean going
> backwards straight from WRITE-TO-STRING's output. I don't know if you
> meant the question within the scope of Lisp data representation, which
> is my answer here, or to be parsing from strings formatted as they are
> in your PERL example, which is what everyone else answered.
>
> [16]> (write-to-string '(a b c))
> "(A B C)"
> [17]>
>
> [18]> (read-from-string "(a b c)")
> (A B C) ;
> 7
> [19]>
Thanks for your answer. Here's the deal.
I working through Winston and Horn, 3rd edition. Doing Problem 6-1, I
am using strings rather than lists to represent data, as strings are
much more natural for me. (By day, I'm a database manager and data
munger and I work with strings a lot.)
Problem 6-1 requires a search function for titles of books by literal
text. With the title as a string, I can do this using (search), but
the problem is that ALL letters match, so for "Moby Dick" 'Moby'
matches, as well as 'oby' as well as 'by' as well as 'y'. I looked at
CL-PPCRE and am satisfied that it will do what I want, but I was
curious whether Lisp could do the same thing as Perl in this context.
To be honest, I'm a Lisp newbie and really don't know enough to ask
intelligent questions. If you can respond to this message, please do
so. If not, don't worry about it.
Thanks, CC.
ccc31807 wrote:
> I working through Winston and Horn, 3rd edition. Doing Problem 6-1, I
> am using strings rather than lists to represent data, as strings are
> much more natural for me. (By day, I'm a database manager and data
> munger and I work with strings a lot.)
>
> Problem 6-1 requires a search function for titles of books by literal
> text. With the title as a string, I can do this using (search), but
> the problem is that ALL letters match, so for "Moby Dick" 'Moby'
> matches, as well as 'oby' as well as 'by' as well as 'y'. I looked at
> CL-PPCRE and am satisfied that it will do what I want, but I was
> curious whether Lisp could do the same thing as Perl in this context.
Now, looking at that problem, the task is to find books whose titles
contain all of a given /set/ of words, i.e., whose titles are a
/superset/ of the query words. The reason that the task is somewhat
complicated by using strings is that now the title is a sequences of the
/characters/ that make up the title rather than a sequence of /words/ in
the title. But even so, the problem asks for a function that finds all
the books whose title includes all the elements in the query, but not
necessarily in the same /order/ as in the query. Consider the examples
from the textbook:
* (find-book-by-title-words '(black orchid) books)
((TITLE (THE BLACK ORCHID))
(AUTHOR (REX STOUT))
(CLASSIFICATION (FICTION MYSTERY)))
* (find-book-by-title-words '(orchid black) books)
((TITLE (THE BLACK ORCHID))
(AUTHOR (REX STOUT))
(CLASSIFICATION (FICTION MYSTERY)))
The solution suggested by the text makes use of SUBSETP and is a one
liner using FIND with :KEY and :TEST arguments. However, SUBSETP is
defined on lists, not general sequences. As such, if you're going to do
the exercise using strings rather than lists of symbols, a better
correspondent would be to find all books whose titles contain all of a
given bag of characters. Thus, something like:
* (find-book-by-title-letters "ck" books)
((TITLE "the black orchid") ; #\c, #\k, are in "the black orchid"
(AUTHOR (REX STOUT))
(CLASSIFICATION (FICTION MYSTERY)))
* (find-book-by-title-letters "db" books)
((TITLE "the black orchid") ; so are #\d and #\b
(AUTHOR (REX STOUT))
(CLASSIFICATION (FICTION MYSTERY)))
Now SEARCH is no longer quite what you're looking for. How can you
approach this problem?
//JT
On Jul 14, 6:01 pm, Joshua Taylor <······@cs.rpi.edu> wrote:
> Now SEARCH is no longer quite what you're looking for. How can you
> approach this problem?
Ordinarily, I'd use a regular expression with word boundaries, or else
say that the observed behavior meets the specification and let it be.
In my job, I take files (some extremely large) and process them line
by line. The lines come in as strings, and my strategy is:
1. read in the line as a string
2. split the string (usually on whitespace, or comma, or pipe) into
some kind of list (separate scalare, an array, or hash, or
combination)
3. manipulate the individual data values
4. join the data values into a new string
5. write out the new line as a string
All this is very simple and easy to do in Perl, but it seems that Lisp
isn't designed to do this easily. This isn't a criticism, just an
observation.
Thanks for your pointers. I'll go back and look at Chapter 6 and
attempt the problem again.
CC
ccc31807 <········@gmail.com> writes:
>
> In my job, I take files (some extremely large) and process them line
> by line. The lines come in as strings, and my strategy is:
> 1. read in the line as a string
READ-LINE
> 2. split the string (usually on whitespace, or comma, or pipe) into
> some kind of list (separate scalare, an array, or hash, or
> combination)
SPLIT-SEQUENCE
> 3. manipulate the individual data values
Lisp
> 4. join the data values into a new string
CONCATENATE
> 5. write out the new line as a string
WRITE-LINE
> All this is very simple and easy to do in Perl, but it seems that Lisp
> isn't designed to do this easily. This isn't a criticism, just an
> observation.
Lisp doesn't come with SPLIT-SEQUENCE out of the box, but fortunately
someone else has written it for you:-)
--
Robert A. Uhl
No, officer, it was strictly a *decorative* beartrap. --Chris Knight
ccc31807 <········@gmail.com> writes:
> On Jul 14, 6:01�pm, Joshua Taylor <······@cs.rpi.edu> wrote:
>> Now SEARCH is no longer quite what you're looking for. �How can you
>> approach this problem?
>
> Ordinarily, I'd use a regular expression with word boundaries, or else
> say that the observed behavior meets the specification and let it be.
>
> In my job, I take files (some extremely large) and process them line
> by line. The lines come in as strings, and my strategy is:
> 1. read in the line as a string
> 2. split the string (usually on whitespace, or comma, or pipe) into
> some kind of list (separate scalare, an array, or hash, or
> combination)
> 3. manipulate the individual data values
> 4. join the data values into a new string
> 5. write out the new line as a string
>
> All this is very simple and easy to do in Perl, but it seems that Lisp
> isn't designed to do this easily. This isn't a criticism, just an
> observation.
>
> Thanks for your pointers. I'll go back and look at Chapter 6 and
> attempt the problem again.
Is that so hard:
#|5:|#(write-line
#|4:|#(mapconcat (function identity)
#|3:|#(manipulate-list-of-words
#|2:|#(split-sequence-if (function special-character-p)
#|1:|#(read-line)))
" "))
?
Then perhaps lisp is not made for you indeed...
PS: Not all of these functions are standard functions, but they're
either found in usual libraries, or heavily discussed here, or
trivial to implement.
--
__Pascal Bourguignon__
On Wed, 15 Jul 2009 06:01:59 -0700 (PDT), ccc31807 <········@gmail.com> said:
> ...
> In my job, I take files (some extremely large) and process them line
> by line. The lines come in as strings, and my strategy is:
> 1. read in the line as a string
> 2. split the string (usually on whitespace, or comma, or pipe) into
> some kind of list (separate scalare, an array, or hash, or
> combination)
> 3. manipulate the individual data values
> 4. join the data values into a new string
> 5. write out the new line as a string
In my opinion and experience, one candidate approach that is
certainly worth considering is to consume the data by setting up a
custom read table and then making calls to READ.
Purely for the sake of a simple illustration, let's say that (i) the
data in the file consists of IDs, first and last names, and a
number, looking like this:
AB0012|Alice|Brown|17.65
AB0034|Charles|Brown|43.21
AB0056|Ellen|Dillon|43.21
AB0078|Frank|Dillon|98.76
...
and (ii) what we want to do is build an index allowing fast lookup
by first or last name and then by ID, i.e. two mappings such as
Alice -> AB0012
Brown -> AB0012 AB0034
...
and
AB0012 -> Alice Brown 17.65
...
To that end, set up a read table such that a vertical bar is read as
white space (using SET-SYNTAX-FROM-CHAR of #\| and #\Space) and a
new line is read as a right parenthesis [*]. Then calling
READ-DELIMITED-LIST of #\Newline repeatedly will yield, in order,
(AB0012 ALICE BROWN 17.65)
(AB0034 CHARLES BROWN 43.21)
...
and then constructing the lookup tables for the mappings is pretty
straightforward, if not trivial. If writing the names with :CASE
(if we call WRITE, or *PRINT-CASE*) :CAPITALIZE is good enough for
our purposes, we would be in business in about half an hour or so.
A more realistic task would be more involved, of course, but the
above is far from the limits of this approach, too. For example, if
some of the fields must be read as strings, not symbols, then the
vertical bar can be defined as a macro character that arranges the
consumption of the string contents and the construction of the
string object, and then we can call INTERN (or PARSE-INTEGER, or
READ) on it or not depending on the position of the field.
Or have the data produced in CSV format and use a read table ^W^W
library [+] for reading that.
_________
[*] we'll probably want some more tweaks, e.g. to make a quote read
as a constituent character (again with SET-SYNTAX-FROM-CHAR
from, say, #\A) for the sake of names such as O'Hara
[+] search?q=Common+Lisp+library+CSV (say)
---Vassil.
--
"Even when the muse is posting on Usenet, Alexander Sergeevich?"
On Tue, 14 Jul 2009 14:16:23 -0700 (PDT), ccc31807 <········@gmail.com> said:
> ...
> I working through Winston and Horn, 3rd edition. Doing Problem 6-1, I
> am using strings rather than lists to represent data, as strings are
> much more natural for me. (By day, I'm a database manager and data
> munger and I work with strings a lot.)
I believe it is important to note that Lisp's natural data are
S-expressions (basically, symbols, numbers, and lists of
S-expressions), just like Perl's natural data are strings, (Perl)
lists and (Perl) hash(-tabl)es. If you manage to get your data to
be S-expressions, you'll have a much easier time then manipulating
them in Lisp programs. For example, as already noted in this
thread, in Lisp it is much easier---indeed, less than trivial---to
do
((lambda (keywords title)
(subsetp keywords title))
'(express murder) '(murder on the orient express))
=> T
than
((lambda (keywords title)
...)
"express murder" "murder on the orient express")
(where filling in the elided part is left as an exercise for the
proverbial industrious reader...).
As another point, one rule of thumb about deciding between symbols
and strings is to choose symbols if a fast equality test will be
needed (so, for example, database fields whose string values are a
kind of ID may be best represented as symbols in a Lisp program).
---Vassil.
--
"Even when the muse is posting on Usenet, Alexander Sergeevich?"
On Jul 15, 1:58 am, Vassil Nikolov <········@pobox.com> wrote:
> I believe it is important to note that Lisp's natural data are
> S-expressions (basically, symbols, numbers, and lists of
> S-expressions), just like Perl's natural data are strings, (Perl)
> lists and (Perl) hash(-tabl)es. If you manage to get your data to
> be S-expressions, you'll have a much easier time then manipulating
> them in Lisp programs.
Okay, point taken. When in Rome ...
Still, in my job data tends to come in as strings as I have noted
above. I don't a philosophical objection to using s-expressions rather
than strings, but if my data consists of strings then I still have the
problem of converting it to lists. Shouldn't be hard to do.
Actually, now that I'm thinking about it, case is significant, and I
don't know how to convert a string to an s-expression and preserve
case.
CC
ccc31807 <········@gmail.com> writes:
> Actually, now that I'm thinking about it, case is significant, and I
> don't know how to convert a string to an s-expression and preserve
> case.
Here's an example.
CL-USER> (let ((*readtable* (copy-readtable)))
(setf (readtable-case *readtable*) :preserve)
(read-from-string "(foo bar baz)"))
(|foo| |bar| |baz|)
13
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
ccc31807 <········@gmail.com>
>
>> I believe it is important to note that Lisp's natural data are
>> S-expressions (basically, symbols, numbers, and lists of
>> S-expressions), just like Perl's natural data are strings, (Perl)
>> lists and (Perl) hash(-tabl)es. If you manage to get your data to
>> be S-expressions, you'll have a much easier time then manipulating
>> them in Lisp programs.
>
> Okay, point taken. When in Rome ...
Yup. In C it's common for data to be binary; in shell and Perl it's
common for it to be strings (which could contain encoded binary data);
in Lisp it's common for it to be symbolic expressions (which could
contain binary and string data).
> Still, in my job data tends to come in as strings as I have noted
> above. I don't a philosophical objection to using s-expressions rather
> than strings, but if my data consists of strings then I still have the
> problem of converting it to lists. Shouldn't be hard to do.
Yup, and once you've done so it can be very pleasant to manipulate data
that way.
> Actually, now that I'm thinking about it, case is significant, and I
> don't know how to convert a string to an s-expression and preserve
> case.
Remember that INTERN is case-preserving, and so is using || to quote a
symbol name.
Also, your s-expressions could contain strings where it makes sense to
do so. Or even other data types.
--
Marmite is a black tarry yeast extract used to encourage New Zealand children
to grow large and strong. The usual method is to feed it to them on toast,
resulting in them growing very quickly, so that they might become big and
strong enough to stop their parents from doing this. --Rupert Boleyn
ccc31807 <········@gmail.com> writes:
> On Jul 15, 1:58�am, Vassil Nikolov <········@pobox.com> wrote:
>> � I believe it is important to note that Lisp's natural data are
>> � S-expressions (basically, symbols, numbers, and lists of
>> � S-expressions), just like Perl's natural data are strings, (Perl)
>> � lists and (Perl) hash(-tabl)es. �If you manage to get your data to
>> � be S-expressions, you'll have a much easier time then manipulating
>> � them in Lisp programs.
>
> Okay, point taken. When in Rome ...
>
> Still, in my job data tends to come in as strings as I have noted
> above. I don't a philosophical objection to using s-expressions rather
> than strings, but if my data consists of strings then I still have the
> problem of converting it to lists. Shouldn't be hard to do.
Vassil spoke to say nothing. A string is a S-expr in lisp.
A S-expr, is a symbolic expression, is an atom, or a list of S-expr.
A string is an atom, therefore a string is a S-expr.
And list of strings are perfectly good S-expr too.
And if you like to process strings, there's nothing preventing you to
do. I'd have some reserves performance-wise, but otherwise, why not?
I'd prefer to write:
(defun month-name (month-number)
(check-type month-number (integer 1 12))
(aref #(nil "January" "February" "March"
"April" "May" "June"
"July" "August" "September"
"October" "November" "December") month-number))
than:
(defun month-name (month-number)
(check-type month-number (integer 1 12))
(string-trim " "
(subseq "January February March April May June July August SeptemberOctober November December "
(* (1- month-number) 9) (* month-number 9))))
but it's up to you, as long as you encapsulate things in nice
abstractions...
And don't tell us perl has no other data structure than strings.
> Actually, now that I'm thinking about it, case is significant, and I
> don't know how to convert a string to an s-expression and preserve
> case.
Well go on studing lisp. Eventually you'll know.
--
__Pascal Bourguignon__
On Jul 15, 10:26 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> And don't tell us perl has no other data structure than strings.
You don't understand. I didn't say that Perl has no data structures
other than strings. What I said was that my job entails working
primarily with strings.
I can export data from a database (e.g., as the return value of an SQL
query) in a number of forms, a text file, a CSV file, an XML file,
even as a pointer or a reference to a memory location. This data can
be read as binary or as ASCII, but as a practical matter, I treat it
as ASCII, whether I open it using something like vi or notepad, or
Excel, or import it into another database (such as Postgres, MySQL,
SQL Server, or even Access).
I don't know of a database that either exports or imports data as s-
expressions. If you know of one, please tell me.
In any case, I don't seek to pervert a language developed to deal with
problems of one sort to deal with problems of another sort. Languages
are simply tools that we use to solve problems. I'm not looking for a
replacement for a tool I already have to solve problems that I already
know how to solve, but for tools that I don't have to solve problems
that I don't know how to solve. In doing so, I'm working from the more
familiar to the less familiar.
CC
On Jul 15, 11:45 am, ccc31807 <········@gmail.com> wrote:
> On Jul 15, 10:26 am, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
> > And don't tell us perl has no other data structure than strings.
> You don't understand. I didn't say that Perl has no data structures
> other than strings. What I said was that my job entails working
> primarily with strings.
I'm hesitant to speak for Pascal, but I suspect he's pointing out that
working with strings usually involves using other data structures in
concert with strings, be they associative arrays, lists, or something
else.
Also, while I think your hesitance to "pervert" Common Lisp too much
during the learning stages is a good one---it's all to easy to waste a
lot of time as a newbie trying to reshape it into something more
familiar---once you get the hang of it, its greatest strength is how
easy it is to pervert. With a little work, you can turn your Lisp
implementation into a very convenient tool for line-oriented string
mangling.
Cheers,
Pillsy
[...]
Pillsy <·········@gmail.com> writes:
> Also, while I think your hesitance to "pervert" Common Lisp too much
> during the learning stages is a good one---it's all to easy to waste a
> lot of time as a newbie trying to reshape it into something more
> familiar---once you get the hang of it, its greatest strength is how
> easy it is to pervert. With a little work, you can turn your Lisp
> implementation into a very convenient tool for line-oriented string
> mangling.
That reminds me of a passage from Erik Naggum that I thought was quite
interesting:
If the goal is to make something "work", you grab the tool that is
already almost there and just whip something together to get all
there, and Common Lisp is not "almost there" for a large set of common
tasks today. (Those who want Common Lisp to be "almost there" with a
huge lot of stupid tasks go off to whine about libraries and small
syntax issues and go create Arc or whatever, instead of seeing that
being "almost there" is not an asset at all, because the more "almost
there" you get, the fewer things are within reach at the same
distance, and those things that are much farther away than others are
curiously considered "unsuitable" for the language once it has
succeeded in getting close enough for comfort for other tasks.)
If the goal is to make something of lasting value, which does only
what it is supposed to do and does not fail randomly, but has tightly
controlled and predictable failure modes with graceful recovery, then
most other languages and tools are so lacking in support for those
problems they were not specifically created to handle well, that
_they_ are unsuited for top quality software and can only achieve this
at great expense. This is where I think Common Lisp really excels.
http://groups.google.com/group/comp.lang.lisp/msg/5f18dd6cdc6b39f0 has
the entire message.
Zach
On Wed, 15 Jul 2009 16:26:58 +0200, ···@informatimago.com (Pascal J. Bourguignon) said:
> ccc31807 <········@gmail.com> writes:
>> On Jul 15, 1:58 am, Vassil Nikolov <········@pobox.com> wrote:
>>> ...
>>> S-expressions (basically, symbols, numbers, and lists of
>>> S-expressions) ...
>> ...
> Vassil spoke to say nothing.
:- )
> A string is a S-expr in lisp.
I thought that by noting in parentheses "basically, symbols,
numbers, and lists of S-expressions" it would be clear what I
referred to by "S-expressions" in that context, but apparently I was
too naive. I shall have to remember to say "classic S-expressions"
or "original S-expressions" next time...
By the way, arrays (including strings), and then structures,
etc. are only technically atoms, owing to an accident of history,
whose fixing had a too low benefit/cost ratio.
---Vassil.
--
"Even when the muse is posting on Usenet, Alexander Sergeevich?"
ccc31807 <········@gmail.com> writes:
> On Jul 15, 1:58�am, Vassil Nikolov <········@pobox.com> wrote:
>> � I believe it is important to note that Lisp's natural data are
>> � S-expressions (basically, symbols, numbers, and lists of
>> � S-expressions), just like Perl's natural data are strings, (Perl)
>> � lists and (Perl) hash(-tabl)es. �If you manage to get your data to
>> � be S-expressions, you'll have a much easier time then manipulating
>> � them in Lisp programs.
>
> Okay, point taken. When in Rome ...
>
> Still, in my job data tends to come in as strings as I have noted
> above. I don't a philosophical objection to using s-expressions rather
> than strings, but if my data consists of strings then I still have the
> problem of converting it to lists. Shouldn't be hard to do.
The internal representation of data in your program is governed by
what kinds of operations you need to perform on that data, not on the
format of the input data, nor of the output. The format of strings is
unstructured text. Thus, if you need to do any form of structured
manipulations of the data, you convert it to a suitable format
first. As an example, a compiler might take strings as inputs, and
produce binary machine code as output, but it does not do all
computations internal computations on those two data types.
This advice is language independant, in that strings are unstructured
in any language.
> Actually, now that I'm thinking about it, case is significant, and I
> don't know how to convert a string to an s-expression and preserve
> case.
Many times you can 'cheat', and use the Lisp reader. It is possible to
make it read case sensitively, and with reader macros make it read any
characters specially. If the input format is not at all Lisp though,
it may be simpler to do what you do in other languages, and read in
text character by character, or line by line.
Bj�rn Lindberg
On Jul 15, 11:38 am, ·····@runa.se (Björn Lindberg) wrote:
> The internal representation of data in your program is governed by
> what kinds of operations you need to perform on that data, not on the
> format of the input data, nor of the output.
Yes, and no. In one view, the internal representation of data is
simply bits of higher voltage or lower voltage, ones or zeros. If you
mean data structures, then obviously you might want to treat small
integers differently from instances of complex objects.
> The format of strings is unstructured text.
Again, it depends. For example, I don't view either of the following
two strings as 'unstructured text' although a machine might view them
as unstructured.
"first","middle","last","address","city","state","zip"
first|middle|last|address|city|state|zip
> Thus, if you need to do any form of structured
> manipulations of the data, you convert it to a suitable format
> first. As an example, a compiler might take strings as inputs, and
> produce binary machine code as output, but it does not do all
> computations internal computations on those two data types.
I agree with this, but one of the nice things about higher level
languages is that you can treat the compiler as a black box, without
regard to what the compiler might do internally. I input a string, the
box outputs a string; I input an s-expression, the box outputs an s-
expression. However the box treats the input internally is no concern
of mine, even though I might imagine that it treats it simply as bits
of either ones or zeros.
> This advice is language independant, in that strings are unstructured
> in any language.
I don't know what you mean by 'unstructured'. The following quote
delimited 'string' may or may not be structured, depending on your
POV:
"<html>
<head>
<title>Structure of Strings</title>
</head>
<body>
<h1>Strings: Structured or Unstructured?</h1>
</body>
</html>"
> Many times you can 'cheat', and use the Lisp reader. It is possible to
> make it read case sensitively, and with reader macros make it read any
> characters specially. If the input format is not at all Lisp though,
> it may be simpler to do what you do in other languages, and read in
> text character by character, or line by line.
Yes. Different tools for different problems. It helps for a learner to
relate what he is learning with his environment, which is what I'm
trying to do.
CC
On Jul 15, 1:10 pm, ccc31807 <········@gmail.com> wrote:
> On Jul 15, 11:38 am, ·····@runa.se (Björn Lindberg) wrote:
>
> > The internal representation of data in your program is governed by
> > what kinds of operations you need to perform on that data, not on the
> > format of the input data, nor of the output.
[...]
> If you
> mean data structures, then obviously you might want to treat small
> integers differently from instances of complex objects.
It's more than that, though. At some point, you're almost certainly
going to want to use the input data to construct a set of data
structures---be they numbers, lists, hash tables, instances objects,
whatever---that actually reflect the nature or the problem you're
trying to solve.
> > The format of strings is unstructured text.
> Again, it depends. For example, I don't view either of the following
> two strings as 'unstructured text' although a machine might view them
> as unstructured.
Well, yeah, but the issue is that to a Lisp implementation, a string
is just a vector of characters. If that's all the structure you need
(sometimes it is--say you wanted something like the 'tr' command from
Unix and, IIRC, Perl), you're set, but 9 times out of 10, you work
with strings like these:
> "first","middle","last","address","city","state","zip"
> first|middle|last|address|city|state|zip
In cases like this, you need to tell Lisp about the structure, just
like you need to tell Perl about the structure using the split()
function. Out of the box, Common Lisp doesn't provide as many
functions as Perl does for telling how the translation works.
There's READ-FROM-STRING, which tells it that the string is a textual
representation of a sexp[1], and there's PARSE-INTEGER, which does
pretty just what it says on the tin, and you can index into the string
or treat it like a list of characters. Beyond that, you can use
libraries to do things like regular expressions or XML parsing or the
like.
Or you can write your own functions and use those.
[...]
> > This advice is language independant, in that strings are unstructured
> > in any language.
> I don't know what you mean by 'unstructured'. The following quote
> delimited 'string' may or may not be structured, depending on your
> POV:
> "<html>
> <head>
> <title>Structure of Strings</title>
> </head>
> <body>
> <h1>Strings: Structured or Unstructured?</h1>
> </body>
> </html>"
The issue isn't so much what your POV is, but how you turn your POW
into a program that allows the machine to share your POV.
Cheers,
Pillsy
ccc31807 <········@gmail.com> writes:
> On Jul 15, 11:38�am, ·····@runa.se (Bj�rn Lindberg) wrote:
>> The internal representation of data in your program is governed by
>> what kinds of operations you need to perform on that data, not on the
>> format of the input data, nor of the output.
>
> Yes, and no. In one view, the internal representation of data is
> simply bits of higher voltage or lower voltage, ones or zeros. If you
> mean data structures, then obviously you might want to treat small
> integers differently from instances of complex objects.
Ask yourself which one of these two views is most relevant to how you
write your program. Then ask yourself why you brought up the other
view at all.
>> Thus, if you need to do any form of structured
>> manipulations of the data, you convert it to a suitable format
>> first. As an example, a compiler might take strings as inputs, and
>> produce binary machine code as output, but it does not do all
>> computations internal computations on those two data types.
>
> I agree with this, but one of the nice things about higher level
> languages is that you can treat the compiler as a black box, without
> regard to what the compiler might do internally. I input a string, the
> box outputs a string; I input an s-expression, the box outputs an s-
> expression. However the box treats the input internally is no concern
> of mine, even though I might imagine that it treats it simply as bits
> of either ones or zeros.
The comparison is between the compiler as a program and *your*
program. Regarding the compiler as a black box in this context does
not help understanding.
>> This advice is language independant, in that strings are unstructured
>> in any language.
>
> I don't know what you mean by 'unstructured'.
In most languages, in particular in Common Lisp, the structure of a
string is a sequence of characters. Regardless of which specific
characters are in the string.
> The following quote
> delimited 'string' may or may not be structured, depending on your
> POV:
>
> "<html>
> <head>
> <title>Structure of Strings</title>
> </head>
> <body>
> <h1>Strings: Structured or Unstructured?</h1>
> </body>
> </html>"
No, the structure of that string is a sequence of characters. Programs
exist to read in that string and turn it into a structured
representation, which might be a hierarchy of class instances, or
lists of lists of strings or atoms. This is the point.
>> Many times you can 'cheat', and use the Lisp reader. It is possible to
>> make it read case sensitively, and with reader macros make it read any
>> characters specially. If the input format is not at all Lisp though,
>> it may be simpler to do what you do in other languages, and read in
>> text character by character, or line by line.
>
> Yes. Different tools for different problems. It helps for a learner to
> relate what he is learning with his environment, which is what I'm
> trying to do.
You mentioned that you deal with database output. Some SQL database
libraries for Common Lisp will return the result of a query as a list
of lists of the fields returned, and do data type conversion to basic
Lisp types:
(("John" "Doe" 28)
("Carter" "Ccc" 31807)
...)
Bj�rn Lindberg
·····@runa.se (Bj�rn Lindberg) writes:
> ccc31807 <········@gmail.com> writes:
>
>> On Jul 15, 11:38�am, ·····@runa.se (Bj�rn Lindberg) wrote:
>>> This advice is language independant, in that strings are unstructured
>>> in any language.
>>
>> I don't know what you mean by 'unstructured'.
>
> In most languages, in particular in Common Lisp, the structure of a
> string is a sequence of characters. Regardless of which specific
> characters are in the string.
And in addition, if you only have strings, you may apply structure on
them as demonstrated in my other answer,
Message-ID: <··············@pbourguignon.anevia.com>
--
__Pascal Bourguignon__
Vassil Nikolov <········@pobox.com> writes:
> On Tue, 14 Jul 2009 14:16:23 -0700 (PDT), ccc31807 <········@gmail.com> said:
>> ...
>> I working through Winston and Horn, 3rd edition. Doing Problem 6-1, I
>> am using strings rather than lists to represent data, as strings are
>> much more natural for me. (By day, I'm a database manager and data
>> munger and I work with strings a lot.)
>
> I believe it is important to note that Lisp's natural data are
> S-expressions (basically, symbols, numbers, and lists of
> S-expressions), just like Perl's natural data are strings, (Perl)
> lists and (Perl) hash(-tabl)es. If you manage to get your data to
> be S-expressions, you'll have a much easier time then manipulating
> them in Lisp programs. For example, as already noted in this
> thread, in Lisp it is much easier---indeed, less than trivial---to
> do
>
> ((lambda (keywords title)
> (subsetp keywords title))
> '(express murder) '(murder on the orient express))
> => T
>
> than
>
> ((lambda (keywords title)
> ...)
> "express murder" "murder on the orient express")
>
> (where filling in the elided part is left as an exercise for the
> proverbial industrious reader...).
>
> As another point, one rule of thumb about deciding between symbols
> and strings is to choose symbols if a fast equality test will be
> needed (so, for example, database fields whose string values are a
> kind of ID may be best represented as symbols in a Lisp program).
But choosing symbols is not even needed (or specially helpful).
((lambda (keywords title)
(subsetp keywords title :test (function string-equal))) ; case insensitive
'("express" "murder") '("murder" "on" "the" "orient" "express"))
Of course, if the OP explained what perl' split does, it would be
easier to help him...
--
__Pascal Bourguignon__
On Wed, 15 Jul 2009 08:10:50 +0200, ···@informatimago.com (Pascal J. Bourguignon) said:
> Vassil Nikolov <········@pobox.com> writes:
>> ...
>> ((lambda (keywords title)
>> (subsetp keywords title))
>> '(express murder) '(murder on the orient express))
>> ...
> But choosing symbols is not even needed (or specially helpful).
> ((lambda (keywords title)
> (subsetp keywords title :test (function string-equal))) ; case insensitive
> '("express" "murder") '("murder" "on" "the" "orient" "express"))
Even at a superficial glance, choosing symbols is helpful towards
being economical, by reducing clutter in the program (and improving
speed a little). As to whether it is needed, that could only be
determined, either way, in the context of a particular problem or
application.
---Vassil.
--
"Even when the muse is posting on Usenet, Alexander Sergeevich?"
From: Teemu Likonen
Subject: Re: converting a string to a list
Date:
Message-ID: <87iqhvpeeq.fsf@iki.fi>
On 2009-07-14 06:17 (-0700), ccc wrote:
>> (setf my-list '(this is a list)) ;make a list
>> my $str = 'This is a string'; #make a string
>> my $list = split $str; #convert the string to a list
>
> How do you convert a string to a list in CL? Is there a CL equivalent
> to Perl's split() function, or Java's StringTokenizer class?
I'm sure you'll get tons of smarter answers than this one but here's the
two simple ways that I know. In CLISP there is REGEXP:REGEXP-SPLIT
function:
(regexp:regexp-split " \\+" "This is a string")
=> ("This" "is" "a" "string")
And in cl-ppcre package there is CL-PPCRE:SPLIT:
(asdf:oos 'asdf:load-op 'cl-ppcre)
(cl-ppcre:split " +" "This is a string")
=> ("This" "is" "a" "string")
But lists' items are strings too. In your original "my-list" variable
list's items are symbols. How to convert them I don't quite know at the
moment. :-)
On Jul 14, 9:44 am, Teemu Likonen <········@iki.fi> wrote:
> On 2009-07-14 06:17 (-0700), ccc wrote:
[...]
> And in cl-ppcre package there is CL-PPCRE:SPLIT:
> (asdf:oos 'asdf:load-op 'cl-ppcre)
> (cl-ppcre:split " +" "This is a string")
> => ("This" "is" "a" "string")
> But lists' items are strings too. In your original "my-list" variable
> list's items are symbols. How to convert them I don't quite know at the
> moment. :-)
You can use INTERN to create symbols from strings.
* (mapcar #'intern '("This" "was" "a" "string"))
(|This| |was| |a| |string|)
The #\| indicate that the strings are mixed- or lower-case; INTERN
preserves case while the Lisp reader upcases by default.
Whether or not you really do want to work with a list of symbols
instead of a list of strings is another matter entirely. For most
applications, you're probably better off working with strings
directly.
Cheers,
Pillsy
From: Giorgos Keramidas
Subject: Re: converting a string to a list
Date:
Message-ID: <87hbxftej9.fsf@kobe.laptop>
On Tue, 14 Jul 2009 16:44:45 +0300, Teemu Likonen <········@iki.fi> wrote:
> On 2009-07-14 06:17 (-0700), ccc wrote:
>>> (setf my-list '(this is a list)) ;make a list
>> my $str = 'This is a string'; #make a string
>> my $list = split $str; #convert the string to a list
>> How do you convert a string to a list in CL? Is there a CL equivalent
>> to Perl's split() function, or Java's StringTokenizer class?
>
> (cl-ppcre:split " +" "This is a string")
> => ("This" "is" "a" "string")
>
> But lists' items are strings too. In your original "my-list" variable
> list's items are symbols. How to convert them I don't quite know at
> the moment. :-)
You can upcase and intern them:
* (mapcar (lambda (name)
(intern (string-upcase name)))
(list "foo" "bar"))
(FOO BAR)
I'll risk stating the obvious: It may still be useful to work with
strings if all you want to do is text processing.
Symbols are nice if you are planning to bind *values* to them, i.e.:
* (defparameter foo nil)
FOO
* (defparameter bar nil)
BAR
* (list foo bar)
(NIL NIL)
* (mapcar #'symbol-value
(mapcar (lambda (name)
(intern (string-upcase name)))
(list "foo" "bar")))
(NIL NIL)
* (setf foo 3)
3
* (setf bar 4)
4
* (mapcar #'symbol-value
(mapcar (lambda (name)
(intern (string-upcase name)))
(list "foo" "bar")))
(3 4)
but working directly with strings is probably going to be a lot more
convenient if you are merely interested in parsing a line, splitting it
in a few fields and "do something" to them.
ccc31807 <········@gmail.com> wrote:
+---------------
| How do you convert a string to a list in CL? Is there a CL equivalent
| to Perl's split() function, or Java's StringTokenizer class?
+---------------
Others have mentioned the SPLIT-SEQUENCE package & function
[almost identical to Perl's split()], but just so you know,
CL also has the ultimate fine-grained split builtin: ;-}
> (coerce "This is a string." 'list)
(#\T #\h #\i #\s #\ #\i #\s #\ #\a #\ #\s #\t #\r #\i #\n #\g #\.)
> (subseq * 8 16)
(#\a #\ #\s #\t #\r #\i #\n #\g)
> (coerce * 'string)
"a string"
>
-Rob
p.s. Of course, SUBSEQ works directly on strings, too:
> (subseq "This is a string." 8 16)
"a string"
>
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607