I started off with a practical question:
How do I figure out the arity of a closure? (I'm writing a generic
event system, and I'd like to pass the correct number of arguments to
handlers based on their definition, rather than requiring some arity-
interface.)
A list search finds that this isn't possible even for functions, at
least in a portable way, which makes me very doubtful of closures.
Any suggestions would be greatly appreciated though.
On a larger note, is there any kind of community process to evolve
common-lisp? It would be great if there were some kind of forum for
proposing, discussing and voting on feature additions and
modifications, which could then be taken up by the various compilers.
Companies tend to be horrible at making this type of thing work
because they have to defend their vested interests, but at least the
open source projects could do this. Anyone ever try? Thoughts,
ideas, server donations?
Happy hacking this weekend,
Jeff
Jeff <······@gmail.com> writes:
> How do I figure out the arity of a closure? (I'm writing a generic
> event system, and I'd like to pass the correct number of arguments to
> handlers based on their definition, rather than requiring some arity-
> interface.)
I think you are approaching the event system interface from the wrong
direction:
Even if you could determine the arity of an arbitrary closure, how would
you know which are the correct arguments to pass? Suppose you get two
closures, each of which take 3 arguments. How do you know which 3
arguments to pass?
So, at some level, your event handling API has to decide which arguments
are available to pass to the handlers. The simplest way to construct
such an API is to then simply require the handlers to accept all of the
arguments that the event dispatcher sends.
This is similar to the contract for the generic function PRINT-OBJECT,
which has a fixed set of arguments, not all of which are relevant for
the object in question. But the method still needs to accept them all
and then ignore the irrelvant ones.
Another alternative would be to have some data structure representing
the event information and then just pass this single data structure as
the argument. Handlers could then extract the event information they
care about from such a data structure.
--
Thomas A. Russ, USC/Information Sciences Institute
On Jan 25, 9:30 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> Jeff <······@gmail.com> writes:
> > How do I figure out the arity of a closure? (I'm writing a generic
> > event system, and I'd like to pass the correct number of arguments to
> > handlers based on their definition, rather than requiring some arity-
> > interface.)
>
> I think you are approaching the event system interface from the wrong
> direction:
>
> Even if you could determine the arity of an arbitrary closure, how would
> you know which are the correct arguments to pass? Suppose you get two
> closures, each of which take 3 arguments. How do you know which 3
> arguments to pass?
>
> So, at some level, your event handling API has to decide which arguments
> are available to pass to the handlers. The simplest way to construct
> such an API is to then simply require the handlers to accept all of the
> arguments that the event dispatcher sends.
>
> This is similar to the contract for the generic function PRINT-OBJECT,
> which has a fixed set of arguments, not all of which are relevant for
> the object in question. But the method still needs to accept them all
> and then ignore the irrelvant ones.
>
> Another alternative would be to have some data structure representing
> the event information and then just pass this single data structure as
> the argument. Handlers could then extract the event information they
> care about from such a data structure.
>
> --
> Thomas A. Russ, USC/Information Sciences Institute
Thanks to everyone for your responses. I guess from what I've seen
the macro that generates a data-structure containing the arity and the
closure seems like the best solution. Just to explain what I'm going
after though...
I'm building a generic event system where I basically want to attach
handlers to arbitrary nodes in a graph. Later on, events can be fired
on a node, and then any handlers registered for that named event will
be called. Quite often the handler won't care about any data that
might be in the event itself, in which case it would be the cleanest
not to have to use something like a &rest parameter when it will never
be used. That was the basic goal. I'll do it with a macro though,
and I think I'll wrap the arguments up into a single event object so
they get passed around in a bundle anyways.
It's interesting how people get sort of defensive about changing
common-lisp. I mean, wouldn't it be nice if good regular expressions
and high level networking were built-in?
Thanks again for the help,
Jeff
From: Maciej Katafiasz
Subject: Re: Arity of a closure and a Lisp Community Process
Date:
Message-ID: <fni78e$a3j$3@news.net.uni-c.dk>
Den Sun, 27 Jan 2008 06:20:47 -0800 skrev Jeff:
> It's interesting how people get sort of defensive about changing
> common-lisp. I mean, wouldn't it be nice if good regular expressions
> and high level networking were built-in?
Huh? How is that at all related to any of the discussion in this thread?
And no, it wouldn't be objectively good, it's not possible to have Python-
style batteries included distribution without adopting Python-style
language development, and that means giving up certain advantages
inherent in the way CL is currently defined. Not the least of which is
the language being independent of any particular implementation, and
having a first-class design, as opposed to sort of "design" that's pretty
much incidental to how the One True implementation does things.
What CL needs is a good way to agree on things so that they work as if
they were built in (we already have that for syntax), not pretending it's
some other language that happens to be more hip at the moment.
Cheers,
Maciej
In article <············@news.net.uni-c.dk>,
Maciej Katafiasz <········@gmail.com> wrote:
> Den Sun, 27 Jan 2008 06:20:47 -0800 skrev Jeff:
>
> > It's interesting how people get sort of defensive about changing
> > common-lisp. I mean, wouldn't it be nice if good regular expressions
> > and high level networking were built-in?
>
> Huh? How is that at all related to any of the discussion in this thread?
> And no, it wouldn't be objectively good, it's not possible to have Python-
> style batteries included distribution without adopting Python-style
> language development, and that means giving up certain advantages
> inherent in the way CL is currently defined. Not the least of which is
> the language being independent of any particular implementation, and
> having a first-class design, as opposed to sort of "design" that's pretty
> much incidental to how the One True implementation does things.
>
> What CL needs is a good way to agree on things so that they work as if
> they were built in (we already have that for syntax), not pretending it's
> some other language that happens to be more hip at the moment.
>
> Cheers,
> Maciej
Right.
If people want Python, there is Python. If someone wants
Ruby, there is Ruby. There is simply no need to make
the core Common Lisp into those languages. It's mostly
newbies who need to unlearn some prior knowledge
and adapt to Common Lisp practice. There is some
resistance to do that, but making Common Lisp into
something other that already exists would make it
useless. Let's add modules, algol syntax, some
process constructs, - halt, wait - that's Ada.
Okay, let's get rid of symbols, dynamic binding,
Lisp2, simplify everything, then complicate again
- halt, wait that's Scheme.
Common Lisp is a language in its own right. Not
everything in the language is created by a series of accidents
in the past and not everything is just baggage.
Though some people might believe that.
The stability of the core language is actually a good thing.
You don't get the latest features, but for lots of stuff
you don't need to change the language - just write some
code - since Common Lisp has more than the
usual language level flexibility built in.
It is also good to remember that Common Lisp takes some
neutral positions - it provides a lot of Lisp (!!!)
functionality. But at the same time it also grants
the user of Common Lisp (the developer) many rights.
Common Lisp for example does only use a small set
of characters for the core language. By design.
[]? {}? Left to the user. Symbols? Use any character
you like. Want to change how characters are read
to provide new data syntax? You can do it yourself.
Special Forms? Only very few. Namespaces? Use your own.
Code transformations? Write your own!
But above requires the core language to be stable and
and conservative.
If one wants interesting language extensions on top
of Common Lisp or even different language on top
of Common Lisp - then we are talking.
Lisp1 on top of Common Lisp is hardly an improvement
for the core Lisp language. So, if the motivation
is because Lisp2 is problematic, now we have
a Lisp1 that is better and should be used? That's
just mostly useless and wrong. There is an existing
practice (literature, software, ...) that uses a Lisp2.
The basic principles are taught in a day. If any
programmer has a problem with that, he can consult
some external help (say some Newsgroup ;-) ) and the usage
of FUNCALL and FUNCTION will be explained to him/her.
If the motivation is to provide an implementation
of a Lisp1 for some special purpose, that can be useful.
If one wants to drive (!) a car in the UK, which side would be the
steering wheel? What would be the first thing you do?
Would you reconstruct your car and put the steering wheel on
the other side? Because one comes from the continent?
Why not use the steering wheel on the side like
all (most) people in the UK? Maybe the default
is sufficient and you could actually spend some time
on the road, instead of spending useless time in the garage?
Sure portable libraries are useful. If users find stuff useful,
they will use it and port it (if necessary). More effort
in that direction would be useful. But don't please hold your breath.
There is enough that can be used now.
From: Maciej Katafiasz
Subject: Re: Arity of a closure and a Lisp Community Process
Date:
Message-ID: <fni9vm$a3j$6@news.net.uni-c.dk>
Den Sun, 27 Jan 2008 16:48:05 +0100 skrev Rainer Joswig:
> If one wants to drive (!) a car in the UK, which side would be the
> steering wheel? What would be the first thing you do? Would you
> reconstruct your car and put the steering wheel on the other side?
> Because one comes from the continent? Why not use the steering wheel on
> the side like all (most) people in the UK? Maybe the default is
> sufficient and you could actually spend some time on the road, instead
> of spending useless time in the garage?
Although one come with one's own car with steering wheel on either side
and drive it around, and CL, like UK traffic laws, allows one to do
that :). It all really boils down to the recently popular question of
"how do we properly remove the incidental complexity associated with
using CL code, so that the actually interesting stuff can be done". I for
one really want to see what comes out of all the CL library management
projects that seem to be really on the rise nowadays.
Cheers,
Maciej
From: Edi Weitz
Subject: Re: Arity of a closure and a Lisp Community Process
Date:
Message-ID: <uk5lvmiql.fsf@agharta.de>
On Sun, 27 Jan 2008 06:20:47 -0800 (PST), Jeff <······@gmail.com> wrote:
> It's interesting how people get sort of defensive about changing
> common-lisp.
My impression is that people aren't defensive but simply realistic.
It's an ANSI standard and the chances of it being changed in the
future are almost NIL. As others have said, search the archives of
this newsgroup and you will find lots of reasons provided by the
people who were involved why a change is extremely unlikely.
> I mean, wouldn't it be nice if good regular expressions and high
> level networking were built-in?
Is it a big, big problem to add one line to your application to load a
regular expression library or the networking support that your
implementation offers? AFAIK this hasn't prevented anyone from
getting things done so far. I agree that it's a favorite topic on
c.l.l, though. People love to complain...
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
In article <·············@agharta.de>, Edi Weitz <········@agharta.de>
wrote:
> On Sun, 27 Jan 2008 06:20:47 -0800 (PST), Jeff <······@gmail.com> wrote:
>
> > It's interesting how people get sort of defensive about changing
> > common-lisp.
>
> My impression is that people aren't defensive but simply realistic.
> It's an ANSI standard and the chances of it being changed in the
> future are almost NIL. As others have said, search the archives of
> this newsgroup and you will find lots of reasons provided by the
> people who were involved why a change is extremely unlikely.
>
> > I mean, wouldn't it be nice if good regular expressions and high
> > level networking were built-in?
>
> Is it a big, big problem to add one line to your application to load a
> regular expression library or the networking support that your
> implementation offers? AFAIK this hasn't prevented anyone from
> getting things done so far. I agree that it's a favorite topic on
> c.l.l, though. People love to complain...
>
> Edi.
A good regular expression package? For Common Lisp? Are you
kidding? You have some insider knowledge? Hmm...
CL-USER> (google '(:edi :weitz :regexp))
(#<URL:HTTP-PATH http://weitz.de/regex-coach/ {48C05775}>
#<URL:HTTP-PATH http://weitz.de/cl-ppcre/ {48C5DF1D}>)
;-)
>
> --
>
> European Common Lisp Meeting, Amsterdam, April 19/20, 2008
>
> http://weitz.de/eclm2008/
>
> Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Peter Hildebrandt
Subject: Re: Arity of a closure and a Lisp Community Process
Date:
Message-ID: <op.t5lpbcolx6i8pv@babyfoot>
On Sun, 27 Jan 2008 15:43:46 +0100, Edi Weitz <········@agharta.de> wrote:
> On Sun, 27 Jan 2008 06:20:47 -0800 (PST), Jeff <······@gmail.com> wrote:
>
>> It's interesting how people get sort of defensive about changing
>> common-lisp.
>
> My impression is that people aren't defensive but simply realistic.
> It's an ANSI standard and the chances of it being changed in the
> future are almost NIL. As others have said, search the archives of
> this newsgroup and you will find lots of reasons provided by the
> people who were involved why a change is extremely unlikely.
I have been following these discussions over the past eight months or so,
and I think I understand that the ANSI standard is a great thing and that
it is nearly impossible to change it.
Yet in my (unexperienced) opinion one should separate two things:
(i) the language
(ii) standard libraries
(i) is in the standard, and this appears to be a good thing to me.
Obviously there is something timeless about a language based on mathematic
reflection, and time has shown that a language can live fifty years and
longer.
(ii) is AFAICT not standardised, since it depends on circumstances and
circumstances change inevitably. Therefore the a set of standard
libraries has to change over time (eg. -- if an example is really
necessary) tcp/ip networking)
I believe what Jeff is saying is *not* that he wants the language standard
changed, but that he wishes there was a (industry) standard for libraries.
I fully agree with this idea. It is not about changing the existing
standard, it is about establishing a community driven standard set of
libraries. This is not a formal standard (with all the problems attached
to it), but an informal, democratic standard.
Edi mentions exactly, what the use would be:
> Is it a big, big problem to add one line to your application to load a
> regular expression library or the networking support that your
> implementation offers?
In other words: with a standard set of libraries this line is *not*
dependend on what /your implementation/ offers.
One could just rely on a set of libraries being present in (most) common
lisp site installations instead of writing a long list of dependencies on
the project web site.
It makes me sad that this seems to be so hard.
A more realistic alternative would be
(i) an asdf-install that automatically installs dependencies and offers an
asdf-install:upgrade to update all installed libraries to current versions
(ii) a list of one recommended library per field to avoid duplication (one
lib for threading, one for reg exps, one for sockets, one fore general
purpose utilities (with-gensyms etc.) etc.)
Peter
> AFAIK this hasn't prevented anyone from
> getting things done so far. I agree that it's a favorite topic on
> c.l.l, though. People love to complain...
>
> Edi.
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Edi Weitz
Subject: Re: Arity of a closure and a Lisp Community Process
Date:
Message-ID: <ud4rnm30m.fsf@agharta.de>
On Sun, 27 Jan 2008 19:22:14 +0100, "Peter Hildebrandt" <·················@gmail.com> wrote:
> I have been following these discussions over the past eight months
> or so, and I think I understand that the ANSI standard is a great
> thing and that it is nearly impossible to change it.
>
> Yet in my (unexperienced) opinion one should separate two things:
>
> (i) the language
> (ii) standard libraries
>
> (i) is in the standard, and this appears to be a good thing to me.
> Obviously there is something timeless about a language based on
> mathematic reflection, and time has shown that a language can live
> fifty years and longer.
Well, the ANSI standard isn't 50 years old...
> (ii) is AFAICT not standardised, since it depends on circumstances
> and circumstances change inevitably. Therefore the a set of
> standard libraries has to change over time (eg. -- if an example is
> really necessary) tcp/ip networking)
>
> I believe what Jeff is saying is *not* that he wants the language
> standard changed, but that he wishes there was a (industry) standard
> for libraries.
>
> I fully agree with this idea. It is not about changing the existing
> standard, it is about establishing a community driven standard set
> of libraries. This is not a formal standard (with all the problems
> attached to it), but an informal, democratic standard.
>
> Edi mentions exactly, what the use would be:
>
>> Is it a big, big problem to add one line to your application to load a
>> regular expression library or the networking support that your
>> implementation offers?
>
> In other words: with a standard set of libraries this line is *not*
> dependend on what /your implementation/ offers.
No, you're wrong. A set of "standard" libraries won't change the
current situation.
There are two types of libraries:
1. The ones that add functionality which can be written in a portable
way. ASDF is one example, CL-PPCRE is another one, there are lots
of others. If I write an application that needs regular
expressions, I add the line
:depends-on (:cl-ppcre)
to its system definition. Done. Doesn't depend on my
implementation or the operating system or the phase of the moon.
2. And then there are things that can't be added to an implementation
without changing the implementation itself - FFI, MP, networking,
MOP, Gray streams being some of the most prominent examples. Every
self-respecting implementation has these features, though.
So, if I need the FFI in one of my applications, I use the FFI my
Lisp implementation has to offer. Done.
If, OTOH, I want to write a library that I want to publish and make
available to as many Lispers as possible, I use a portability layer
instead. In other words, I add a line like
:depends-on (:cffi)
to my system definition. Done. Was that so hard? (For all the
features listed above you will find a portability layer. Maybe
they're not all perfect, but if they're not, you can help make them
perfect.)
Oh, yes, I had to download and install CFFI once to make this magic
possible. Big deal...
> One could just rely on a set of libraries being present in (most)
> common lisp site installations instead of writing a long list of
> dependencies on the project web site.
>
> It makes me sad that this seems to be so hard.
How about doing something against it if it makes you sad?
> A more realistic alternative would be
>
> (i) an asdf-install that automatically installs dependencies
That exists already.
> and offers an asdf-install:upgrade to update all installed libraries
> to current versions
People are already working on this AFAIK. Check the Planet Lisp
postings from the last week for example. Join them and help if you
think that's important.
> (ii) a list of one recommended library per field to avoid
> duplication (one lib for threading, one for reg exps, one for
> sockets, one fore general purpose utilities (with-gensyms etc.)
> etc.)
How about a list of one recommended implementation? Wouldn't that be
even better? Sigh. People seem to have a problem with choice. Isn't
that supposed to be a good thing? If you come to Perl or Python or
Ruby, there's only one implemtation - take it or leave it.[*]
But if people discover Common Lisp, they sooner or later find out that
there are several high quality implementations to choose from.
Instead of being happy about this situation, it obviously makes most
of them nervous. What if I use Lisp A and I'll later find out that
Lisp B has something A doesn't have? I've heard C is faster than D,
but D has a mature Windows port while C hasn't. What to do? It seems
E is the best choice after all, but what if someone releases a new
library that only works with A, B, and D? Oh my god!!!
Anyway, I'm digressing...
I'm not going to stop others from trying to improve the Lisp
ecosystem. Lots of things have happened in the last ten years or so
and I'm sure lots more can be done. I have one advice, though:
Whatever you want to do or want to happen - there's a /guaranteed /way
to make it fail before you even started: Discuss it on c.l.l first...
HTH,
Edi.
[*] Yeah, I know that some of these languages have alternative
implementations, but as far as market share is concerned these are
mostly theoretical alternatives.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Peter Hildebrandt
Subject: Re: Arity of a closure and a Lisp Community Process
Date:
Message-ID: <op.t5l1cuapx6i8pv@babyfoot>
Edi,
you got me quite wrong here. Let me try to clear things up.
I completely agree with pretty much everything you say. The only issue is
right here:
> Oh, yes, I had to download and install CFFI once to make this magic
> possible. Big deal...
Not for you and not for me now. But it used to be a big deal for me when
I took up lisp.
Now I am looking at the problem from a different angle: recently I
planned to introduce threading into cells-gtk. Since this is a free
library, what I want is a compatibility layer. And of course I'd like to
use one which is (a) under active development and (b) used by many people
already so that I do not force every cells-gtk user to install an
otherwise useless library.
Where is a good point to find out which library to use? (And this is an
honest question. If there is an answer, I'd be most grateful. I know
about [1], but this is not quite up to date).
I stumbled accross bordeaux-threads on c.l.l, and this appears to be the
way to go.
What I'm looking for is a more systematic approach to finding the one
library/portability layer that most people use.
[1] http://www.cliki.net/Current%20recommended%20libraries
>> (i) an asdf-install that automatically installs dependencies
>
> That exists already.
...
> People are already working on this AFAIK. Check the Planet Lisp
> postings from the last week for example. Join them and help if you
> think that's important.
My apologies. I did not do my homework here. Gary King's post is pretty
much what I had in mind, but more elaborately written. Lispy looks like a
great project to answer those points.
>> (ii) a list of one recommended library per field to avoid
>> duplication (one lib for threading, one for reg exps, one for
>> sockets, one fore general purpose utilities (with-gensyms etc.)
>> etc.)
>
> How about a list of one recommended implementation? Wouldn't that be
> even better? Sigh. People seem to have a problem with choice. Isn't
> that supposed to be a good thing? If you come to Perl or Python or
> Ruby, there's only one implemtation - take it or leave it.[*]
Not with choice per se. Only with the lack of a road map (or some other
appropriate tool to handle it efficiently).
Obviously there is a point in having different implementations, and in
having different packages for eg. web servers. However, I do not see the
value in having two different thread portability layers. That is more
like a waste of ressources.
> I'm not going to stop others from trying to improve the Lisp
> ecosystem. Lots of things have happened in the last ten years or so
> and I'm sure lots more can be done. I have one advice, though:
> Whatever you want to do or want to happen - there's a /guaranteed /way
> to make it fail before you even started: Discuss it on c.l.l first...
Well, I got a few good pointers out of this discussion, so I think it was
very much worth it.
Thanks,
Peter
>
> HTH,
> Edi.
>
>
> [*] Yeah, I know that some of these languages have alternative
> implementations, but as far as market share is concerned these are
> mostly theoretical alternatives.
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Edi Weitz
Subject: Re: Arity of a closure and a Lisp Community Process
Date:
Message-ID: <u63xdftob.fsf@agharta.de>
On Sun, 27 Jan 2008 23:42:20 +0100, "Peter Hildebrandt" <·················@gmail.com> wrote:
> you got me quite wrong here.
OK. That wasn't my intention, of course.
> I completely agree with pretty much everything you say. The only
> issue is right here:
>
>> Oh, yes, I had to download and install CFFI once to make this
>> magic possible. Big deal...
>
> Not for you and not for me now. But it used to be a big deal for me
> when I took up lisp.
Yes, for me as well. (And things were much worse back then.) But you
got over it pretty fast and so did I. If you're trying something new
or if you're doing something you're not accustomed to, there'll always
be some obstacles. I think they call that "learning curve". Knowing
how to use your tools (and finding, installing, and loading libraries
belong in that category) is an integral part of that, although
probably not the most important one.
> However, I do not see the value in having two different thread
> portability layers. That is more like a waste of ressources.
For some areas it certainly doesn't make sense to have different
portability layers, for example for Gray streams. And AFAIK there
also is only one. Likewise for the MOP.
For other areas it is not that easy. What the different
implementations have to offer might be so diverse that it is hard to
fit all of that under one umbrella. You might end up losing
functionality if you opt for the LCD approach, but there might still
be good reasons to do that anyway. But there might also be a good
reason to have, cough, choice.
Two examples:
- Foreign function interfaces. Read the archives of the UFFI and
CLSQL mailing lists and ask yourself why CFFI was invented when UFFI
was already there and some kind of "standard". Does that make UFFI
obsolete? Also, does CFFI cover /everything/ the LispWorks FFI (for
example) has to offer? (Hint: The answer is no.)
- Threads: Think about the huge differences between "green" user land
threads (for example CMUCL and old versions of LispWorks) and real
SMP (like in Scieneer, OpenMCL, some versions of SBCL). Do you
think it will be able to write /one/ portability layer that can do
justice to both?
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On Jan 27, 9:23 pm, Edi Weitz <········@agharta.de> wrote:
> On Sun, 27 Jan 2008 19:22:14 +0100, "Peter Hildebrandt" <·················@gmail.com> wrote:
> > I believe what Jeff is saying is *not* that he wants the language
> > standard changed, but that he wishes there was a (industry) standard
> > for libraries.
Yup, that would be great.
> > I fully agree with this idea. It is not about changing the existing
> > standard, it is about establishing a community driven standard set
> > of libraries. This is not a formal standard (with all the problems
> > attached to it), but an informal, democratic standard.
Exactly.
> >> Is it a big, big problem to add one line to your application to load a
> >> regular expression library or the networking support that your
> >> implementation offers?
Sure, using asdf-install and just requiring libraries is fine. I
think if a community of people is sitting on top of a common set of
libraries they tend to get much better, much faster. In addition, by
trying to create a cohesive core of libraries they can share coding
style and common utilities that can then be used by others. This is
especially helpful for new people, but I don't think it's a bad idea
to be nice to newbies. Especially in a world where we would like to
see lisp better respected and more often used, thus providing lisp
jobs, lisp oriented research and in general a richer lisp ecosystem.
> People are already working on this AFAIK. Check the Planet Lisp
> postings from the last week for example. Join them and help if you
> think that's important.
In one of these very posts (http://metabang.com/unclogit/?p=242), I
think Gary King spells out pretty clearly what are some of the
problems in the lisp library world. Having a more streamlined install
and library management mechanism like he is describing will surely
help, but having a common set of libraries would help more. If
anything it's a body of code for people to rally around. Maybe it
just needs someone to start it. I would nominate you Mr. Weitz! :-)
Master of the common lisp library collection. I mean, you sort of are
already...
> I'm not going to stop others from trying to improve the Lisp
> ecosystem. Lots of things have happened in the last ten years or so
> and I'm sure lots more can be done. I have one advice, though:
> Whatever you want to do or want to happen - there's a /guaranteed /way
> to make it fail before you even started: Discuss it on c.l.l first...
So it seems. This is a problem though. Maybe we need a new list
where people can actually help each other and talk about ideas for the
future of lisp without being slammed by the old guard after even a
brief mention of that terrible thing called change...
Thanks for your thoughtful responses Edi.
-Jeff
Jeff wrote:
> On Jan 27, 9:23 pm, Edi Weitz <········@agharta.de> wrote:
>>I'm not going to stop others from trying to improve the Lisp
>>ecosystem. Lots of things have happened in the last ten years or so
>>and I'm sure lots more can be done. I have one advice, though:
>>Whatever you want to do or want to happen - there's a /guaranteed /way
>>to make it fail before you even started: Discuss it on c.l.l first...
>
>
> So it seems. This is a problem though. Maybe we need a new list
> where people can actually help each other and talk about ideas for the
> future of lisp without being slammed by the old guard after even a
> brief mention of that terrible thing called change...
>
> Thanks for your thoughtful responses Edi.
Here's my thoughtful response. Lisp needs programmers, not bullsh*t
artists who the first thing they think of is a processs or an
organization or a fricking /mechanism/ as opposed to actually creating
some code. The good news is that we now get ANNCs of new libs here in
c.l.l about as often as we get you idiot saviors who know exactly what
is wrong with this fifty year old language after three chapters of PCL.
Why don't you just STFU and create a frickin library? Edi creates
libraries, I create libraries, I mentor Google projects to create
libraries actually needed to program applications. The old guard is not
the problem, Lisp noobs like you who do nothing but talk are the
problem. Lisp noobs that help out on projects are not the problem.
See a pattern? Now please try Ruby, I hear it rocks. Great libraries,
does not even /have/ an old guard.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: Edi Weitz
Subject: Re: Arity of a closure and a Lisp Community Process
Date:
Message-ID: <uabmpfukw.fsf@agharta.de>
On Mon, 28 Jan 2008 06:45:19 -0800 (PST), Jeff <······@gmail.com> wrote:
> So it seems. This is a problem though. Maybe we need a new list
> where people can actually help each other and talk about ideas for
> the future of lisp without being slammed by the old guard after even
> a brief mention of that terrible thing called change...
You are too touchy... :)
Try this:
http://www.lispniks.com/cl-gardeners/
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de> writes:
> On Sun, 27 Jan 2008 06:20:47 -0800 (PST), Jeff <······@gmail.com> wrote:
>
>> It's interesting how people get sort of defensive about changing
>> common-lisp.
>
> My impression is that people aren't defensive but simply realistic.
> It's an ANSI standard and the chances of it being changed in the
> future are almost NIL. As others have said, search the archives of
> this newsgroup and you will find lots of reasons provided by the
> people who were involved why a change is extremely unlikely.
>
>> I mean, wouldn't it be nice if good regular expressions and high
>> level networking were built-in?
>
> Is it a big, big problem to add one line to your application to load a
> regular expression library or the networking support that your
> implementation offers?
No if it's really that simple. However I just can say that I had much
more trouble getting many Common Lisp libraries working, agreed there
are what I'd call exceptons-to-the-rule but I just have found that a
lot of things simply do not work out-of-the-box. And that is
annoying. I thought about a web page on which one just collects how
easy/difficult the installation and usage of diverse libraries really
is. I know at least one which I would expect to grade very good BTW
;-)
>AFAIK this hasn't prevented anyone from
> getting things done so far. I agree that it's a favorite topic on
> c.l.l, though. People love to complain...
Well maybe, but not every complain is spurious.
Regards
Friedrich
--
Please remove just-for-news- to reply via e-mail.
Friedrich Dominicus wrote:
> No if it's really that simple. However I just can say that I had much
> more trouble getting many Common Lisp libraries working, agreed there
> are what I'd call exceptons-to-the-rule but I just have found that a
> lot of things simply do not work out-of-the-box. And that is
> annoying.
Really? I have not yet had any significant problem with a Common Lisp
library from a package advertised as stable. I have encountered a few
bugs, to be sure, but I have encountered a few bugs in just about any
software I have ever used. In fairness, I've really only used a few:
ASDF, ASDF-install, ASDF-binary-locations, cffi, cl-ppcre, clx, esa,
flexichain, iterate, swank, clsql, md5, and uffi. And I am only using
these as a hobbyist. Of course, if I were ever to find myself in the
fortunate position of writing lisp for pay and not just for fun, I would
also probably consider purchasing one of the commercial lisp
implementations, which tend to include many quality libraries which are
well documented and supported.
Friedrich Dominicus wrote:
> No if it's really that simple. However I just can say that I had much
> more trouble getting many Common Lisp libraries working,...
It works like this. If I am just looking out of curiosity, my tolerance
is zero. I guess it is like Lisp and parentheses -- the only people who
are bothered by them are tire kickers. If I am Actually Working
(something most of you yobbos do not know about unless it is something
really important like a peephole optimizer for sbcl) I understand I will
have to do some work to get /anything/ working.
This is because Lisp is not dead but the community still is, so we have
occasional demonic bursts of energy from random open source fairies who
then realize how much frickin work it takes to actually maintain a
library so well that it becomes plug-n-play on any lisp on any OS and
say fuck it.
Your problem is that people skilled and creative enough to be open
source fairies have better things to do with their time than hold the
ungrateful hands of people who discover the gold you gave them is only
12 karats and get annoyed.
So what is needed is a larger community of Live Bodies to take the baton
and add polish to Lisp open source or even just its documentation when
they like a library. Mr Hildebrandt happens to be doing both in re
cells-gtk and because of that I am taking time to port it to Cells3 and
help him do ODEci (ODE w/ Cells Inside(tm)) so good things happen when
people roll up their sleeves and nothing happens when the Lisp Living
Dead whine about the state of libraries.
> agreed there
> are what I'd call exceptons-to-the-rule but I just have found that a
> lot of things simply do not work out-of-the-box. And that is
> annoying. I thought about a web page on which one just collects how
> easy/difficult the installation and usage of diverse libraries really
> is. I know at least one which I would expect to grade very good BTW
> ;-)
I see. You have the energy to review all these libraries and put up a
web page of results -- oh, wait, you are only talking. But it would be
funny if you did. Lispers: Unlimited Energy for Whining, Zero Energy for
constructive work.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Ken Tilton <···········@optonline.net> writes:
> I see. You have the energy to review all these libraries and put up a
> web page of results -- oh, wait, you are only talking. But it would be
> funny if you did. Lispers: Unlimited Energy for Whining, Zero Energy
> for constructive work.
This answer is absolutly useless, I spend more time on
getting somewhere with some libraries and guess what: I even dared to
write about that which has took me a lot of time. But wait I'm just
one of thos annoying library users and not developers, which feel it's
funky to just say "use the source luke". Well I see it's just my
fault. You attitude is all to typcial. Who cares for the users of the
library.., I surely not.
So keep on writing your code....
Friedrich
--
Please remove just-for-news- to reply via e-mail.
From: Ken Tilton
Subject: ANNC: Cells-Gtk: In Search of Cells3 [was Re: Arity of a closure and a Lisp Community Process]
Date:
Message-ID: <479edf70$0$6371$607ed4bc@cv.net>
Friedrich Dominicus wrote:
> Ken Tilton <···········@optonline.net> writes:
>
>
>>I see. You have the energy to review all these libraries and put up a
>>web page of results -- oh, wait, you are only talking. But it would be
>>funny if you did. Lispers: Unlimited Energy for Whining, Zero Energy
>>for constructive work.
>
> This answer is absolutly useless, I spend more time on
> getting somewhere with some libraries and guess what: I even dared to
> write about that which has took me a lot of time.
Damn it man, let's go shopping!
No, you are right, it is a total PITA. Until we push those other
languages into the sea and enslave the their captured users we just
won't have the resources needed to turn one developer's personal gem
into a portable, easily-installed, well-documented open source package.
Someone spoke to Lisp-NYC about that big Lisp math lib and grabbed me
with the analysis of how the laws of threes made open source projects 27
times harder than doing something for yourself. Having wasted god only
knows how many hours on you ungrateful yobbos...well, I knew the 27 was
no joke. What needs to change is Lispers, not Lisp. And the way to get
better Lisp libraries is to work on them, not whine about them and
defintely not to create another Lisp Gardeners? Other communities show
their enthusiasm for their language by pitching in to make things
happen. Lispers hang out on c.l.l and moan about crappy open source
libraries which is really funny because they do not realize that open
source software is created by people like them so I am picturing a mob
of whining Lispers complaining about the libraries to their reflection
in a big mirror. I was joking people there is no open source fairy, stop
checking under your pillow. Anyone opening their big yap on this issue
better be able to document two libraries they have helped out on and the
one they are helping on now. At a minimum. I need a snappy line about
not asking what others can do for you, rather... I need a finish.
The commonplace whine is that there are many projects out there in
half-baked, unmaintained form. Hello? Figured it out yet? The answer is
26. Creating the project had a cost of 1, making it a package costs 26
more. That's you, OK?
A few people make decent libraries, then they decide the world might
like it, too, so they put it up on c-l.net. End of story, unfortunately,
mostly because you people really do not actually program computers with
Lisp or we'd be hearing about your cool projects and if you did then you
would end up using the libraries and then contributing to them. Everyone
wishes they could use Lisp on the job. No, you wish you could be
programming in Lisp. You can be. Just Do It. rah rah sis boom bah.
No, seriously write a hobby program for yourself or something to help an
old folks home I don't know just write some Lisp, you'll need some
libraries, get them working and leave a trail of bread crumbs for others
to follow (documentation, patches for other Lisps/OSes). I am going to
win this argument because Peter Hildebrandt is doing the poster boy
thing on this as we speak, adding a significant extension to cells-gtk
(after fighting tooth and nail to get all sorts of libraries working,
still tricky even though former o/s poster boy Peter Denno made
cells-gtk into a fine and documented package and made a nice enhancement
by porting to CFFI and adding widgets which really only makes my point).
What was my point?
> But wait I'm just
> one of thos annoying library users and not developers, which feel it's
> funky to just say "use the source luke".
No, some of us released our libraries in the hope of getting others to
pitch in. I have actually seen some stellar input, Frank Goenninger
being a standout and Ilias helped out a lot with Cells, but when I think
of how much work I went thru sharing my code even with the stellar input
I have to say it's a net loss. Sadly because Lispers are so useless as a
rule.
> Well I see it's just my
> fault. You attitude is all to typcial. Who cares for the users of the
> library.., I surely not.
Nonsense! We /shared/ the code, didn't we? Doing so cost us an enormous
amount of time and grief. Shuuu-uhhhh-uuut up! Besides...
It would not do any good if we shrink-wrapped the damn stuff, came over
and installed it for free and gave you a week of training. You all just
are not doing any programming, if you were you would be using the
libraries and getting help from the original developers most likely. I
went thru that on the user end with cl-s3 because I am working on an
application (oops, I used the "A" word). But you are not writing A's so
you kinda need an excuse so you say Damn libraries! Ha, it's like my
excuses for putting that workout program off just one extra day -- I can
always find one and don't let me make that sound like it is hard to do.
I just don't want to tear my fat ass away from this computer. Where was I?
>
> So keep on writing your code....
Thanks. I just put this up:
http://common-lisp.net/cgi-bin/viewcvs.cgi/cells-gtk/?root=cells
That is baby step #1 of Cells-Gtk ala Cells3, which is alongside it in
the same repository. Otherwise it is standalone and includes a copy of
CFFI (not current, but we may try).
All the demos stagger to the starting gate and function on the basics,
but gaping holes remain that will take you straight back to the OS. I
eagerly await the assistance from the hordes of Lisp users of
PWUAHAHAHAHHAHAHAHAHAHA I kill myself so it will become another
unmaintained buggy undocumented library and I'll get the blame thank you
very much.
We are doing this so Peter Hildebrandt -- hmmm, Peter Herth, Peter Denno
... I must think on this -- can do cells-ode (the name says it all, but
given the precedent set by Edi with Hunchentoot I have suggested he name
it The Suez Canal. Next step will be a using list of :cells :cl-ode
:kt-opengl, just begging to be named Grain Alcohol.
What open source did you do today?
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Ken Tilton <···········@optonline.net> writes:
> Friedrich Dominicus wrote:
>> Ken Tilton <···········@optonline.net> writes:
>>
>>>I see. You have the energy to review all these libraries and put up a
>>>web page of results -- oh, wait, you are only talking. But it would be
>>>funny if you did. Lispers: Unlimited Energy for Whining, Zero Energy
>>>for constructive work.
>> This answer is absolutly useless, I spend more time on
>> getting somewhere with some libraries and guess what: I even dared to
>> write about that which has took me a lot of time.
>
>
> Damn it man, let's go shopping!
Good idea
>
>
> Thanks. I just put this up:
>
> http://common-lisp.net/cgi-bin/viewcvs.cgi/cells-gtk/?root=cells
>
> That is baby step #1 of Cells-Gtk ala Cells3, which is alongside it in
> the same repository. Otherwise it is standalone and includes a copy of
> CFFI (not current, but we may try).
>
> All the demos stagger to the starting gate and function on the basics,
> but gaping holes remain that will take you straight back to the OS. I
> eagerly await the assistance from the hordes of Lisp users of
> PWUAHAHAHAHHAHAHAHAHAHA I kill myself so it will become another
> unmaintained buggy undocumented library and I'll get the blame thank
> you very much.
Yeah I see, you're live is incredible hard. Such an eloquent Lisper and just
thankless morons. Bad day, I'm sorry to not "make your day"
Regards
Friedrich
--
Please remove just-for-news- to reply via e-mail.
Ken Tilton <···········@optonline.net> writes:
>> Well I see it's just my
>> fault. You attitude is all to typcial. Who cares for the users of the
>> library.., I surely not.
>
> Nonsense! We /shared/ the code, didn't we? Doing so cost us an
> enormous amount of time and grief. Shuuu-uhhhh-uuut up! Besides...
You just wrote the code for yourself and was thinking, ey that's
nifty. Let's see if other find it useful and then you put it out. And
guess what not all people can just follow your brilliant programming excursions.
>
> It would not do any good if we shrink-wrapped the damn stuff, came
> over and installed it for free and gave you a week of training. You
> all just are not doing any programming, if you were you would be using
> the libraries and getting help from the original developers most
> likely.
You're damn right, I just wanted to try to understand a totalyl
undocumented piece of software just to see whether there is something
one can learn. But I should have known better and that's my
fault, I should not expect anything from your stuff. If it happens to
be useful by accident then hey, I got something...
So long I can crawl back to the so bad C tools and keep whining
there.
Friedrich
--
Please remove just-for-news- to reply via e-mail.
Friedrich Dominicus wrote:
> Ken Tilton <···········@optonline.net> writes:
>
>
>>>Well I see it's just my
>>>fault. You attitude is all to typcial. Who cares for the users of the
>>>library.., I surely not.
>>
>>Nonsense! We /shared/ the code, didn't we? Doing so cost us an
>>enormous amount of time and grief. Shuuu-uhhhh-uuut up! Besides...
>
> You just wrote the code for yourself and was thinking, ey that's
> nifty. Let's see if other find it useful and then you put it out. And
> guess what not all people can just follow your brilliant programming excursions.
Well, the rest fall into these pie slices:
-- never emailed me for help. I cannot tell you anything about them,
except that they include Vasily Margioulas, original author of Cells-gtk
who astonishingly started from nothing but an early Celtk to pull off
Cells-Gtk as an /experiment/ in software engineering.
-- emailed me for help and got along fine after one/two emails
> You're damn right, I just wanted to try to understand a totalyl
> undocumented piece of software just to see whether there is something
> one can learn. But I should have known better...
Yes, I was much happier after realizing my work got no support because
you all are losers, you'll be much happier after accepting that all us
library authors are deliberately torturing you with bad installation
directions... hang on... we could just pull off your toenails... can I
get back to you?
>... and that's my
> fault, I should not expect anything from your stuff. If it happens to
> be useful by accident then hey, I got something...
Probably an asteroid up your wazoo, cuz I think that will happen before
you accidentally build any of my libraries.
>
> So long I can crawl back to the so bad C tools and keep whining
> there.
No, wait, please! Don't go!....PWUAAHAHHAHAAHA, sorry I tried....
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Ken Tilton <···········@optonline.net> writes:
>
> Yes, I was much happier after realizing my work got no support because
> you all are losers,
I guess you love this sentence.
> you'll be much happier after accepting that all
^^^
don't we exagerate a bit? I can't remember written about all, some
sure, some really do care and some just are like you. If the user do
not knee down for your majestiy brilliance and just point out that
it's not easy to set up then we can simply start putting them
down. It's much more fun I guess....
> us
> library authors are deliberately torturing you with bad installation
> directions... hang on... we could just pull off your toenails... can I
> get back to you?
I'm afraid my toonails belong to me. So I want sacrifice them for his
majesty.
>
> Probably an asteroid up your wazoo, cuz I think that will happen
> before you accidentally build any of my libraries.
Accidently I build one library, but it was useless because I could not
use it.
>
>> So long I can crawl back to the so bad C tools and keep whining
>> there.
>
> No, wait, please! Don't go!....PWUAAHAHHAHAAHA, sorry I tried....
Well Kenny you tried really hard, I'm sorry to disappoint you. I wish
you a good laugh and a happy
lisping
Friedrich
--
Please remove just-for-news- to reply via e-mail.
Ken Tilton <···········@optonline.net> writes:
>
> Probably an asteroid up your wazoo, cuz I think that will happen
> before you accidentally build any of my libraries.
You loose I got that stuff comiled (while not used; but I guess that
will count as success)
>
> No, wait, please! Don't go!....PWUAAHAHHAHAAHA, sorry I tried....
>
Yes you tried and I spend a few hours on that stuff. Congrats, at
least one you could capture.
Have nice day
Friedrich
--
Please remove just-for-news- to reply via e-mail.
Friedrich Dominicus wrote:
> Ken Tilton <···········@optonline.net> writes:
>
>
>>Probably an asteroid up your wazoo, cuz I think that will happen
>>before you accidentally build any of my libraries.
>
> You loose I got that stuff comiled (while not used; but I guess that
> will count as success)
>
>
>>No, wait, please! Don't go!....PWUAAHAHHAHAAHA, sorry I tried....
>>
>
> Yes you tried and I spend a few hours on that stuff. Congrats, at
> least one you could capture.
>
> Have nice day
You, too, and good luck with your projects, whatever language you use,
even Q. :)
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: Sohail Somani
Subject: Re: Arity of a closure and a Lisp Community Process
Date:
Message-ID: <Ryomj.28447$yQ1.20276@edtnps89>
On Fri, 25 Jan 2008 08:36:03 -0800, Jeff wrote:
> How do I figure out the arity of a closure? (I'm writing a generic
> event system, and I'd like to pass the correct number of arguments to
> handlers based on their definition, rather than requiring some arity-
> interface.)
I'm probably missing something obvious, but why not just use (apply
handler all-possible-args) and just have the handlers use &rest to ignore
the ones they don't care about?
--
Sohail Somani
http://uint32t.blogspot.com
From: Edi Weitz
Subject: Re: Arity of a closure and a Lisp Community Process
Date:
Message-ID: <usl0llum1.fsf@agharta.de>
On Fri, 25 Jan 2008 08:36:03 -0800 (PST), Jeff <······@gmail.com> wrote:
> How do I figure out the arity of a closure? (I'm writing a generic
> event system, and I'd like to pass the correct number of arguments
> to handlers based on their definition, rather than requiring some
> arity- interface.)
>
> A list search finds that this isn't possible even for functions, at
> least in a portable way, which makes me very doubtful of closures.
> Any suggestions would be greatly appreciated though.
If you don't insist on writing in a portable way, it should be
possible. Or the system could send compound objects instead of
closures around, for example a cons (N . <closure>) where N is the
arity. No big deal, I'd say, and completely portable.
Why this makes you "doubtful of closures" escapes me, though.
Depending on the compilation strategy a closure can simply be a blob
of machine code the system is supposed to execute. If the standard
required each and every implementation to always make the (Lisp)
argument lists of these closures available to the code, that'd be a
severe problem for vendors trying to generate efficient code.
(Don't forget that it's not only about the number of required
arguments - there's also &OPTIONAL, &KEY, &REST. And, depending on
declarations or its own analysis, the compiler might have decided to
modify the "effective" argument list.)
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Richard M Kreuter
Subject: Re: Arity of a closure and a Lisp Community Process
Date:
Message-ID: <871w85ohrb.fsf@progn.net>
Jeff <······@gmail.com> writes:
> I started off with a practical question:
>
> How do I figure out the arity of a closure?
There is probably no portable way to do this.
> (I'm writing a generic event system, and I'd like to pass the
> correct number of arguments to handlers based on their definition,
> rather than requiring some arity- interface.)
I can think of several approaches:
(1) Have the event handler functions take &rest arguments, and process
their argument lists "manually";
(2) Have some machinery that records, for each event handler you
construct, the number of arguments that that handler takes, and
have the event handler invocation machinery look up the number of
arguments recorded for the event handler;
(3) Don't pass many arguments to the event handler, but pass a data
structure that collects an event's properties into one object (a
list, a structure, a CLOS instance, etc.);
I'd probably lean toward (3), since if you represent events as typed
objects, you can foist off the dispatch work onto generic function
machinery.
> On a larger note, is there any kind of community process to evolve
> common-lisp?
This gets discussed ad nauseam every few months. Please google.
--
RmK
J> How do I figure out the arity of a closure? (I'm writing a generic
J> event system, and I'd like to pass the correct number of arguments to
J> handlers based on their definition, rather than requiring some arity-
J> interface.)
correct number of arguments? if it asks 20 arguments, where would it take it
from?
if your closures require from 0 to 5 arguments, just pass all of them -- and
write your closures as (lambda (a b c &rest ignored) ...), you can make a
macro to do this if you wish.
you can also use keyword arguments and specify &allow-other-keys.
this is pretty interesting.. suppose you have closure-arity function. how
will you use it?
J> On a larger note, is there any kind of community process to evolve
J> common-lisp?
you need to evolve common lisp because you have some wicked ideas?
there is MOP stuff like funcallable-standard-object, this way you can make
sort of function and attach information (like arity) to it, but i'm pretty
sure there's easier way..
Jeff wrote:
> I started off with a practical question:
>
> How do I figure out the arity of a closure? (I'm writing a generic
> event system, and I'd like to pass the correct number of arguments to
> handlers based on their definition, rather than requiring some arity-
> interface.)
>
> A list search finds that this isn't possible even for functions, at
> least in a portable way, which makes me very doubtful of closures.
> Any suggestions would be greatly appreciated though.
As other people already suggested, it's probably best to have &rest or
&key arguments, pass everything, and just ignore what you don't need.
If you insist on checking the arity, function-lambda-expression _may_
give what you need. (A Common Lisp implementation is not required to
support this.)
If you have access to the CLOS MOP, you can build your own function
class and support it yourself. The rough idea is this:
(defclass function-with-arity (funcallable-standard-object)
((min-arity :initarg :min-arity :reader min-arity))
(:metaclass funcallable-standard-class))
(defun make-function-with-arity (lambda-list body)
(let ((fun (make-instance 'function-with-arity
:min-arity (loop for arg in lambda-list
until (member arg lambda-list-keywords)
count t))))
(set-funcallable-instance-function
(compile nil `(lambda ,lambda-list ,@body)))
fun))
(defmacro alambda ((&rest lambda-list) &body body)
`(make-function-with-arity ',lambda-list ',body))
[Note: Untested. Especially the test for lambda-list-keywords probably
needs more care.]
> On a larger note, is there any kind of community process to evolve
> common-lisp? It would be great if there were some kind of forum for
> proposing, discussing and voting on feature additions and
> modifications, which could then be taken up by the various compilers.
> Companies tend to be horrible at making this type of thing work
> because they have to defend their vested interests, but at least the
> open source projects could do this. Anyone ever try? Thoughts,
> ideas, server donations?
False assumptions: The Lisp companies are our friends, because they want
us to succeed. What you say is true of huge software companies, like
Microsoft, IBM, Sun, Apple, and so on. Lisp companies are not huge.
Apart from that, try the Common Lisp Document Repository.
Pascal
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
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: Edi Weitz
Subject: Re: Arity of a closure and a Lisp Community Process
Date:
Message-ID: <u8x2dprbc.fsf@agharta.de>
On Fri, 25 Jan 2008 21:34:52 +0100, Pascal Costanza <··@p-cos.net> wrote:
> False assumptions: The Lisp companies are our friends, because they
> want us to succeed. What you say is true of huge software companies,
> like Microsoft, IBM, Sun, Apple, and so on. Lisp companies are not
> huge.
Good point. Look at this for example
http://www.lispworks.com/lambda-express.html
and imagine Microsoft or Apple doing something like that... :)
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Sohail Somani
Subject: Re: Arity of a closure and a Lisp Community Process
Date:
Message-ID: <6ftmj.43079$fj2.4349@edtnps82>
On Fri, 25 Jan 2008 21:45:43 +0100, Edi Weitz wrote:
> Good point. Look at this for example
>
> http://www.lispworks.com/lambda-express.html
>
> and imagine Microsoft or Apple doing something like that...
Microsoft rented out Universal Studios or something at one point for one
of their conferences. To me, that smells of "pay no attention to the man
behind the curtain!" Certainly no good when it comes to technology
anyway. But the people who went definitely had a good time :-)
--
Sohail Somani
http://uint32t.blogspot.com
From: Edi Weitz
Subject: Re: Arity of a closure and a Lisp Community Process
Date:
Message-ID: <u8x2dmt66.fsf@agharta.de>
On Fri, 25 Jan 2008 22:18:42 GMT, Sohail Somani <······@taggedtype.net> wrote:
> Microsoft rented out Universal Studios or something at one point for
> one of their conferences. To me, that smells of "pay no attention to
> the man behind the curtain!" Certainly no good when it comes to
> technology anyway. But the people who went definitely had a good
> time :-)
Hey, if you come to the ECLM, you can have a boat tour through
Amsterdam! Who wants to go to the lame Universal Studios instead?
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Sohail Somani
Subject: Re: Arity of a closure and a Lisp Community Process
Date:
Message-ID: <eHtmj.43312$fj2.30566@edtnps82>
On Fri, 25 Jan 2008 23:33:53 +0100, Edi Weitz wrote:
> On Fri, 25 Jan 2008 22:18:42 GMT, Sohail Somani <······@taggedtype.net>
> wrote:
>
>> Microsoft rented out Universal Studios or something at one point for
>> one of their conferences. To me, that smells of "pay no attention to
>> the man behind the curtain!" Certainly no good when it comes to
>> technology anyway. But the people who went definitely had a good time
>> :-)
>
> Hey, if you come to the ECLM, you can have a boat tour through
> Amsterdam! Who wants to go to the lame Universal Studios instead?
Very tempting but we will be having Sohail 3.0 soon! I will try to make
it to the next CLM though.
Though I didn't go at the time of the MS conference, Universal Studios is
*a lot* of fun. Atleast it was when I was a kid.
--
Sohail Somani
http://uint32t.blogspot.com
Jeff wrote:
> I started off with a practical question:
>
> How do I figure out the arity of a closure? (I'm writing a generic
> event system, and I'd like to pass the correct number of arguments to
> handlers based on their definition, rather than requiring some arity-
> interface.)
Someone asked but you did not reply, and I am quite curious: if you did
know the number, how would you know which bits of data to pass to whom?
Somebody might want A, B, and C, somebody else might want B and D.
I realize the problem has gone away because you are going with an event
data structure (the best thing, IMO), but I am still curious as to your
original plan. I am curious because in the end this seems to be a
classic case of a noob overwhelmed by the Unbearable Richness of Common
Lisp not knowing which bit to leverage when. Don't worry, you'll get
past that in about ten years if you program Lisp continuously.
>
> A list search finds that this isn't possible even for functions, at
> least in a portable way, which makes me very doubtful of closures.
> Any suggestions would be greatly appreciated though.
If for some reason your requirement was not better handled by having an
event structure, you would use macrology:
(defhandler mouse-tracker (time position time shift-key-down?)
....)
Where mouse-tracker would be a name you could use when registering the
handler and the parameters would be a bit like keywords in a language in
that you'd have to use those names cuz those are the ones the dispatcher
is hard-coded for. (You could have the macro look for miscoded
parameters, so this is not too onerous and there are not that many event
attributes anyway.)
The defhandler macro would then store parameter list info as, say, a
property-list attribute ('my-groovy-parameters?) on the symbol
'mouse-tracker. the dispatcher would look to that property on the
handler name to see what data to cobble together for the handler.
>
> On a larger note, is there any kind of community process to evolve
> common-lisp?
There /is/ a community process, but it is dedicated to keeping CL stuck
in the 80s and impervious to improvement. Mostly our work involves
hunting down people like you.
> It would be great if there were some kind of forum for
> proposing, discussing and voting on feature additions and
> modifications, which could then be taken up by the various compilers.
Try #lisp IRC.
> Companies tend to be horrible at making this type of thing work
> because they have to defend their vested interests, but at least the
> open source projects could do this. Anyone ever try? Thoughts,
> ideas, server donations?
Yeah. Get to work. Either using CL as it is, which is fine thanks very
much, or /producing/ a library such as CFFI or cl-ppcre which became
unwritten standards by being portable, useful, and good.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Jan 27, 7:54 pm, Ken Tilton <···········@optonline.net> wrote:
> Jeff wrote:
> > I started off with a practical question:
>
> > How do I figure out the arity of a closure? (I'm writing a generic
> > event system, and I'd like to pass the correct number of arguments to
> > handlers based on their definition, rather than requiring some arity-
> > interface.)
>
> Someone asked but you did not reply, and I am quite curious: if you did
> know the number, how would you know which bits of data to pass to whom?
> Somebody might want A, B, and C, somebody else might want B and D.
In javascript, for example, you can do this:
function foo(a) { alert(a) }
foo(2, 3, 5)
In my event system I'd like to save the user from having to understand
details of how things are working in the back-end. Having to define
every handler using a &rest argument definition is lame unless you
actually need &rest arguments. I would have looked at the arity of a
handler and pass the arguments in order up until I hit the arity
limit.
> I realize the problem has gone away because you are going with an event
> data structure (the best thing, IMO), but I am still curious as to your
> original plan. I am curious because in the end this seems to be a
> classic case of a noob overwhelmed by the Unbearable Richness of Common
> Lisp not knowing which bit to leverage when. Don't worry, you'll get
> past that in about ten years if you program Lisp continuously.
Actually I think this is an unbearable lack of common introspection
features which are easily found in languages which are allowed to
evolve. I'm sure it takes time to become a good lisp hacker, and
luckily I've got patience. I also promise that when I do arrive there
I won't be acting like an arrogant prick while responding to questions
on the mailing list.
-Jeff
Jeff <······@gmail.com> writes:
> I started off with a practical question:
>
> How do I figure out the arity of a closure? (I'm writing a generic
> event system, and I'd like to pass the correct number of arguments to
> handlers based on their definition, rather than requiring some arity-
> interface.)
>
> A list search finds that this isn't possible even for functions, at
> least in a portable way, which makes me very doubtful of closures.
> Any suggestions would be greatly appreciated though.
Of course, there is FUNCTION-LAMBDA-EXPRESSION, which is the portable
way to get the info you need, when it's available. The problem being
that CL implementations are allowed to compile to very tight and
optimized code so this kind of information is allowed to be discarded
at run-time.
That's why to do what you want portably, you'll need to wrap your
event handlers (your "closures") in your own macro that will do the
bookkeeping you need.
> On a larger note, is there any kind of community process to evolve
> common-lisp?
There's the CLRFI process. http://clrfi.alu.org/
--
__Pascal Bourguignon__
Pascal J. Bourguignon wrote:
> Jeff <······@gmail.com> writes:
>
>
>>I started off with a practical question:
>>
>>How do I figure out the arity of a closure? (I'm writing a generic
>>event system, and I'd like to pass the correct number of arguments to
>>handlers based on their definition, rather than requiring some arity-
>>interface.)
>>
>>A list search finds that this isn't possible even for functions, at
>>least in a portable way, which makes me very doubtful of closures.
>>Any suggestions would be greatly appreciated though.
>
>
> Of course, there is FUNCTION-LAMBDA-EXPRESSION, which is the portable
> way to get the info you need, when it's available. The problem being
> that CL implementations are allowed to compile to very tight and
> optimized code so this kind of information is allowed to be discarded
> at run-time.
>
> That's why to do what you want portably, you'll need to wrap your
> event handlers (your "closures") in your own macro that will do the
> bookkeeping you need.
Look, as always when someone asks for something Lisp cannot do it is
because they are completely confused about how to do what they think
they want to do so let's not encourage them, ok? Pick up that stick and
whack them upside the head, see what bleeds out.
>
>
>
>>On a larger note, is there any kind of community process to evolve
>>common-lisp?
>
>
> There's the CLRFI process. http://clrfi.alu.org/
>
PWUAHAHAHAHHAHAA, you slay me:\
"At present, the only two CLRFI exists. CLRFI number 1, CLRFI: 1:
FEATUREP, is very much a "trial" CLRFI; it's so trivial as to contain
almost no technical content..."
If Columbus had been a Lisper we'd all be speaking European.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Jan 25, 8:36 am, Jeff <······@gmail.com> wrote:
> I started off with a practical question:
>
> How do I figure out the arity of a closure? (I'm writing a generic
> event system, and I'd like to pass the correct number of arguments to
> handlers based on their definition, rather than requiring some arity-
> interface.)
If there is a finite repertoire of such definitions, then group them
into subsets. Each subset has its own corresponding registration
chain. When you register a function, it is placed into the correct
chain based on its arity (which is known to the caller, and somehow
specified during the registration, by using different functions for
registering different handler types, etc). Your event dispatcher then
processes each chain separately, with a separate piece of code that
contains a FUNCALL with the correct arity and correct semantics of the
arguments for that type of handler. This way, if there are some events
that are not applicable to some types of handlers, you don't even have
to process the chains of those inapplicable handlers.
Another is simply to enumerate the types using symbols. Register each
event handler along with its type. The core of the dispacher is then a
switch which checks whether the event makes sense for each given
handler, and calls it. The call is some CASE construct switched on
handler type.
Even if you knew the arity of each closure, you'd still have to treat
that arity as a type code. For each arity, you'd have to have a
separately coded funcall construct (or else build one on the fly and
eval or compile it). E.g.:
(case arity
(0 (funcall f))
(1 (funcall f arg1))
(2 (funcall f arg1 arg2))
....)
But arity doesn't tell you everything about the event handler type.
Two event handling closures of the same arity could take arguments of
totally different types. Moreover, two event handling closures of the
same arity, which take arguments of the same types could still take
arguments with totally different semantics (e.g. different type of
data extracted from a different type of event).