Using Emacs Lisp for script writing

Using Emacs Lisp for script writing

[Cecil Westerhof]

I already use 'emacs -batch' for scripting where no user input is used,
but I would like to use it also for interactive scripting. Until now I
did not find any usable information about this. Anybody using Emacs for
interactive scripts?

Also I use three evals. One to define the function, one to compile it
and one to call it. Can this be done better?

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

Re: Using Emacs Lisp for script writing

[Sam Steingold]

Cecil Westerhof wrote:
> I already use 'emacs -batch' for scripting where no user input is used,
> but I would like to use it also for interactive scripting. Until now I
> did not find any usable information about this. Anybody using Emacs for
> interactive scripts?

I use clisp for all scripting, interactive and not.
Common Lisp is more powerful than Emacs Lisp and clisp is faster than emacs.

> Also I use three evals. One to define the function, one to compile it
> and one to call it. Can this be done better?

yes. you do not need any evals.
you put your function into a file, byte-compile the file, and then load the 
file and call the function from the command line.

Re: Using Emacs Lisp for script writing

[Teemu Likonen]

On 2009-12-16 16:32 (+0100), Cecil Westerhof wrote:

> I already use 'emacs -batch' for scripting where no user input is
> used, but I would like to use it also for interactive scripting. Until
> now I did not find any usable information about this. Anybody using
> Emacs for interactive scripts?

I suggest using some Common Lisp implementation instead. They are more
general-purpose Lisp dialects I like CLISP.

    #!/usr/bin/clisp
    (format *query-io* "Type something: ")
    (format t "You wrote: ~A" (read-line *query-io*))

Re: Using Emacs Lisp for script writing

[Cecil Westerhof]

Teemu Likonen <tlikonen@iki.fi> writes:

>> I already use 'emacs -batch' for scripting where no user input is
>> used, but I would like to use it also for interactive scripting. Until
>> now I did not find any usable information about this. Anybody using
>> Emacs for interactive scripts?
>
> I suggest using some Common Lisp implementation instead. They are more
> general-purpose Lisp dialects I like CLISP.
>
>     #!/usr/bin/clisp
>     (format *query-io* "Type something: ")
>     (format t "You wrote: ~A" (read-line *query-io*))

I'll try that. I already understood that elisp is 'old' and that clisp
has a lot more possibilities. One thing. Using your script gives:
    ./dummy.lisp: line 3: format: command not found
    ./dummy.lisp: line 4: syntax error near unexpected token `('
    ./dummy.lisp: line 4: `(format t "You wrote: ~A" (read-line *query-io*))'
Using 'clisp dummy.lisp' works.

Now I need to learn ELisp and CLisp. ;-]

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

Re: Using Emacs Lisp for script writing

[Sam Steingold]

Cecil Westerhof wrote:
> Teemu Likonen <tlikonen@iki.fi> writes:
> 
>>> I already use 'emacs -batch' for scripting where no user input is
>>> used, but I would like to use it also for interactive scripting. Until
>>> now I did not find any usable information about this. Anybody using
>>> Emacs for interactive scripts?
>> I suggest using some Common Lisp implementation instead. They are more
>> general-purpose Lisp dialects I like CLISP.
>>
>>     #!/usr/bin/clisp
>>     (format *query-io* "Type something: ")
>>     (format t "You wrote: ~A" (read-line *query-io*))

works for me.

> I'll try that. I already understood that elisp is 'old' and that clisp
> has a lot more possibilities. One thing. Using your script gives:
>     ./dummy.lisp: line 3: format: command not found
>     ./dummy.lisp: line 4: syntax error near unexpected token `('
>     ./dummy.lisp: line 4: `(format t "You wrote: ~A" (read-line *query-io*))'

these are not clisp messages.
these look like (ba)sh messages.

> Using 'clisp dummy.lisp' works.

maybe clisp is not installed as /usr/bin/clisp?

Re: Using Emacs Lisp for script writing

[Pascal J. Bourguignon]

Cecil Westerhof <Cecil@decebal.nl> writes:

> I already use 'emacs -batch' for scripting where no user input is used,
> but I would like to use it also for interactive scripting. Until now I
> did not find any usable information about this. Anybody using Emacs for
> interactive scripts?
>
> Also I use three evals. One to define the function, one to compile it
> and one to call it. Can this be done better?

I must concur.  I wrote quite a number of emacs scripts, but eventually,
I switched to Common Lisp, specifically clisp (but other CL
implementations are also usable for scripts), to write my scripts.
Common Lisp allows you to write scripts more easily than emacs lisp.

-- 
__Pascal Bourguignon__
http://www.informatimago.com

Re: Using Emacs Lisp for script writing

[Cecil Westerhof]

Sam Steingold <sds@gnu.org> writes:

>> I already use 'emacs -batch' for scripting where no user input is used,
>> but I would like to use it also for interactive scripting. Until now I
>> did not find any usable information about this. Anybody using Emacs for
>> interactive scripts?
>
> I use clisp for all scripting, interactive and not.
> Common Lisp is more powerful than Emacs Lisp and clisp is faster than
> emacs.

Okay. I'll look into that. Emacs is more general, because it will be
installed on more systems. But when Common Lisp is a better option, I
should maybe go for it.

By the way. I have been looking into Common Lisp and I understood that
the following is correct:
    (list a: 1)
But I get:
    *** - READ uit #<INPUT CONCATENATED-STREAM #<INPUT STRING-INPUT-STREAM> #<IO TERMINAL-STREAM>>: er is geen package met naam "A"
    Mogelijkheden om opnieuw te beginnen:
    ABORT          :R1      ABORT
    ABORT          :R2      ABORT
    ABORT          :R3      ABORT
What is going wrong here?
On the system is the version: GNU CLISP 2.39. So maybe I should update.


>> Also I use three evals. One to define the function, one to compile it
>> and one to call it. Can this be done better?
>
> yes. you do not need any evals.
> you put your function into a file, byte-compile the file, and then load
> the file and call the function from the command line.

I thought about this, but the functionality is run from a bash-script. I
like to have everything in one file, but maybe I should work with
several files.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

Re: Using Emacs Lisp for script writing

[Cecil Westerhof]

Cecil Westerhof <Cecil@decebal.nl> writes:

