There are many repositories of Common Lisp free libraries, many of
which you can find through links in my survey paper at
http://common-lisp.net/~dlw/LispSurvey.html.
I just learned about one I had not heard about before: www.lispwire.com.
It's sponsored by Franz but it's fine for everyone. Franz provides a
link to "Allegro CL Free Express Edition" at
http://www.franz.com/downloads/allegrodownload.lhtml. The libraries
have been tested with Allegro but it is my impression that many of
them will work with other implementations.
Kudos to Franz for sponsoring this.
There will be discussion at the International Lisp Conference about
the future of Common Lisp library repositories. There's no reason we
can't do something as popular and useful as, say, CPAN.
Dan Weinreb <···@alum.mit.edu> writes:
> I just learned about one I had not heard about before: www.lispwire.com.
> It's sponsored by Franz but it's fine for everyone. Franz provides a
> link to "Allegro CL Free Express Edition" at
> http://www.franz.com/downloads/allegrodownload.lhtml. The libraries
> have been tested with Allegro but it is my impression that many of
> them will work with other implementations.
>
> Kudos to Franz for sponsoring this.
I think it's a good idea, but the execution has been somewhat lacking. I
learned about lispwire.com a few years ago, a few years after it was
introduced, and it has not had any activity since.
I personally don't feel like adding any of my libraries to lispwire for
two reasons: nobody would notice it, and the submission form at
http://www.lispwire.com/template.txt is a little daunting.
> There will be discussion at the International Lisp Conference about
> the future of Common Lisp library repositories. There's no reason we
> can't do something as popular and useful as, say, CPAN.
It would "just" take someone with the right mix of ability, motivation,
and time. What Luke Gorrie and others did for SLIME, maybe someone can
do for Lisp libraries.
Zach
On Aug 14, 3:42 am, Dan Weinreb <····@alum.mit.edu> wrote:
> There are many repositories of Common Lisp free libraries, many of
> which you can find through links in my survey paper athttp://common-lisp.net/~dlw/LispSurvey.html.
>
> I just learned about one I had not heard about before: www.lispwire.com.
> It's sponsored by Franz but it's fine for everyone. Franz provides a
> link to "Allegro CL Free Express Edition" athttp://www.franz.com/downloads/allegrodownload.lhtml. The libraries
> have been tested with Allegro but it is my impression that many of
> them will work with other implementations.
>
> Kudos to Franz for sponsoring this.
>
> There will be discussion at the International Lisp Conference about
> the future of Common Lisp library repositories. There's no reason we
> can't do something as popular and useful as, say, CPAN.
When one thinks about it, this situation of lispers not having a
centralized lib depository is quite, extremely stupid.
Mathematica, had mathsource.com in the early 1990s, and now merged
into the wolfram.com info section.
Perl's CPAN and TeX's TPAN's been around in about the same time.
I was also deeply chagrined, to know that there's no central
depository for elisp.
Such a despsitory isn't hard to do. Any seanoned web developer can do
it in few days, esp with today's abundance of tools. (for example,
today, a full featured website for code depository with search
abilities and categories etc so on, can be be literally done in a
couple of days. (any company can pay me 1k USD and i'll have it up
running. (please contact me)))
It is not a wonder, that non-lispers have a hard time to love or
appreciate lisp, and in my opinion they are just.
Sometimes, when one considers many of the open source projects, their
apparent deficiencies (when compared to commercial products for
example), yet met with the most, extreme motherfucking denial, really
makes it sad. (as my experiences in advocating modernization of emacs
for example
http://xahlee.org/emacs/modernization.html
)
In the past about 13 years i used newsgroup, typically i don't post
more than 1 or 2 messages per week (unless the group is moderated such
as Mathematica.). Over the years, esp post 2000, i learned that many
what i'd call unix or perl morons simply don't know things, so instead
of me assumig they are just to fuck with me, i should not take offense
and should try more explanatory approach instead (as opposed to simply
post a summarized opinion that often criticise something and assume
well educated readers). But in this year, especially this month, i
started to post freely, experimenting with a conversational style like
most tech geekers are. I learned, GHASTLY, the actual degree of their
ignorance. The problem becomes, to answer each and every post
patiently, and in detail. (most of these newsgroup fuckers don't read
the whole thread, and most simply just react to one message (or a
single line) that touched their fancy. (they actually think they are
participating reasonably in a discussion with a straight face) And in
my 10+ years of newsgroup use, i think the number of people who
actually tried to read whole threads as a discussion and consider the
subject as a whole, is countable on my fingers. Reasonable people who
appreciate their time have long abandoned newsgroups as idea/question
exchange place.)
Yesterday, i realized that i'm the #1 poster in gnu.emacs.help for
this month with respect to frequency, and am #3 in comp.lang.lisp this
month. LOL. Congradulations Xah! Well done.
Due to the numrousness of posting and the fact of actually conversing
with each individual (many are emacs developers), there is actually a
positive effect. That is, because i actually responded to each or most
messages individually (and without being sarcastic or swearing), they
began to think i'm serious in my views and seriously consider points i
made. And, i'd say, they began to actually to admit, that i have some
valid points (to say the least). (LOL. Quite ridiculous these cave
dwellers. (imagine, a professor in subject X. Instead of publishing a
book for society to read, he now has to actually patiently shake hands
and say hello to each highschool students, so that these highschoolers
wouldn't consider him a troll))
Xah
∑ http://xahlee.org/
☄
······@gmail.com wrote:
> On Aug 14, 3:42 am, Dan Weinreb <····@alum.mit.edu> wrote:
>> There are many repositories of Common Lisp free libraries, many of
>> which you can find through links in my survey paper athttp://common-lisp.net/~dlw/LispSurvey.html.
>>
>> I just learned about one I had not heard about before: www.lispwire.com.
>> It's sponsored by Franz but it's fine for everyone. Franz provides a
>> link to "Allegro CL Free Express Edition" athttp://www.franz.com/downloads/allegrodownload.lhtml. The libraries
>> have been tested with Allegro but it is my impression that many of
>> them will work with other implementations.
>>
>> Kudos to Franz for sponsoring this.
>>
>> There will be discussion at the International Lisp Conference about
>> the future of Common Lisp library repositories. There's no reason we
>> can't do something as popular and useful as, say, CPAN.
>
>
> When one thinks about it, this situation of lispers not having a
> centralized lib depository is quite, extremely stupid.
>
> Mathematica, had mathsource.com in the early 1990s, and now merged
> into the wolfram.com info section.
>
> Perl's CPAN and TeX's TPAN's been around in about the same time.
>
> I was also deeply chagrined, to know that there's no central
> depository for elisp.
>
> Such a despsitory isn't hard to do.
No, what is hard to do is herding cats. Lispers by definition cannot be
organized, unless it is to drink.
Any seanoned web developer can do
> it in few days, esp with today's abundance of tools. (for example,
> today, a full featured website for code depository with search
> abilities and categories etc so on, can be be literally done in a
> couple of days. (any company can pay me 1k USD and i'll have it up
> running. (please contact me)))
>
> It is not a wonder, that non-lispers have a hard time to love or
> appreciate lisp, and in my opinion they are just.
Would you expect sheep to be attracted to the lifestyle of a hawk?
>
> Sometimes, when one considers many of the open source projects, their
> apparent deficiencies (when compared to commercial products for
> example), yet met with the most, extreme motherfucking denial, really
> makes it sad. (as my experiences in advocating modernization of emacs
> for example
> http://xahlee.org/emacs/modernization.html
> )
>
> In the past about 13 years i used newsgroup, typically i don't post
> more than 1 or 2 messages per week (unless the group is moderated such
> as Mathematica.). Over the years, esp post 2000, i learned that many
> what i'd call unix or perl morons simply don't know things, so instead
> of me assumig they are just to fuck with me, i should not take offense
> and should try more explanatory approach instead (as opposed to simply
> post a summarized opinion that often criticise something and assume
> well educated readers). But in this year, especially this month, i
> started to post freely, experimenting with a conversational style like
> most tech geekers are. I learned, GHASTLY, the actual degree of their
> ignorance. The problem becomes, to answer each and every post
> patiently, and in detail. (most of these newsgroup fuckers don't read
> the whole thread, and most simply just react to one message (or a
> single line) that touched their fancy. (they actually think they are
> participating reasonably in a discussion with a straight face) And in
> my 10+ years of newsgroup use, i think the number of people who
> actually tried to read whole threads as a discussion and consider the
> subject as a whole, is countable on my fingers. Reasonable people who
> appreciate their time have long abandoned newsgroups as idea/question
> exchange place.)
>
> Yesterday, i realized that i'm the #1 poster in gnu.emacs.help for
> this month with respect to frequency, and am #3 in comp.lang.lisp this
> month. LOL. Congradulations Xah! Well done.
>
> Due to the numrousness of posting and the fact of actually conversing
> with each individual (many are emacs developers), there is actually a
> positive effect. That is, because i actually responded to each or most
> messages individually (and without being sarcastic or swearing), they
> began to think i'm serious in my views and seriously consider points i
> made.
The Mighty Xah, domesticated?
Say it ain't so, Xah! Say it ain't so!
But I guess it's good for your blood pressure.
And, i'd say, they began to actually to admit, that i have some
> valid points (to say the least). (LOL. Quite ridiculous these cave
> dwellers. (imagine, a professor in subject X. Instead of publishing a
> book for society to read, he now has to actually patiently shake hands
> and say hello to each highschool students, so that these highschoolers
> wouldn't consider him a troll))
I think I have quoted before the Bell Labs engineer being written up in
the Newark Star-Ledger 25 years ago on the occasion of some
wonderfulness of his saying, "The hardest part for me was realizing I
was being tolerated by all the people I had been tolerating."
hth, kt
--
$$$$$: http://www.theoryyalgebra.com/
Cells: http://common-lisp.net/project/cells/
BSlog: http://smuglispweeny.blogspot.com/
Kenny wrote:
> > It is not a wonder, that non-lispers have a hard time to love or
> > appreciate lisp, and in my opinion they are just.
>
> Would you expect sheep to be attracted to the lifestyle of a hawk?
you are implying lisp is superior?
frankly, today, i find nothing in lisp that would warrent it as a
superior language, in light of the so many new functional langs.
as i have said here, i have been coding as a hobby elisp since 2006. I
like it more than say perl, python, only marginally, primarily only
because the language is primarily geared towards functional style. The
more i know of elisp as a lisp, and the more i learned cursorily of
Common Lisp, the less i have interest in lisp. As i've said, i find no
interest in learning Common Lisp (nor Scheme lisp).
The fundamental problems of lisp i wrote:
http://xahlee.org/UnixResource_dir/writ/lisp_problems.html
are just problems of lisp in some pure computing language perpective.
Practically, as we know, there are also problems of having relatively
very small users, lack of modern libraries, huge complexity (counting
the widely acknowledged Scheme 6 fucked up), lack of some more
expressive construct in modern functional langs (e.g. pattern
matching), lack or complexity of library or name space scheme,
incompatible and mulitple implementations... (of course, lisp heads
would argue for each of these..., but the above are pretty much the
general conception just as perl is regarded as a syntax soup problem
and java is verbose to no ends)
Kenny wrote:
> The Mighty Xah, domesticated?
>
> Say it ain't so,Xah! Say it ain't so!
>
> But I guess it's good for your blood pressure.
Flame war is good!! War is good. Leisure human animals like wars, as
opposed to rotting off in boredom. It is why we see the tech geekers,
who are one of the most lonely and bored class of people, dive into
the most trivial debates with all-out energy and excitment, such as
top-posting vs bottom-posting.
See:
What Desires Are Politically Important? by Bertrand Russell
http://xahlee.org/Periodic_dosage_dir/_p2/russell-lecture.html
Quote: «With civilized men, as with primitive Red Indian tribes, it
is, I think, chiefly love of excitement which makes the populace
applaud when war breaks out; the emotion is exactly the same as at a
football match, although the results are sometimes somewhat more
serious.»
See also:
Industrial Society and its Future, Theodore Kaczynski
SURROGATE ACTIVITIES
http://xahlee.org/p/um/um-s06.html
------------
this message is posted to comp.lang.lisp and comp.lang.scheme .
Xah
∑ http://xahlee.org/
☄
······@gmail.com wrote:
> Kenny wrote:
>>> It is not a wonder, that non-lispers have a hard time to love or
>>> appreciate lisp, and in my opinion they are just.
>> Would you expect sheep to be attracted to the lifestyle of a hawk?
>
> you are implying lisp is superior?
Good lord, man. The contrast was in a tendency to herd vs a tendency to
go solo. Aside from mating, of course.
>
> frankly, today, i find nothing in lisp...
may I ask on what application you are currently working that is immune
to Lisp's charms?
> ...that would warrent it as a
> superior language, in light of the so many new functional langs.
All of them copying Lisp badly, incompletely, and interpretedly. And
none of them, not even Scheme, have proper macros. That they are
/trying/ to be Lisps shows they know Lisp is superior.
QED.
kt
--
$$$$$: http://www.theoryyalgebra.com/
Cells: http://common-lisp.net/project/cells/
BSlog: http://smuglispweeny.blogspot.com/
Kenny wrote:
> All of them copying Lisp badly, incompletely, and interpretedly. And
> none of them, not even Scheme, have proper macros. That they are
> /trying/ to be Lisps shows they know Lisp is superior.
Outdated information. As of R6RS, scheme makes macros having the
expressive power of defmacro standard.
There are things I think that the most recent report got wrong.
They made it unnecessarily complex, but variable capture, at least,
is now possible.
Bear
Ray Dillinger wrote:
> Kenny wrote:
>
>> All of them copying Lisp badly, incompletely, and interpretedly. And
>> none of them, not even Scheme, have proper macros. That they are
>> /trying/ to be Lisps shows they know Lisp is superior.
>
> Outdated information. As of R6RS, scheme makes macros having the
> expressive power of defmacro standard.
>
> There are things I think that the most recent report got wrong.
> They made it unnecessarily complex, but variable capture, at least,
> is now possible.
...but that new macro system _is_ unnecessarily complex.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Ray Dillinger wrote:
>> There are things I think that the most recent [scheme] report got wrong.
>> They made it unnecessarily complex, but variable capture, at least,
>> is now possible.
> ...but that new macro system _is_ unnecessarily complex.
Your mouth to God's ear, friend.
Wouldn't it work just fine to base it on the CL defmacro form,
with internal syntax like (with-captures ... ) enclosing code
specifying when you _don't_ want to use renaming discipline?
That way you get hygiene by default, avoid inadvertent capture,
and get variable capture with a very simple additional syntax.
Bear
On Aug 25, 6:32 am, Ray Dillinger <····@sonic.net> wrote:
> Pascal Costanza wrote:
> > ...but that new macro system _is_ unnecessarily complex.
>
> Your mouth to God's ear, friend.
>
> Wouldn't it work just fine to base it on the CL defmacro form,
> with internal syntax like (with-captures ... ) enclosing code
> specifying when you _don't_ want to use renaming discipline?
> That way you get hygiene by default, avoid inadvertent capture,
> and get variable capture with a very simple additional syntax.
Butbut... what are we going to write papers on, then?!
M/
Ray Dillinger wrote:
> Pascal Costanza wrote:
>
>> Ray Dillinger wrote:
>
>>> There are things I think that the most recent [scheme] report got wrong.
>>> They made it unnecessarily complex, but variable capture, at least,
>>> is now possible.
>
>> ...but that new macro system _is_ unnecessarily complex.
>
> Your mouth to God's ear, friend.
>
> Wouldn't it work just fine to base it on the CL defmacro form,
> with internal syntax like (with-captures ... ) enclosing code
> specifying when you _don't_ want to use renaming discipline?
> That way you get hygiene by default, avoid inadvertent capture,
> and get variable capture with a very simple additional syntax.
That's syntactic closures. Yes, that would be a fine solution.
I'd prefer to go even more minimalistic. I think Will Clinger's renaming
system is all you need.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Alexander Schmolck
Subject: Re: Another place to find free Common Lisp libraries
Date:
Message-ID: <yfsod3g1wuq.fsf@gmail.com>
Pascal Costanza <··@p-cos.net> writes:
> Ray Dillinger wrote:
>> Pascal Costanza wrote:
>>
>>> Ray Dillinger wrote:
>>
>>>> There are things I think that the most recent [scheme] report got wrong.
>>>> They made it unnecessarily complex, but variable capture, at least,
>>>> is now possible.
>>
>>> ...but that new macro system _is_ unnecessarily complex.
>> Your mouth to God's ear, friend.
>>
>> Wouldn't it work just fine to base it on the CL defmacro form, with internal
>> syntax like (with-captures ... ) enclosing code specifying when you _don't_
>> want to use renaming discipline? That way you get hygiene by default, avoid
>> inadvertent capture, and get variable capture with a very simple additional
>> syntax.
>
> That's syntactic closures. Yes, that would be a fine solution.
>
> I'd prefer to go even more minimalistic. I think Will Clinger's renaming
> system is all you need.
Hmm, what exactly is "necessary" and what current macro systems provide it?
Apart from expressivness I think a good macro system would need the following
4 things (roughly in reverse order of importance):
1. ease of use (for writing macros))
2. robustness
3. plays well with interactive development
4. easy of use (for using macros viz. debugging support)
Is there any language/implementation that ticks all these boxes?
In my experience the core defect of CL's defmacro is not the often touted lack
of hygiene (see 2.) but extremely poor debuggability which IMO really
compromises CL's otherwise very good support for interactive development and
DSL creation.
I'm not sure to what extent poor debuggability is a quality of implementation
issue, but on the face of it the task seems much, much harder for procedural,
plain sexp-based macros than for e.g. define-syntax style macros (I can't
remember what the situation for syntax-case looked like, but I'm sure I
witnessed error reporting for exceptions originating in define-syntax macros
in scheme that is incomparably better than anything I've ever seen in CL
implementations).
'as
Alexander Schmolck <··········@gmail.com> writes:
> In my experience the core defect of CL's defmacro is not the often touted lack
> of hygiene (see 2.) but extremely poor debuggability which IMO really
> compromises CL's otherwise very good support for interactive development and
> DSL creation.
Bullshit.
(defmacro m (args...) body...)
is equivalent to:
(defun m* (args...) body...)
(defmacro m (args...) (m& args...))
and m* is debuggable as easily as any other function.
> I'm not sure to what extent poor debuggability is a quality of implementation
> issue, but on the face of it the task seems much, much harder for procedural,
> plain sexp-based macros than for e.g. define-syntax style macros (I can't
> remember what the situation for syntax-case looked like, but I'm sure I
> witnessed error reporting for exceptions originating in define-syntax macros
> in scheme that is incomparably better than anything I've ever seen in CL
> implementations).
Macros are compiler hooks. It is expected that macro writers make the
effort of testing and signaling meaningful compile-time errors.
In the case of define-syntax, the macro writer is the define-syntax
operator itself. (The poor programmer is just using some restricted
define-syntax DSL, and cannot do much by himself).
--
__Pascal Bourguignon__ http://www.informatimago.com/
IMPORTANT NOTICE TO PURCHASERS: The entire physical universe,
including this product, may one day collapse back into an
infinitesimally small space. Should another universe subsequently
re-emerge, the existence of this product in that universe cannot be
guaranteed.
From: Alexander Schmolck
Subject: Re: Another place to find free Common Lisp libraries
Date:
Message-ID: <yfszln0zfnl.fsf@gmail.com>
···@informatimago.com (Pascal J. Bourguignon) writes:
> Alexander Schmolck <··········@gmail.com> writes:
>> In my experience the core defect of CL's defmacro is not the often touted lack
>> of hygiene (see 2.) but extremely poor debuggability which IMO really
>> compromises CL's otherwise very good support for interactive development and
>> DSL creation.
>
> Bullshit.
>
> (defmacro m (args...) body...)
>
> is equivalent to:
>
> (defun m* (args...) body...)
> (defmacro m (args...) (m& args...))
>
> and m* is debuggable as easily as any other function.
I should have made it clearer that the poor debuggability refers not primarily
to the macro itself, but to code that uses it. You normally don't get precise
error locations for unhandled conditions originating from code that was
(def)macro-generated.
>> I'm not sure to what extent poor debuggability is a quality of implementation
>> issue, but on the face of it the task seems much, much harder for procedural,
>> plain sexp-based macros than for e.g. define-syntax style macros (I can't
>> remember what the situation for syntax-case looked like, but I'm sure I
>> witnessed error reporting for exceptions originating in define-syntax macros
>> in scheme that is incomparably better than anything I've ever seen in CL
>> implementations).
>
> Macros are compiler hooks. It is expected that macro writers make the
> effort of testing and signaling meaningful compile-time errors.
>
Sure -- and this can inherently not be fully automated (but of course all else
being equal, a system that gives you better error messages out of the box for
the subset of things for which this is possible is preferable).
> In the case of define-syntax, the macro writer is the define-syntax
> operator itself. (The poor programmer is just using some restricted
> define-syntax DSL, and cannot do much by himself).
Well, but in return you get a rather convenient system for specifying the most
simple macros[*], plus, crucially, a pretty good inverse transform from a
location in the expansion to location in your actual source code. And of
course there's always syntax-case which allows you to do anything you can do
with defmacro. However since I haven't used it properly I don't know how it
compares in practice and I'd be curious to know how it does on my list of
criteria (the same for alternative scheme macro systems with less mind-share,
as well as solutions in other languages such as dylan).
'as
[*] And of course interesting intellectual challenges for those insisting on
doing anything of even moderate complexity in it :)
See e.g. http://eval.apply.googlepages.com/eccentric.txt
Alexander Schmolck <··········@gmail.com> writes:
> I should have made it clearer that the poor debuggability refers not primarily
> to the macro itself, but to code that uses it. You normally don't get precise
> error locations for unhandled conditions originating from code that was
> (def)macro-generated.
But almost the same can be said of even "normal" CL code. Remember
that in CL, there are only 24 Special Operators, vs. 91 Macros: most
of the Common Lisp language is made of macros, and even "normal" CL
code will be "hard" to debug given that it will be essentially
macroexpanded all over.
Nonetheless, this doesn't prevent a "source-level" debugger to be
developed for Common Lisp.
>> In the case of define-syntax, the macro writer is the define-syntax
>> operator itself. (The poor programmer is just using some restricted
>> define-syntax DSL, and cannot do much by himself).
>
> Well, but in return you get a rather convenient system for specifying the most
> simple macros[*], plus, crucially, a pretty good inverse transform from a
> location in the expansion to location in your actual source code. And of
> course there's always syntax-case which allows you to do anything you can do
> with defmacro. However since I haven't used it properly I don't know how it
> compares in practice and I'd be curious to know how it does on my list of
> criteria (the same for alternative scheme macro systems with less mind-share,
> as well as solutions in other languages such as dylan).
I would almost propose my standard answer: "do it yourself", but I'm
wondering if it's really worthwhile. As long as you have a simple
macro to write, it could look interesting to have a specialized macro
maker, but then when you need to make it more complex, you will have
to translate from the simple language back to Common Lisp defmacro. I
guess the best solution I've seen proposed is that to have utility
routines and macros to help writting simple defmacros. They would be
better integrated into CL.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Cats meow out of angst
"Thumbs! If only we had thumbs!
We could break so much!"
Alexander Schmolck wrote:
> ···@informatimago.com (Pascal J. Bourguignon) writes:
>> Macros are compiler hooks. It is expected that macro writers make the
>> effort of testing and signaling meaningful compile-time errors.
>
> Sure -- and this can inherently not be fully automated (but of course all else
> being equal, a system that gives you better error messages out of the box for
> the subset of things for which this is possible is preferable).
But all else is not equal...
>> In the case of define-syntax, the macro writer is the define-syntax
>> operator itself. (The poor programmer is just using some restricted
>> define-syntax DSL, and cannot do much by himself).
>
> Well, but in return you get a rather convenient system for specifying the most
> simple macros[*], plus, crucially, a pretty good inverse transform from a
> location in the expansion to location in your actual source code. And of
> course there's always syntax-case which allows you to do anything you can do
> with defmacro. However since I haven't used it properly I don't know how it
> compares in practice and I'd be curious to know how it does on my list of
> criteria (the same for alternative scheme macro systems with less mind-share,
> as well as solutions in other languages such as dylan).
A programming language is not a list of features that its designers
ticked off. A main question is how various parts of the language design
fit and work together. What I'm trying to get at: Yes, in terms of lists
of features given on paper, syntax-case gives you all you want. That
doesn't necessarily mean that it's a good macro system.
It's the old Turing tarpit again...
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Tobias C. Rittweiler
Subject: Re: Another place to find free Common Lisp libraries
Date:
Message-ID: <871w0cp3bv.fsf@freebits.de>
Alexander Schmolck <··········@gmail.com> writes:
> Well, but in return you get a rather convenient system for specifying
> the most simple macros[*], [...]
In my experience, the set of simple macros is mostly just macros which
are wrappers around CALL-WITH-FOO functions (cf. [1].) And those are
not only easily done with DEFMACRO, but also very readable.
Getting most other macros as wonderfully crafted as the macros in the
Common Lisp standard is quite a non-trivial task. The complexity does
not come from DEFMACRO, though, but from the (seemingly inherent)
complexity in language design.
The problems of source location tracking comes, as Pascal Costanza
rightfully mentioned, from the insufficiencies of conses to build up
source code. That's also a realization shared by people like
David A. Moon.
-T.
[1] http://random-state.net/log/3390120648.html
Alexander Schmolck wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>> Ray Dillinger wrote:
>>> Pascal Costanza wrote:
>>>
>>>> Ray Dillinger wrote:
>>>>> There are things I think that the most recent [scheme] report got wrong.
>>>>> They made it unnecessarily complex, but variable capture, at least,
>>>>> is now possible.
>>>
>>>> ...but that new macro system _is_ unnecessarily complex.
>>> Your mouth to God's ear, friend.
>>>
>>> Wouldn't it work just fine to base it on the CL defmacro form, with internal
>>> syntax like (with-captures ... ) enclosing code specifying when you _don't_
>>> want to use renaming discipline? That way you get hygiene by default, avoid
>>> inadvertent capture, and get variable capture with a very simple additional
>>> syntax.
>> That's syntactic closures. Yes, that would be a fine solution.
>>
>> I'd prefer to go even more minimalistic. I think Will Clinger's renaming
>> system is all you need.
>
> Hmm, what exactly is "necessary" and what current macro systems provide it?
None of this is necessary. There exists a lot of code written in Common
Lisp, and more code is being developed and will be developed in the
future. You don't hear a lot of complaints because the macro system is
"unreliable," you actually hear hardly any complaints about the macro
system at all, apart from beginners. The problems for real-world
development are elsewhere.
> Apart from expressivness I think a good macro system would need the following
> 4 things (roughly in reverse order of importance):
>
> 1. ease of use (for writing macros))
> 2. robustness
> 3. plays well with interactive development
> 4. easy of use (for using macros viz. debugging support)
>
> Is there any language/implementation that ticks all these boxes?
>
> In my experience the core defect of CL's defmacro is not the often touted lack
> of hygiene (see 2.) but extremely poor debuggability which IMO really
> compromises CL's otherwise very good support for interactive development and
> DSL creation.
Macros are functions that transform s-expressions into s-expressions. A
good way to ensure that you have "correct" macros is to do what you
should do with any function: Write test suites.
> I'm not sure to what extent poor debuggability is a quality of implementation
> issue, but on the face of it the task seems much, much harder for procedural,
> plain sexp-based macros than for e.g. define-syntax style macros (I can't
> remember what the situation for syntax-case looked like, but I'm sure I
> witnessed error reporting for exceptions originating in define-syntax macros
> in scheme that is incomparably better than anything I've ever seen in CL
> implementations).
The main reason why it is harder to implement good debuggers for CL's
macro system is because different parts of a macroexpansion may
partially share structure, or even may share structure with other
macroexpansions. This means that, in the general case, you cannot
unambiguously deduce from part of a macroexpansion which actual macro
invocation generated that code.
In the syntax-case macro system, that's different: Due to its reliance
on syntax objects, you can always infer which macro invocation generated
which target code.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Xah Lee writes:
«When one thinks about it, this situation of lispers not having a
centralized lib depository in 2008, is quite, stupid. ...»
This essay is now archived at:
http://xahlee.org/Netiquette_dir/chat_style_posts.html
with editing and addendum.
Xah wrote:
«Due to the numrousness of posting and the fact of actually conversing
with each individual (many are emacs developers), there is actually a
positive effect. That is, because i actually responded to each or most
messages individually (and without being sarcastic or swearing), they
began to think i'm serious in my views and seriously consider points i
made. And, i'd say, they began to actually to admit, that i have some
valid points (to say the least). (LOL. Quite ridiculous these cave
dwellers. (imagine, a professor in subject X. Instead of publishing a
book for society to read, he now has to actually patiently shake hands
and say hello to each highschool students, so that these highschoolers
wouldn't consider him a troll))»
actually, considered broadly, that's what politicians do exactly. In
election days, you see how they tour the country to shake crowd's
hands and win people's votes. Politicians do that because ultimately
that's what works best. It works best because ultimately the
motivation of people is self-based. People are prone to like your
views when they have met you, physically having touched you, or know
you. Logic, reason, are supplemental.
Xah
∑ http://xahlee.org/
☄