I've read that a C programmer will write LISP as C. as i recall that
is attributed to Paul Graham. I seem to be in that category (except
I'm using Perl). I can't figure out what a proper style for LISP is
(or maybe there isn't and I'm just thinking that there is).
This involves the very common Perl task of munging data -- opening
files as input to read data, grabbing the data and manipulating it,
and opening files as output to write data. Here is a skeleton of some
typical Perl template that opens two files for input and opens tow
files for output:
my (%data_hash_in, %data_hash_out);
open IN1, '<', 'firstinput.txt';
while (<IN1>)
{
first_stuff_data_into_hash(); #using %data_hash_in
}
close IN1;
open IN2, '<', 'secondinput.txt';
while (<IN2>)
{
second_stuff_data_into_hash(); #using %data_hash_in
}
close IN2;
%data_hash_out = munge_data(%data_hash_in);
open OUT1, '>', 'csvoutput.csv';
open OUT2, '>', 'pdfoutput.pdf';
foreach my $key (sort keys %data_hash_out)
{
print_to_csv($data_hash_out{$key});
print_to_pdf($data_hash_out{$key});
}
close OUT1;
close OUT2;
exit(0);
The LISP template that I'm attempting to use looks something like
this:
My mental image of Perl is a sequential set of steps, called one after
another, processing lines iteratively. My mental image of LISP is an
outer function calling inner functions processing lines recursively.
Either this is an incorrect mental image of LISP or I'm not yet
equipped to write in proper LISP style (most likely).
What would be an appropriate style for the case of opening two files
(say, a students file and a classes file), mashing the data together
(with the students info and the classes info and the class), and
writing to two output files (say, a report cards file as a PDF and a
statistical analysis file in CSV)?
What you have writte is no recursion but a statically (lexically)
nested expression, but you are right: It is possible to make recursive
function calls in Lisp.
I'd consider the nested expression appropriate style if you have a fixed
number of files to open and have to keep them open all together.
In your case I'd rather write it similar to your Perls code.
(with-open-file (in1 "firstinput.txt" :direction :input)
;; Not doing your homework here ..
)
;; .. nor here.
ccc31807 wrote:
> I've read that a C programmer will write LISP as C. as i recall that
> is attributed to Paul Graham. I seem to be in that category (except
> I'm using Perl). I can't figure out what a proper style for LISP is
> (or maybe there isn't and I'm just thinking that there is).
> This involves the very common Perl task of munging data -- opening
> files as input to read data, grabbing the data and manipulating it,
> and opening files as output to write data. Here is a skeleton of some
> typical Perl template that opens two files for input and opens tow
> files for output:
> my (%data_hash_in, %data_hash_out);
> open IN1, '<', 'firstinput.txt';
> while (<IN1>)
> {
> first_stuff_data_into_hash(); #using %data_hash_in
> }
> close IN1;
> open IN2, '<', 'secondinput.txt';
> while (<IN2>)
> {
> second_stuff_data_into_hash(); #using %data_hash_in
> }
> close IN2;
> %data_hash_out = munge_data(%data_hash_in);
> open OUT1, '>', 'csvoutput.csv';
> open OUT2, '>', 'pdfoutput.pdf';
> foreach my $key (sort keys %data_hash_out)
> {
> print_to_csv($data_hash_out{$key});
> print_to_pdf($data_hash_out{$key});
> }
> close OUT1;
> close OUT2;
> exit(0);
> The LISP template that I'm attempting to use looks something like
> this:
> My mental image of Perl is a sequential set of steps, called one after
> another, processing lines iteratively. My mental image of LISP is an
> outer function calling inner functions processing lines recursively.
> Either this is an incorrect mental image of LISP or I'm not yet
> equipped to write in proper LISP style (most likely).
> What would be an appropriate style for the case of opening two files
> (say, a students file and a classes file), mashing the data together
> (with the students info and the classes info and the class), and
> writing to two output files (say, a report cards file as a PDF and a
> statistical analysis file in CSV)?
ccc31807 <carte...@gmail.com> wrote:
> I've read that a C programmer will write LISP as C. as i recall that
> is attributed to Paul Graham. I seem to be in that category (except
> I'm using Perl). I can't figure out what a proper style for LISP is
> (or maybe there isn't and I'm just thinking that there is).
> This involves the very common Perl task of munging data -- opening
> files as input to read data, grabbing the data and manipulating it,
> and opening files as output to write data. Here is a skeleton of some
> typical Perl template that opens two files for input and opens tow
> files for output:
> my (%data_hash_in, %data_hash_out);
> open IN1, '<', 'firstinput.txt';
> while (<IN1>)
> {
> first_stuff_data_into_hash(); #using %data_hash_in
> }
> close IN1;
> open IN2, '<', 'secondinput.txt';
> while (<IN2>)
> {
> second_stuff_data_into_hash(); #using %data_hash_in
> }
> close IN2;
> %data_hash_out = munge_data(%data_hash_in);
> open OUT1, '>', 'csvoutput.csv';
> open OUT2, '>', 'pdfoutput.pdf';
> foreach my $key (sort keys %data_hash_out)
> {
> print_to_csv($data_hash_out{$key});
> print_to_pdf($data_hash_out{$key});
> }
> close OUT1;
> close OUT2;
> exit(0);
> The LISP template that I'm attempting to use looks something like
> this:
> My mental image of Perl is a sequential set of steps, called one after
> another, processing lines iteratively. My mental image of LISP is an
> outer function calling inner functions processing lines recursively.
> Either this is an incorrect mental image of LISP or I'm not yet
> equipped to write in proper LISP style (most likely).
> What would be an appropriate style for the case of opening two files
> (say, a students file and a classes file), mashing the data together
> (with the students info and the classes info and the class), and
> writing to two output files (say, a report cards file as a PDF and a
> statistical analysis file in CSV)?
> Thanks, CC.
In this case, I think the Lisp style would be pretty similar to the Perl style. There's no reason to nest the calls for the input files if you don't need to access both streams concurrently. So it would be something like:
On May 29, 11:46 am, Norbert_Paul <norbertpauls_spam...@yahoo.com>
wrote:
> What you have writte is no recursion but a statically (lexically)
> nested expression, but you are right: It is possible to make recursive
> function calls in Lisp.
Which actually responds to a question I didn't ask.
With Perl, you can manipulate a file line by line, which would process
a file that contains one record per line in a row oriented framework
(like a line in a spreadsheet or a row in a database table. Or, you
can use slurp mode to manipulate the entire file as one long string,
if (for example) you wanted to manipulate a text file.
In order to recurse on a CSV file, you would need to read the entire
file into memory as a list, with each record becoming a list element.
(loop for key being each hash-key of $data_hash_out
using (hash-value val)
do (print-csv val out1)
(print-pdf val out2)))
;; unwind forms
(unless (null out1) (close out1))
(unless (null out2) (close out2))))
Othertimes when you want to decouple OPEN from unwind-close pattern, you
can use the WITH-OPEN-STREAM macro, giving it the open stream; and the
macro which will automatically CLOSE the file, when the forms are
done. This just lets you avoid spelling out the UNWIND-PROTECT form
explicitly.
| My mental image of Perl is a sequential set of steps, called one after
| another, processing lines iteratively. My mental image of LISP is an
| outer function calling inner functions processing lines recursively.
| Either this is an incorrect mental image of LISP or I'm not yet
| equipped to write in proper LISP style (most likely).
|
file operations are the same in any language. The specific problem you
are trying to solve (beyond figuring out the file system syntax), may be
amenable to mapping solutions (i.e. map this function across all
records). However for the tasks you have exhibited here over the years,
what you could do with lisp (in employing this style), you can also do
in perl.
ccc31807 <carte...@gmail.com> writes:
> On May 29, 11:46 am, Norbert_Paul <norbertpauls_spam...@yahoo.com>
> wrote:
>> What you have writte is no recursion but a statically (lexically)
>> nested expression, but you are right: It is possible to make recursive
>> function calls in Lisp.
> Which actually responds to a question I didn't ask.
> With Perl, you can manipulate a file line by line, which would process
> a file that contains one record per line in a row oriented framework
> (like a line in a spreadsheet or a row in a database table. Or, you
> can use slurp mode to manipulate the entire file as one long string,
> if (for example) you wanted to manipulate a text file.
> In order to recurse on a CSV file, you would need to read the entire
> file into memory as a list, with each record becoming a list element.
There are several libraries to read or write CSV files.
> To me, it's more intuitive, less space intensive, and maybe less time
> intensive, to manipulate a file line by line iteratively that
> recursively.
> Comments?
Indeed. But how often do you have to process files bigger than the RAM
nowadays? (eg. I have 24GB of RAM in my workstation, and 4GB in my game
computer).
But yes, if you have to process multi-terabyte log files, better do it
in chunks.
I think it would be better for you to grab some tutorial and learn something instead of asking stupid questions in group. I'm not judging, but you're wasting your own and everybody else's time.
Please start with assumption that Lisp can do absolutely anything a general purpose language can do (because it is a general purpose language) and go though a couple of tutorials/books until you feel comfortable.
Before that your "comments" and "conclusions" have absolutely no value because you don't know anything about programming in Lisp. Is it hard to understand?
ccc31807 <carte...@gmail.com> wrote:
> On May 29, 11:46 am, Norbert_Paul <norbertpauls_spam...@yahoo.com>
> wrote:
> > What you have writte is no recursion but a statically (lexically)
> > nested expression, but you are right: It is possible to make recursive
> > function calls in Lisp.
> Which actually responds to a question I didn't ask.
> With Perl, you can manipulate a file line by line, which would process
> a file that contains one record per line in a row oriented framework
> (like a line in a spreadsheet or a row in a database table. Or, you
> can use slurp mode to manipulate the entire file as one long string,
> if (for example) you wanted to manipulate a text file.
> In order to recurse on a CSV file, you would need to read the entire
> file into memory as a list, with each record becoming a list element.
Barry Margolin wrote:
> In article > <fcce762a-70a6-47db-a489-6e2c8464b...@a1g2000yqd.googlegroups.com>,
> ccc31807 <carte...@gmail.com> wrote:
> > I've read that a C programmer will write LISP as C. as i recall that
> > is attributed to Paul Graham. I seem to be in that category (except
> > I'm using Perl). I can't figure out what a proper style for LISP is
> > (or maybe there isn't and I'm just thinking that there is).
> > This involves the very common Perl task of munging data -- opening
> > files as input to read data, grabbing the data and manipulating it,
> > and opening files as output to write data. Here is a skeleton of some
> > typical Perl template that opens two files for input and opens tow
> > files for output:
> > my (%data_hash_in, %data_hash_out);
> > open IN1, '<', 'firstinput.txt';
> > while (<IN1>)
> > {
> > first_stuff_data_into_hash(); #using %data_hash_in
> > }
> > close IN1;
> > open IN2, '<', 'secondinput.txt';
> > while (<IN2>)
> > {
> > second_stuff_data_into_hash(); #using %data_hash_in
> > }
> > close IN2;
> > %data_hash_out = munge_data(%data_hash_in);
> > open OUT1, '>', 'csvoutput.csv';
> > open OUT2, '>', 'pdfoutput.pdf';
> > foreach my $key (sort keys %data_hash_out)
> > {
> > print_to_csv($data_hash_out{$key});
> > print_to_pdf($data_hash_out{$key});
> > }
> > close OUT1;
> > close OUT2;
> > exit(0);
> > The LISP template that I'm attempting to use looks something like
> > this:
> > My mental image of Perl is a sequential set of steps, called one after
> > another, processing lines iteratively. My mental image of LISP is an
> > outer function calling inner functions processing lines recursively.
> > Either this is an incorrect mental image of LISP or I'm not yet
> > equipped to write in proper LISP style (most likely).
> > What would be an appropriate style for the case of opening two files
> > (say, a students file and a classes file), mashing the data together
> > (with the students info and the classes info and the class), and
> > writing to two output files (say, a report cards file as a PDF and a
> > statistical analysis file in CSV)?
> > Thanks, CC.
> In this case, I think the Lisp style would be pretty similar to the Perl > style. There's no reason to nest the calls for the input files if you > don't need to access both streams concurrently. So it would be > something like:
> since you need files sequentially, there is no need to keep them all
> open at the same time.
> (let ((hash1 (make-hash-table))
> (hash2 (make-hash-table)))
> (with-open-file (in "firstinput")
> (loop :for line = (read-line in nil nil) :while line
> :do (first_stuff_data_into_hash hash1 line)))
> (with-open-file (in "secondinput")
> (loop :for line = (read-line in nil nil) :while line
> :do (second_stuff_data_into_hash hash1 line)))
> (munge_data hash1 hash2)
> (with-open-file (csv "csvoutput" :direction :output)
> (with-open-file (pdf "pdfoutput" :direction :output)
> (loop :for value :being :each :hash-value :of hash2 :do
> (print_to_csv csv value)
> (print_to_pdf pdf value)))))
Thanks for this, and the others who replied. Yes, I can see how this
works now. Conceptually, it's not much different from what I would
expect to do that uses a main() function to run everything.
ccc31807 <carte...@gmail.com> writes:
> Here is a skeleton of some typical Perl template that opens two files
> for input and opens tow files for output:
> my (%data_hash_in, %data_hash_out);
> open IN1, '<', 'firstinput.txt';
> while (<IN1>)
> {
> first_stuff_data_into_hash(); #using %data_hash_in
> }
> close IN1;
Perl programmers typically use IO::Handle objects instead of bare
filehandles like this.
If you're going to write LISP instead of Lisp, please be fair and write
PERL instead of Perl.
On May 30, 9:45 am, Zach Beane <x...@xach.com> wrote:
> Perl programmers typically use IO::Handle objects instead of bare
> filehandles like this.
Well ... yes. However, TIMTOWTDI, and after having used both styles, I
like the bareword style because it stands out better on the page. I
earn my daily bread by munging data with Perl, and the bareword style
works for me.
> If you're going to write LISP instead of Lisp, please be fair and write
> PERL instead of Perl.
Is there a right way and a wrong way? It makes no difference to me one
way or the other. I have some old books (predating CL) that always
write LISP, but I certainly don't mind writing Common Lisp if that's
the way to do it.
ccc31807 <carte...@gmail.com> writes:
> On May 30, 9:45 am, Zach Beane <x...@xach.com> wrote:
>> Perl programmers typically use IO::Handle objects instead of bare
>> filehandles like this.
> Well ... yes. However, TIMTOWTDI, and after having used both styles, I
> like the bareword style because it stands out better on the page. I
> earn my daily bread by munging data with Perl, and the bareword style
> works for me.
>> If you're going to write LISP instead of Lisp, please be fair and write
>> PERL instead of Perl.
> Is there a right way and a wrong way? It makes no difference to me one
> way or the other. I have some old books (predating CL) that always
> write LISP, but I certainly don't mind writing Common Lisp if that's
> the way to do it.
LISP is LISP (1) or LISP 1.5.
Common Lisp or CL is Common Lisp.
COMMON-LISP or CL is the COMMON-LISP package.
Lisp or lisp is the generic name for the lisp family of languages.
Emacs lisp or elisp is Emacs lisp.
LISP, elisp or Common Lisp are lisp languages.
On May 30, 3:39 pm, "Pascal J. Bourguignon" <p...@informatimago.com>
wrote:
> LISP is LISP (1) or LISP 1.5.
> Common Lisp or CL is Common Lisp.
> COMMON-LISP or CL is the COMMON-LISP package.
> Lisp or lisp is the generic name for the lisp family of languages.
> Emacs lisp or elisp is Emacs lisp.
> LISP, elisp or Common Lisp are lisp languages.
perl is the name of the executable.
Perl is the name of the programming language.
PERL is either the Practical Extraction and Reporting Language or the
Pathologically Eclectic Rubbish Collector.
All in all, I'd rather see Common Lisp than LISP, and it suits me fine
to adopt that convention.