> By the way. I have been looking into Common Lisp and I understood that
> the following is correct:
>     (list a: 1)
> But I get:
>     *** - READ uit #<INPUT CONCATENATED-STREAM #<INPUT STRING-INPUT-STREAM> #<IO TERMINAL-STREAM>>: er is geen package met naam "A"
>     Mogelijkheden om opnieuw te beginnen:
>     ABORT          :R1      ABORT
>     ABORT          :R2      ABORT
>     ABORT          :R3      ABORT
> What is going wrong here?

I should have been using:
  (list :a 1)

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

Re: Using Emacs Lisp for script writing

[Frank Fredstone]

Sam Steingold <sds@gnu.org> writes:

> Cecil Westerhof wrote:
>> I already use 'emacs -batch' for scripting where no user input is used,
>> but I would like to use it also for interactive scripting. Until now I
>> did not find any usable information about this. Anybody using Emacs for
>> interactive scripts?
>
> I use clisp for all scripting, interactive and not.
> Common Lisp is more powerful than Emacs Lisp and clisp is faster than emacs.

One thing I like about emacs for batch text processing is that you can
search forward for something and then search backward from there for
the text to process, which can be quicker than creating a parser
grammar or encoding one in code using lists and variables. So, unless
there is a regular expression library for common lisp that provides
backward search capabilites, that might be a reason to prefer emacs in
some cases.

Re: Using Emacs Lisp for script writing

[Cecil Westerhof]

Sam Steingold <sds@gnu.org> writes:

>> I already use 'emacs -batch' for scripting where no user input is used,
>> but I would like to use it also for interactive scripting. Until now I
>> did not find any usable information about this. Anybody using Emacs for
>> interactive scripts?
>
> I use clisp for all scripting, interactive and not.
> Common Lisp is more powerful than Emacs Lisp and clisp is faster than
> emacs.

I have been experimenting with clisp. But I think that Emacs Lisp does a
pretty good job. I translated a script I wrote in Emacs Lisp to CL. The
Emacs Lisp version needed 51 seconds on a certain data set. When using
clisp with the converted code, clisp needs 79 seconds. That is more as
50% longer.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

Re: Using Emacs Lisp for script writing

[Sam Steingold]

Cecil Westerhof wrote:
> Sam Steingold <sds@gnu.org> writes:
> 
>>> I already use 'emacs -batch' for scripting where no user input is used,
>>> but I would like to use it also for interactive scripting. Until now I
>>> did not find any usable information about this. Anybody using Emacs for
>>> interactive scripts?
>> I use clisp for all scripting, interactive and not.
>> Common Lisp is more powerful than Emacs Lisp and clisp is faster than
>> emacs.
> 
> I have been experimenting with clisp. But I think that Emacs Lisp does a
> pretty good job. I translated a script I wrote in Emacs Lisp to CL. The
> Emacs Lisp version needed 51 seconds on a certain data set. When using
> clisp with the converted code, clisp needs 79 seconds. That is more as
> 50% longer.
> 

did you compile the CL code?
if it is a script, you might want to add "-C" to the "#!/.../clisp" line to 
enable on-the-fly compilation.

Re: Using Emacs Lisp for script writing

[Sam Steingold]

Cecil Westerhof wrote:
> Sam Steingold <sds@gnu.org> writes:
> 
>>> I already use 'emacs -batch' for scripting where no user input is used,
>>> but I would like to use it also for interactive scripting. Until now I
>>> did not find any usable information about this. Anybody using Emacs for
>>> interactive scripts?
>> I use clisp for all scripting, interactive and not.
>> Common Lisp is more powerful than Emacs Lisp and clisp is faster than
>> emacs.
> 
> I have been experimenting with clisp. But I think that Emacs Lisp does a
> pretty good job. I translated a script I wrote in Emacs Lisp to CL. The
> Emacs Lisp version needed 51 seconds on a certain data set. When using
> clisp with the converted code, clisp needs 79 seconds. That is more as
> 50% longer.
> 

in addition to compilation - there might be non-obvious inefficiencies in the 
code. you might want to post it here (if it is not too big).

Re: Using Emacs Lisp for script writing

[Tim X]

Cecil Westerhof <Cecil@decebal.nl> writes:

> Sam Steingold <sds@gnu.org> writes:
>
>>> I already use 'emacs -batch' for scripting where no user input is used,
>>> but I would like to use it also for interactive scripting. Until now I
>>> did not find any usable information about this. Anybody using Emacs for
>>> interactive scripts?
>>
>> I use clisp for all scripting, interactive and not.
>> Common Lisp is more powerful than Emacs Lisp and clisp is faster than
>> emacs.
>
> I have been experimenting with clisp. But I think that Emacs Lisp does a
> pretty good job. I translated a script I wrote in Emacs Lisp to CL. The
> Emacs Lisp version needed 51 seconds on a certain data set. When using
> clisp with the converted code, clisp needs 79 seconds. That is more as
> 50% longer.

Hi cecil,

your comparisons of speed are not really justified. Clisp is a general
purpose implementation of CL while emacs lisp is a specialised dialect
for text processing. This means that you will likely get pretty good
performance from elisp compared to clisp when using it at a novice
level.  However, as your understanding of CL and your familiarity with
clisp improve, you will get faster and faster results from clisp. 

Clisp (and most modern CL implementations) have lots of optimisation
which can be applied. In general, you don't do this until it is
necessary and until you have the algorithms worked out. There are also
many basic lisp idioms you have yet to learn that will improve both your
code readability and its performance. The good news is that it will
likely help in both your elisp and your CL (and scheme and any other
lispy language you might try). 

The performance differences you are geting now really say more about
your level of expertise with the language. It does show that with a
specialised dialect, such as elisp, the novice will likely do better
than with a general dialect, such as CL. However, depending on the
scripts and what you are doing, you will likely run into situations
where you cannot easily do with elisp what you want and you ahve to
start jumping through lots of hoops that would be much easier using a
more general dialect, such as CL. 

A possible example is prompting for user input in an elisp script. While
this is no problem when running in an interactive mode (i.e. from within
emacs), it is more difficult when running non-interactively via a batch
mode. This isn't a problem with clisp. Using emacs for scripting can
also have much longer load times, especially if your not using emacs in
server mode, compared to a natively compiled clisp program. 

