From: Christian Hofer
Subject: Is Lisp more than another language?
Date:
Message-ID: <c8nai2$cu8$1@online.de>
The way I came to lisp was via the Squeak mailing lists: people were
crediting Lisp a lot for most of the ideas which seem to make
Smalltalk-80 unique. Now that I have played around with Lisp for a while
I get the impression: it's a really cool language, but it does not
deliver the environment that Squeak has. To be more precise: This
environment just seems to be hidden from the beginner. (Or have these
ideas really got lost during the Common Lisp standardization process?)
There is a cool book for learning Squeak from Mark Guzdial, Squeak.
Object-Oriented Design with Multimedia Applications. It has extensive
sections on tool use, exactly what I am missing from Lisp books. The
spirit of Squeak is, that it is more than a language: it is an
environment for developing ideas.
While the task of the book is easier because it has to handle only one
specific Smalltalk-80 implementation, I would very much appreciate an
introduction on how to use the Lisp language features like the debugger
(not just the small appendix in Graham's ACL), the ways to find methods
/ functions etc. - all these things that seem to be built into Lisp
but are not normally regarded as the "programming language", although
they make using the language much more productive. (Now, of course,
macros are part of it, but I mean the more fundamental things.)
It seems that even Peter Seibel's very interesting book is missing such
a section - but I didn't have time for a close look so far.
Let me give you an example: I tried to figure out how to do s.th. as
simple as setting a break point. Now I found a function "break". The
hyperspec says:
"break formats format-control and format-arguments and then goes
directly into the debugger without allowing any possibility of
interception by programmed error-handling facilities.
If the continue restart is used while in the debugger, break immediately
returns nil without taking any unusual recovery action."
This does not exactly tell a newbie like me, if this is the usual way to
set a breakpoint. To make it worse, in SLIME with SBCL this does not
open the SLIME debugger, but the SBCL one.
I hope you can understand what I mean.
Regards,
Chris
It sounds like you need a Lisp book with a friendly treatment of tools
such as break, trace, step, and time. One standard text is Winston
and Horn, "Lisp", 3rd ed. It has a chapter on these tools, with
enough information to get you started.
Christian Hofer <·······@gmx.de> wrote in message news:<············@online.de>...
> The way I came to lisp was via the Squeak mailing lists: people were
> crediting Lisp a lot for most of the ideas which seem to make
> Smalltalk-80 unique. Now that I have played around with Lisp for a while
> I get the impression: it's a really cool language, but it does not
> deliver the environment that Squeak has. To be more precise: This
> environment just seems to be hidden from the beginner. (Or have these
> ideas really got lost during the Common Lisp standardization process?)
>
> There is a cool book for learning Squeak from Mark Guzdial, Squeak.
> Object-Oriented Design with Multimedia Applications. It has extensive
> sections on tool use, exactly what I am missing from Lisp books. The
> spirit of Squeak is, that it is more than a language: it is an
> environment for developing ideas.
>
> While the task of the book is easier because it has to handle only one
> specific Smalltalk-80 implementation, I would very much appreciate an
> introduction on how to use the Lisp language features like the debugger
> (not just the small appendix in Graham's ACL), the ways to find methods
> / functions etc. - all these things that seem to be built into Lisp
> but are not normally regarded as the "programming language", although
> they make using the language much more productive. (Now, of course,
> macros are part of it, but I mean the more fundamental things.)
>
> It seems that even Peter Seibel's very interesting book is missing such
> a section - but I didn't have time for a close look so far.
>
> Let me give you an example: I tried to figure out how to do s.th. as
> simple as setting a break point. Now I found a function "break". The
> hyperspec says:
>
> "break formats format-control and format-arguments and then goes
> directly into the debugger without allowing any possibility of
> interception by programmed error-handling facilities.
>
> If the continue restart is used while in the debugger, break immediately
> returns nil without taking any unusual recovery action."
>
> This does not exactly tell a newbie like me, if this is the usual way to
> set a breakpoint. To make it worse, in SLIME with SBCL this does not
> open the SLIME debugger, but the SBCL one.
>
> I hope you can understand what I mean.
>
> Regards,
> Chris
Christian Hofer wrote:
> The way I came to lisp was via the Squeak mailing lists: people were
> crediting Lisp a lot for most of the ideas which seem to make
> Smalltalk-80 unique. Now that I have played around with Lisp for a while
> I get the impression: it's a really cool language, but it does not
> deliver the environment that Squeak has.
I tried to live with early versions of QKS SmalltalkAgents for the Mac,
so I think I know what you mean, and you are right, Lisp IDEs suck. That
was my first, uh, second reaction to Lisp, the first being that Lisp was
fucking awesome.
The good news is that in time you will have developed your own IDE, if
you will, of ways of to use Lisp to help you develop Lisp. As for the
IDEs, they vary. You would like AllegroCL on win32, which has "Set
Breakpoint" under the Run menu, shortcut F7, and just about everything
else you might be accustomed to under Squeak: Lisp editor, project
manager, class browser, GUI builder, etc, etc. This might be the one
Lisp IDE that can hold its own in a comparison with those of C++/Java.
Lispworks and MCL also offer nice IDEs.
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
From: Christian Hofer
Subject: Re: Is Lisp more than another language?
Date:
Message-ID: <c8oepm$id0$1@online.de>
Kenny Tilton wrote:
> The good news is that in time you will have developed your own IDE, if
> you will, of ways of to use Lisp to help you develop Lisp.
This is exactly what I was trying to express: it's not really a problem
that open source IDEs suck, as long as it is possible to develop one's
own IDE. I would like to have a description of the interiors of Lisp
that make this possible: the power that is contained in the possibility
to access the whole programming environment as I know it from Squeak.
But obviously - what I didn't know so far - the implementations are just
too different.
Thank you for your answers, they gave me a better impression of what
Lisp actually is and what it is not. Still, Lisp is the coolest and most
powerful language I have ever seen! (But this is what I first thought
when I saw Java, later when I saw Smalltalk, and maybe some time in the
future I will think that of Prolog or Oz or some other language - who knows)
My first goal is finishing SICP, maybe I get a better understanding then...
Chris
Christian Hofer <·······@gmx.de> wrote in message news:<············@online.de>...
> My first goal is finishing SICP, maybe I get a better understanding then...
SICP seems to be about every OTHER language than lisp. IIRC, access to
code-as-data is almost exclusively through the ' operator; macros are
only mentioned in a footnote which essentially warns people away from
them.
I still think SICP is one of the whoopass books, just that I remember
having a pretty anti-lisp conception of lisp after reading it. PLT
Scheme was a great IDE, but after writing a few Scheme programs, it
became clear how limited everything was. Fortunately, I soon tried
Common Lisp.
Scheme is the ultimate ontological attack against lisp.
Mind the two different sets of video lectures, if you haven't...
http://www.cliki.net/SICP
From: Rahul Jain
Subject: Re: Is Lisp more than another language?
Date:
Message-ID: <878yf7dfht.fsf@nyct.net>
Christian Hofer <·······@gmx.de> writes:
> I would like to have a description of the interiors of Lisp
> that make this possible: the power that is contained in the possibility
> to access the whole programming environment as I know it from Squeak.
Maybe the hardest part of answering this question is that the answer is
probably of no help at all. :)
What's inside of Lisp that lets you get at the insides is Lisp. Code is
data. Macros are functions that take in code (actually, arbitrary data)
as parameters and return code as the result.
It's one of those things where I can tell you the answer, but you'll
need to understand the answer before you ask the question for it to make
sense to you.
To get you on your way, try to look at introspective operators such as
the following:
SUBTYPEP
UPGRADED-ARRAY-ELEMENT-TYPE
DO-{ALL-,EXTERNAL-,}SYMBOLS
{COMPILER-,}MACROEXPAND{-1,}
COMPILEDP
CONSTANTP
CLASS-PRECEDENCE-LIST
BOUNDP
FBOUNDP
SLOT-BOUNDP
SYMBOL-VALUE
SYMBOL-FUNCTION
DOCUMENTATION
Also, the &environment arg to macros, but the behavior of environment
objects is not officially standardized. It was deemed too early to set
it in stone when the ANSI standard was being created, so that chapter
was removed. However, most implementations come close to CLtL2's spec
for them.
You can also use SYMBOL-PLIST or symbol-keyed hash-tables (preferably
weak-keyed, as well, if your implementation provides that) to associate
application-specific semantic information with symbols the same way that
variable, function, type, block, catch, and tag bindings are associated
with symbols by the lisp compiler.
In the MOP:
COMPUTE-APPLICABLE-METHOD
ADD-DEPENDENT
METHOD-SPECIALIZERS
METHOD-QUALIFIERS
MAKE-METHOD-LAMBDA
... There are many others, but you can start with those.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Christian Hofer wrote:
> The way I came to lisp was via the Squeak mailing lists: people were
> crediting Lisp a lot for most of the ideas which seem to make
> Smalltalk-80 unique. Now that I have played around with Lisp for a while
> I get the impression: it's a really cool language, but it does not
> deliver the environment that Squeak has. To be more precise: This
> environment just seems to be hidden from the beginner. (Or have these
> ideas really got lost during the Common Lisp standardization process?)
>
> There is a cool book for learning Squeak from Mark Guzdial, Squeak.
> Object-Oriented Design with Multimedia Applications. It has extensive
> sections on tool use, exactly what I am missing from Lisp books. The
> spirit of Squeak is, that it is more than a language: it is an
> environment for developing ideas.
Apparently, this used to be true in the case of Lisp Machines as well.
Note that Squeak is its own operating system, so to speak, that doesn't
care much about the platform that it runs on. The typical Common Lisp
implementation nowadays tries to deliver an environment in which you can
develop applications that integrate well with the existing
infrastructure. Note, however, that the ANSI standard is intentionally
agnostic in this respect.
> This does not exactly tell a newbie like me, if this is the usual way to
> set a breakpoint. To make it worse, in SLIME with SBCL this does not
> open the SLIME debugger, but the SBCL one.
IIUC, it's up to a CL vendor to spell out what debugging capabilities
exist in a specific implementation and how to use them. Note that SLIME
is a pretty new effort, so documentation is lacking at the moment.
Furthermore, all the environments for CL based on emacs / xemacs have to
deal with the fact that there is a gap between the development
environment and the CL implementation that needs to be crossed, and this
can lead to inconsistencies. A combination of emacs + Smalltalk would
suffer from similar problems, probably even more so.
It's a good idea to check out the (commercial) implementations that come
with environments that better integrate with CL because they are
implemented in the same language. They also come with documentation that
should help you to get your questions answered.
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
From: Christian Hofer
Subject: Re: Is Lisp more than another language?
Date:
Message-ID: <c8nd9o$i9l$1@online.de>
Pascal Costanza wrote:
> IIUC, it's up to a CL vendor to spell out what debugging capabilities
> exist in a specific implementation and how to use them. Note that SLIME
> is a pretty new effort, so documentation is lacking at the moment.
> Furthermore, all the environments for CL based on emacs / xemacs have to
> deal with the fact that there is a gap between the development
> environment and the CL implementation that needs to be crossed, and this
> can lead to inconsistencies. A combination of emacs + Smalltalk would
> suffer from similar problems, probably even more so.
Thank you for your answer, but I'm not yet quite convinced ;-)
When people are implementing s.th. as great as SLIME, they e.g. know how
to implement "Metapoint". I didn't have a look at this, but my
impression has been that - despite some differences between the
implementations - there are certain mechanisms built into Lisp that
ensure the working of such a tool. I.e. what I am missing is (although
my example maybe gave this impression) not so much descriptions of how a
certain specific environment works, but what the internal working of the
Lisp environments are: What is so special about symbols that allows Lisp
to be as flexible as it is compared to other languages? While there are
some some explanations in all books I have looked in so far, I would
appreciate, if exactly this aspect could be stressed more: There is
s.th. very special about Lisp (and it's not only macros!), and it has to
do with symbols and with the reason, why Lisp does not create usual
"stand-alone" applications. I admit that I could figure that probably
out myself in more detail if I found the time for it at the moment
(perhaps should just do this instead of spending my time with cll) - as
everyone else does. But if I didn't have come from Smalltalk, I maybe
had not realized this at all, and would have just asked: "And how do I
build a stand-alone application?"
Chris
Christian Hofer <·······@gmx.de> wrote in message news:<············@online.de>...
> I.e. what I am missing is (although
> my example maybe gave this impression) not so much descriptions of how a
> certain specific environment works, but what the internal working of the
> Lisp environments are: What is so special about symbols that allows Lisp
> to be as flexible as it is compared to other languages?
I think it is more that most languages don't allow you access to
"variable names," than some particularly impressive mojo on lisp's
part. Lisp seems like a repetition of one trick, which is the
self-interested opening up of the environment to the language user.
(As I understand, the traditional benchmark for this opening-up is
about increasing expressive power without reducing it in other useful
places. Which is likely why it's probably wrong to say CL is a dynamic
language, even if it currently happens to be more dynamic than most
languages out there. Also this might show where CL can no longer
evolve.)
> While there are
> some some explanations in all books I have looked in so far, I would
> appreciate, if exactly this aspect could be stressed more: There is
> s.th. very special about Lisp (and it's not only macros!), and it has to
> do with symbols and with the reason, why Lisp does not create usual
> "stand-alone" applications.
I recently noticed what a powerful idea it was, how lexical scope and
dynamic extent interacted. (A closure performing a 'nonlocal exit' to
a block or tagbody, say.) In comparison, my older epiphany about
syntactic abstraction seems trivial and immature in comparison. I
think lisp's control over syntax is this incredibly flashy thing which
doesn't fail in capturing peoples' imaginations, and it certainly is a
power multiplier, but lisp is not just about that.
> When people are implementing s.th. as great as SLIME, they e.g. know how
> to implement "Metapoint". I didn't have a look at this, but my
> impression has been that - despite some differences between the
> implementations - there are certain mechanisms built into Lisp that
> ensure the working of such a tool.
Maybe you can speak with the Slime developers about your ideas. If
these features are as trivial as you imply and would make the devs
happy, they'll probably bake it in. I suspect Slime is rather new...
Christian Hofer wrote:
> I.e. what I am missing is (although
> my example maybe gave this impression) not so much descriptions of how a
> certain specific environment works, but what the internal working of the
> Lisp environments are: What is so special about symbols that allows Lisp
> to be as flexible as it is compared to other languages?
I think I still don't completely understand what you mean, but you might
want to read the two following papers (which happen to be my two
favorite Lisp papers ;), in that order:
- Paul Graham, The Roots of Lisp, http://www.paulgraham.com/rootsoflisp.html
- Guy Steele, Gerald Sussman, The Art of the Interpreter,
http://library.readscheme.org/page1.html
Paul Graham's essays about Lisp, and Steele's and Sussman's "lambda
papers", give a good idea what Lisp is all about.
If you want to see how notions of metacircularity can be applied to
object-oriented programming, read the following material.
- Andreas Paepcke, User-Level Language Crafting,
http://www-db.stanford.edu/~paepcke/shared-documents/mopintro.ps
- Gregor Kiczales, Jim des Rivieres, Daniel Bobrow, The Art of the
Metaobject Protocol
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
Christian Hofer <·······@gmx.de> writes:
> I.e. what I am missing is [...] what the internal working of the
> Lisp environments are: What is so special about symbols that allows Lisp
> to be as flexible as it is compared to other languages?
What I find cool is the mix-match between symbols, lists and code.
In other languages, one can have only code in source files, so they
invent a different syntax for configuration files (e.g. XML or
line-based junk with ad hoc syntax). This is superfluous.
Consider the following mixture of symbols, lists and code:
(define my-schema-transformations
`(*default* . ,(lambda (tag . elems) (entagX tag elems)))
(*text* . ,(lambda (trigger str)
(if (string? str) (string->goodXML str) str)))
(*PI* *preorder*
. ,(lambda (tag target body)
(list "<?" target " " body "?>")))
(DocType *preorder*
. ,(lambda (tag . elems) ;TODO XMLSchema.dtd full URL
(list #\newline "<!DOCTYPE xs:schema PUBLIC \"-//W3C//DTD XMLSCHEMA 200102//EN\" \"XMLSchema.dtd\">")))
(*Schema *macro*
. ,(lambda (tag . elems)
`((*PI* "xml" "version='1.0' encoding='UTF-8'")
(DocType)
(xs:schema (@ (xmlns:xs "http://www.w3.org/2001/XMLSchema")
(xmlns:ds "http://www.w3.org/2000/09/xmldsig#"))
(comment "Stand 19. Dezember 2003")
,elems))))
(comment *macro*
. ,(lambda (tag . elems)
`(xs:annotation (xs:documentation ,elems))))
...)
You can freely use trees with mainly symbols to describe whatever you
wish. The above example comes from using SXML. Also, Oleg's SXPATH is
much more readable than XSLT junk.
> But if I didn't have come from Smalltalk, I maybe
> had not realized this at all, and would have just asked: "And how do I
> build a stand-alone application?"
In other languages, you can try to come close using dozens of
constructors, e.g. you must build up a linked datastructure. This
results in a somewhat functional or declarative style. E.g.,
here's some Python code from an unrelated application:
transAllgemein = TransAllgemein(0,
TransID(10000011,200011),74,
TerminalID(5,4,3),transZeit,
OrtID(11,77770,5011),65)
transFahrt = TransFahrt(transAllgemein,TransProdEfs(54),transFahrtDaten)
This remembers me of how many applications build up their X/windows
widgets/windows/elements.
Regards,
Jorg Hohle
Telekom/T-Systems Technology Center
Christian Hofer <·······@gmx.de> writes:
> It seems that even Peter Seibel's very interesting book is missing
> such a section - but I didn't have time for a close look so far.
And it's not done yet. I've yet to write my chapter on symbols (and
packages) which you asked about in another thread. Please do send any
comments about either what's there that you like or dislike or what's
not that you think should be.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Christian Hofer <·······@gmx.de> writes:
> This does not exactly tell a newbie like me, if this is the usual way to
> set a breakpoint. To make it worse, in SLIME with SBCL this does not
> open the SLIME debugger, but the SBCL one.
>
> I hope you can understand what I mean.
Having once struggled to learn how to use Lisp, then having used
Squeak, I'm pretty sure I know what it is you're asking. The
different Lisp implementations are too divergant to write a
newbie-friendly guide for what you want. However, the concepts are
similar, so we can all understand each other when a user of Lisp X
asks a user of Lisp Y, "how do you find the source form for <blank>".
To learn what to look for, you should focus on a particular
environment. The open source IDEs are in the process of catching up,
but right now are lightyears behind what you're used to. If you have
a Mac, I'd recommend getting MCL, otherwise try Allegro for Windows,
or LispWorks. They all have demo/personal versions available, and I
can vouch for the fact that MCL has the manual you're looking for,
"Getting Started with Macintosh Common Lisp."
If you're married to open source software, Hemlock (which runs in
CMUCL) still has the best documentation.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Christian Hofer
Subject: Re: Is Lisp more than another language?
Date:
Message-ID: <c8qfpa$odj$1@online.de>
Thomas F. Burdick wrote:
> Having once struggled to learn how to use Lisp, then having used
> Squeak, I'm pretty sure I know what it is you're asking. The
> different Lisp implementations are too divergant to write a
> newbie-friendly guide for what you want. However, the concepts are
> similar, so we can all understand each other when a user of Lisp X
> asks a user of Lisp Y, "how do you find the source form for <blank>".
>
> To learn what to look for, you should focus on a particular
> environment. The open source IDEs are in the process of catching up,
> but right now are lightyears behind what you're used to. If you have
> a Mac, I'd recommend getting MCL, otherwise try Allegro for Windows,
> or LispWorks. They all have demo/personal versions available, and I
> can vouch for the fact that MCL has the manual you're looking for,
> "Getting Started with Macintosh Common Lisp."
>
> If you're married to open source software, Hemlock (which runs in
> CMUCL) still has the best documentation.
>
Maybe I am more married to open source than I am ready to admit. But on
the other hand, when I first started with CL, people told me to get used
to Emacs. Now I am quite used to it and I hate to click around the
different Lispworks tabbed windows with the mouse. What is worse, it
does not offer an exact copy of the useful Emacs key bindings that are
offered by SLIME. I even don't know if it would run in Linux
compatibility mode on FreeBSD (my desktop OS - besides my iBook).
(Portable) Hemlock on the other hand didn't even recognize my German
keyboard and its umlauts.
Thus, I am quite happy with SLIME, but will probably have to use another
environment to better get acquainted to the available tools until I know
more of the Lisp internals.
Chris
From: Friedrich Dominicus
Subject: Re: Is Lisp more than another language?
Date:
Message-ID: <87d64vw2g4.fsf@fbigm.here>
Christian Hofer <·······@gmx.de> writes:
> Now I am quite used to it and I hate to click around
> the different Lispworks tabbed windows with the mouse. What is worse,
> it does not offer an exact copy of the useful Emacs key bindings that
> are offered by SLIME.
Well you know that you can "script" the editor. So what prevents you
from adding your favourite keyboard shortcuts?
> I even don't know if it would run in Linux
> compatibility mode on FreeBSD (my desktop OS - besides my
> iBook). (Portable) Hemlock on the other hand didn't even recognize my
> German keyboard and its umlauts.
I remember reading that there shouldn't be a problem. But do not have
the URL at hand.
Regards
Friedrich
--
Please remove just-for-news- to reply via e-mail.
According to Christian Hofer <·······@gmx.de>:
> I even don't know if [LispWorks Linux] would run in Linux
> compatibility mode on FreeBSD (my desktop OS - besides my iBook).
I have LWL 4.2 Personal running on my FreeBSD 4.9, with OpenMotif.
LWL 4.3 wants an updated OpenMotif and I haven't gotten around to doing
that.
--
Ng Pheng Siong <····@netmemetic.com>
http://firewall.rulemaker.net -+- Firewall Change Management & Version Control
http://sandbox.rulemaker.net/ngps -+- ZServerSSL/Zope Windows Installers
"Christian Hofer" <·······@gmx.de> wrote in message
·················@online.de...
> It seems that even Peter Seibel's very interesting book is missing such
> a section - but I didn't have time for a close look so far.
>
> Let me give you an example: I tried to figure out how to do s.th. as
> simple as setting a break point. Now I found a function "break". The
> hyperspec says:
>
> "break formats format-control and format-arguments and then goes
> directly into the debugger without allowing any possibility of
> interception by programmed error-handling facilities.
The lack of a readily available "How to USE CL" piece has been a lament of
mine for somekind.
There always seemed to be a large amount of folklore that buzzes in the
background about using Lisp, but very little written about it.
The kind of thing that were you working next to a Lisp Guru, he wouldn't
just be kibitzing your code or style, but also code layout, and tool use.
How often do you come up on a co-worker and see them struggling with some
process to which you know a much easier way? Then, perhaps you might chime
in with how to do it the better way.
For me, this is a key motivation behind Lisp In A Box, particularly for
someone like Peter, because it will give him a reasonably consistent and
portable laboratory on which he can describe not just CL language elements
and syntax, but also package layout, interaction with Emacs and how
SLIME/ILISP/etc interface and interact with CL to make both easier and more
powerful.
This kind of thing, if nothing else, gives readers a baseline for when they
move on to another environment. "In LIAB, I could do X by doing Y. How can I
do the same thing in QED Lisp?". With several implementations, it can't be
expected the book authors go into detail about using the system. But with a
readily available, portable, and painless to install system, a book author
could easily leverage that.
I'm sure for many features, Allegro, LW and MCL overlap, but for new people
who simply have no exposure to those features, they simply may not know what
they're missing, or write some feature off as less important than it sounds.
Regards,
Will Hartung
(·····@msoft.com)
"Will Hartung" <·····@msoft.com> writes:
> The kind of thing that were you working next to a Lisp Guru, he wouldn't
> just be kibitzing your code or style, but also code layout, and tool use.
...
> For me, this is a key motivation behind Lisp In A Box, particularly for
> someone like Peter, because it will give him a reasonably consistent and
> portable laboratory on which he can describe not just CL language elements
> and syntax, but also package layout, interaction with Emacs and how
> SLIME/ILISP/etc interface and interact with CL to make both easier and more
> powerful.
I only got off the ground with Lisp (if I am indeed off the ground)
because of the existence of SLIME. I may have been able to get off
the ground sooner if I switched to Debian Linux sooner than I did
(from a different Linux distro). But that's debatable because by the
time I switched over to Debian, I was too busy with other things to
deal with Lisp.
Now that I am working on picking up Lisp, I have other obstacles.
Even with a high quality environment, I have no personal contact with
any Lispers. Everyone I know thinks Lisp is a dead language and is
either playing with Java, Perl, or (in one odd case) Ada.
That leaves me with the Internet as my only support mechanism. I
can't watch people's workflow over the Internet.
Another requirement I have is a uniform environment between Mac OS X
and Linux. I use both and don't want to have to deal with different
key bindings or anything else that adds to what I need to learn. The
learning curve is steep enough for me thank you very much. Emacs +
Slime to the rescue again! The carbon build of Emacs I have from CVS
+ Slime from CVS gives me an almost identical look and feel with Emacs
from Debian + Slime from CVS.
I also got uControl for my Mac so I could map the caps lock key to the
ctrl function.
So what am I left with? The hump I needed to get over to start
mucking about with Lisp was sufficiently lowered for /me/. I can't
speak for others. I can now poke around the Hyperspec and enter code
into a lisp buffer (not just the repl) in Slime and play around with
it. I even noticed this evening (doing a C-h b in the lisp buffer)
that there are key bindings to toggle trace/untrace of a function in
Slime. I'll have to try those. But so far I've been mostly on my own
working out an efficient workflow so that the tools are working with
me to help me with Lisp.
I think the workflow issue is very important. I expect a lot of
potential neo-lispers are like me in that they have no one looking
over their shoulder as they do stuff. I also expect there are plenty
of people like me who do not want to go through C-h t or read the
entire Emacs manual. I actually don't care to have to learn any ELisp
as well. ANSI Common Lisp is big enough.
LIAB can really help with this. It is also possible that people may
be better served by the trial versions of LW and Alegro. I'm
something of a FOSSite, so I went the Free route even though it also
ment a steeper climb. Free is not without cost ;-).
I don't know how much lead time Peter has before his book is cast in
camera copy, but a workflow appendix would probably be a very good
thing. Workflow should not be considered an advanced topic either.
Dealing with the debugger, for example, is something that is likely to
come up very early on. So far, my main goal has been to get out of
the debugger.
Norvig's PAIP has some stuff related to that in Part III. But it
already assumes some reasonable amount of knowledge. Norvig is
talking about program efficiency, not programmer efficiency.
With LIAB, one can get very specific about workflow. But it would be
nice to have good coverage of a broad subset of things lispers do to
produce working code. I can't imagine that some of the more complex
macro examples I have seen were conceived fully formed. Functions
less trivial than (fib n) probably also go through a code test recode
cycle. All that involves working with the tools and with Lisp's own
built in facilities to get the job done.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
David Steuber <·····@david-steuber.com> writes:
> I only got off the ground with Lisp (if I am indeed off the ground)
> because of the existence of SLIME.
Can you say why? I'm curious, because for me it would be
the opposite. Having to learn an IDE tool like SLIME
would be an obstacle.
> I think the workflow issue is very important.
That makes me wonder too: when did "workflow" start being
a word that was used in such contexts? (And when did it
start being a word?)
[This is not a criticism of you. I work on workflow
tools these days. I'm just wondering where this way
of thinging entered the picture and when.]
> I can't imagine that some of the more complex
> macro examples I have seen were conceived fully formed. Functions
> less trivial than (fib n) probably also go through a code test recode
> cycle. All that involves working with the tools and with Lisp's own
> built in facilities to get the job done.
It's not necessary to do anything very elaborate. Lisp
probably has less need for fancy IDEs than most languages.
-- jd
Jeff Dalton <····@todday.inf.ed.ac.uk> writes:
> David Steuber <·····@david-steuber.com> writes:
>
> > I only got off the ground with Lisp (if I am indeed off the ground)
> > because of the existence of SLIME.
>
> Can you say why? I'm curious, because for me it would be
> the opposite. Having to learn an IDE tool like SLIME
> would be an obstacle.
Well it's nice to use an editor for code. But what's really nice is
that SLIME gives you a repl buffer as well as a code buffer. You can
play with things in the repl. But what I really like is that in the
code buffer, I can do things like C-c C-c to compile a function or
macro definiton, C-x C-e to eval an expression, C-c RET to see a
macroexpand-1, etc. The repl is there, but the need to use it is
greatly diminished.
There are other cool things like autodoc-mode that show hints in the
mini buffer for function/macro arguments. You can lookup symbols at
the point in the CLHS.
Everything is made easier.
> > I think the workflow issue is very important.
>
> That makes me wonder too: when did "workflow" start being
> a word that was used in such contexts? (And when did it
> start being a word?)
I got contaminated by this at my last job. I had to design and
implement a workflow system for a website. At the time, I had no idea
what the heck one of those things was.
> [This is not a criticism of you. I work on workflow
> tools these days. I'm just wondering where this way
> of thinging entered the picture and when.]
Work. Flow. I don't know.
It seems like a reasonable way to describe the process of development
though.
> > I can't imagine that some of the more complex
> > macro examples I have seen were conceived fully formed. Functions
> > less trivial than (fib n) probably also go through a code test recode
> > cycle. All that involves working with the tools and with Lisp's own
> > built in facilities to get the job done.
>
> It's not necessary to do anything very elaborate. Lisp
> probably has less need for fancy IDEs than most languages.
One other thing I like is being able to doodle in the editor and use a
simple key chord to see if the code will compile and run. I can stick
litle test forms after the functions I've just compiled to see if I
get what I'm hoping for.
I'm still learning the language, so I find all this incredibly useful.
I expect that next to Xcode, Visual Studio .NET, etc, many people
won't think of Emacs + SLIME as a fancy IDE. Underneath that text
interface though is some cool stuff.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
David Steuber <·····@david-steuber.com> writes:
> C-c RET to see a macroexpand-1, etc.
Why do you (and Emacs) talk about it as C-c RET when C-c C-m is
actually mnemonic? I suppose you do it because Emacs does, but
that's no excuse for things like Emacs's manual using C-x RET for the
Mule bindings....
--
Alan Shutko <···@acm.org> - I am the rocks.
Alan Shutko <···@acm.org> writes:
> David Steuber <·····@david-steuber.com> writes:
>
> > C-c RET to see a macroexpand-1, etc.
>
> Why do you (and Emacs) talk about it as C-c RET when C-c C-m is
> actually mnemonic? I suppose you do it because Emacs does, but
> that's no excuse for things like Emacs's manual using C-x RET for the
> Mule bindings....
When I was in SLIME's Lisp buffer, I did C-h b to see what key
bindings were available to me. C-c RET was listed next to
slime-macroexpand-1. That is why I talk about it that way.
I actually have not memorized the ctrl chars for given keys like RET
and so forth. Also, when possible, I prefer to press one key rather
than two.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
David Steuber <·····@david-steuber.com> writes:
> Also, when possible, I prefer to press one key rather than two.
For me, C-c C-m is easier, because I depress Control and whack c and
m. C-c RET would involve pressing control, hitting c, releasing
control, and hitting ret.
--
Alan Shutko <···@acm.org> - I am the rocks.
Try Megumi Bears--the snack that bites YOUR head off!
David Steuber <·····@david-steuber.com> writes:
> Jeff Dalton <····@todday.inf.ed.ac.uk> writes:
>
> > David Steuber <·····@david-steuber.com> writes:
> >
> > > I only got off the ground with Lisp (if I am indeed off the ground)
> > > because of the existence of SLIME.
> >
> > Can you say why? I'm curious, because for me it would be
> > the opposite. Having to learn an IDE tool like SLIME
> > would be an obstacle.
>
> Well it's nice to use an editor for code. But what's really nice is
> that SLIME gives you a repl buffer as well as a code buffer.
Emacs can do that for you: run your Lisp in a shell buffer.
Your REPL is there, and you use other buffers for editing files.
Here are some obstacles to using SLIME:
* It works with only some Common Lisps.
* It looks like you're supposed to get it from the CVS
repository rather than just grabbing a tar file from a URL.
* The web page http://common-lisp.net/project/slime/
currently doesn't work, and that's the site the obvious
Google search gives you and the one linked from Cliki.
* You then have to learn the various commands and key
bindings.
> You can play with things in the repl. But what I really like is
> that in the code buffer, I can do things like C-c C-c to compile
> a function or macro definiton, C-x C-e to eval an expression,
> C-c RET to see a macroexpand-1, etc. The repl is there, but
> the need to use it is greatly diminished.
Ok, but those sound more like habits you'd get into
after you'd been using SLIME for a while, rather than
things that would get you off the ground with Lisp.
Were you used to having an IDE for other languages before
you started using Lisp?
-- jd
Jeff Dalton <····@todday.inf.ed.ac.uk> writes:
> * It works with only some Common Lisps.
Pretty much every popular one.
> * It looks like you're supposed to get it from the CVS
> repository rather than just grabbing a tar file from a URL.
There's also a nightly tarball you would have noticed if...
> * The web page http://common-lisp.net/project/slime/
> currently doesn't work, and that's the site the obvious
> Google search gives you and the one linked from Cliki.
common-lisp.net hadn't been down due to an intrusion. Shame.
> * You then have to learn the various commands and key
> bindings.
True, but many of them are just what you would expect from Emacs.
M-., C-x C-e, C-M-x, etc.
> Ok, but those sound more like habits you'd get into
> after you'd been using SLIME for a while, rather than
> things that would get you off the ground with Lisp.
Not necessarily, but it helps to have played with Emacs Lisp.
--
Alan Shutko <···@acm.org> - I am the rocks.
Jeff Dalton <····@todday.inf.ed.ac.uk> writes:
> David Steuber <·····@david-steuber.com> writes:
>
> > Well it's nice to use an editor for code. But what's really nice is
> > that SLIME gives you a repl buffer as well as a code buffer.
>
> Emacs can do that for you: run your Lisp in a shell buffer.
> Your REPL is there, and you use other buffers for editing files.
I've never liked Emacs's shell buffer. I just couldn't get into it.
Besides, if the shell buffer did everything just as well as SLIME,
there would be no SLIME. I also doubt there would be an ILISP or any
of the other customized Lisp modes.
> Here are some obstacles to using SLIME:
>
> * It works with only some Common Lisps.
True. But it works with the Lisps I use and gives me a consistent
(mostly) interface to the Lisps I have on hand.
> * It looks like you're supposed to get it from the CVS
> repository rather than just grabbing a tar file from a URL.
That is the prefered method. If you have CVS it is actually easier
than a tarball. That said, a tarball is available.
> * The web page http://common-lisp.net/project/slime/
> currently doesn't work, and that's the site the obvious
> Google search gives you and the one linked from Cliki.
Others have addressed this point. If you are interested in looking at
SLIME, I have made a tarball of my latest CVS update and made it
available here:
http:///www.david-steuber.com/~david/Lisp/USUG/slime-snapshot.tar.gz
It's from 22 May at approximatly 22:26 EST.
> * You then have to learn the various commands and key
> bindings.
I have to do that for Emacs anyway. Or Vi. Or any other editor on
Earth.
> > You can play with things in the repl. But what I really like is
> > that in the code buffer, I can do things like C-c C-c to compile
> > a function or macro definiton, C-x C-e to eval an expression,
> > C-c RET to see a macroexpand-1, etc. The repl is there, but
> > the need to use it is greatly diminished.
>
> Ok, but those sound more like habits you'd get into
> after you'd been using SLIME for a while, rather than
> things that would get you off the ground with Lisp.
>
> Were you used to having an IDE for other languages before
> you started using Lisp?
Yes. I got spoiled by IDEs early in life. I never did learn to write
a makefile or use GDB from the command line.
To be honest, I would sorely miss not being able to evaluate
expressions from inside my Lisp buffer. That is so much nicer than
pasting code into the repl and evaluating it there. Why switch
buffers when you don't have to?
If I had to, I suppose I could go with a bare naked Lisp. At least
CLISP has readline support in its repl to make it less hostile. But
there would still be a bunch of copy-paste going on.
I don't even know how to describe the joy in being able to do C-c RET
to see a macroexpand-1 of a form. I never have to type out the
macroexpand-1 form again just to see how a macro I'm working on will
expand. Of coure, nothing stops me from writing that form and doing
C-x C-e on it which is exactly what I was doing before I learned about
C-c RET.
SLIME really has been of great help to me. It makes Lisp more
interactive. I bet the Python folks would enjoy having SPIME ;-)
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
Jeff Dalton wrote:
> * It works with only some Common Lisps.
Yep, and Visual C++ only works with C++. I don't consider this a problem;
it's just what it's designed for.
> * It looks like you're supposed to get it from the CVS
> repository rather than just grabbing a tar file from a URL.
>
This is an advantage for me. I like having the latest code, and with CVS
it's as simple as doing a "cvs up"; the next time I load Slime it'll
recompile itself automatically.
I used to think that Lisp's system definiton facilities were hopelessly
complex, but the fact that it can do this makes up for it. (And it's
still simpler than autoconf. :)
> * The web page http://common-lisp.net/project/slime/
> currently doesn't work, and that's the site the obvious
> Google search gives you and the one linked from Cliki.
>
Unfortunate, that. Imagine if we could trust people...
> * You then have to learn the various commands and key
> bindings.
>
True, but not a *large* problem. It's worth it, and there are menus while
I'm learning.
>> You can play with things in the repl. But what I really like is
>> that in the code buffer, I can do things like C-c C-c to compile
>> a function or macro definiton, C-x C-e to eval an expression,
>> C-c RET to see a macroexpand-1, etc. The repl is there, but
>> the need to use it is greatly diminished.
>
> Ok, but those sound more like habits you'd get into
> after you'd been using SLIME for a while, rather than
> things that would get you off the ground with Lisp.
>
> Were you used to having an IDE for other languages before
> you started using Lisp?
I wish.
No, I was used to the edit-compile-run cycle; I still do it, but now that
I know there's something better I'm bitter about it.
Jeff Dalton <····@todday.inf.ed.ac.uk> wrote:
> * The web page http://common-lisp.net/project/slime/
> currently doesn't work, and that's the site the obvious
> Google search gives you and the one linked from Cliki.
This is a temporary outage due to the attack on common-lisp.net, not
a Slime issue. I know you didn't claim it was, but just to keep things
clear...
Cheers,
-- Nikodemus "Not as clumsy or random as a C++ or Java.
An elegant weapon for a more civilized time."
Greetings!
Jeff Dalton <····@todday.inf.ed.ac.uk> writes:
> David Steuber <·····@david-steuber.com> writes:
>
> > Jeff Dalton <····@todday.inf.ed.ac.uk> writes:
> >
> > > David Steuber <·····@david-steuber.com> writes:
> > >
> > > > I only got off the ground with Lisp (if I am indeed off the ground)
> > > > because of the existence of SLIME.
> > >
> > > Can you say why? I'm curious, because for me it would be
> > > the opposite. Having to learn an IDE tool like SLIME
> > > would be an obstacle.
> >
> > Well it's nice to use an editor for code. But what's really nice is
> > that SLIME gives you a repl buffer as well as a code buffer.
>
> Emacs can do that for you: run your Lisp in a shell buffer.
> Your REPL is there, and you use other buffers for editing files.
>
> Here are some obstacles to using SLIME:
>
> * It works with only some Common Lisps.
>
Well I guess you mean GCL here. It is my intention to get this
working right after 2.6.2 is released. It is not difficult, and we've
already had some helpful feedback from the SLIME developers.
2.6.2 is just wrapping up its release-quality regression tests right
now, and its looking quite good. Several new platforms, significant
performance improvements, greatly enhanced windows port, maxima, acl2,
and axiom across the board, (pc-)nqthm, plus an effectively infinite
(as far as can be discerned at present :-) error free rate on Paul's
random compiler 'torture' tester.
The first item of business for 2.7.0 is to clear the remaining ansi
compliance issues in the new ansi build.
Take care,
> * It looks like you're supposed to get it from the CVS
> repository rather than just grabbing a tar file from a URL.
>
> * The web page http://common-lisp.net/project/slime/
> currently doesn't work, and that's the site the obvious
> Google search gives you and the one linked from Cliki.
>
> * You then have to learn the various commands and key
> bindings.
>
> > You can play with things in the repl. But what I really like is
> > that in the code buffer, I can do things like C-c C-c to compile
> > a function or macro definiton, C-x C-e to eval an expression,
> > C-c RET to see a macroexpand-1, etc. The repl is there, but
> > the need to use it is greatly diminished.
>
> Ok, but those sound more like habits you'd get into
> after you'd been using SLIME for a while, rather than
> things that would get you off the ground with Lisp.
>
> Were you used to having an IDE for other languages before
> you started using Lisp?
>
> -- jd
--
Camm Maguire ····@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Jeff Dalton wrote:
> David Steuber <·····@david-steuber.com> writes:
>
>> I only got off the ground with Lisp (if I am indeed off the ground)
>> because of the existence of SLIME.
>
> Can you say why? I'm curious, because for me it would be
> the opposite. Having to learn an IDE tool like SLIME
> would be an obstacle.
It was the same for me, actually; I started with ilisp, but gravitated
towards Slime fairly quickly.
In either case it was anything but an obstacle; the IDE gives me better
debugging capabilities, automatic indentation, *editing* capabilities,
and so on and so forth repeating itself redundantly without
end /ad/ /infinitum/. [1]
The alternative is (was) to work with the raw REPL, what you get when
typing 'sbcl' at the command line. Sure, that's still better than what
you get with Python (mostly) or Java (definitely), but Lisp is supposed
to be beyond that.
Slime is a large part of what makes Lisp the best language for me. More to
the point: I already knew Emacs, and Slime doesn't get in the way (a lot
[2]. I don't need to use its features if I don't want to.
>> I think the workflow issue is very important.
>
> That makes me wonder too: when did "workflow" start being
> a word that was used in such contexts? (And when did it
> start being a word?)
>
> [This is not a criticism of you. I work on workflow
> tools these days. I'm just wondering where this way
> of thinging entered the picture and when.]
What does workflow mean for you?
For me, in Java, it's
edit-compile-run-insert_print_statements-compile-run-repeat. I never
*did* find a debugger I liked; Eclipse might make things better, but I'm
too lazy to learn it right now.
In Lisp, I can do... well, anything I want. I've yet to think of anything
that would be good for debugging that Lisp/Slime doesn't already do.
>> I can't imagine that some of the more complex
>> macro examples I have seen were conceived fully formed. Functions
>> less trivial than (fib n) probably also go through a code test recode
>> cycle. All that involves working with the tools and with Lisp's own
>> built in facilities to get the job done.
>
> It's not necessary to do anything very elaborate. Lisp
> probably has less need for fancy IDEs than most languages.
>
Yes, because of the REPL; yet, as mentioned, Slime doesn't get in the way;
you can treat it as nothing but an enhanced REPL if you like.
--
1: My newsreader uses cursive for this, and similar for other decorations.
Does yours? Can I rely on it, these days?
2: I want to put (declare (optimize debug)) in .sbclrc, but it doesn't
work. Please help me?
In article <····················@news2.e.nsc.no>,
Svein Ove Aas <··············@brage.info> wrote:
>Jeff Dalton wrote:
>> Can you say why? I'm curious, because for me it would be
>> the opposite. Having to learn an IDE tool like SLIME
>> would be an obstacle.
>
>The alternative is (was) to work with the raw REPL, what you get when
>typing 'sbcl' at the command line. Sure, that's still better than what
>you get with Python (mostly) or Java (definitely), but Lisp is supposed
>to be beyond that.
No, no. The alternative is to work in your favorite editor (which you
already know), set up a build script to automate compilation of your
program, and then run it.
That's how I worked in Java until I went to the trouble of
familiarizing myself with NetBeans; it's how I worked in .NET until I
went to the trouble of using Visual Studio; it's how I worked in Perl
at all times; and it's how I'm working in Lisp until I go to the
trouble of learning SLIME. (Of course, since my preferred editor is
Emacs, the learning curve shouuld be rather shorter, here.)
>> It's not necessary to do anything very elaborate. Lisp
>> probably has less need for fancy IDEs than most languages.
>>
>Yes, because of the REPL; yet, as mentioned, Slime doesn't get in the way;
>you can treat it as nothing but an enhanced REPL if you like.
I don't see how the REPL has a thing to do with IDEs. The point of an
IDE is to be (as the name indicates) an integrated development
environment, to bring together all (or, at least, most of) the tools
you normally use -- the editor, the compiler, the build configuration
stuff, the debugger, the version control, the resource editors, the
unit test runners -- in one place, working in a single interface. The
REPL doesn't do anything toward integrating those tools.
--
Mike Kozlowski
http://www.klio.org/mlk/
Mike Kozlowski wrote:
[Svein Ove Aas:]
>> Yes, because of the REPL; yet, as mentioned, Slime doesn't get in the way;
>> you can treat it as nothing but an enhanced REPL if you like.
[Mike:]
> I don't see how the REPL has a thing to do with IDEs. The point of an
> IDE is to be (as the name indicates) an integrated development
> environment, to bring together all (or, at least, most of) the tools
> you normally use -- the editor, the compiler, the build configuration
> stuff, the debugger, the version control, the resource editors, the
> unit test runners -- in one place, working in a single interface. The
> REPL doesn't do anything toward integrating those tools.
I suppose it depends on what you think the process of
"development" is. For me, an interactive command line --
a REPL -- *is* a key development tool, in any language
that has one. The "command line" bit isn't absolutely
essential here; something like a Smalltalk environment
(have a play with Squeak if you never have) would do
too even though what it provides isn't exactly a
command line :-). But the ability to interact directly
with the system is an amazingly helpful development
tool, and I miss it enormously when I'm writing software
in a language (implementation) that lacks that ability.
So, for me, the REPL has as much to do with IDEs as
the debugger, the class browser, or the compiler.
--
Gareth McCaughan
.sig under construc
>>>>> "Svein" == Svein Ove Aas <··············@brage.info> writes:
Svein> It was the same for me, actually; I started with ilisp, but
Svein> gravitated towards Slime fairly quickly.
Svein> In either case it was anything but an obstacle; the IDE
Svein> gives me better debugging capabilities, automatic
Svein> indentation, *editing* capabilities, and so on and so forth
Svein> repeating itself redundantly without end /ad/
Svein> /infinitum/. [1]
Svein> The alternative is (was) to work with the raw REPL, what
Svein> you get when typing 'sbcl' at the command line. Sure,
Svein> that's still better than what you get with Python (mostly)
Svein> or Java (definitely), but Lisp is supposed to be beyond
Svein> that.
Svein> Slime is a large part of what makes Lisp the best language
Svein> for me. More to the point: I already knew Emacs, and Slime
Svein> doesn't get in the way (a lot [2]. I don't need to use its
Svein> features if I don't want to.
[ some bits removed ]
What I'm finding rather nice, along with the rest of the goodies, is
that Slime works nicely to provide a more portable work
environment. What I do at home with Linux and SBCL looks the same in
many ways at work, with Windows and Clisp. Sure, there are
differences, but the basic environment is close enough.
The ease of introduction has allowed me to slide a little Lisp into my
own work day, quickly enough not to prod anyone to ask why I'm
spending time on it. :)
--
"Facts are stubborn, but statistics are more pliable."
- Mark Twain
Svein Ove Aas <··············@brage.info> writes:
> Jeff Dalton wrote:
>
> > David Steuber <·····@david-steuber.com> writes:
> >
> >> I only got off the ground with Lisp (if I am indeed off the ground)
> >> because of the existence of SLIME.
> >
> > Can you say why? I'm curious, because for me it would be
> > the opposite. Having to learn an IDE tool like SLIME
> > would be an obstacle.
>
> It was the same for me, actually; I started with ilisp, but gravitated
> towards Slime fairly quickly.
>
> In either case it was anything but an obstacle; the IDE gives me better
> debugging capabilities, automatic indentation, *editing* capabilities,
> and so on and so forth repeating itself redundantly without
> end /ad/ /infinitum/. [1]
Emacs with a suitable Lisp-editing mode gives you automatic
indentation, and editing. Lisp systems have step and trace
and backtrace built-in. You can also run your Lisp in an
Emacs shell buffer, thus making it easy to edit commands
as you type them in and to repeat commands.
You get a lot without having to work out how to install and
use an IDE tool.
(I used to use ILISP and even adapted it to some Lisps
that it didn't already support, so I thought it was
worth a fair amount of trouble. But if I'd needed
to work out how to use ILISP before I could do much
with Lisp, it would have been an obstacle.)
> In Lisp, I can do... well, anything I want. I've yet to think of
> anything that would be good for debugging that Lisp/Slime doesn't
> already do.
I've written additional debugging tools for some systems,
built-in tools weren/t sufficient. Fortunately, Lisp
makes it easy to do that.
-- jd
Svein Ove Aas <··············@brage.info> writes:
...
> 2: I want to put (declare (optimize debug)) in .sbclrc, but it doesn't
> work. Please help me?
You can only use DECLARE at the beginning of certain forms. If you
want a global declaration in your .sbclrc, you should probably use
PROCLAIM. (proclaim '(optimize debug)), I think.
--
-Tim
<···@tenkan.org> wrote:
>Svein Ove Aas <··············@brage.info> writes:
>> 2: I want to put (declare (optimize debug)) in .sbclrc, but it doesn't
>> work. Please help me?
>
>You can only use DECLARE at the beginning of certain forms. If you
>want a global declaration in your .sbclrc, you should probably use
>PROCLAIM. (proclaim '(optimize debug)), I think.
I don't think that'll work either. SBCL resets the compiler policy
back to it's original value when it finishes loading a file. So a
proclamation made in .sbclrc would only be visible in files loaded
directly from .sbclrc.
--
Juho Snellman
Tim Daly Jr. wrote:
>
> Svein Ove Aas <··············@brage.info> writes:
> ...
>> 2: I want to put (declare (optimize debug)) in .sbclrc, but it doesn't
>> work. Please help me?
>
> You can only use DECLARE at the beginning of certain forms. If you
> want a global declaration in your .sbclrc, you should probably use
> PROCLAIM. (proclaim '(optimize debug)), I think.
>
Of course, I used declaim, not declare; sorry.
Well, declaim didn't work. I'll try proclaim.
(Does this mean that Slime will get compiled with maximum debugging,
though? Is there a way around that?)
From: Duane Rettig
Subject: Re: Is Lisp more than another language?
Date:
Message-ID: <4k6ywczzh.fsf@franz.com>
Svein Ove Aas <··············@brage.info> writes:
> Tim Daly Jr. wrote:
>
> >
> > Svein Ove Aas <··············@brage.info> writes:
> > ...
> >> 2: I want to put (declare (optimize debug)) in .sbclrc, but it doesn't
> >> work. Please help me?
> >
> > You can only use DECLARE at the beginning of certain forms. If you
> > want a global declaration in your .sbclrc, you should probably use
> > PROCLAIM. (proclaim '(optimize debug)), I think.
> >
> Of course, I used declaim, not declare; sorry.
>
> Well, declaim didn't work. I'll try proclaim.
> (Does this mean that Slime will get compiled with maximum debugging,
> though? Is there a way around that?)
The declaim/proclaim pair is another of those terrible :-)
macro/functional interface pairs, which do similar things.
One is a macro and its arguments will not be evaluated, and one
is functional and thus its arguments will be evaluated. You
can do (pprint (macroexpand '(declaim (optimize debug)))) to
see how it is implemented. It likely has at least one eval-when
component in it.
If you want the optimize quality to stick, try
(eval-when (compile load eval)
(proclaim '(optimize debug)))
That _might_ work, depending on your implementation. This form
with either proclaim or declaim would certainly work this way
in Allegro CL.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Svein Ove Aas <··············@brage.info> writes:
> Tim Daly Jr. wrote:
>
>>
>> You can only use DECLARE at the beginning of certain forms. If you
>> want a global declaration in your .sbclrc, you should probably use
>> PROCLAIM. (proclaim '(optimize debug)), I think.
>>
> Of course, I used declaim, not declare; sorry.
>
> Well, declaim didn't work. I'll try proclaim.
> (Does this mean that Slime will get compiled with maximum debugging,
> though? Is there a way around that?)
If proclaim didn't work, then declaim won't either. It is
likely that the problem is that the effect(s) of proclaim/declaim only
extends to the file they're in.
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
From: Christophe Rhodes
Subject: Re: Is Lisp more than another language?
Date:
Message-ID: <sqvfigx3g9.fsf@cam.ac.uk>
Raymond Wiker <·············@fast.no> writes:
> Svein Ove Aas <··············@brage.info> writes:
>
>> Tim Daly Jr. wrote:
>>
>>>
>>> You can only use DECLARE at the beginning of certain forms. If you
>>> want a global declaration in your .sbclrc, you should probably use
>>> PROCLAIM. (proclaim '(optimize debug)), I think.
>>>
>> Of course, I used declaim, not declare; sorry.
>>
>> Well, declaim didn't work. I'll try proclaim.
>> (Does this mean that Slime will get compiled with maximum debugging,
>> though? Is there a way around that?)
>
> If proclaim didn't work, then declaim won't either. It is
> likely that the problem is that the effect(s) of proclaim/declaim only
> extends to the file they're in.
While we're on the subject: what are user expectations of compiling
and loading a file that looks like
(declaim (optimize debug))
(defun foo ...)
(defun bar ...)
[...]
? Specifically, what would people expect the value of the DEBUG
quality to be after loading this file?
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes <·····@cam.ac.uk> writes:
> While we're on the subject: what are user expectations of compiling
> and loading a file that looks like
>
> (declaim (optimize debug))
>
> (defun foo ...)
> (defun bar ...)
> [...]
> ? Specifically, what would people expect the value of the DEBUG
> quality to be after loading this file?
Speaking for myself, I would expect the optimization settings
to be reset to what they were before the file. I also expected there
to a special variable called something like
*default-compiler-policy* or something like that. Seems I'm wrong
on the latter, at least :-)
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
In article <···············@todday.inf.ed.ac.uk>,
Jeff Dalton <····@todday.inf.ed.ac.uk> wrote:
> > I think the workflow issue is very important.
>
> That makes me wonder too: when did "workflow" start being
> a word that was used in such contexts? (And when did it
> start being a word?)
Don't know about anyone else, but I think I first came across the word
when I started poking my nose into the printing industry in the mid 80's
(because of PostScript).
-- Bruce