I am new to both emacs and lisp.  After I enter a lisp script, I would
like to run it to see it crash (this is what my programs usually do).  I
understand that I could save the script to a file, exit from emacs (or
shell out of it), and then run the script.

My question: Is there a way to remain in emacs and somehow run the script
without having to shell out?  Where can I find the documentation that
would explain this?

Thanks.

--
QOTD:
        "What women and psychologists call `dropping your armor', we call
        "baring your neck."

If you are writing Common Lisp, then what you need is slime.  It can be
found here.

http://common-lisp.net/project/slime/

It has a set of tools for writing, editing and running Common Lisp from
within Emacs (and lots more).  If you are using quicklisp (and if you
aren't using quicklisp, you should) you can get slime from there.

If you are writing Emacs Lisp then you should try M-x ielm.  To learn
how to use it start ielm (with M-x ielm) and then type '(describe-mode)'
for help.

Jason

1- read http://cliki.net/

2- you may use slime as advised.  However, that might be a tad
   overwhelming.  My advice is to start by using inferior-lisp.  Then
   when you start to write programs with more than half a dozen
   functions, switch to slime.

M-x customize-variable RET inferior-lisp-program RET
and enter the path of your choosen lisp implementation.
Eg.:  /usr/bin/clisp -ansi

Then type:

M-x inferior-lisp RET

C-x 3

C-x C-f /tmp/example.lisp RET

(+ 1 2) C-x C-e ; observe how the result is displayed in the
                ; inferior-lisp buffer.

(defun fact (x) (if (< x 1) 1 (* x (fact (1- x))))) C-x C-e

(fact 40) C-x C-e

etc.

Type C-h m in the .lisp buffer to see the inferior lisp specific key
bindings.

slime is a layer above inferior-lisp providing more sophisticated tools.
After a couple of weeks of learning Common Lisp, install slime and use
it to write your projects.

--
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

<snip>

Jason, thanks for that info.  I am using Common Lisp (GCL), and I think I
even have slime installed.  I'll have to see if I can find the man pages
for it.

I was going to try Emacs Lisp, but I figured I have enough to learn just
using emacs itself, without complicating it.

Thanks again.

--
Cheese -- milk's leap toward immortality.
                -- Clifton Fadiman, "Any Number Can Play"

<snip>

Thanks, Pascal.  I may just do that - if inferior-lisp has a gentler
learning curve, it might keep me from getting wholly lost.  Between lisp
and emacs, it's a handful.  Or maybe a brainful.  Whatever.

--
//GO.SYSIN DD *, DOODAH, DOODAH

Don't.  GCL is the worst CL implementation around.  It's hardly
maintained, and AFAIK it's not even fully compliant yet.

Check http://www.cliki.net/Common+Lisp+implementation
for a list of CL implementations.

Thanks to the standard, you can easily write CL conforming code that
will work equally well on the various CL implementations.  You may then
easily user several different implementations during the course of a
project developments, or for deploymnet.  Each CL implementation has
strong points.

My advice is to begin with GNU clisp, which has a nice stand alone
debugger (on non-compiled code).
http://www.cliki.net/TutorialClispDebugger

Later you may want to use ccl (strong on MacOSX), sbcl (strong on
generating fast code), or for more specialized uses, ecl (strong with C
and unix integration, also to embed into C applications), abcl (strong
with java), etc.  But most of those other implementations also require
slime, since their debuggers is not user friendly enough IMO.

http://common-lisp.net/project/slime/doc/html/

That said, emacs lisp is close enough to Common Lisp.  Learning Common
Lisp, you'll know enough to write emacs lisp code.  (Mostly, emacs lisp
is a subset of Common Lisp; there's also (require 'cl) to provide more
CL-like operators).  Of course, to write emacs lisp extensions, what
you'll need to learn is the emacs lisp editor library, in addition to
the language.  But this is done easily and progressively, thanks to the
introspective features of emacs.

--
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

That's very interesting, because GCL took up over 200 Meg of disk space.  
Not sure what it had - maybe lots of libraries?

This is very interesting.  I had no idea there were so many flavors of
common lisp - I thought it was just one, maybe two.

This should be very helpful.  I like it when there's a decent debugger,
because I tend to spend a lot of time there.

I've actually got sbcl on my computer.  I'll leave it for another day.

This is comforting, that elisp is a subset of common lisp.  I had been
concerned that it was a wholly different flavor that would require
learning even more new stuff.  I like a challenge, but I do have my
limits.