At this point in your learning curve, any comparisons of performance are
very much meaningless as they are not really comparing the tehcnologies,
but rather the programmer. While you may find elisp faster and easier at
this point, you will find CL a more useful general purpose tool in the
long term. I suspect that in the end, both tools will be valuable. Which
one you use for a task will depend on the type of task. Some scripts
will be more suited for elisp and others will be more suited to CL. 

Tim
 
-- 
tcross (at) rapttech dot com dot au

Re: Using Emacs Lisp for script writing

[Cecil Westerhof]

Tim X <timx@nospam.dev.null> writes:

> your comparisons of speed are not really justified. Clisp is a general
> purpose implementation of CL while emacs lisp is a specialised dialect
> for text processing. This means that you will likely get pretty good
> performance from elisp compared to clisp when using it at a novice
> level.  However, as your understanding of CL and your familiarity with
> clisp improve, you will get faster and faster results from clisp. 

It is already a lot better as it was. I am learning and -most important-
get a lot of help from this group.


> Clisp (and most modern CL implementations) have lots of optimisation
> which can be applied. In general, you don't do this until it is
> necessary and until you have the algorithms worked out. There are also
> many basic lisp idioms you have yet to learn that will improve both your
> code readability and its performance. The good news is that it will
> likely help in both your elisp and your CL (and scheme and any other
> lispy language you might try). 
>
> The performance differences you are geting now really say more about
> your level of expertise with the language. It does show that with a
> specialised dialect, such as elisp, the novice will likely do better
> than with a general dialect, such as CL. However, depending on the
> scripts and what you are doing, you will likely run into situations
> where you cannot easily do with elisp what you want and you ahve to
> start jumping through lots of hoops that would be much easier using a
> more general dialect, such as CL. 

One problem is interacting. Just batch scripting is no problem in elisp,
but at the moment you want to interact with the user, you have a
problem. That is the reason I started with CL.

If you want to see what I have done until: I put the scripts on the web.
The CL files are reachable at:
    http://www.decebal.nl/CommonLisp/sources/substitute-expression.cl
    http://www.decebal.nl/CommonLisp/sources/script-utils.cl

The original Emacs Lisp code:
    http://www.decebal.nl/EmacsLisp/sources/substitute-expression.el

>> Using emacs for scripting can
> also have much longer load times, especially if your not using emacs in
> server mode, compared to a natively compiled clisp program. 

I am not using Emacs server at the moment, but the load times are not a
real problem.


> At this point in your learning curve, any comparisons of performance are
> very much meaningless as they are not really comparing the tehcnologies,
> but rather the programmer. While you may find elisp faster and easier at
> this point, you will find CL a more useful general purpose tool in the
> long term.

I hope -and expect- so. ;-]


> I suspect that in the end, both tools will be valuable. Which
> one you use for a task will depend on the type of task. Some scripts
> will be more suited for elisp and others will be more suited to CL. 

I think I will try to write the scripts only in CL. In that way it is
easier to share. Otherwise people need to have a CL implementation and
Emacs on their system. When there is a situation that an elisp version
is a lot more efficient -because of the optimisation for text- I could
create two versions. But elisp is of course very handy for extending the
functionality of Emacs. :-D

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

Re: Using Emacs Lisp for script writing

[Tim X]

Cecil Westerhof <Cecil@decebal.nl> writes:

> Tim X <timx@nospam.dev.null> writes:
>
>
> I think I will try to write the scripts only in CL. In that way it is
> easier to share. Otherwise people need to have a CL implementation and
> Emacs on their system. When there is a situation that an elisp version
> is a lot more efficient -because of the optimisation for text- I could
> create two versions. But elisp is of course very handy for extending the
> functionality of Emacs. :-D

I think that is a wise way to go. My apologies if I sounded too
'preachy' or critical of what you are doing. My main motivation was to
highlight that at this stage, you need to be very careful about
assessing efficiency and performance. Lisp dialects are somewhat
notorious for being easy to learn and very hard to master.  CL in
particular can be very daunting at first because it is quite a large
language and the hyperspec takes considerable time to get comfortable
with. For me, the most difficult part has been identifying/finding the
functions you are after. The terminology can seem unfamiliar and
searching the hyperspec index can be frustrating when you don't know the
right terminology to use. I frequently spend considerable time searching
for something which I know will be there, but not having the right
terminology, I can't find it. For this reason, I've found other
resources, such as Practical Common Lisp, CLTL2 and other books really
useful. I tend to skim them, find the general area and terms I need and
then go back to the hyperspec to get the precise definition/usage. 

from experience, I would say your decision to focus on CL for now is a
good one. I've seen a number of posts from people who have managed to
get themselves really confused because of switching between different
dialects. I have managed to get myself confused as well by doing this.
It is best to concentrate on one until you are quite comfortable and
familiar with it and then move on to the next dialect. Apart from
reducing the potential for confusion, you can also appreciate the
pros/cons of the different dialects better. Like many others, myself
included, you will likely find elisp a little limiting after having
worked with CL as there are a number of features CL has that would be
nice to have in elisp (though I still find elisp and emacs the best
extensible editor and kitchen sink available!)

good luck

Tim

P.S. Another advantage to CL is that if you plan to share/distribute
some of what you are doing, you can compile it to native code. This
means people don't even have to know you wrote it in lisp. This can help
overcome the considerable FUD regarding CL that exists out there. 

PPS. Make sure you do put the effort into getting SLIME working. Apart
from making you more productive in CL, I think you will find the whole
development process very enlightening. This is what I love the most
about CL. Instead of the time wasting edit -> compile -> debug ->
edit ->... loop, you have a much tighter code -> evaluate -> refine loop
that encourages small incremental change and practices like unit testing
and test driven development. I also find it much easier to 'explore'
solutions. In general, a whole development experience that is more rewarding
and for me at least, produces better code. It has also had positive
benefits on the rest of my coding in other languages. In general, I
think it has made me a better programmer. 

-- 
tcross (at) rapttech dot com dot au

Re: Using Emacs Lisp for script writing

[Cecil Westerhof]

Tim X <timx@nospam.dev.null> writes:

