Running a lisp script

[Chiron]

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."

[Jason Earl]

On Wed, Mar 21 2012, Chiron wrote:

> 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?

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

[Pascal J. Bourguignon]

Chiron <chiron613.no.spam.@no.spam.please.gmail.com> writes:

> 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?

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 {}.

[Chiron]

On Wed, 21 Mar 2012 22:43:05 -0600, Jason Earl wrote:

<snip>

>
> 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

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"

[Chiron]

On Thu, 22 Mar 2012 06:28:12 +0100, Pascal J. Bourguignon wrote:

<snip>

>
> 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.

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

[Pascal J. Bourguignon]

Chiron <chiron613.no.spam.@no.spam.please.gmail.com> writes:

> On Wed, 21 Mar 2012 22:43:05 -0600, Jason Earl wrote:
>
> <snip>
>>
>> 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
>
> Jason, thanks for that info. I am using Common Lisp (GCL),

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.

> and I think I
> even have slime installed. I'll have to see if I can find the man pages
> for it.

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

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

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.

[Chiron]

On Thu, 22 Mar 2012 07:08:05 +0100, Pascal J. Bourguignon wrote:

>> Jason, thanks for that info. I am using Common Lisp (GCL),
>
> Don't. GCL is the worst CL implementation around. It's hardly
> maintained, and AFAIK it's not even fully compliant yet.
>

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

>
>
> 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.
>

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

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

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

> 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.

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

>
>
>
>> and I think I
>> even have slime installed. I'll have to see if I can find the man
>> pages for it.
>
> http://common-lisp.net/project/slime/doc/html/
>

Thank you.

>
>> I was going to try Emacs Lisp, but I figured I have enough to learn
>> just using emacs itself, without complicating it.
>
> 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.

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.

[Pascal J. Bourguignon]

Chiron <chiron613.no.spam.@no.spam.please.gmail.com> writes:

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

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/bin&h=3e45c94ed4db651943a6d3f3edd4e72f36e218e9&hb=e15ad2e48525a89b3b3f921a7557311194e07d36&f=clall

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

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

[Chiron]

On Thu, 22 Mar 2012 09:50:49 +0100, Pascal J. Bourguignon wrote:

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

[David Combs]

In article <8762dxw...@kuiper.lan.informatimago.com>,

Pascal J. Bourguignon <p...@informatimago.com> wrote:
>
>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). ...

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

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

[Juanma Barranquero]

On Sun, Apr 22, 2012 at 08:06, David Combs <dkc...@panix.com> wrote:

> 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?

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_dynamic_scoping

    Juanma

[PJ Weisberg]

On Sunday, April 22, 2012, Juanma Barranquero <lek...@gmail.com> wrote:
> On Sun, Apr 22, 2012 at 08:06, David Combs <dkc...@panix.com> wrote:
>

>> 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?
>

> 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).

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.

[David Combs]

In article <mailman.444.13351228...@gnu.org>,
PJ Weisberg <pjwei...@gmail.com> wrote:
>-=-=-=-=-=-

>-=-=-=-=-=-
>[Alternative: text/html]
>-=-=-=-=-=-

WOW!

David