--
"To IBM, 'open' means there is a modicum of interoperability among some
of their
equipment."
                -- Harv Masterson

--
Tis man's perdition to be safe, when for the truth he ought to die.

By the way, there's a clall script:
http://paste.lisp.org/display/123280
http://git.informatimago.com/viewgit/index.php?a=viewblob&p=public/bi...

that you can use to run snippets on all the implementations you have
installed, so that you can easily see the differences.

Eg. the package-use-list of the cl-user package is implementation
dependant.  A conforming program should not depend on it.

$ clall -r '(package-use-list :cl-user)'

Armed Bear Common Lisp         --> (#<PACKAGE JAVA> #<PACKAGE EXTENSIONS> #<PACKAGE COMMON-LISP>)
Clozure Common Lisp            --> (#<Package "CCL"> #<Package "COMMON-LISP">)
CLISP                          --> (#<PACKAGE COMMON-LISP> #<PACKAGE EXT>)
CMU Common Lisp                --> (#<The EXTENSIONS package, 233/503 internal, 394/494 external>
                                    #<The COMMON-LISP package, 0/5 internal, 978/1227 external>)
ECL                            --> (#<"COMMON-LISP" package>)
SBCL                           --> (#<PACKAGE "COMMON-LISP">
                                    #<PACKAGE "SB-ALIEN"> #<PACKAGE "SB-DEBUG">
                                    #<PACKAGE "SB-EXT"> #<PACKAGE "SB-GRAY">
                                    #<PACKAGE "SB-PROFILE">)

========================================================================

Another example: this expression could be non-conforming (if we used the
result in a way that would lead to different results):

$ clall -r '(let ((x 1) (y 0)) (handler-case (/ x y) (error (err) (princ-to-string err))))'

Armed Bear Common Lisp         --> "Arithmetic error DIVISION-BY-ZERO signalled."
Clozure Common Lisp            --> "DIVISION-BY-ZERO detected"
CLISP                          --> "/: division by zero
"
CMU Common Lisp                --> "Arithmetic error DIVISION-BY-ZERO signalled.
Operation was KERNEL::DIVISION, operands (1 0)."
ECL                            --> "#<a DIVISION-BY-ZERO>"
SBCL                           --> "arithmetic error DIVISION-BY-ZERO signalled
Operation was SB-KERNEL::DIVISION, operands (1 0)."

========================================================================

But this one is conforming: you will get the same result on all
conforming implementation:

$ clall -r '(let ((x 1) (y 0)) (handler-case (/ x y) (division-by-zero () (quote division-by-zero))))'

Armed Bear Common Lisp         --> DIVISION-BY-ZERO
Clozure Common Lisp            --> DIVISION-BY-ZERO
CLISP                          --> DIVISION-BY-ZERO
CMU Common Lisp                --> DIVISION-BY-ZERO
ECL                            --> DIVISION-BY-ZERO
SBCL                           --> DIVISION-BY-ZERO

========================================================================

--
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

That's a cool script; very handy...

OTOH, I think most of what it offers is a bit beyond me at the moment.  
But I've got it handy just in case.

--
"You can't get very far in this world without your dossier being there
first."
                -- Arthur Miller

In article <8762dxw4l6....@kuiper.lan.informatimago.com>,
Pascal J. Bourguignon <p...@informatimago.com> wrote:

Outta say something about those new scoping rules that Sussman and IforgetWho
invented 30 or more years ago and created Scheme to use it with, and that
later, when Common Lisp was being decided etc, put it there too.

Too late at night for me to remember the name of the "scheme", but
Perl added it via its (sic) "local" variables.   AH -- dynamic binding,
that's what it's called.  Which Elisp doesn't have, being derived from
MacLisp thinking.

That was a long time ago.  Is what I remember actually a correct memory?

Thanks,

David

I think you've mixed a bit lexical and dynamic scoping (Perl "local"
is indeed dynamic scoping, but Scheme's novelty was lexical scoping,
which Common Lisp copied).

http://en.wikipedia.org/wiki/Lexical_scope#Lexical_scoping_and_dynami...

    Juanma

And to answer the question, elisp supports dynamic scoping, and support for
lexical scoping will be added in Emacs 24.1.

--
-PJ

Gehm's Corollary to Clark's Law: Any technology distinguishable from
magic is insufficiently advanced.

In article <mailman.444.1335122807.751.help-gnu-em...@gnu.org>,
PJ Weisberg  <pjweisb...@gmail.com> wrote:

WOW!

David