>> I think I will try to write the scripts only in CL. In that way it is
>> easier to share. Otherwise people need to have a CL implementation and
>> Emacs on their system. When there is a situation that an elisp version
>> is a lot more efficient -because of the optimisation for text- I could
>> create two versions. But elisp is of course very handy for extending the
>> functionality of Emacs. :-D
>
> I think that is a wise way to go. My apologies if I sounded too
> 'preachy' or critical of what you are doing.

No problem. I do not mind to be put on the right track. ;-)

> My main motivation was to
> highlight that at this stage, you need to be very careful about
> assessing efficiency and performance.

I'll try to keep that in mind. But compiling the regular expression made
a big difference. Also, I remember someone telling me that lists are not
very efficient. What should I use instead? Or will I found that out in
Practical Common Lisp?


> Lisp dialects are somewhat
> notorious for being easy to learn and very hard to master.

I already experienced a little of it.


> For this reason, I've found other
> resources, such as Practical Common Lisp, CLTL2 and other books really
> useful. I tend to skim them, find the general area and terms I need and
> then go back to the hyperspec to get the precise definition/usage. 

Practical Common Lisp I already use. (From there I got the property
list.) From CLTL2 is said:
    "The book does not correspond exactly with the ANSI standard: some
    details are different; some things from the standard are missing;
    and some things from CLtL2 are not in the final ANSI standard.
    Programmers should therefore be wary of using it as a reference."
But I'll add it to my (already very big -maybe I need to sift) arsenal.


> I have managed to get myself confused as well by doing this.
> It is best to concentrate on one until you are quite comfortable and
> familiar with it and then move on to the next dialect. Apart from
> reducing the potential for confusion, you can also appreciate the
> pros/cons of the different dialects better.

With different dialects do you mean different Lisp dialects or different
CL dialects? The former I think I do not like, the latter is where I
will aim at. When I write portable code, I can switch to the dialect
that is best for the situation.


> (though I still find elisp and emacs the best
> extensible editor and kitchen sink available!)

I agree. For example I am also using GNUS -just as you I saw-. It is a
lot of work, but I think/hope that when I have GNUS in my fingers, I can
easily make it do what I want instead of what the developer thought I
wanted. ;-)


> good luck

I'll need it. :-D


> P.S. Another advantage to CL is that if you plan to share/distribute
> some of what you are doing, you can compile it to native code. This
> means people don't even have to know you wrote it in lisp. This can help
> overcome the considerable FUD regarding CL that exists out there. 

That is a good point. But with clisp that does not work as far as I
know. I tried to install SBCL, but the install process needs Lisp. It
only mention it to do with SBCL and CMUCL. So that can wait until later.


> PPS. Make sure you do put the effort into getting SLIME working.

I already planned that.

Another question. The BBDB and also the example in Practical Common Lisp
use lists for the database. Is this not inefficient? Would a real
database not be better. Not that I want to burn me at the moment on
databases. ;-)

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

Re: Using Emacs Lisp for script writing

[Pascal J. Bourguignon]

Cecil Westerhof <Cecil@decebal.nl> writes:

> I'll try to keep that in mind. But compiling the regular expression made
> a big difference. Also, I remember someone telling me that lists are not
> very efficient. 

See?  This is what we meant when we told you that you need to know
more before trying to optimize things out!

Adding an element to a list or removing one is O(1) (when it's the
first element of the list).  Doing the same with a vector is O(n).
With a tree it'll be O(log(n)), and with a hash-table, it will be O(1)
amortized, that is, the constant factors will kill you.

Now of course if your algorithm is not adding or removing the first
element of the data structure, the time complexities and constant
factors will be different.

So either you have a partial memory, or the someone who told you that
lists are not very efficient did the same error most people do, that
is forgetting the conditions of application.




> What should I use instead? Or will I found that out in
> Practical Common Lisp?

Practical Common Lisp is only the first step.  There is a lot of
literature to read and programs to write to learn what has to be
learnt.

Browse the cliki: 

http://cliki.net/Education
http://cliki.net/Online%20Tutorial
http://cliki.net/Lisp%20books



> Another question. The BBDB and also the example in Practical Common Lisp
> use lists for the database. Is this not inefficient? 

No, not in those conditions of application.


> Would a real database not be better. Not that I want to burn me at
> the moment on databases. ;-)

A real database would be overkill to store five records.  Just
"opening" the database would takes hundreds times more of cycles than
pushing onto a list, and don't you know the speed differential between
memory write and disk writes?


Remember this is a "simple database", a small example given to give a
taste of lisp before even introducing the Syntax of lisp!

But the most important thing you should have learnt from this chapter,
is not that it used lists to store the records, but that the storing
of the records was abstracted away with a add-record function.  That
means that all the programs presented in this chapter will work the
same once you hook a disk based database under add-record instead of
the simple list  (See SICP).


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

"Specifications are for the weak and timid!"

Re: Using Emacs Lisp for script writing

[Cecil Westerhof]

pjb@informatimago.com (Pascal J. Bourguignon) writes:

>> I'll try to keep that in mind. But compiling the regular expression made
>> a big difference. Also, I remember someone telling me that lists are not
>> very efficient. 
>
> See?  This is what we meant when we told you that you need to know
> more before trying to optimize things out!
>
> Adding an element to a list or removing one is O(1) (when it's the
> first element of the list).  Doing the same with a vector is O(n).
> With a tree it'll be O(log(n)), and with a hash-table, it will be O(1)
> amortized, that is, the constant factors will kill you.
>
> Now of course if your algorithm is not adding or removing the first
> element of the data structure, the time complexities and constant
> factors will be different.

Thanks. I'll keep those things in mind.


>> What should I use instead? Or will I found that out in
>> Practical Common Lisp?
>
> Practical Common Lisp is only the first step.  There is a lot of
> literature to read and programs to write to learn what has to be
> learnt.
>
> Browse the cliki: 
>
> http://cliki.net/Education
> http://cliki.net/Online%20Tutorial
> http://cliki.net/Lisp%20books

I'll do that.


>> Another question. The BBDB and also the example in Practical Common Lisp
>> use lists for the database. Is this not inefficient? 
>
> No, not in those conditions of application.
>
>
>> Would a real database not be better. Not that I want to burn me at
>> the moment on databases. ;-)
>
> A real database would be overkill to store five records.  Just
> "opening" the database would takes hundreds times more of cycles than
> pushing onto a list, and don't you know the speed differential between
> memory write and disk writes?
>
>
> Remember this is a "simple database", a small example given to give a
> taste of lisp before even introducing the Syntax of lisp!

Yes, but the BBDB could become quit big I would think. Maybe a tree
would be better as a list. But I have enough to worry about. So I'll put
it on the back burner.


> But the most important thing you should have learnt from this chapter,
> is not that it used lists to store the records, but that the storing
> of the records was abstracted away with a add-record function.  That
> means that all the programs presented in this chapter will work the
> same once you hook a disk based database under add-record instead of
> the simple list  (See SICP).

Abstraction is always good to do. SICP was already on my list to read.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

Re: Using Emacs Lisp for script writing

[Tim X]

Cecil Westerhof <Cecil@decebal.nl> writes:

> Tim X <timx@nospam.dev.null> writes:
>
> I'll try to keep that in mind. But compiling the regular expression made
> a big difference. Also, I remember someone telling me that lists are not
> very efficient. What should I use instead? Or will I found that out in
> Practical Common Lisp?
>
I'm always very wary of claims such as lists are not efficient. Lists in
lisp tend to be a lot more efficient than lists in other languages.
However, my main reason for being cautious is that it really depends on
what your doing and what the performance expectations are. While I do
try to develop efficient algorithms and I certainly due try to choose
the best abstract data type for the problem at hand, I frequently start
with a list and then possibly change to some other structure once it
becomes clear the list is not going to be efficient or is going to be
less clear code wise compared to using something else, such as s struct,
array or class. Lists are pretty fundamental in lisp - even the code is
a list of lists. Apart from having an efficient list implementation,
lisp also tends to have a lot of useful functions that work on lists. 


>
>> Lisp dialects are somewhat
>> notorious for being easy to learn and very hard to master.
>
> I already experienced a little of it.
>
>
>> For this reason, I've found other
>> resources, such as Practical Common Lisp, CLTL2 and other books really
>> useful. I tend to skim them, find the general area and terms I need and
>> then go back to the hyperspec to get the precise definition/usage. 
>
> Practical Common Lisp I already use. (From there I got the property
> list.) From CLTL2 is said:
>     "The book does not correspond exactly with the ANSI standard: some
>     details are different; some things from the standard are missing;
>     and some things from CLtL2 are not in the final ANSI standard.
>     Programmers should therefore be wary of using it as a reference."
> But I'll add it to my (already very big -maybe I need to sift) arsenal.
>
>
>> I have managed to get myself confused as well by doing this.
>> It is best to concentrate on one until you are quite comfortable and
>> familiar with it and then move on to the next dialect. Apart from
>> reducing the potential for confusion, you can also appreciate the
>> pros/cons of the different dialects better.
>
> With different dialects do you mean different Lisp dialects or different
> CL dialects? The former I think I do not like, the latter is where I
> will aim at. When I write portable code, I can switch to the dialect
> that is best for the situation.

I was referring to the different lisp dialects rather than different CL
dialects. For example, elisp, scheme, guile, rep and cl are all lisp
dialects. They are similar enough that usually you can understand the
code by just reading it, but they have enough differences that you can
easily get confused when switching between them.
>
>
>> (though I still find elisp and emacs the best
>> extensible editor and kitchen sink available!)
>
> I agree. For example I am also using GNUS -just as you I saw-. It is a
> lot of work, but I think/hope that when I have GNUS in my fingers, I can
> easily make it do what I want instead of what the developer thought I
> wanted. ;-)
>
Yep, this is the huge benefit of emacs. Its quite amazing what you can
do with it. I use it pretty much for everything. In fact, I have to as
I'm an emacspeak user. I lost my sight over 12 years ago. Thanks to
emacs and emacspeak, not only have I been able to continue working, I've
actually managed to continue developing a career as a programmer. 

Emacspeak uses a very neat feature of emacs called defadvice. Using
elisp's advice functionality, key functions have been advised to provide
both spoken feedback and auditory icons. Essentially, the advice
mechanism provides a way to modify the behavior of a function without
changing its code. The advice works like a wrapper around the original
function, allowing you to call/run additional bits of elisp before,
after or around the original function. This elisp can do all sorts of
things, such as changing/modifying arguments passed to the function or
values returned by the function or possibly do something quite unrelated
etc. It can be a dangerous feature if not used cautiously and it can
create challenges when debugging, but is a very useful feature. 
>

>> P.S. Another advantage to CL is that if you plan to share/distribute
>> some of what you are doing, you can compile it to native code. This
>> means people don't even have to know you wrote it in lisp. This can help
>> overcome the considerable FUD regarding CL that exists out there. 
>
> That is a good point. But with clisp that does not work as far as I
> know. I tried to install SBCL, but the install process needs Lisp. It
> only mention it to do with SBCL and CMUCL. So that can wait until later.
>
Although I've not done it, looking at the clisp docs, there does appear
to be functionality that will support dumping out the lisp program to
native code. I wouldn't worry about it now, but it probably would be
worth looking at later.


>
>> PPS. Make sure you do put the effort into getting SLIME working.
>
> I already planned that.
>
> Another question. The BBDB and also the example in Practical Common Lisp
> use lists for the database. Is this not inefficient? Would a real
> database not be better. Not that I want to burn me at the moment on
> databases. ;-)

Ive used bbdb for years and have a large .bbdb database file. I have
never encountered any performance issues. Actually, bbdb is possibly a
good example of what I was trying to explain above concerning not
worrying about efficiency and performance too much when developing the
code. 

I would be vary cautious regarding statements such as lists are
inefficient. Such a statement is a huge generalisation and needs to be
considered in context. 

Most argue lists are inefficient mainly because of additional storage
(i.e. each node has a pointer to the next node) and because they don't
support random access (you have to traverse the list to get to the last
element) etc. While this is all true, it is important to balance this
with the fact that lisps have gotten very good at managing lists
efficiently, provide lots of very useful and optimised functions for
operating on lists  and have developed idioms for using lists that avoid
some of the inefficiencies, such as pushing new elements onto the front
of the list and then reversing the list when you are done rather than
traversing the list multiple times to add new elements etc.  Generally
speaking, lists in lisp are a lot more efficient than lists in other
languages. A common mistake/criticism of lisp is that non-lispers think
lists are all there is in lisp and they think lists are inefficient.
This is not necessarily the case and overlooks the fact lisps tend to
support other data types, such as arrays, structs and classes.

Having said that, it is still possible to use lists in lisp
inappropriately and end up with slow or inefficient programs. However,
this isn't a problem with the language as much as with the experience of
the programmer. A good understanding of lisp list structure, how it
shares storage between structures (for example, joining part of one list
with another list usually doesn't create a totally new list with all its
associated storage. More likely, you will modify the 'links' in your
list and will end up with a new linked structure which shares storage
with one of the original lists. Essentially, rather than creating
multiple copies of things, lisps will genrally manipulate the links in a
list to create different representations of the linked atoms that make
up the list. Instead of having multiple copies of the atom, you will
have just one, but it might be pointed to by multiple structures that
represent that atom in different lists. This is why in most lisps you
need to be careful about where you use distructive operations as you
cannot always know what else in the program is sharing some of the
structure. It also explains why lisp is frequently used in a functional
programming style (though this is not the only paradigm CL supports).
However, I digress....

The bbdb uses lists and shows that they can be used in an efficient
manner. While you could use a full blown database for this, you probably
wouldn't get any improvement in performance as you would now have all
the overheads associated with making database connections and managing
database files etc. If on the other hand we were talking about an
application that had to process large amounts of data or had to query
the data in complex ways or support ad hoc queries etc, then maybe a
list would not be the right data type and we might find structures or
classes better. However, in reality, we are talking about a basic
address book. the types of queries are well structured, the records are
fairly well structured and quite small and the system has few
updates/inserts.

At the end of the day, the real measure of whether it is efficient
enough is user experience. If the user is able to add and update records
and query for data in a time that is acceptable without all available
resources being used and essentially, the system is useful and
beneficial, then the program is efficient enough. You could possibly
re-write the whole system to use a different data structure or a
database for storage and maybe you might see a 50% improvement in speed
or reduction in storage requirements, but if that makes no difference to
the user experience, what benefit was it? In addition, adding all the
code to manage a new data structure or manage database communicaitons
wil likely make the code larger and more complex, bringing with it more
bugs and probably more maintenance effort. Increasing responsiveness so
that I get a result in 25 msec rather than 50 msec is unlikely to
impress anyone (or even be noticed).

If you adopt good coding style, changing from one data structure to
another within lisp is usually fairly straight forward. Therefore, my
standard approach is to initially use lists while developing the first
version. If I find that managing the data with lists becomes too coplex
or the efficiency is not good enough, I will change to a new structure.
This usually only involves changing a few low level functions that
manipulate the data at a low level. Doing it this way also usually means
that by the time I've got to this stage, I have much better
understanding of the problem domain and can also make a better decision
as to what is the best structure to use. Something I may not have been
able to do at the very beginning when my knowledge of the problem was
more abstract.

-- 
tcross (at) rapttech dot com dot au

Re: Using Emacs Lisp for script writing

[Cecil Westerhof]

Tim X <timx@nospam.dev.null> writes:

>> I'll try to keep that in mind. But compiling the regular expression made
>> a big difference. Also, I remember someone telling me that lists are not
>> very efficient. What should I use instead? Or will I found that out in
>> Practical Common Lisp?
>>
> I'm always very wary of claims such as lists are not efficient. Lists in
> lisp tend to be a lot more efficient than lists in other languages.
> However, my main reason for being cautious is that it really depends on
> what your doing and what the performance expectations are. While I do
> try to develop efficient algorithms and I certainly due try to choose
> the best abstract data type for the problem at hand, I frequently start
> with a list and then possibly change to some other structure once it
> becomes clear the list is not going to be efficient or is going to be
> less clear code wise compared to using something else, such as s struct,
> array or class. Lists are pretty fundamental in lisp - even the code is
> a list of lists. Apart from having an efficient list implementation,
> lisp also tends to have a lot of useful functions that work on lists. 

Lets default stick with lists then and write the code in such a way that
it is easily changed.


>> With different dialects do you mean different Lisp dialects or different
>> CL dialects? The former I think I do not like, the latter is where I
>> will aim at. When I write portable code, I can switch to the dialect
>> that is best for the situation.
>
> I was referring to the different lisp dialects rather than different CL
> dialects. For example, elisp, scheme, guile, rep and cl are all lisp
> dialects. They are similar enough that usually you can understand the
> code by just reading it, but they have enough differences that you can
> easily get confused when switching between them.

I'll stick for the moment with CL and elisp. And when I am 'fluent' in
them maybe I'll look at scheme.


>>> (though I still find elisp and emacs the best
>>> extensible editor and kitchen sink available!)
>>
>> I agree. For example I am also using GNUS -just as you I saw-. It is a
>> lot of work, but I think/hope that when I have GNUS in my fingers, I can
>> easily make it do what I want instead of what the developer thought I
>> wanted. ;-)
>>
> Yep, this is the huge benefit of emacs. Its quite amazing what you can
> do with it. I use it pretty much for everything. In fact, I have to as

It only has a bad press. I once wanted to use it, but everyone told me
not to use it because it was 'hard to learn and to use'. Not long ago I
started using it anyway and regretted it very much that I listened to
other people. :-(


> Emacspeak uses a very neat feature of emacs called defadvice. Using

I have heard about it, but not tempered with it yet.


> etc. It can be a dangerous feature if not used cautiously and it can
> create challenges when debugging, but is a very useful feature. 

Both are very true I think.


>>> P.S. Another advantage to CL is that if you plan to share/distribute
>>> some of what you are doing, you can compile it to native code. This
>>> means people don't even have to know you wrote it in lisp. This can help
>>> overcome the considerable FUD regarding CL that exists out there. 
>>
>> That is a good point. But with clisp that does not work as far as I
>> know. I tried to install SBCL, but the install process needs Lisp. It
>> only mention it to do with SBCL and CMUCL. So that can wait until later.
>>
> Although I've not done it, looking at the clisp docs, there does appear
> to be functionality that will support dumping out the lisp program to
> native code. I wouldn't worry about it now, but it probably would be
> worth looking at later.

I'll not worry about it. Before sharing I first need to get fluent. And
I am afraid I still have a road ahead of me.  But I think I'll go for
SBCL. Compiling to native code looks better to me as dumping to native
code. But that is for another day to decide.


>> Another question. The BBDB and also the example in Practical Common Lisp
>> use lists for the database. Is this not inefficient? Would a real
>> database not be better. Not that I want to burn me at the moment on
>> databases. ;-)
>
> Ive used bbdb for years and have a large .bbdb database file. I have
> never encountered any performance issues. Actually, bbdb is possibly a
> good example of what I was trying to explain above concerning not
> worrying about efficiency and performance too much when developing the
> code. 

I have a very small .bbdb, so that was why I was wondering. But I do not
need to worry then.
The only problem I have with bbdb is that there are no links. Say for
example people are part of a certain company. Now I have -as far as I
know- to put the general information in every record. With a database
the general information could be retrieved from the company record when
fetching the employee record. For me that is not a problem, but I think
it is a restriction.


> I would be vary cautious regarding statements such as lists are
> inefficient. Such a statement is a huge generalisation and needs to be
> considered in context.

Default I'll stick with lists and change it when necessary.


> list and will end up with a new linked structure which shares storage
> with one of the original lists. Essentially, rather than creating
> multiple copies of things, lisps will genrally manipulate the links in a
> list to create different representations of the linked atoms that make
> up the list. Instead of having multiple copies of the atom, you will
> have just one, but it might be pointed to by multiple structures that
> represent that atom in different lists. This is why in most lisps you
> need to be careful about where you use distructive operations as you
> cannot always know what else in the program is sharing some of the
> structure.

And modifying operations of course.


> and the system has few updates/inserts.

But a lot of fetching. But that is then proof -because you have a big
bbdb- that list are efficient in lisp.


> At the end of the day, the real measure of whether it is efficient
> enough is user experience. If the user is able to add and update records
> and query for data in a time that is acceptable without all available
> resources being used and essentially, the system is useful and
> beneficial, then the program is efficient enough.

Yes and no. I have seen it to many times that a program worked great
when the demo was given. But at the moment real data was used, or the
data grew above a certain amount, huge problems appeared. But when it is
true that in Lisp changing the underlying structure is more easy, then
it is not something to worry about.


> If you adopt good coding style, changing from one data structure to
> another within lisp is usually fairly straight forward. Therefore, my
> standard approach is to initially use lists while developing the first
> version. If I find that managing the data with lists becomes too coplex
> or the efficiency is not good enough, I will change to a new structure.

I'll copy you. ;-)

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

Re: Using Emacs Lisp for script writing

[Cecil Westerhof]

Sam Steingold <sds@gnu.org> writes:

>>> I use clisp for all scripting, interactive and not.
>>> Common Lisp is more powerful than Emacs Lisp and clisp is faster than
>>> emacs.
>>
>> I have been experimenting with clisp. But I think that Emacs Lisp does a
>> pretty good job. I translated a script I wrote in Emacs Lisp to CL. The
>> Emacs Lisp version needed 51 seconds on a certain data set. When using
>> clisp with the converted code, clisp needs 79 seconds. That is more as
>> 50% longer.
>>
>
> did you compile the CL code?
> if it is a script, you might want to add "-C" to the "#!/.../clisp" line
> to enable on-the-fly compilation.

Yes, I did. I call my code mostly with clisp -C. But your tip is
valuable. When calling as a script without the -C the script takes 2:35
and with the -C it takes 1:19. The only problem is that I always use:
    #!/usr/bin/env clisp

That is not possible with -C, so now I have to use:
    #!/usr/bin/clisp -C

It is not a big deal, but when the script is put on another system and
on this system clisp is in another location, the script has to be
modified (or a link has to be created). But halving the execution time
is important enough.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

Re: Using Emacs Lisp for script writing

[Tim X]

Cecil Westerhof <Cecil@decebal.nl> writes:

>
> It is not a big deal, but when the script is put on another system and
> on this system clisp is in another location, the script has to be
> modified (or a link has to be created). But halving the execution time
> is important enough.

There is a trick used by other scripting languages to get around the
issue of the script interpreter being in a different location and for
those systems which only handle 30 characters in the #! line

#!/bin/sh 
# the next line restarts using the interpreter foobar \
exec foobar "$0" "$@"

I wonder if something like this cold work. The problem I see is that
clisp would have to be told to ignore these lines and only start
evaluating code from the line following the exec. I'm not familiar
enough with the lisp reader to know. the other problem is that if it
needed changes to the reader, then those changes would also need to be
on the host you attempt to run this one, so unless it was a standard
feature, it probably woldn't buy much. 

just thinking out loud.....

Tim

-- 
tcross (at) rapttech dot com dot au

Re: Using Emacs Lisp for script writing

[Pascal J. Bourguignon]

Tim X <timx@nospam.dev.null> writes:

> Cecil Westerhof <Cecil@decebal.nl> writes:
>
>>
>> It is not a big deal, but when the script is put on another system and
>> on this system clisp is in another location, the script has to be
>> modified (or a link has to be created). But halving the execution time
>> is important enough.
>
> There is a trick used by other scripting languages to get around the
> issue of the script interpreter being in a different location and for
> those systems which only handle 30 characters in the #! line
>
> #!/bin/sh 
> # the next line restarts using the interpreter foobar \
> exec foobar "$0" "$@"
>
> I wonder if something like this could work. 

Sure.

[pjb@hubble :0.0 ~]$ cat ./s 
#!/bin/sh
#| Both a lisp and sh comment.
exec clisp "$0" "$@" 
|#
(princ "Hi") (terpri)

[pjb@hubble :0.0 ~]$ ./s
Hi
[pjb@hubble :0.0 ~]$ 


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

WARNING: This product attracts every other piece of matter in the
universe, including the products of other manufacturers, with a
force proportional to the product of the masses and inversely
proportional to the distance between them.

Re: Using Emacs Lisp for script writing

[Cecil Westerhof]

pjb@informatimago.com (Pascal J. Bourguignon) writes:

>>> It is not a big deal, but when the script is put on another system and
>>> on this system clisp is in another location, the script has to be
>>> modified (or a link has to be created). But halving the execution time
>>> is important enough.
>>
>> There is a trick used by other scripting languages to get around the
>> issue of the script interpreter being in a different location and for
>> those systems which only handle 30 characters in the #! line
>>
>> #!/bin/sh 
>> # the next line restarts using the interpreter foobar \
>> exec foobar "$0" "$@"
>>
>> I wonder if something like this could work. 
>
> Sure.
>
> [pjb@hubble :0.0 ~]$ cat ./s 
> #!/bin/sh
> #| Both a lisp and sh comment.
> exec clisp "$0" "$@" 
> |#

Works like a charm. I made it:
    #!/usr/bin/env bash
    #| Both a lisp and sh comment.
    exec clisp -C "$0" "$@" 
    |#

And now all three work:
    script.cl
    clisp -C script.cl
    clisp -c script.cl

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

Re: Using Emacs Lisp for script writing

[Pascal J. Bourguignon]

Cecil Westerhof <Cecil@decebal.nl> writes:
> Works like a charm. I made it:
>     #!/usr/bin/env bash

IMO, there's higher probability that /bin/bash be present than /usr/bin/env.
And even higher probability that /bin/sh be present.

Since you're not using any bash feature in the script, you could as
well go for the sure case, and use #!/bin/sh.


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

Re: Using Emacs Lisp for script writing

[Cecil Westerhof]

pjb@informatimago.com (Pascal J. Bourguignon) writes:

> Cecil Westerhof <Cecil@decebal.nl> writes:
>> Works like a charm. I made it:
>>     #!/usr/bin/env bash
>
> IMO, there's higher probability that /bin/bash be present than /usr/bin/env.
> And even higher probability that /bin/sh be present.
>
> Since you're not using any bash feature in the script, you could as
> well go for the sure case, and use #!/bin/sh.

I have once been on a system where the shells were in a different
directory. (I think it was a BSD system.) As I understand it
/usr/bin/env should be on every system, as a real file or a link. That
is why I use /usr/bin/env. But properly sh would be better instead of
bash. There are systems where bash is not installed.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

Re: Using Emacs Lisp for script writing

[Tim X]

pjb@informatimago.com (Pascal J. Bourguignon) writes:

> Cecil Westerhof <Cecil@decebal.nl> writes:
>> Works like a charm. I made it:
>>     #!/usr/bin/env bash
>
> IMO, there's higher probability that /bin/bash be present than /usr/bin/env.
> And even higher probability that /bin/sh be present.
>
> Since you're not using any bash feature in the script, you could as
> well go for the sure case, and use #!/bin/sh.

I second this. If I remember correctly, to be posix compliant, you must
have  sh, but you don't have to have bash or env.

Tim


-- 
tcross (at) rapttech dot com dot au

Re: Using Emacs Lisp for script writing

[Cecil Westerhof]

Tim X <timx@nospam.dev.null> writes:

>>> Works like a charm. I made it:
>>>     #!/usr/bin/env bash
>>
>> IMO, there's higher probability that /bin/bash be present than /usr/bin/env.
>> And even higher probability that /bin/sh be present.
>>
>> Since you're not using any bash feature in the script, you could as
>> well go for the sure case, and use #!/bin/sh.
>
> I second this. If I remember correctly, to be posix compliant, you must
> have  sh, but you don't have to have bash or env.

I have to look into that. I know that bash is not always there -I have
worked on a Tru-64 system, which did not have it-, I also understood
that /usr/bin/env should always be there -as a real file or a link- and
I had it once -I think on a BSD system- that the shell was in another
directory. But I 'always' work with bash, so it could be that /bin/sh is
always there. So lets just change it. And if there is a system where
there is not a /bin/sh lets hope that the administrator is willing to
make the link. Otherwise the script(s) have to be changed, but that is
no rocket science. ;-)

On my system the three calls still work. ;-)

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

Re: Using Emacs Lisp for script writing

[Cecil Westerhof]

Sam Steingold <sds@gnu.org> writes:

> in addition to compilation - there might be non-obvious inefficiencies
> in the code. you might want to post it here (if it is not too big).

It is not that big, but I just post the links here. This way the latest
version can always be fetched when I update the files.
The files are reachable at:
    http://www.decebal.nl/CommonLisp/sources/substitute-expression.cl
    http://www.decebal.nl/CommonLisp/sources/script-utils.cl

The original Emacs Lisp code:
    http://www.decebal.nl/EmacsLisp/sources/substitute-expression.el

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

Re: Using Emacs Lisp for script writing

[Andreas Politz]

Cecil Westerhof <Cecil@decebal.nl> writes:

> I already use 'emacs -batch' for scripting where no user input is used,
> but I would like to use it also for interactive scripting. Until now I
> did not find any usable information about this. Anybody using Emacs for
> interactive scripts?

No, but it should be noted, that this is not very difficult :

$ emacs -Q -batch -eval '(yes-or-no-p "Want some cookies ?")'

-ap

Re: Using Emacs Lisp for script writing

[David Engster]

Andreas Politz <politza@fh-trier.de> writes:
> Cecil Westerhof <Cecil@decebal.nl> writes:
>
>> I already use 'emacs -batch' for scripting where no user input is used,
>> but I would like to use it also for interactive scripting. Until now I
>> did not find any usable information about this. Anybody using Emacs for
>> interactive scripts?
>
> No, but it should be noted, that this is not very difficult :
>
> $ emacs -Q -batch -eval '(yes-or-no-p "Want some cookies ?")'

You can also use the '--script' option in a shebang line:

----------------- test.sh -----------------
#!/usr/bin/emacs --script

(if (yes-or-no-p "Choose ")
  (message "You said yes")
 (message "You said no"))
-------------------------------------------

I use emacs regularly for writing scripts, since with its thousands of
packages you have a huge library readily available.

-David

Re: Using Emacs Lisp for script writing

[mug896]

I use emacs lisp read-* function

(setq ans1 (yes-or-no-p "Is this good ? "))
(message "\nYour answer is => %s\n" (symbol-name ans1))

(setq ans2 (read-string "Enter message : "))
(message "\nYour message is => %s\n" ans2 )

(setq ans3 (read-number "Enter number : "))
(message "\nYour number is => %s\n" ans3 )