From: Javier
Subject: Is a new CL standard possible?
Date:
Message-ID: <gq64jr$3g4$1@aioe.org>
I was thinking this when reading the thread originated by Elena about
CL's fixable issues.
CL was standardized 20 years ago. In this time, several new languages
have been emerged, old languages has been changed, but CL didn't.
Because of this, people made new frameworks that have turned to be
almost standard, but still there are important implementation
differences in some cases, and even some of them are not universally
available.
In this respect, yet nobody has been able to propose a new standard. It
is very costly, and Lisp is gaining very little use with respect to the
rest of the languages because of this. People prefer things already
packaged, standardized, universal, well documented. So they use
languages like Java, Python, Perl....
My idea is: why not creating a "community" standard and a committee,
that is, a standard maintained and actualized by the Lisp community,
more or less like it is happening with scheme, responsible for:
- Say what new frameworks are to be considered standard.
- Say what things about CL should be modernized.
- Say what new language constructs may be added.
- Write unified documentation, like a new hyperspec.
About the frameworks, it can be used:
- CFFI
- SB-THREAD
- ASDF
- LTK (or some other GUI library)
- Slime
- CL-SQL
- Any web framework, etc
About the CL to be modernized:
- Change names.
- Better AMOP
- A better syntax.
About new features:
- FSet or some other kind of inmutable structures.
- Memory transactions
And whatever may be discussed.
And with all of this, any particular implementation can include all of
that, on top of the actual CL, so one can switch between the "new" and
the "old" standard. User can have the security that his/her program can
work in every implementation/platform almost without changes.
I think it is not that difficult, but people _must_ participate in order
to be successful.
What do think?
On 22 Mar, 20:49, Javier <·······@gmail.com> wrote:
> I was thinking this when reading the thread originated by Elena about
> CL's fixable issues.
> CL was standardized 20 years ago. In this time, several new languages
> have been emerged, old languages has been changed, but CL didn't.
> Because of this, people made new frameworks that have turned to be
> almost standard, but still there are important implementation
> differences in some cases, and even some of them are not universally
> available.
>
> In this respect, yet nobody has been able to propose a new standard. It
> is very costly, and Lisp is gaining very little use with respect to the
> rest of the languages because of this. People prefer things already
> packaged, standardized, universal, well documented. So they use
> languages like Java, Python, Perl....
>
> My idea is: why not creating a "community" standard and a committee,
> that is, a standard maintained and actualized by the Lisp community,
> more or less like it is happening with scheme, responsible for:
>
> - Say what new frameworks are to be considered standard.
> - Say what things about CL should be modernized.
> - Say what new language constructs may be added.
> - Write unified documentation, like a new hyperspec.
>
> About the frameworks, it can be used:
>
> - CFFI
> - SB-THREAD
> - ASDF
> - LTK (or some other GUI library)
> - Slime
> - CL-SQL
> - Any web framework, etc
>
> About the CL to be modernized:
>
> - Change names.
> - Better AMOP
> - A better syntax.
>
> About new features:
>
> - FSet or some other kind of inmutable structures.
> - Memory transactions
>
> And whatever may be discussed.
> And with all of this, any particular implementation can include all of
> that, on top of the actual CL, so one can switch between the "new" and
> the "old" standard. User can have the security that his/her program can
> work in every implementation/platform almost without changes.
>
> I think it is not that difficult, but people _must_ participate in order
> to be successful.
>
> What do think?
I think that's an huge task, impossible to accomplish. Investigate
what has just happened to the R6RS for Scheme, a much smaller job.
Completed but dismissed by major implementers. OTOH, the initiative
signaled by Pascal C. is admirable and I hope it will gain traction.
I'd say that there is already a new Common Lisp standard. Its name is
SBCL:
http://www.lispforum.com/viewtopic.php?f=2&t=140
As soon as the Windows port is stable, I think it will be the
reference implementation for people interested in cross platform
development.
On Mar 23, 1:32 am, Elena <········@gmail.com> wrote:
> On 22 Mar, 20:49, Javier <·······@gmail.com> wrote:
>
>
>
> > I was thinking this when reading the thread originated by Elena about
> > CL's fixable issues.
> > CL was standardized 20 years ago. In this time, several new languages
> > have been emerged, old languages has been changed, but CL didn't.
> > Because of this, people made new frameworks that have turned to be
> > almost standard, but still there are important implementation
> > differences in some cases, and even some of them are not universally
> > available.
>
> > In this respect, yet nobody has been able to propose a new standard. It
> > is very costly, and Lisp is gaining very little use with respect to the
> > rest of the languages because of this. People prefer things already
> > packaged, standardized, universal, well documented. So they use
> > languages like Java, Python, Perl....
>
> > My idea is: why not creating a "community" standard and a committee,
> > that is, a standard maintained and actualized by the Lisp community,
> > more or less like it is happening with scheme, responsible for:
>
> > - Say what new frameworks are to be considered standard.
> > - Say what things about CL should be modernized.
> > - Say what new language constructs may be added.
> > - Write unified documentation, like a new hyperspec.
>
> > About the frameworks, it can be used:
>
> > - CFFI
> > - SB-THREAD
> > - ASDF
> > - LTK (or some other GUI library)
> > - Slime
> > - CL-SQL
> > - Any web framework, etc
>
> > About the CL to be modernized:
>
> > - Change names.
> > - Better AMOP
> > - A better syntax.
>
> > About new features:
>
> > - FSet or some other kind of inmutable structures.
> > - Memory transactions
>
> > And whatever may be discussed.
> > And with all of this, any particular implementation can include all of
> > that, on top of the actual CL, so one can switch between the "new" and
> > the "old" standard. User can have the security that his/her program can
> > work in every implementation/platform almost without changes.
>
> > I think it is not that difficult, but people _must_ participate in order
> > to be successful.
>
> > What do think?
>
> I think that's an huge task, impossible to accomplish. Investigate
> what has just happened to the R6RS for Scheme, a much smaller job.
> Completed but dismissed by major implementers. OTOH, the initiative
> signaled by Pascal C. is admirable and I hope it will gain traction.
>
> I'd say that there is already a new Common Lisp standard. Its name is
> SBCL:
>
> http://www.lispforum.com/viewtopic.php?f=2&t=140
>
> As soon as the Windows port is stable, I think it will be the
> reference implementation for people interested in cross platform
> development.
There are already "reference implementations" for Windows. They are
called Lispworks and AllegroCL.
They offer all you asked for and much much more.
The problem is that you need consensus, especially from the commercial
vendors.
If you look carefully at SBCL and CMUCL you will see that they
implement the SIMPLE-STREAM protocol by Franz (up to a point). So,
innovation has started there. Franz also expanded on the
'environment' interface of CLtL2. LW has not followed suite and it is
unclear what the "free" implementations are implementing something
similar. The best GUI framework for CL is CAPI by LW full stop (not
LTk, at least until you can do away with MAINLOOP; and - at least -
you should consider CLG). Christophe Rhodes' generic sequences are a
good thing, but I have not seen them anywhere else than SBCL. You
want to really fix something? Try the pathnames :)
"Fixing CL" is not an easy task. Renaming functions is practically
pointless.
Just an extra note for you Elena... Your renaming of == to 'eq' and !
= to 'ne' in C++ calls for a mob of angry C/C++ programmers with
pitchforks and torches. Do you also do
#define BEGIN {
#define END }
#define R_U_SERIUOS :)
?
Cheers
--
Marco
On 23 Mar, 09:33, Marco Antoniotti <·······@gmail.com> wrote:
> On Mar 23, 1:32 am, Elena <········@gmail.com> wrote:
> > I'd say that there is already a new Common Lisp standard. Its name is
> > SBCL:
>
> >http://www.lispforum.com/viewtopic.php?f=2&t=140
>
> > As soon as the Windows port is stable, I think it will be the
> > reference implementation for people interested in cross platform
> > development.
>
> There are already "reference implementations" for Windows. They are
> called Lispworks and AllegroCL.
> They offer all you asked for and much much more.
I'd prefer the reference implementation not to be a commercial one:
standards should be free. And I'd like it to be a decent
implementation too. Slower than commercial ones? Nevermind, it's free.
More memory hungry? Nevermind, it's free. With lesser tools?
Nevermind, it's free. I'm not going to complain: it's free. But then I
could use it to build prototypes and if management want a prototype to
just go in production - as we commercial developers know that's often
the case - I could easily reply: "Well, dear boss, it works. I know,
it's slow and memory hungry. We'd have to improve it. We could rewrite
it in Blub, but that would be a chore. A lot of time. Can't we just
shell out a few bucks and buy this faster/slimmer compiler compiler?
I've tried the trial edition: it works. I can release the thing in an
hour. What do you want to do?". Compare that with another scenario:
"Hi PHB, I'd like to try out this new language. A lot of experienced
developers say it boosts productivity. It's not mainstream, no flashy
IDE, I have to say. Licenses start at XXX.". Which would be an easier
sell? Do you see my point?
Don't say: "Just use the trial edition in the first instance".
Wouldn't the PHB say: "Why didn't you asked me if we could afford the
licenses afterward? You fool, rewrite the damn thing in your leisure
time!". Happily, my manager is not a jerk, he is a very kind person,
but still he is a manager. And other programmers could be less lucky.
>
> The problem is that you need consensus, especially from the commercial
> vendors.
Commercial vendors will do what their customers want. If a free
implementation takes the lead, they'll have to follow it.
>
> If you look carefully at SBCL and CMUCL you will see that they
> implement the SIMPLE-STREAM protocol by Franz (up to a point). So,
> innovation has started there. Franz also expanded on the
> 'environment' interface of CLtL2. LW has not followed suite and it is
> unclear what the "free" implementations are implementing something
> similar. The best GUI framework for CL is CAPI by LW full stop (not
> LTk, at least until you can do away with MAINLOOP; and - at least -
> you should consider CLG).
Nothing wrong with that. I'm not against commercial implementations at
all. They have their role. If I were a skilled professional lisper,
I'd go with them. But then I'd also understand that newbies have to
face a lot of challenges to promote Common Lisp - I'm there now - and
I'd like to help them as much as I can.
>
> "Fixing CL" is not an easy task. Renaming functions is practically
> pointless.
I agree on the fixing issue. Renaming functions pointless? I don't
think so, but please show me I'm wrong. Here is a test: write a few
lines of code to search a project for lines which have side effects,
including lines calling lisp code you don't have the source (I don't
know if the last sentence makes sense for Lisp). My solution for a
project with an appropriate naming convention would be a shell one
liner. What about yours? Second challenge: write an Emacs macro which
highlights with a different face lines with side effects, same
conditions as before. Again, my solution is few lines long. What about
yours?
Why? I think that functional programming can help me improve my
programming and I want - I've said "I want" - my tools to help me as
much as possible. Isn't Lisp all about programming any way you want? I
know I could do OOP in bare C, but C wouldn't help me to that.
(I'm just trying to show my reasons, I don't mean to be hostile)
> Just an extra note for you Elena... Your renaming of == to 'eq' and !
> = to 'ne' in C++ calls for a mob of angry C/C++ programmers with
> pitchforks and torches. Do you also do
>
> #define BEGIN {
> #define END }
>
> #define R_U_SERIUOS :)
>
> ?
I'm serious. I was not that serious at all when I was throwing jokes
at my colleagues who had to spend the evening in their cubicles just
before a deadline, trying to debug stupid issues I've had fixed a long
time ago with my "weird" tricks.
Only lately I'm realizing I've always been a lisper in disguise. I
hope I will manage to become a lisper in full light.
Anyway, you've given me a cool idea. Tomorrow morning I'm going to
write into an header:
#ifdef LISP_RULEZ
# define PROGN {
# define END_PROGN }
#endif
And of course I'm going to define LISP_RULEZ :-)))))
Cheers ^_^
On Mar 23, 8:25 pm, Elena <········@gmail.com> wrote:
> On 23 Mar, 09:33, Marco Antoniotti <·······@gmail.com> wrote:
>
> > On Mar 23, 1:32 am, Elena <········@gmail.com> wrote:
> > > I'd say that there is already a new Common Lisp standard. Its name is
> > > SBCL:
>
> > >http://www.lispforum.com/viewtopic.php?f=2&t=140
>
> > > As soon as the Windows port is stable, I think it will be the
> > > reference implementation for people interested in cross platform
> > > development.
>
> > There are already "reference implementations" for Windows. They are
> > called Lispworks and AllegroCL.
> > They offer all you asked for and much much more.
>
> I'd prefer the reference implementation not to be a commercial one:
> standards should be free. And I'd like it to be a decent
> implementation too. Slower than commercial ones? Nevermind, it's free.
> More memory hungry? Nevermind, it's free. With lesser tools?
> Nevermind, it's free. I'm not going to complain: it's free. But then I
> could use it to build prototypes and if management want a prototype to
> just go in production - as we commercial developers know that's often
> the case - I could easily reply: "Well, dear boss, it works. I know,
> it's slow and memory hungry. We'd have to improve it. We could rewrite
> it in Blub, but that would be a chore. A lot of time. Can't we just
> shell out a few bucks and buy this faster/slimmer compiler compiler?
> I've tried the trial edition: it works. I can release the thing in an
> hour. What do you want to do?". Compare that with another scenario:
> "Hi PHB, I'd like to try out this new language. A lot of experienced
> developers say it boosts productivity. It's not mainstream, no flashy
> IDE, I have to say. Licenses start at XXX.". Which would be an easier
> sell? Do you see my point?
>
> Don't say: "Just use the trial edition in the first instance".
> Wouldn't the PHB say: "Why didn't you asked me if we could afford the
> licenses afterward? You fool, rewrite the damn thing in your leisure
> time!". Happily, my manager is not a jerk, he is a very kind person,
> but still he is a manager. And other programmers could be less lucky.
Look. These arguments have been hashed and rehashed here many many
time before. People here are all aware of them. Solving them is
another problem altogether.
> > The problem is that you need consensus, especially from the commercial
> > vendors.
>
> Commercial vendors will do what their customers want. If a free
> implementation takes the lead, they'll have to follow it.
It has not happened yet, and it does not look like it will happen any
time soon. Did you have a look at Allegro documentation? (And no. I
do not have a license).
> > If you look carefully at SBCL and CMUCL you will see that they
> > implement the SIMPLE-STREAM protocol by Franz (up to a point). So,
> > innovation has started there. Franz also expanded on the
> > 'environment' interface of CLtL2. LW has not followed suite and it is
> > unclear what the "free" implementations are implementing something
> > similar. The best GUI framework for CL is CAPI by LW full stop (not
> > LTk, at least until you can do away with MAINLOOP; and - at least -
> > you should consider CLG).
>
> Nothing wrong with that. I'm not against commercial implementations at
> all. They have their role. If I were a skilled professional lisper,
> I'd go with them. But then I'd also understand that newbies have to
> face a lot of challenges to promote Common Lisp - I'm there now - and
> I'd like to help them as much as I can.
That is good (or bad...) but that is also a matter of perspective.
What makes you think that what is out there is not good enough?
> > "Fixing CL" is not an easy task. Renaming functions is practically
> > pointless.
>
> I agree on the fixing issue. Renaming functions pointless? I don't
> think so, but please show me I'm wrong. Here is a test: write a few
> lines of code to search a project for lines which have side effects,
> including lines calling lisp code you don't have the source (I don't
> know if the last sentence makes sense for Lisp). My solution for a
> project with an appropriate naming convention would be a shell one
> liner. What about yours? Second challenge: write an Emacs macro which
> highlights with a different face lines with side effects, same
> conditions as before. Again, my solution is few lines long. What about
> yours?
You seem to ignore that CL has very well defined rules for most of its
naming conventions. Some of them are quaint and old-smelling, but
they are there. As for your question, it is me who gives out
homeworks here :) especially to the Ruby guy. Show me your code first
and I'll show you mine; I'd bet it would not be as short as you
think. But before you have to define better what you want. What is a
"side effect" for you?
As per CL, you just have to collect those forms that have a SETF
inside plus a handful of peculiar operators (those starting with N,
PUSH, PUSHNEW, POP, whatever)
> Why? I think that functional programming can help me improve my
> programming and I want - I've said "I want" - my tools to help me as
> much as possible. Isn't Lisp all about programming any way you want? I
> know I could do OOP in bare C, but C wouldn't help me to that.
CL is not a pure functional language. You'd have to try Haskell if
you want something really along those lines.
>
> (I'm just trying to show my reasons, I don't mean to be hostile)
>
> > Just an extra note for you Elena... Your renaming of == to 'eq' and !
> > = to 'ne' in C++ calls for a mob of angry C/C++ programmers with
> > pitchforks and torches. Do you also do
>
> > #define BEGIN {
> > #define END }
>
> > #define R_U_SERIUOS :)
>
> > ?
>
> I'm serious. I was not that serious at all when I was throwing jokes
> at my colleagues who had to spend the evening in their cubicles just
> before a deadline, trying to debug stupid issues I've had fixed a long
> time ago with my "weird" tricks.
>
> Only lately I'm realizing I've always been a lisper in disguise. I
> hope I will manage to become a lisper in full light.
>
> Anyway, you've given me a cool idea. Tomorrow morning I'm going to
> write into an header:
>
> #ifdef LISP_RULEZ
> # define PROGN {
> # define END_PROGN }
> #endif
>
> And of course I'm going to define LISP_RULEZ :-)))))
>
> Cheers ^_^
Alright. Have fun with your colleagues. :)
Cheers
--
Marco
On 23 Mar, 21:08, Marco Antoniotti <·······@gmail.com> wrote:
> On Mar 23, 8:25 pm, Elena <········@gmail.com> wrote:
> Look. These arguments have been hashed and rehashed here many many
> time before. People here are all aware of them. Solving them is
> another problem altogether.
You are right on the spot, Marco: talk is cheap, let's show them the
code ^_^
Maybe the time to take action has come. Let's contact the people in
charge for the main free Common Lisp implementations and let's hope
they will agree to our proposal for a shared "not ANSI" codebase.
Let's agree on a (little) set of improvements over Common Lisp and
let's tackle the challenge.
I'm a newbie but I'm going to do my best: documentation, testing,
everything I can do.
Come on, Lispers, we can do it!
> > Commercial vendors will do what their customers want. If a free
> > implementation takes the lead, they'll have to follow it.
>
> It has not happened yet, and it does not look like it will happen any
> time soon. Did you have a look at Allegro documentation? (And no. I
> do not have a license).
>
> > I'm not against commercial implementations at
> > all. They have their role. If I were a skilled professional lisper,
> > I'd go with them. But then I'd also understand that newbies have to
> > face a lot of challenges to promote Common Lisp - I'm there now - and
> > I'd like to help them as much as I can.
>
> That is good (or bad...) but that is also a matter of perspective.
> What makes you think that what is out there is not good enough?
Well, my point was different. I was just saying that I'm not a cheap
stake and I don't want a free-as-in-free-beer industrial-grade Lisp,
I'm willing to pay for it. I just want a free-as-in-free-speech
language specification.
>
> You seem to ignore that CL has very well defined rules for most of its
> naming conventions. Some of them are quaint and old-smelling, but
> they are there. As for your question, it is me who gives out
> homeworks here :) especially to the Ruby guy. Show me your code first
> and I'll show you mine; I'd bet it would not be as short as you
> think. But before you have to define better what you want. What is a
> "side effect" for you?
> As per CL, you just have to collect those forms that have a SETF
> inside plus a handful of peculiar operators (those starting with N,
> PUSH, PUSHNEW, POP, whatever)
Marco, I swear I understand. Really. For instance, GNU Emacs has its
own dictionary (buffers, windows, etc.) which is "old-smelling" ("Lisp
is not dead, it just smells funny." ^_^). But I'm not complaining
about it, because it's different, yet it's *consistent*. Does Common
Lisp has a consistent way to distinguish destructive operations? I
don't think so, therefore I'd wish to fix that issue.
Let's try with an example. Let's suppose we are programming in C: you
know, we'd have routines which could fail and routines which couldn't
possibly fail. You'd assign a "void" return type to the latter and a
"error_t" to the former. Right? Wouldn't be better if we could
distinguish them just by looking at their invocation instead of having
to reach for the documentation? Then we could spot an unchecked return
type just by looking at the code. Remember, Marco, not all programmers
are natural-born gurus. Some are newbies, some are... well... not that
accurate. Remember, Marco, sometimes there are deadlines, too. I've
been there :-( If you haven't and therefore you don't understand,
well... I can understand that. I have had to understand so many things
in my life... Thank you for your attention, anyway.
>
> > Why? I think that functional programming can help me improve my
> > programming and I want - I've said "I want" - my tools to help me as
> > much as possible. Isn't Lisp all about programming any way you want? I
> > know I could do OOP in bare C, but C wouldn't help me to that.
>
> CL is not a pure functional language. You'd have to try Haskell if
> you want something really along those lines.
Nope. I'd wish to use a multi-paradigm language which "supports" (not
merely "allows") functional programming.
On 23 mar, 18:02, Elena <········@gmail.com> wrote:
> On 23 Mar, 21:08, Marco Antoniotti <·······@gmail.com> wrote:
>
> > On Mar 23, 8:25 pm, Elena <········@gmail.com> wrote:
> > Look. These arguments have been hashed and rehashed here many many
> > time before. People here are all aware of them. Solving them is
> > another problem altogether.
>
> You are right on the spot, Marco: talk is cheap, let's show them the
> code ^_^
>
> Maybe the time to take action has come. Let's contact the people in
> charge for the main free Common Lisp implementations and let's hope
> they will agree to our proposal for a shared "not ANSI" codebase.
> Let's agree on a (little) set of improvements over Common Lisp and
> let's tackle the challenge.
>
> I'm a newbie but I'm going to do my best: documentation, testing,
> everything I can do.
>
> Come on, Lispers, we can do it!
>
I agree with you. The only reason that CL is not changing is that we
don't get our hands dirty to change this. I believe one big problem is
the amount of code that was already written in CL. This means that
changing the spec will also make all libraries outdated, all of them
will be thrown away.
Now, here is my solution. Why don't we create a whole new lisp on top
of Common Lisp, just like arc is to scheme? This lisp could be simply
just a new package (name suggestion: :new-common-lisp, with
nickname :ncl). This package would export all of cl's functions, but
some of them renamed to follow a convention (e.g., delete would be
named nremove or remove!). I would also rename multiple-value-bind,
maybe to values-bind or, even better, extend let similarly to
metabang's bind (let ((values q r) floor a b)) ...). Standard
utilities would be added (e.g. compose, flatten). All de facto
standards would also be exported from this package (ASDF, CFFI, closer-
mop, maybe bordeaux-threads and some socket library). Changes to the
language can be decided by popular vote.
The advantage of this approach is that it is completely backward
compatible. If the idea works out and the lisp community accepts it,
and if eventually we want to add some change that can't be done in
portable code, then we can bug CL implementors to work on these
changes.
Well, these are my ideas. You can count me in for suggestions and
programming.
On 23 Mar, 23:56, gugamilare <··········@gmail.com> wrote:
> I agree with you. The only reason that CL is not changing is that we
> don't get our hands dirty to change this. I believe one big problem is
> the amount of code that was already written in CL. This means that
> changing the spec will also make all libraries outdated, all of them
> will be thrown away.
Heck! Now I realize why I was facing so much resistance: I haven't
been very clear about my proposal. I'm not proposing changing the
spec. No way! That would mean throwing away the already scarce
available (good) libraries for CL.
> Now, here is my solution. Why don't we create a whole new lisp on top
> of Common Lisp, just like arc is to scheme? This lisp could be simply
> just a new package (name suggestion: :new-common-lisp, with
> nickname :ncl). This package would export all of cl's functions, but
> some of them renamed to follow a convention (e.g., delete would be
> named nremove or remove!). I would also rename multiple-value-bind,
> maybe to values-bind or, even better, extend let similarly to
> metabang's bind (let ((values q r) floor a b)) ...). Standard
> utilities would be added (e.g. compose, flatten). All de facto
> standards would also be exported from this package (ASDF, CFFI, closer-
> mop, maybe bordeaux-threads and some socket library).
That's was my proposal, exactly. But being a newbie I wasn't able to
spelled it out. I don't mind if you stole it ;-)
> Changes to the
> language can be decided by popular vote.
Hmmm... what about already available libraries? There aren't many
hands available to update them. Would we risk breaking existing code?
OTOH, packages importing :new-common-lisp could take advantage of
those new features. I know it's ugly, but we'd better make small
steps, so that if we can't manage to complete the thing, at least we'd
have accomplished something and made the CL world a better world. Or
were you talking about completely new "non-breaking" features?
> Well, these are my ideas. You can count me in for suggestions and
> programming.
Thank you for your understanding ^_^
On 23 mar, 21:36, Elena <········@gmail.com> wrote:
> On 23 Mar, 23:56, gugamilare <··········@gmail.com> wrote:
> > Changes to the
> > language can be decided by popular vote.
>
> Hmmm... what about already available libraries? There aren't many
> hands available to update them. Would we risk breaking existing code?
> OTOH, packages importing :new-common-lisp could take advantage of
> those new features. I know it's ugly, but we'd better make small
> steps, so that if we can't manage to complete the thing, at least we'd
> have accomplished something and made the CL world a better world. Or
> were you talking about completely new "non-breaking" features?
Well, my personal experience says that the CL community is larger than
scheme's, but it is more fragmented, mostly because of the inexistent
CLRFI. And most libraries have only one maintainer.
I believe that most important changes won't break existing libraries
since everything is encapsulated inside a package. In the future we
can see about any eventual changes that breaks existing code. For the
moment we stick to simple changes that we now not to break anything.
On Mar 23, 3:56 pm, gugamilare <··········@gmail.com> wrote:
> I would also rename multiple-value-bind,
> maybe to values-bind or, even better, extend let similarly to
> metabang's bind (let ((values q r) floor a b)) ...).
Also have a look at my "new LET" macro:
http://www.cliki.net/Misc-Extensions
It doesn't do destructuring, but does let you write arbitrary
combinations of parallel and sequential binding, and the syntax for
binding multiple values is more elegant.
-- Scott
On 24 mar, 02:00, Scott Burson <········@gmail.com> wrote:
> On Mar 23, 3:56 pm, gugamilare <··········@gmail.com> wrote:
>
> > I would also rename multiple-value-bind,
> > maybe to values-bind or, even better, extend let similarly to
> > metabang's bind (let ((values q r) floor a b)) ...).
>
> Also have a look at my "new LET" macro:
>
> http://www.cliki.net/Misc-Extensions
>
> It doesn't do destructuring, but does let you write arbitrary
> combinations of parallel and sequential binding, and the syntax for
> binding multiple values is more elegant.
>
> -- Scott
I like multiple values syntax, but I dislike the nesting syntax for
parallel binding. It confuses me, more then helps me. I think the
perfect case would be
(let ((a b c (foo x)) ; multiple values
((x &optional y &rest r) some-list) ; destructuring-bind
(w (bar z)) ; normal binding
...)
and do the same thing with let*.
Those extensions to cond and case are also very handy.
P� Tue, 24 Mar 2009 15:06:45 +0100, skrev gugamilare
<··········@gmail.com>:
> On 24 mar, 02:00, Scott Burson <········@gmail.com> wrote:
>> On Mar 23, 3:56�pm, gugamilare <··········@gmail.com> wrote:
>>
>> > I would also rename multiple-value-bind,
>> > maybe to values-bind or, even better, extend let similarly to
>> > metabang's bind (let ((values q r) floor a b)) ...).
>>
>> Also have a look at my "new LET" macro:
>>
>> �http://www.cliki.net/Misc-Extensions
>>
>> It doesn't do destructuring, but does let you write arbitrary
>> combinations of parallel and sequential binding, and the syntax for
>> binding multiple values is more elegant.
>>
>> -- Scott
>
> I like multiple values syntax, but I dislike the nesting syntax for
> parallel binding. It confuses me, more then helps me. I think the
> perfect case would be
>
> (let ((a b c (foo x)) ; multiple values
> ((x &optional y &rest r) some-list) ; destructuring-bind
> (w (bar z)) ; normal binding
> ...)
>
> and do the same thing with let*.
>
> Those extensions to cond and case are also very handy.
Take a look at bind: http://common-lisp.net/project/metabang-bind/
--------------
John Thingstad
From: Javier
Subject: Re: Is a new CL standard possible?
Date:
Message-ID: <gq95dc$siq$1@aioe.org>
gugamilare escribi�:
> On 23 mar, 18:02, Elena <········@gmail.com> wrote:
>> On 23 Mar, 21:08, Marco Antoniotti <·······@gmail.com> wrote:
>>
>>> On Mar 23, 8:25 pm, Elena <········@gmail.com> wrote:
>>> Look. These arguments have been hashed and rehashed here many many
>>> time before. People here are all aware of them. Solving them is
>>> another problem altogether.
>> You are right on the spot, Marco: talk is cheap, let's show them the
>> code ^_^
>>
>> Maybe the time to take action has come. Let's contact the people in
>> charge for the main free Common Lisp implementations and let's hope
>> they will agree to our proposal for a shared "not ANSI" codebase.
>> Let's agree on a (little) set of improvements over Common Lisp and
>> let's tackle the challenge.
>>
>> I'm a newbie but I'm going to do my best: documentation, testing,
>> everything I can do.
>>
>> Come on, Lispers, we can do it!
>>
> I agree with you. The only reason that CL is not changing is that we
> don't get our hands dirty to change this. I believe one big problem is
> the amount of code that was already written in CL. This means that
> changing the spec will also make all libraries outdated, all of them
> will be thrown away.
>
> Now, here is my solution. Why don't we create a whole new lisp on top
> of Common Lisp, just like arc is to scheme? This lisp could be simply
> just a new package (name suggestion: :new-common-lisp, with
> nickname :ncl). This package would export all of cl's functions, but
> some of them renamed to follow a convention (e.g., delete would be
> named nremove or remove!). I would also rename multiple-value-bind,
> maybe to values-bind or, even better, extend let similarly to
> metabang's bind (let ((values q r) floor a b)) ...). Standard
> utilities would be added (e.g. compose, flatten). All de facto
> standards would also be exported from this package (ASDF, CFFI, closer-
> mop, maybe bordeaux-threads and some socket library). Changes to the
> language can be decided by popular vote.
>
> The advantage of this approach is that it is completely backward
> compatible. If the idea works out and the lisp community accepts it,
> and if eventually we want to add some change that can't be done in
> portable code, then we can bug CL implementors to work on these
> changes.
>
> Well, these are my ideas. You can count me in for suggestions and
> programming.
+1
I like your view.
From: Javier
Subject: Re: Is a new CL standard possible?
Date:
Message-ID: <gq8ukq$mgo$1@aioe.org>
Elena escribi�:
> You are right on the spot, Marco: talk is cheap, let's show them the
> code ^_^
>
> Maybe the time to take action has come. Let's contact the people in
> charge for the main free Common Lisp implementations and let's hope
> they will agree to our proposal for a shared "not ANSI" codebase.
> Let's agree on a (little) set of improvements over Common Lisp and
> let's tackle the challenge.
>
> I'm a newbie but I'm going to do my best: documentation, testing,
> everything I can do.
>
> Come on, Lispers, we can do it!
I agree, and can participate too.
This can even be my first "serious" (but funny) Lisp project.
I would particularly interested in immutable structures add ons to the
"standard".
On Mar 23, 2:26 pm, Javier <·······@gmail.com> wrote:
>
> I would particularly interested in immutable structures add ons to the
> "standard".
This is one of the few things I think CL desperately needs. Immutable
structures open up new strategies for concurrent GC, as you can copy
them without updating all existing pointers to them immediately; you
just have to be sure you've updated all pointers before reusing the
memory. High-performance concurrent GC is going to be an enabling
technology for serious multicore programming in a world where midrange
PCs have 16 cores and high-end ones have 64.
-- Scott
On 24 mar, 05:47, Scott Burson <········@gmail.com> wrote:
> On Mar 23, 2:26 pm, Javier <·······@gmail.com> wrote:
>
>
>
> > I would particularly interested in immutable structures add ons to the
> > "standard".
>
> This is one of the few things I think CL desperately needs. Immutable
> structures open up new strategies for concurrent GC, as you can copy
> them without updating all existing pointers to them immediately; you
> just have to be sure you've updated all pointers before reusing the
> memory. High-performance concurrent GC is going to be an enabling
> technology for serious multicore programming in a world where midrange
> PCs have 16 cores and high-end ones have 64.
There's nothing in the language stopping an enterprising implementor
from toying around with that now. Defstruct supports read-only slots,
and once you have such a structure, there's no standard way of
changing anything about it. We just need someone to take advantage of
this property. (And admittedly, defstruct is not the lovliest
interface in the language)
Thomas F. Burdick wrote:
> On 24 mar, 05:47, Scott Burson <········@gmail.com> wrote:
>> On Mar 23, 2:26 pm, Javier <·······@gmail.com> wrote:
>>
>>
>>
>>> I would particularly interested in immutable structures add ons to the
>>> "standard".
>> This is one of the few things I think CL desperately needs. Immutable
>> structures open up new strategies for concurrent GC, as you can copy
>> them without updating all existing pointers to them immediately; you
>> just have to be sure you've updated all pointers before reusing the
>> memory. High-performance concurrent GC is going to be an enabling
>> technology for serious multicore programming in a world where midrange
>> PCs have 16 cores and high-end ones have 64.
>
> There's nothing in the language stopping an enterprising implementor
> from toying around with that now. Defstruct supports read-only slots,
> and once you have such a structure, there's no standard way of
> changing anything about it. We just need someone to take advantage of
> this property. (And admittedly, defstruct is not the lovliest
> interface in the language)
Not quite. Two different struct instances with the same slot values are
still not eq. So you would have to find a way of saying that you cannot
rely on eqness anymore.
Pascal
--
ELS'09: http://www.european-lisp-symposium.org/
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: Javier
Subject: Re: Is a new CL standard possible?
Date:
Message-ID: <gqarqm$6s1$1@aioe.org>
Thomas F. Burdick escribi�:
> On 24 mar, 05:47, Scott Burson <········@gmail.com> wrote:
>> On Mar 23, 2:26 pm, Javier <·······@gmail.com> wrote:
>>
>>
>>
>>> I would particularly interested in immutable structures add ons to the
>>> "standard".
>> This is one of the few things I think CL desperately needs. Immutable
>> structures open up new strategies for concurrent GC, as you can copy
>> them without updating all existing pointers to them immediately; you
>> just have to be sure you've updated all pointers before reusing the
>> memory. High-performance concurrent GC is going to be an enabling
>> technology for serious multicore programming in a world where midrange
>> PCs have 16 cores and high-end ones have 64.
>
> There's nothing in the language stopping an enterprising implementor
> from toying around with that now. Defstruct supports read-only slots,
> and once you have such a structure, there's no standard way of
> changing anything about it. We just need someone to take advantage of
> this property. (And admittedly, defstruct is not the lovliest
> interface in the language)
What we understand about immutable data is not only it being immutable,
nor as only immutable objects, but also every kind of
sequences/sets/maps, and having efficient algorithms to treat them, with
little impact on performance (both space and speed), and optimized for
multi threading purposes.
I think we could learn a lot from Clojure:
http://clojure.org/state
Of course, all of this without touching mutability if that is what you
want. Think about this like a powerful add-on.
From: Javier
Subject: Re: Is a new CL standard possible?
Date:
Message-ID: <gqaep2$r76$1@aioe.org>
Scott Burson escribi�:
> On Mar 23, 2:26 pm, Javier <·······@gmail.com> wrote:
>> I would particularly interested in immutable structures add ons to the
>> "standard".
>
> This is one of the few things I think CL desperately needs. Immutable
> structures open up new strategies for concurrent GC, as you can copy
> them without updating all existing pointers to them immediately; you
> just have to be sure you've updated all pointers before reusing the
> memory. High-performance concurrent GC is going to be an enabling
> technology for serious multicore programming in a world where midrange
> PCs have 16 cores and high-end ones have 64.
>
> -- Scott
I think on adding something like FSet. Have you seen it?
Javier wrote:
> Scott Burson escribi�:
>> On Mar 23, 2:26 pm, Javier <·······@gmail.com> wrote:
>>> I would particularly interested in immutable structures add ons to the
>>> "standard".
>> This is one of the few things I think CL desperately needs. Immutable
>> structures open up new strategies for concurrent GC, as you can copy
>> them without updating all existing pointers to them immediately; you
>> just have to be sure you've updated all pointers before reusing the
>> memory. High-performance concurrent GC is going to be an enabling
>> technology for serious multicore programming in a world where midrange
>> PCs have 16 cores and high-end ones have 64.
>>
>> -- Scott
>
> I think on adding something like FSet. Have you seen it?
Where to begin...
From: Javier
Subject: Re: Is a new CL standard possible?
Date:
Message-ID: <gqappc$594$1@aioe.org>
Kenneth Tilton escribi�:
> Javier wrote:
>> Scott Burson escribi�:
>>> On Mar 23, 2:26 pm, Javier <·······@gmail.com> wrote:
>>>> I would particularly interested in immutable structures add ons to the
>>>> "standard".
>>> This is one of the few things I think CL desperately needs. Immutable
>>> structures open up new strategies for concurrent GC, as you can copy
>>> them without updating all existing pointers to them immediately; you
>>> just have to be sure you've updated all pointers before reusing the
>>> memory. High-performance concurrent GC is going to be an enabling
>>> technology for serious multicore programming in a world where midrange
>>> PCs have 16 cores and high-end ones have 64.
>>>
>>> -- Scott
>>
>> I think on adding something like FSet. Have you seen it?
>
> Where to begin...
FSet is probably a good base:
http://common-lisp.net/project/fset/
http://common-lisp.net/project/fset/Site/index.html
Now add memory transactions:
http://en.wikipedia.org/wiki/Software_transactional_memory
And a standard way of managing threads:
http://trac.common-lisp.net/bordeaux-threads/wiki/ApiDocumentation
And you got the full package, among other things.
But before starting to do anything, think twice: we are going to name
functions like "remove" and "remove!", so be aware, this could irritate
your old-dog eyes.
On 24 mar, 11:15, Javier <·······@gmail.com> wrote:
> Kenneth Tilton escribió:
>
>
>
> > Javier wrote:
> >> Scott Burson escribió:
> >>> On Mar 23, 2:26 pm, Javier <·······@gmail.com> wrote:
> >>>> I would particularly interested in immutable structures add ons to the
> >>>> "standard".
> >>> This is one of the few things I think CL desperately needs. Immutable
> >>> structures open up new strategies for concurrent GC, as you can copy
> >>> them without updating all existing pointers to them immediately; you
> >>> just have to be sure you've updated all pointers before reusing the
> >>> memory. High-performance concurrent GC is going to be an enabling
> >>> technology for serious multicore programming in a world where midrange
> >>> PCs have 16 cores and high-end ones have 64.
>
> >>> -- Scott
>
> >> I think on adding something like FSet. Have you seen it?
>
> > Where to begin...
>
> FSet is probably a good base:
>
> http://common-lisp.net/project/fset/http://common-lisp.net/project/fset/Site/index.html
>
> Now add memory transactions:
>
> http://en.wikipedia.org/wiki/Software_transactional_memory
>
> And a standard way of managing threads:
>
> http://trac.common-lisp.net/bordeaux-threads/wiki/ApiDocumentation
>
> And you got the full package, among other things.
>
> But before starting to do anything, think twice: we are going to name
> functions like "remove" and "remove!", so be aware, this could irritate
> your old-dog eyes.
Personally I think nremove is much better, it follows more the general
CL convention.
From: Javier
Subject: Re: Is a new CL standard possible?
Date:
Message-ID: <gqat2e$820$1@aioe.org>
gugamilare escribi�:
>> But before starting to do anything, think twice: we are going to name
>> functions like "remove" and "remove!", so be aware, this could irritate
>> your old-dog eyes.
>
> Personally I think nremove is much better, it follows more the general
> CL convention.
I don't mind in fact. That option will make happy old-dogs. I said that
because of Elena's propositions.
On Mar 24, 11:45 pm, Elena <········@gmail.com> wrote:
> On 24 Mar, 23:27, gugamilare <··········@gmail.com> wrote:
>
> > Hum... Not sure about and editor being able to highlight it, since
> > there are functions that begin with n. It is pretty obvious to see
> > that "nfoo" is a non-consing version of "foo", and it is also easy to
> > see that "not" is not a non-consing version of anything. I believe the
> > confusions will be small, or none.
>
> Pretty obvious either to you or to me. What about non native English
> speakers? Many amongst them just "babble" English? Couldn't they still
> get confused?
That's wy I advocate using Latin for keywords in programming
language. Actually we should all switch to Lingua Perligata
Latina. :)
Cheers
--
Marco
Marco Antoniotti <·······@gmail.com> writes:
That's wy I advocate using Latin for keywords in
programming language. Actually we should all switch to
Lingua Perligata Latina. :)
CL-USER> (tertius '(I II III IV))
III
But seriously (and regarding the thread in general) with as
often as I hear that Lisp doesn't have enough libraries, and
then that it does, they're just not part of the standard,
and then that the real problem is that it's just a pita to
install them, it surprises me that I don't often hear the
idea of just making Lisp distributions, like Debian for
Linux, but for Lisp. If someone thinks that kind of
semi-standard way of doing it would be good, why not pick
your implementation of choice, add all the libraries you've
ever hear of, spend a few man-centuries getting them all to
build and play together more or less, and then roll out a
tarball, or something? You can set it up any way you want
to; you can add everything to cl-user; you can make it use
Emacs; you can make it refuse to work with Emacs; whatever
you want. If it's easy for the newbies to use, then more's
the good. If not, then maybe a competing distribution will
be. I don't know; it worked pretty well for LaTeX.
Or for that matter, someone (not me, of course) could fork
an actual Linux disto and focus it on Lisp, with all the
tools, implementations and libraries pre-loaded you can
think of, and a bias in favor of Lispy system tools and
environments. But I guess that's a different fantasy.
On 25 mar, 21:12, Evans Winner <······@timbral.net> wrote:
> Marco Antoniotti <·······@gmail.com> writes:
>
> That's wy I advocate using Latin for keywords in
> programming language. Actually we should all switch to
> Lingua Perligata Latina. :)
>
> CL-USER> (tertius '(I II III IV))
> III
>
> But seriously (and regarding the thread in general) with as
> often as I hear that Lisp doesn't have enough libraries, and
> then that it does, they're just not part of the standard,
> and then that the real problem is that it's just a pita to
> install them, it surprises me that I don't often hear the
> idea of just making Lisp distributions, like Debian for
> Linux, but for Lisp. If someone thinks that kind of
> semi-standard way of doing it would be good, why not pick
> your implementation of choice, add all the libraries you've
> ever hear of, spend a few man-centuries getting them all to
> build and play together more or less, and then roll out a
> tarball, or something? You can set it up any way you want
> to; you can add everything to cl-user; you can make it use
> Emacs; you can make it refuse to work with Emacs; whatever
> you want. If it's easy for the newbies to use, then more's
> the good. If not, then maybe a competing distribution will
> be. I don't know; it worked pretty well for LaTeX.
>
> Or for that matter, someone (not me, of course) could fork
> an actual Linux disto and focus it on Lisp, with all the
> tools, implementations and libraries pre-loaded you can
> think of, and a bias in favor of Lispy system tools and
> environments. But I guess that's a different fantasy.
That is more or less one of the things I proposed - to take all the
utilities that are commonly used, plus all de facto standard and
portability libraries, everything exported through one unique package.
But include only libraries that are commonly used by many other
libraries, and state that they are "standard". This way, you know that
people will have all these libraries already installed and you fell
free to use their functions as you like, whenever you need.
Sometimes you just have one library (say, A) that has a few functions
that are very useful for you to do something in you library B. Most
people would think: "I will not include the entire library A as
dependency of my lib B just because I need a few functions. Instead, I
will make my own version of these function." Having to worry about
little things like this, for me, is the hell. People won't think about
that if they can rely on the user already having that library.
From: Pascal J. Bourguignon
Subject: Re: Is a new CL standard possible?
Date:
Message-ID: <871vskeobd.fsf@galatea.local>
gugamilare <··········@gmail.com> writes:
> On 25 mar, 21:12, Evans Winner <······@timbral.net> wrote:
>> Marco Antoniotti <·······@gmail.com> writes:
>>
>> � � That's wy I advocate using Latin for keywords in
>> � � programming language. �Actually we should all switch to
>> � � Lingua Perligata Latina. :)
>>
>> CL-USER> (tertius '(I II III IV))
>> III
>>
>> But seriously (and regarding the thread in general) with as
>> often as I hear that Lisp doesn't have enough libraries, and
>> then that it does, they're just not part of the standard,
>> and then that the real problem is that it's just a pita to
>> install them, it surprises me that I don't often hear the
>> idea of just making Lisp distributions, like Debian for
>> Linux, but for Lisp. �If someone thinks that kind of
>> semi-standard way of doing it would be good, why not pick
>> your implementation of choice, add all the libraries you've
>> ever hear of, spend a few man-centuries getting them all to
>> build and play together more or less, and then roll out a
>> tarball, or something? �You can set it up any way you want
>> to; you can add everything to cl-user; you can make it use
>> Emacs; you can make it refuse to work with Emacs; whatever
>> you want. �If it's easy for the newbies to use, then more's
>> the good. �If not, then maybe a competing distribution will
>> be. �I don't know; it worked pretty well for LaTeX.
>>
>> Or for that matter, someone (not me, of course) could fork
>> an actual Linux disto and focus it on Lisp, with all the
>> tools, implementations and libraries pre-loaded you can
>> think of, and a bias in favor of Lispy system tools and
>> environments. �But I guess that's a different fantasy.
>
> That is more or less one of the things I proposed - to take all the
> utilities that are commonly used, plus all de facto standard and
> portability libraries, everything exported through one unique package.
> But include only libraries that are commonly used by many other
> libraries, and state that they are "standard". This way, you know that
> people will have all these libraries already installed and you fell
> free to use their functions as you like, whenever you need.
>
> Sometimes you just have one library (say, A) that has a few functions
> that are very useful for you to do something in you library B. Most
> people would think: "I will not include the entire library A as
> dependency of my lib B just because I need a few functions. Instead, I
> will make my own version of these function." Having to worry about
> little things like this, for me, is the hell. People won't think about
> that if they can rely on the user already having that library.
This is more or less what has been proposed twice a year since I read
cll (at least since 2000).
Some things have been worked on (eg. asdf, alexandra,
common-lisp.net); some things have been started and felt into
inactivity and oblitions immediately after; most haven't even been
started.
--
__Pascal Bourguignon__
On Mar 26, 8:27 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> gugamilare <··········@gmail.com> writes:
> > On 25 mar, 21:12, Evans Winner <······@timbral.net> wrote:
> >> Marco Antoniotti <·······@gmail.com> writes:
>
> >> That's wy I advocate using Latin for keywords in
> >> programming language. Actually we should all switch to
> >> Lingua Perligata Latina. :)
>
> >> CL-USER> (tertius '(I II III IV))
> >> III
>
> >> But seriously (and regarding the thread in general) with as
> >> often as I hear that Lisp doesn't have enough libraries, and
> >> then that it does, they're just not part of the standard,
> >> and then that the real problem is that it's just a pita to
> >> install them, it surprises me that I don't often hear the
> >> idea of just making Lisp distributions, like Debian for
> >> Linux, but for Lisp. If someone thinks that kind of
> >> semi-standard way of doing it would be good, why not pick
> >> your implementation of choice, add all the libraries you've
> >> ever hear of, spend a few man-centuries getting them all to
> >> build and play together more or less, and then roll out a
> >> tarball, or something? You can set it up any way you want
> >> to; you can add everything to cl-user; you can make it use
> >> Emacs; you can make it refuse to work with Emacs; whatever
> >> you want. If it's easy for the newbies to use, then more's
> >> the good. If not, then maybe a competing distribution will
> >> be. I don't know; it worked pretty well for LaTeX.
>
> >> Or for that matter, someone (not me, of course) could fork
> >> an actual Linux disto and focus it on Lisp, with all the
> >> tools, implementations and libraries pre-loaded you can
> >> think of, and a bias in favor of Lispy system tools and
> >> environments. But I guess that's a different fantasy.
>
> > That is more or less one of the things I proposed - to take all the
> > utilities that are commonly used, plus all de facto standard and
> > portability libraries, everything exported through one unique package.
> > But include only libraries that are commonly used by many other
> > libraries, and state that they are "standard". This way, you know that
> > people will have all these libraries already installed and you fell
> > free to use their functions as you like, whenever you need.
>
> > Sometimes you just have one library (say, A) that has a few functions
> > that are very useful for you to do something in you library B. Most
> > people would think: "I will not include the entire library A as
> > dependency of my lib B just because I need a few functions. Instead, I
> > will make my own version of these function." Having to worry about
> > little things like this, for me, is the hell. People won't think about
> > that if they can rely on the user already having that library.
>
> This is more or less what has been proposed twice a year since I read
> cll (at least since 2000).
>
> Some things have been worked on (eg. asdf, alexandra,
> common-lisp.net); some things have been started and felt into
> inactivity and oblitions immediately after; most haven't even been
> started.
>
> --
> __Pascal Bourguignon__
Exactly. I and *I* am one of the culprits. :)
Cheers
--
Marco
On Mar 25, 3:25 am, ··················@gmail.com wrote:
> On Mar 24, 5:19 pm, Elena <········@gmail.com> wrote:
>
> > On 24 Mar, 20:50, "eric-and-jane-smith" <·······@nospam.com> wrote:
>
> > > Elena <········@gmail.com> wrote ···········································@e18g2000yqo.googlegroups.com:
>
> > > > I do mind instead. Or are you going to reserve "N" prefix for non
> > > > consing procedures? That would be fine with me. Remember: our purpose
> > > > should be making non-consing functions so easy to spot that even an
> > > > editor could easily highlight them.
>
> > > Why not simply put the names of the non-consing functions in a list, for
> > > the editor to recognize them?
>
> > What about user defined ones? What about user-defined ones which share
> > the name with a non consing library one? or should we expect users to
> > know all CL functions all the time?
>
> N-- is the convention for non-consing list instructions.
>
> Push isn't really a destructive function, you have to think of it more
> like setf or rplaca (it is about assignment).
OK, I've chosen a bad example.
>
> I don't know how you could force people to name user defined functions
> in a certain way.
Of course you can't, but I've observed that most people will just
follow the lead.
> Although I've got to say here that I think a lot of people learning
> lisp use lists when they should use other data structures.
>
> Knowing is wasted brain space, I just look things up...
I do agree on the first sentence. Still, having to look things up is
wasted time.
>
> Re: Everything else if someone could produce a fire and forget SBCL
> +Weblocks (maybe CLSQL as well) installer (perhaps clisp instead when
> it gets threading),
> I think it would cover most of the things mentioned here as 'issues'
> in Lisp.
We could investigate that.
>
> That lisp has a steep /learning/ curve isn't really a problem. It is a
> large language with a lot of really nice features. (And the learning
> curve is mostly an unlearning curve).
>
> The real problem I have is the installation process.
> It takes a fairly stubborn individual to get to a point where he can
> do anything interesting.
>
> (But like cross country skiing, its /so/ rewarding).
Installation woes have been mentioned as an issue, and I agree that in
practice they are more urgent.
On Mar 25, 5:22 am, "eric-and-jane-smith" <·······@nospam.com> wrote:
> ··················@gmail.com wrote ···········································@a12g2000yqm.googlegroups.com:
>
> > Knowing is wasted brain space, I just look things up...
>
> Memorizing stuff seems like excercising a muscle. I have found over the
> years that the more stuff I memorize the easier it is to memorize more. To
> that end I have memorized huge quantities of meaningless trivia which will
> probably only come in handy if I ever go on "Who Wants to be a
> Millionaire". E.g. if the question is "which of these four poems has the
> word "claught" in it, I would be likely to know the answer.
>
> Besides that, life is short. When you die, your whole brain gets wasted.
> So you might as well use it up.
Yeah, but you could exercise your "muscle" by learning different
subjects instead of struggling with just one.
On Mar 25, 6:53 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Here a old dog will start it for you:
>
> (defpackage "NEW-DOG-COMMON-LISP"
> (:nicknames "NEW-DOG-CL" "NDCL")
> (:export "REMOVE!" ...)
> (:use "COMMON-LISP"))
Ha! Ha! Ha! I'd vote for the "NEW-DOG-COMMON-LISP" package name
proposal ;-)))))
>(defun remove! (item sequence &rest args &key from-end test test-not start end count key)
> (apply (function cl:delete) item sequence args))
We would be more likely to just define an alias, since the two
functions are indeed the same one. Thank you for sketching a proposal,
anyway.
>
> ;; ... let's see if any new dog will do the rest.
>
> (If you scan cll, you might notice a pattern).
> --
> __Pascal Bourguignon__
Pascal makes a point here. I understand that many experienced CLers
quickly dismiss proposals for improvements because such a subject has
been raised again and again, but very little action has been
undertaken afterward.
Let's hope this time things will be different.
On Mar 25, 4:12 am, Elena <········@gmail.com> wrote:
> On Mar 25, 6:53 am, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>
> > Here a old dog will start it for you:
>
> > (defpackage "NEW-DOG-COMMON-LISP"
> > (:nicknames "NEW-DOG-CL" "NDCL")
> > (:export "REMOVE!" ...)
> > (:use "COMMON-LISP"))
>
> Ha! Ha! Ha! I'd vote for the "NEW-DOG-COMMON-LISP" package name
> proposal ;-)))))
>
Its not accurate enough. "PUPPY-DOG-COMMON-LISP" is better.
W
On Mar 25, 2:28 pm, Wade <·············@gmail.com> wrote:
> On Mar 25, 4:12 am, Elena <········@gmail.com> wrote:
>
> > On Mar 25, 6:53 am, ····@informatimago.com (Pascal J. Bourguignon)
> > wrote:
>
> > > Here a old dog will start it for you:
>
> > > (defpackage "NEW-DOG-COMMON-LISP"
> > > (:nicknames "NEW-DOG-CL" "NDCL")
> > > (:export "REMOVE!" ...)
> > > (:use "COMMON-LISP"))
>
> > Ha! Ha! Ha! I'd vote for the "NEW-DOG-COMMON-LISP" package name
> > proposal ;-)))))
>
> Its not accurate enough. "PUPPY-DOG-COMMON-LISP" is better.
>
> W
I second that. This makes for an even easier marketing.
What about "Cool Lisp" (domain is available, still CL as an acronym)?
On Mar 25, 2:40 pm, Elena <········@gmail.com> wrote:
> On Mar 25, 2:28 pm, Wade <·············@gmail.com> wrote:
>
>
>
> > On Mar 25, 4:12 am, Elena <········@gmail.com> wrote:
>
> > > On Mar 25, 6:53 am, ····@informatimago.com (Pascal J. Bourguignon)
> > > wrote:
>
> > > > Here a old dog will start it for you:
>
> > > > (defpackage "NEW-DOG-COMMON-LISP"
> > > > (:nicknames "NEW-DOG-CL" "NDCL")
> > > > (:export "REMOVE!" ...)
> > > > (:use "COMMON-LISP"))
>
> > > Ha! Ha! Ha! I'd vote for the "NEW-DOG-COMMON-LISP" package name
> > > proposal ;-)))))
>
> > Its not accurate enough. "PUPPY-DOG-COMMON-LISP" is better.
>
> > W
>
> I second that. This makes for an even easier marketing.
>
> What about "Cool Lisp" (domain is available, still CL as an acronym)?
Nevermind. Puppy Dog CL still better. We could also design a puppy as
the logo.
edit: Google is asking my to enter a validation code to post the
message. Can you guess it?
"conses"! I swear! (I've saved the screenshot)
I take that as a sign: the god of Internet is with us. Let's go ahead,
Lispers!
On 25 mar, 11:40, Elena <········@gmail.com> wrote:
> On Mar 25, 2:28 pm, Wade <·············@gmail.com> wrote:
>
>
>
> > On Mar 25, 4:12 am, Elena <········@gmail.com> wrote:
>
> > > On Mar 25, 6:53 am, ····@informatimago.com (Pascal J. Bourguignon)
> > > wrote:
>
> > > > Here a old dog will start it for you:
>
> > > > (defpackage "NEW-DOG-COMMON-LISP"
> > > > (:nicknames "NEW-DOG-CL" "NDCL")
> > > > (:export "REMOVE!" ...)
> > > > (:use "COMMON-LISP"))
>
> > > Ha! Ha! Ha! I'd vote for the "NEW-DOG-COMMON-LISP" package name
> > > proposal ;-)))))
>
> > Its not accurate enough. "PUPPY-DOG-COMMON-LISP" is better.
>
> > W
>
> I second that. This makes for an even easier marketing.
>
> What about "Cool Lisp" (domain is available, still CL as an acronym)?
I still like New Dog Common Lisp more. "Puppy" sounds like "baby".
On Mar 25, 8:57 am, gugamilare <··········@gmail.com> wrote:
> On 25 mar, 11:40, Elena <········@gmail.com> wrote:
>
>
>
> > On Mar 25, 2:28 pm, Wade <·············@gmail.com> wrote:
>
> > > On Mar 25, 4:12 am, Elena <········@gmail.com> wrote:
>
> > > > On Mar 25, 6:53 am, ····@informatimago.com (Pascal J. Bourguignon)
> > > > wrote:
>
> > > > > Here a old dog will start it for you:
>
> > > > > (defpackage "NEW-DOG-COMMON-LISP"
> > > > > (:nicknames "NEW-DOG-CL" "NDCL")
> > > > > (:export "REMOVE!" ...)
> > > > > (:use "COMMON-LISP"))
>
> > > > Ha! Ha! Ha! I'd vote for the "NEW-DOG-COMMON-LISP" package name
> > > > proposal ;-)))))
>
> > > Its not accurate enough. "PUPPY-DOG-COMMON-LISP" is better.
>
> > > W
>
> > I second that. This makes for an even easier marketing.
>
> > What about "Cool Lisp" (domain is available, still CL as an acronym)?
>
> I still like New Dog Common Lisp more. "Puppy" sounds like "baby".
But puppies are sooooo cuuuute! And they are dogs.
Got something against puppies??
W
On 25 Mar, 16:48, Wade <·············@gmail.com> wrote:
> On Mar 25, 8:57 am, gugamilare <··········@gmail.com> wrote:
>
>
>
> > On 25 mar, 11:40, Elena <········@gmail.com> wrote:
>
> > > On Mar 25, 2:28 pm, Wade <·············@gmail.com> wrote:
>
> > > > On Mar 25, 4:12 am, Elena <········@gmail.com> wrote:
>
> > > > > On Mar 25, 6:53 am, ····@informatimago.com (Pascal J. Bourguignon)
> > > > > wrote:
>
> > > > > > Here a old dog will start it for you:
>
> > > > > > (defpackage "NEW-DOG-COMMON-LISP"
> > > > > > (:nicknames "NEW-DOG-CL" "NDCL")
> > > > > > (:export "REMOVE!" ...)
> > > > > > (:use "COMMON-LISP"))
>
> > > > > Ha! Ha! Ha! I'd vote for the "NEW-DOG-COMMON-LISP" package name
> > > > > proposal ;-)))))
>
> > > > Its not accurate enough. "PUPPY-DOG-COMMON-LISP" is better.
>
> > > > W
>
> > > I second that. This makes for an even easier marketing.
>
> > > What about "Cool Lisp" (domain is available, still CL as an acronym)?
>
> > I still like New Dog Common Lisp more. "Puppy" sounds like "baby".
>
> But puppies are sooooo cuuuute! And they are dogs.
> Got something against puppies??
>
> W
I agree. Having cartoon-ish logos hasn't stopped software products in
being industrial-strength and respected for their intrinsic value.
Think Linux, FreeBSD, etc.
But we'll talk about it later.
On Mar 25, 3:40 pm, Elena <········@gmail.com> wrote:
> On Mar 25, 2:28 pm, Wade <·············@gmail.com> wrote:
>
>
>
> > On Mar 25, 4:12 am, Elena <········@gmail.com> wrote:
>
> > > On Mar 25, 6:53 am, ····@informatimago.com (Pascal J. Bourguignon)
> > > wrote:
>
> > > > Here a old dog will start it for you:
>
> > > > (defpackage "NEW-DOG-COMMON-LISP"
> > > > (:nicknames "NEW-DOG-CL" "NDCL")
> > > > (:export "REMOVE!" ...)
> > > > (:use "COMMON-LISP"))
>
> > > Ha! Ha! Ha! I'd vote for the "NEW-DOG-COMMON-LISP" package name
> > > proposal ;-)))))
>
> > Its not accurate enough. "PUPPY-DOG-COMMON-LISP" is better.
>
> > W
>
> I second that. This makes for an even easier marketing.
>
> What about "Cool Lisp" (domain is available, still CL as an acronym)?
That is way too cool! But we are condemned to use Communist Lisp :)
Apart from that Ron Garret proposed something like Ciel, which makes
perfect sense to Italian speakers :)
Cheers
--
Marco
On 25 mar, 07:12, Elena <········@gmail.com> wrote:
> On Mar 25, 6:53 am, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>
> > Here a old dog will start it for you:
>
> > (defpackage "NEW-DOG-COMMON-LISP"
> > (:nicknames "NEW-DOG-CL" "NDCL")
> > (:export "REMOVE!" ...)
> > (:use "COMMON-LISP"))
>
> Ha! Ha! Ha! I'd vote for the "NEW-DOG-COMMON-LISP" package name
> proposal ;-)))))
+1 - it is indeed a funny name. I thank you for the name, Pascal.
>
> >(defun remove! (item sequence &rest args &key from-end test test-not start end count key)
> > (apply (function cl:delete) item sequence args))
>
> We would be more likely to just define an alias, since the two
> functions are indeed the same one. Thank you for sketching a proposal,
> anyway.
I would create a macro that expand to (eval-when (...[always]...)
(setf (symbol-function 'remove!) (symbol-function 'delete)).
>
>
>
> > ;; ... let's see if any new dog will do the rest.
>
> > (If you scan cll, you might notice a pattern).
> > --
> > __Pascal Bourguignon__
>
> Pascal makes a point here. I understand that many experienced CLers
> quickly dismiss proposals for improvements because such a subject has
> been raised again and again, but very little action has been
> undertaken afterward.
>
> Let's hope this time things will be different.
Indeed.
On 25 mar, 08:10, ·····@runa.se (Björn Lindberg) wrote:
> Elena <········@gmail.com> writes:
> > However, your answer and previous answers by advanced lispers show
> > exactly what I intended when I said that CLers are set in their ways:
> > you people can't see things through the eyes of a novice anymore.
>
> The opposite is also true; you cannot see things through the eyes of
> the experienced. There are many new-comers with the same initial
> reactions you have, we see them in the group frequently. We also see
> what happens to them over time. A part of them is not interested in
> learning the language. The approach "please change your language so
> that I become motivated in learning it" generally works as well as
> when an immigrant to a country says "please change the laws so that I
> can accept following them". These people tend to go away
> eventually. The rest of them learn the language. With gaining
> experience, they realize that the superficial hurdles they saw as
> novices are not, and they become like the people you are now
> criticizing. Not people without criticism or ideas for improvement,
> but people with _interesting_ ideas about the language. Even the
> Clojure guy most certainly knew both Java and Lisp very well before he
> set out to improve on them.
>
> Björn Lindberg
That's a good point. I agree, most people who seem to be trying to
innovate are just trying not to learn too much. If someone here think
that CL sucks the way it is shouldn't be giving any opinion here.
I am learning CL for a while, now. It's been three years since I
started to read Practical Common Lisp book online. And I think CL is a
great language, and, even if this New Dog Common Lisp completely
fails, I'll continue programming on CL. You can write that down if you
want. But, when I saw this thread, I just thought: What if CL wasn't
the way it is? What if we could change small parts of CL, what parts
would I want to change in order to make it better?
I know that for now this is more like an extension package with no
real changes to the language itself. But we don't need to stop the
changes here. This is the start point, not the end point. The thing is
CL needs some fresh air, it's been in a close room for 20 years now.
Almost as old as me :)
For now I can just hope things not to end the way they usually do, and
start doing something.
gugamilare <··········@gmail.com> writes:
> I am learning CL for a while, now. It's been three years since I
> started to read Practical Common Lisp book online.
Congratulations!
> And I think CL is a
> great language, and, even if this New Dog Common Lisp completely
> fails, I'll continue programming on CL. You can write that down if you
> want. But, when I saw this thread, I just thought:
> What if CL wasn't
> the way it is? What if we could change small parts of CL, what parts
> would I want to change in order to make it better?
Then you would be programming in CL. This is exactly how you program
in lisp. You have a base programming language and you have a problem
to solve, and unfortunately, the programming language doesn't solve it
alone (there's no CL:SOLVE-MY-PROBLEM function). So you start by
changing small parts of CL. What parts? The parts that would make it
a language closer to the problem at hand, so you can write easily a
solution. That's what we call DSL, Domain Specific Languages.
> I know that for now this is more like an extension package with no
> real changes to the language itself. But we don't need to stop the
> changes here. This is the start point, not the end point. The thing is
> CL needs some fresh air,
That's what we call "applications".
> it's been in a close room for 20 years now.
> Almost as old as me :)
>
> For now I can just hope things not to end the way they usually do, and
> start doing something.
Indeed. Start a new lisp application!
--
__Pascal Bourguignon__
P� Wed, 25 Mar 2009 15:39:36 +0100, skrev gugamilare
<··········@gmail.com>:
>
> I would create a macro that expand to (eval-when (...[always]...)
> (setf (symbol-function 'remove!) (symbol-function 'delete)).
Fine. But I don't know what remove! is so I try to look it up. No luck.. I
try to track what other parts in the application use remove! or where it
was defined. Still no luck! See that is handled in a implementation
spesific manner by defun.. No, I have to guess that what remove! does is
the same as delete. Do you have any idea of how many software problems are
caused by guessing?
--------------
John Thingstad
Elena <········@gmail.com> writes:
>>(defun remove! (item sequence &rest args &key from-end test test-not start end count key)
>> (apply (function cl:delete) item sequence args))
>
> We would be more likely to just define an alias, since the two
> functions are indeed the same one. Thank you for sketching a proposal,
> anyway.
There are a lot of reasons why you'd want to define your own function,
amongst them:
1- you may want to define a generic function instead of a normal one.
2- defining your own function, you can TRACE it, or you can memoize
it, etc.
3- you may want them to deal with your own data types (immutable,
generic, whatever).
> Pascal makes a point here. I understand that many experienced CLers
> quickly dismiss proposals for improvements because such a subject has
> been raised again and again, but very little action has been
> undertaken afterward.
>
> Let's hope this time things will be different.
+ Tamas's answer in Message-ID: <··············@mid.individual.net>
--
__Pascal Bourguignon__
From: Cesar Rabak
Subject: Re: Is a new CL standard possible?
Date:
Message-ID: <gqdbm2$9il$1@aioe.org>
Elena escreveu:
> On 25 Mar, 02:20, Cesar Rabak <·······@yahoo.com.br> wrote:
>> Elena escreveu:
>>
>>> On 25 Mar, 00:04, Cesar Rabak <·······@yahoo.com.br> wrote:
>>>> Elena escreveu:
>>>>> What about user defined ones? What about user-defined ones which
>>>>> share the name with a non consing library one? or should we
>>>>> expect users to know all CL functions all the time?
>>>> Do you know any other environment� where this happens?
>>>> [1] Taking out all "concept" or immature languages, and thinking of
>>>> production ones, of course.
>>> Sadly, no. I say "sadly" because it seems that few designers, not
>>> just language designers, are really able to ease users' life.
>> I beg to differ!
>
> Have a read:
>
> http://www.amazon.com/Design-Everyday-Things-Donald-Norman/dp/0385267746
>
> Afterward, maybe you won't differ anymore.
>
I still differ because IMO [programming] languages are artifacts we use
for thinking, while keyboards (and stretching the concept the IDEs) are
more mechanical devices.
>>> And users are so used to warp themselves into ways of doing things
>>> (and "unergonomic" languages) just because that's how everyone has
>>> always made.
>> I don't think the use of the word ergonomics applies to programming
>> languages except as a metalepsis (albeit a forced one).
>
> That's the way I intended. Programming languages shouldn't be tied to
> "ergonomics", if that would hamper their effectiveness. Look at Lisp's
> parenthesis: you could argue they are "counter-intuitive", yet they
> are there for a reason. (Albeit I argue that Lisp is "ergonomic":
> after programming in it for a few days, looking at C++ or Java code
> make my eyes ache; the opposite is not true).
>
>>> For instance, early users of typewriters had to adjust themselves to
>>> the machines, because early typewriters had issues. Well, more than a
>>> century later, we have modern keyboards but still have to adjust to
>>> early typewriters because mainstream designers don't push for a real
>>> improvement. Why bother? Do you know any other keyboard� where this
>>> happens?
>>> [1] Taking out all "concept" or immature keyboards, and thinking of
>>> production ones, of course.
>> Which due my reasoning above makes this /non sequitur/. . .
>
> Why not?
>
Hope is clear now.
>> Notwithstanding, notice that for a lot of workers the strains caused by
>> the non ergonomic keyboards are less and less an issue due the ways we
>> use them.
>
> You've just stated that: they have been an useless issue for quite a
> while.
>
> Of course, if you are an hunt-and-peck typist, you couldn't mind less.
> Or do you program with a speech recognition program?
I would say that in my work typing (be it programming or ordinary text)
is 10% to 20% of the time, most time is used reading and in meetings.
For the PDA I have hand recognition applet, but speech recognition would
be nice asap they become feasible for technical writing and programming ;-)
On 25 Mar, 14:41, Cesar Rabak <·······@yahoo.com.br> wrote:
> Elena escreveu:
>
>
>
> > On 25 Mar, 02:20, Cesar Rabak <·······@yahoo.com.br> wrote:
> >> Elena escreveu:
>
> >>> On 25 Mar, 00:04, Cesar Rabak <·······@yahoo.com.br> wrote:
> >>>> Elena escreveu:
> >>>>> What about user defined ones? What about user-defined ones which
> >>>>> share the name with a non consing library one? or should we
> >>>>> expect users to know all CL functions all the time?
> >>>> Do you know any other environment¹ where this happens?
> >>>> [1] Taking out all "concept" or immature languages, and thinking of
> >>>> production ones, of course.
> >>> Sadly, no. I say "sadly" because it seems that few designers, not
> >>> just language designers, are really able to ease users' life.
> >> I beg to differ!
>
> > Have a read:
>
> >http://www.amazon.com/Design-Everyday-Things-Donald-Norman/dp/0385267746
>
> > Afterward, maybe you won't differ anymore.
>
> I still differ because IMO [programming] languages are artifacts we use
> for thinking, while keyboards (and stretching the concept the IDEs) are
> more mechanical devices.
>
>
>
> >>> And users are so used to warp themselves into ways of doing things
> >>> (and "unergonomic" languages) just because that's how everyone has
> >>> always made.
> >> I don't think the use of the word ergonomics applies to programming
> >> languages except as a metalepsis (albeit a forced one).
>
> > That's the way I intended. Programming languages shouldn't be tied to
> > "ergonomics", if that would hamper their effectiveness. Look at Lisp's
> > parenthesis: you could argue they are "counter-intuitive", yet they
> > are there for a reason. (Albeit I argue that Lisp is "ergonomic":
> > after programming in it for a few days, looking at C++ or Java code
> > make my eyes ache; the opposite is not true).
>
> >>> For instance, early users of typewriters had to adjust themselves to
> >>> the machines, because early typewriters had issues. Well, more than a
> >>> century later, we have modern keyboards but still have to adjust to
> >>> early typewriters because mainstream designers don't push for a real
> >>> improvement. Why bother? Do you know any other keyboard¹ where this
> >>> happens?
> >>> [1] Taking out all "concept" or immature keyboards, and thinking of
> >>> production ones, of course.
> >> Which due my reasoning above makes this /non sequitur/. . .
>
> > Why not?
>
> Hope is clear now.
>
> >> Notwithstanding, notice that for a lot of workers the strains caused by
> >> the non ergonomic keyboards are less and less an issue due the ways we
> >> use them.
>
> > You've just stated that: they have been an useless issue for quite a
> > while.
>
> > Of course, if you are an hunt-and-peck typist, you couldn't mind less.
> > Or do you program with a speech recognition program?
>
> I would say that in my work typing (be it programming or ordinary text)
> is 10% to 20% of the time, most time is used reading and in meetings.
>
> For the PDA I have hand recognition applet, but speech recognition would
> be nice asap they become feasible for technical writing and programming ;-)
I was about to write a nice reply, but who cares anymore?
Time to act. Thanks for your posts.
Thread closed.
P� Mon, 23 Mar 2009 22:26:28 +0100, skrev Javier <·······@gmail.com>:
> Elena escribi�:
>
>> You are right on the spot, Marco: talk is cheap, let's show them the
>> code ^_^
>>
>> Maybe the time to take action has come. Let's contact the people in
>> charge for the main free Common Lisp implementations and let's hope
>> they will agree to our proposal for a shared "not ANSI" codebase.
>> Let's agree on a (little) set of improvements over Common Lisp and
>> let's tackle the challenge.
>>
>> I'm a newbie but I'm going to do my best: documentation, testing,
>> everything I can do.
>>
>> Come on, Lispers, we can do it!
>
> I agree, and can participate too.
> This can even be my first "serious" (but funny) Lisp project.
>
> I would particularly interested in immutable structures add ons to the
> "standard".
Exactly why would you want to have a non-standard standard? The whole
point of Common Lisp was exactly to avoid fragmenting a already small
community into smaller fragments. These name issues generally only confuse
newbies anyhow. They become a non-issue when you know the library. To me
it seems several almost identical libraries would just add to the
confusion. Just how mutch code would you have to read to determine if you
were reading one or the other?
As for a standard library alla "Lisp Starter Pack" for LispWorks (Edi
Weitz) it sounds like a good idea. Getting SBCL up for useful work is a
annoying task of tracking hundreds of sometimes incompatible or
overlapping libraries from all over the web.
If you want immutable data-structures you would be better served with a
language optimized for functional code like Haskell.
--------------
John Thingstad
On 23 mar, 19:56, "John Thingstad" <·······@online.no> wrote:
> På Mon, 23 Mar 2009 22:26:28 +0100, skrev Javier <·······@gmail.com>:
>
>
>
> > Elena escribió:
>
> >> You are right on the spot, Marco: talk is cheap, let's show them the
> >> code ^_^
>
> >> Maybe the time to take action has come. Let's contact the people in
> >> charge for the main free Common Lisp implementations and let's hope
> >> they will agree to our proposal for a shared "not ANSI" codebase.
> >> Let's agree on a (little) set of improvements over Common Lisp and
> >> let's tackle the challenge.
>
> >> I'm a newbie but I'm going to do my best: documentation, testing,
> >> everything I can do.
>
> >> Come on, Lispers, we can do it!
>
> > I agree, and can participate too.
> > This can even be my first "serious" (but funny) Lisp project.
>
> > I would particularly interested in immutable structures add ons to the
> > "standard".
>
> Exactly why would you want to have a non-standard standard? The whole
> point of Common Lisp was exactly to avoid fragmenting a already small
> community into smaller fragments.
This is exactly why I suggested creating a new package instead of
trying to change the standard. Changing the standard is rather
complicated. Creating a new package is straightforward and has no
compatibility issues.
> These name issues generally only confuse
> newbies anyhow. They become a non-issue when you know the library. To me
> it seems several almost identical libraries would just add to the
> confusion. Just how mutch code would you have to read to determine if you
> were reading one or the other?
You need only to see which package each created package imports - the
standard :cl or the new package. For most libraries, this is reduced
to only one.
>
> As for a standard library alla "Lisp Starter Pack" for LispWorks (Edi
> Weitz) it sounds like a good idea. Getting SBCL up for useful work is a
> annoying task of tracking hundreds of sometimes incompatible or
> overlapping libraries from all over the web.
>
> If you want immutable data-structures you would be better served with a
> language optimized for functional code like Haskell.
No I won't :)
I never said I want immutable data-structures, I like using side
effects once in a while. I just want to make naming more intuitive.
Whenever you see two functions - remove and remove! - and you know
exactly what remove does, you also now exactly what remove! does.
>
> --------------
> John Thingstad
Anyway, another advantage to this approach is that no one needs to
abandon CL. If you want CL the way it is, just stick to it. If your
friend likes the "new standard" better, he can use it. You will
encounter some difficulties to share the code with your friend, just
like you would if he created a small hack lib with some shortcuts, but
there will be no difficulties to share entire packages and use their
functions / methods / whatever.
It is a new language, but it can still be completely valid ANSI Common
Lisp code. Isn't CL perfect for DSL?
From: Javier
Subject: Re: Is a new CL standard possible?
Date:
Message-ID: <gq95jd$suc$1@aioe.org>
John Thingstad escribi�:
> Exactly why would you want to have a non-standard standard? The whole
> point of Common Lisp was exactly to avoid fragmenting a already small
> community into smaller fragments.
I think that we do not pretend to create smaller fragments as it is
today, but merge all of them into a new CL metapackage.
> These name issues generally only
> confuse newbies anyhow. They become a non-issue when you know the
> library. To me it seems several almost identical libraries would just
> add to the confusion. Just how mutch code would you have to read to
> determine if you were reading one or the other?
>
> As for a standard library alla "Lisp Starter Pack" for LispWorks (Edi
> Weitz) it sounds like a good idea. Getting SBCL up for useful work is a
> annoying task of tracking hundreds of sometimes incompatible or
> overlapping libraries from all over the web.
>
> If you want immutable data-structures you would be better served with a
> language optimized for functional code like Haskell.
Or Clojure.
But everybody says that Lisp can do EVERYTHING, why not immutable data too?
Adding the features of Clojure to CL would be very nice.
> --------------
> John Thingstad
Elena wrote:
> On 22 Mar, 20:49, Javier <·······@gmail.com> wrote:
>> I was thinking this when reading the thread originated by Elena about
>> CL's fixable issues.
>> CL was standardized 20 years ago. In this time, several new languages
>> have been emerged, old languages has been changed, but CL didn't.
>> Because of this, people made new frameworks that have turned to be
>> almost standard, but still there are important implementation
>> differences in some cases, and even some of them are not universally
>> available.
>>
>> In this respect, yet nobody has been able to propose a new standard. It
>> is very costly, and Lisp is gaining very little use with respect to the
>> rest of the languages because of this. People prefer things already
>> packaged, standardized, universal, well documented. So they use
>> languages like Java, Python, Perl....
>>
>> My idea is: why not creating a "community" standard and a committee,
>> that is, a standard maintained and actualized by the Lisp community,
>> more or less like it is happening with scheme, responsible for:
>>
>> - Say what new frameworks are to be considered standard.
>> - Say what things about CL should be modernized.
>> - Say what new language constructs may be added.
>> - Write unified documentation, like a new hyperspec.
>>
>> About the frameworks, it can be used:
>>
>> - CFFI
>> - SB-THREAD
>> - ASDF
>> - LTK (or some other GUI library)
>> - Slime
>> - CL-SQL
>> - Any web framework, etc
>>
>> About the CL to be modernized:
>>
>> - Change names.
>> - Better AMOP
>> - A better syntax.
>>
>> About new features:
>>
>> - FSet or some other kind of inmutable structures.
>> - Memory transactions
>>
>> And whatever may be discussed.
>> And with all of this, any particular implementation can include all of
>> that, on top of the actual CL, so one can switch between the "new" and
>> the "old" standard. User can have the security that his/her program can
>> work in every implementation/platform almost without changes.
>>
>> I think it is not that difficult, but people _must_ participate in order
>> to be successful.
>>
>> What do think?
>
> I think that's an huge task, impossible to accomplish. Investigate
> what has just happened to the R6RS for Scheme, a much smaller job.
> Completed but dismissed by major implementers. OTOH, the initiative
> signaled by Pascal C. is admirable and I hope it will gain traction.
>
> I'd say that there is already a new Common Lisp standard. Its name is
> SBCL:
>
> http://www.lispforum.com/viewtopic.php?f=2&t=140
>
> As soon as the Windows port is stable, I think it will be the
> reference implementation for people interested in cross platform
> development.
This gratuitous. The fact that there are different Common Lisp
implementations, with different advantages and disadvantages, with
different sets of features, with different focuses, is a real strength.
There is no need for one of them dominating all the others. This
wouldn't serve any real purpose after all.
Pascal
--
ELS'09: http://www.european-lisp-symposium.org/
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: Brian Adkins
Subject: Re: Is a new CL standard possible?
Date:
Message-ID: <m2fxh4nsvl.fsf@gmail.com>
Pascal Costanza <··@p-cos.net> writes:
> Elena wrote:
>> I'd say that there is already a new Common Lisp standard. Its name is
>> SBCL:
>>
>> http://www.lispforum.com/viewtopic.php?f=2&t=140
>>
>> As soon as the Windows port is stable, I think it will be the
>> reference implementation for people interested in cross platform
>> development.
>
> This gratuitous. The fact that there are different Common Lisp
> implementations, with different advantages and disadvantages, with
> different sets of features, with different focuses, is a real
> strength. There is no need for one of them dominating all the
> others. This wouldn't serve any real purpose after all.
Pascal, I do agree with the strength of diversity you mention, but
couldn't there also be a disadvantage (at least among the open source
versions) in a diffusion of talent/effort?
It may be moot if the political & technical issues make it difficult
to for the open source Lisp implementation developers to pool
together, but in theory it seems that a single version could be
improved more rapidly, and there would be a larger user base for
testing & feedback.
I'm commenting from a "commercial use" perspective. I can see that
from an academic/experimental perspective, more versions is better.
--
Brian Adkins
http://lojic.com/
From: Javier
Subject: Re: Is a new CL standard possible?
Date:
Message-ID: <gq8j8r$at6$1@aioe.org>
Brian Adkins escribi�:
> Pascal Costanza <··@p-cos.net> writes:
>
>> Elena wrote:
>>> I'd say that there is already a new Common Lisp standard. Its name is
>>> SBCL:
>>>
>>> http://www.lispforum.com/viewtopic.php?f=2&t=140
>>>
>>> As soon as the Windows port is stable, I think it will be the
>>> reference implementation for people interested in cross platform
>>> development.
>> This gratuitous. The fact that there are different Common Lisp
>> implementations, with different advantages and disadvantages, with
>> different sets of features, with different focuses, is a real
>> strength. There is no need for one of them dominating all the
>> others. This wouldn't serve any real purpose after all.
>
> Pascal, I do agree with the strength of diversity you mention, but
> couldn't there also be a disadvantage (at least among the open source
> versions) in a diffusion of talent/effort?
>
> It may be moot if the political & technical issues make it difficult
> to for the open source Lisp implementation developers to pool
> together, but in theory it seems that a single version could be
> improved more rapidly, and there would be a larger user base for
> testing & feedback.
>
> I'm commenting from a "commercial use" perspective. I can see that
> from an academic/experimental perspective, more versions is better.
>
I agree.
Even more, LispWorks and Allegro are attractive because they are
consistent packages of frameworks on top of CL. Unfortunably, they are
not free nor consistent to each other and other implementations.
With SBCL you usually need to install Emacs, and all the external
frameworks in order to do real programming. With Clisp, ECL, Clozure,
the same.
On 23 Mar, 19:12, Javier <·······@gmail.com> wrote:
> With SBCL you usually need to install Emacs, and all the external
> frameworks in order to do real programming. With Clisp, ECL, Clozure,
> the same.
Don't ever touch Emacs! .\_/.
You will know the One True Editor and it will set you free ^_^
When it comes to Lisp programming, flashy IDEs just can't cut it.
Trust the oldies.
If you want a friendlier editor, try out ABLE:
http://phil.nullable.eu/
It should be the editor of choice for Common Lisp's newbie packages.
From: Javier
Subject: Re: Is a new CL standard possible?
Date:
Message-ID: <gq8vog$nij$1@aioe.org>
Elena escribi�:
> On 23 Mar, 19:12, Javier <·······@gmail.com> wrote:
>> With SBCL you usually need to install Emacs, and all the external
>> frameworks in order to do real programming. With Clisp, ECL, Clozure,
>> the same.
>
> Don't ever touch Emacs! .\_/.
>
> You will know the One True Editor and it will set you free ^_^
>
> When it comes to Lisp programming, flashy IDEs just can't cut it.
> Trust the oldies.
>
> If you want a friendlier editor, try out ABLE:
>
> http://phil.nullable.eu/
>
> It should be the editor of choice for Common Lisp's newbie packages.
I'm used to Emacs, no problem with that.
But ABLE is nice, too.
From: Pascal J. Bourguignon
Subject: Re: Is a new CL standard possible?
Date:
Message-ID: <87ab7di5zl.fsf@galatea.local>
Javier <·······@gmail.com> writes:
> I think it is not that difficult, but people _must_ participate in order
> to be successful.
>
> What do think?
If I _must_ participate, I _will_ if you _pay_ me to do so.
Either I've got a job and my boss doesn't pay me to do what you think
people must do, or I don't have a job and I must find bread and
shelter before doying what you think people must do.
So now, put your money where your mouth is. You can send the money to
my paypal account (at the From: email).
--
__Pascal Bourguignon__
Javier wrote:
> I was thinking this when reading the thread originated by Elena about
> CL's fixable issues.
> CL was standardized 20 years ago. In this time, several new languages
> have been emerged, old languages has been changed, but CL didn't.
> Because of this, people made new frameworks that have turned to be
> almost standard, but still there are important implementation
> differences in some cases, and even some of them are not universally
> available.
>
> In this respect, yet nobody has been able to propose a new standard. It
> is very costly, and Lisp is gaining very little use with respect to the
> rest of the languages because of this. People prefer things already
> packaged, standardized, universal, well documented. So they use
> languages like Java, Python, Perl....
>
> My idea is: why not creating a "community" standard and a committee,
> that is, a standard maintained and actualized by the Lisp community,
> more or less like it is happening with scheme, responsible for:
>
> - Say what new frameworks are to be considered standard.
> - Say what things about CL should be modernized.
> - Say what new language constructs may be added.
> - Write unified documentation, like a new hyperspec.
>
> About the frameworks, it can be used:
>
> - CFFI
> - SB-THREAD
> - ASDF
> - LTK (or some other GUI library)
> - Slime
> - CL-SQL
> - Any web framework, etc
>
> About the CL to be modernized:
>
> - Change names.
> - Better AMOP
> - A better syntax.
>
> About new features:
>
> - FSet or some other kind of inmutable structures.
> - Memory transactions
>
>
> And whatever may be discussed.
> And with all of this, any particular implementation can include all of
> that, on top of the actual CL, so one can switch between the "new" and
> the "old" standard. User can have the security that his/her program can
> work in every implementation/platform almost without changes.
>
> I think it is not that difficult, but people _must_ participate in order
> to be successful.
>
> What do think?
Good idea. We actually have an infrastructure for such improvements. See
http://cdr.eurolisp.org/
Just start somewhere.
Pascal
--
ELS'09: http://www.european-lisp-symposium.org/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
I haven't been using CL for as long as most of the people who frequent
here. But, here's my 2 cents to toss into the pot (knowing full well
that this - or any other similar proposal - will never actually
happen)...
Every language at its core is a set of rules that answer how data is
created, stored, accessed, and output. But, by themselves, these rules
do very little. In order to do _real_ work, libraries are needed
(whether composed in that language or at a lower level and later
linked to). Even a language as low-level as C can't print "Hello,
world!" out to the screen without the additional help of a library.
Usually, a well designed language comes with a standard method for
accessing all those external libraries as to extend its own
functionality. In C this is header files and linking libraries. In Lua
this is writing some C glue code and using some built-in functions for
linking to them at runtime. Ruby has its "gems." And many other
languages have their own methodologies.
Common Lisp's core problem (IMHO) with wide-spread acceptance has
little to do with ()'s or even a lack of libraries (because there's a
wealth of them out there to do anything you might want!). But rather,
it's the language's lack of a standardized method of getting those
libraries into a usable form quickly for a newbie.
DEFPACKAGE, LOAD, REQUIRE, and PROVIDE are so minimal and haphazard
that they don't even begin to qualify. Has anyone actually made a
large Lisp program with nothing but them (that's meant to be
rhetorical)? The proof of this is just how many implementations of
Lisp attempt to wrap them into a usable format: LispWorks uses
DEFSYSTEM, Allegro does its own thing, CCL has its.
The idea that I need to download and install a 3rd party system (ASDF)
so that I can install a 3rd party package (CFFI) so that I can utilize
3rd party libraries is ridiculous. That the language doesn't provide
at least a standard method of utilizing lower-level, dynamic libraries
is also equally puzzling. Having just these 2 simple additions to
Common Lisp would add so much overnight, I think c.l.l would suddenly
get a surge of activity.
Imagine if downloading Python meant that all you got were the basic
types, an REPL. There were many implementations of Python out there,
and they each had their own version of the "import" keyword (because
import wasn't part of the language in this upside-down world). You'd
like to prototype a simple socket app, but now you need a socket
library. Okay, well, since each Python implementation loads libraries
differently, you need to now download a wrapper library for this. But
it requires the "common" wrapper for loading additional code. It's
taken less than 20 minutes for you - as a programmer - to give up on
Python as a plausible tool for use in real production environment. And
Python would never, ever gain any kind of widespread acceptance. Why?
- Significant time sync just to prototype a stupidly simple idea
- Too many 3rd party requirements (they can be discontinued, go away,
be bought out, ...)
- Lots of preparation work, and if there's more than 1 person on the
team, lots of upkeep, too
- Even if an implementation came with everything that did it for you,
it's not portable
And this is sad, because we all know how wonderful Python (*cough*
Lisp *cough*) is, how much of a dream it can be to work with, and the
production benefits.
(Jumps for cover behind comp.lang.smalltalk ;-))
Jeff M.
On 23 Mar, 19:36, "Jeff M." <·······@gmail.com> wrote:
> I haven't been using CL for as long as most of the people who frequent
> here. But, here's my 2 cents to toss into the pot (knowing full well
> that this - or any other similar proposal - will never actually
> happen)...
>
> Every language at its core is a set of rules that answer how data is
> created, stored, accessed, and output. But, by themselves, these rules
> do very little. In order to do _real_ work, libraries are needed
> (whether composed in that language or at a lower level and later
> linked to). Even a language as low-level as C can't print "Hello,
> world!" out to the screen without the additional help of a library.
>
> Usually, a well designed language comes with a standard method for
> accessing all those external libraries as to extend its own
> functionality. In C this is header files and linking libraries. In Lua
> this is writing some C glue code and using some built-in functions for
> linking to them at runtime. Ruby has its "gems." And many other
> languages have their own methodologies.
>
> Common Lisp's core problem (IMHO) with wide-spread acceptance has
> little to do with ()'s or even a lack of libraries (because there's a
> wealth of them out there to do anything you might want!). But rather,
> it's the language's lack of a standardized method of getting those
> libraries into a usable form quickly for a newbie.
>
> DEFPACKAGE, LOAD, REQUIRE, and PROVIDE are so minimal and haphazard
> that they don't even begin to qualify. Has anyone actually made a
> large Lisp program with nothing but them (that's meant to be
> rhetorical)? The proof of this is just how many implementations of
> Lisp attempt to wrap them into a usable format: LispWorks uses
> DEFSYSTEM, Allegro does its own thing, CCL has its.
>
> The idea that I need to download and install a 3rd party system (ASDF)
> so that I can install a 3rd party package (CFFI) so that I can utilize
> 3rd party libraries is ridiculous. That the language doesn't provide
> at least a standard method of utilizing lower-level, dynamic libraries
> is also equally puzzling. Having just these 2 simple additions to
> Common Lisp would add so much overnight, I think c.l.l would suddenly
> get a surge of activity.
>
> Imagine if downloading Python meant that all you got were the basic
> types, an REPL. There were many implementations of Python out there,
> and they each had their own version of the "import" keyword (because
> import wasn't part of the language in this upside-down world). You'd
> like to prototype a simple socket app, but now you need a socket
> library. Okay, well, since each Python implementation loads libraries
> differently, you need to now download a wrapper library for this. But
> it requires the "common" wrapper for loading additional code. It's
> taken less than 20 minutes for you - as a programmer - to give up on
> Python as a plausible tool for use in real production environment. And
> Python would never, ever gain any kind of widespread acceptance. Why?
>
> - Significant time sync just to prototype a stupidly simple idea
> - Too many 3rd party requirements (they can be discontinued, go away,
> be bought out, ...)
> - Lots of preparation work, and if there's more than 1 person on the
> team, lots of upkeep, too
> - Even if an implementation came with everything that did it for you,
> it's not portable
>
> And this is sad, because we all know how wonderful Python (*cough*
> Lisp *cough*) is, how much of a dream it can be to work with, and the
> production benefits.
>
> (Jumps for cover behind comp.lang.smalltalk ;-))
>
> Jeff M.
Jeff... I... love... you... ^_^
From: Javier
Subject: Re: Is a new CL standard possible?
Date:
Message-ID: <gq8otm$goc$1@aioe.org>
Jeff M. escribi�:
> I haven't been using CL for as long as most of the people who frequent
> here. But, here's my 2 cents to toss into the pot (knowing full well
> that this - or any other similar proposal - will never actually
> happen)...
>
> Every language at its core is a set of rules that answer how data is
> created, stored, accessed, and output. But, by themselves, these rules
> do very little. In order to do _real_ work, libraries are needed
> (whether composed in that language or at a lower level and later
> linked to). Even a language as low-level as C can't print "Hello,
> world!" out to the screen without the additional help of a library.
>
> Usually, a well designed language comes with a standard method for
> accessing all those external libraries as to extend its own
> functionality. In C this is header files and linking libraries. In Lua
> this is writing some C glue code and using some built-in functions for
> linking to them at runtime. Ruby has its "gems." And many other
> languages have their own methodologies.
>
> Common Lisp's core problem (IMHO) with wide-spread acceptance has
> little to do with ()'s or even a lack of libraries (because there's a
> wealth of them out there to do anything you might want!). But rather,
> it's the language's lack of a standardized method of getting those
> libraries into a usable form quickly for a newbie.
>
> DEFPACKAGE, LOAD, REQUIRE, and PROVIDE are so minimal and haphazard
> that they don't even begin to qualify. Has anyone actually made a
> large Lisp program with nothing but them (that's meant to be
> rhetorical)? The proof of this is just how many implementations of
> Lisp attempt to wrap them into a usable format: LispWorks uses
> DEFSYSTEM, Allegro does its own thing, CCL has its.
>
> The idea that I need to download and install a 3rd party system (ASDF)
> so that I can install a 3rd party package (CFFI) so that I can utilize
> 3rd party libraries is ridiculous. That the language doesn't provide
> at least a standard method of utilizing lower-level, dynamic libraries
> is also equally puzzling. Having just these 2 simple additions to
> Common Lisp would add so much overnight, I think c.l.l would suddenly
> get a surge of activity.
>
> Imagine if downloading Python meant that all you got were the basic
> types, an REPL. There were many implementations of Python out there,
> and they each had their own version of the "import" keyword (because
> import wasn't part of the language in this upside-down world). You'd
> like to prototype a simple socket app, but now you need a socket
> library. Okay, well, since each Python implementation loads libraries
> differently, you need to now download a wrapper library for this. But
> it requires the "common" wrapper for loading additional code. It's
> taken less than 20 minutes for you - as a programmer - to give up on
> Python as a plausible tool for use in real production environment. And
> Python would never, ever gain any kind of widespread acceptance. Why?
>
> - Significant time sync just to prototype a stupidly simple idea
> - Too many 3rd party requirements (they can be discontinued, go away,
> be bought out, ...)
> - Lots of preparation work, and if there's more than 1 person on the
> team, lots of upkeep, too
> - Even if an implementation came with everything that did it for you,
> it's not portable
>
> And this is sad, because we all know how wonderful Python (*cough*
> Lisp *cough*) is, how much of a dream it can be to work with, and the
> production benefits.
>
> (Jumps for cover behind comp.lang.smalltalk ;-))
>
> Jeff M.
I mostly agree, except that I extent your requirements:
- Threads are a must.
- Net access is a must.
- CFFI is a must.
- Unified documentation is a must.
- GUI libraries are not a must, but very convenient.
- Database access is not a must, but very convenient.
At the end, you end up with the requirements of my original message. I'm
not telling to add some esoteric library about Fourier transformations,
just some common things that are absolutely a must for doing anything
serious.
Isn't it Common Lisp supposed to be common? It is a joke that it has
that name, but at the end it severely lacks common things. That's
because the standard is too old. I think we need fresh air. And, if the
community doesn't do it... who else?
On Mar 23, 8:48 pm, Javier <·······@gmail.com> wrote:
> Jeff M. escribió:
>
>
>
> > I haven't been using CL for as long as most of the people who frequent
> > here. But, here's my 2 cents to toss into the pot (knowing full well
> > that this - or any other similar proposal - will never actually
> > happen)...
>
> > Every language at its core is a set of rules that answer how data is
> > created, stored, accessed, and output. But, by themselves, these rules
> > do very little. In order to do _real_ work, libraries are needed
> > (whether composed in that language or at a lower level and later
> > linked to). Even a language as low-level as C can't print "Hello,
> > world!" out to the screen without the additional help of a library.
>
> > Usually, a well designed language comes with a standard method for
> > accessing all those external libraries as to extend its own
> > functionality. In C this is header files and linking libraries. In Lua
> > this is writing some C glue code and using some built-in functions for
> > linking to them at runtime. Ruby has its "gems." And many other
> > languages have their own methodologies.
>
> > Common Lisp's core problem (IMHO) with wide-spread acceptance has
> > little to do with ()'s or even a lack of libraries (because there's a
> > wealth of them out there to do anything you might want!). But rather,
> > it's the language's lack of a standardized method of getting those
> > libraries into a usable form quickly for a newbie.
>
> > DEFPACKAGE, LOAD, REQUIRE, and PROVIDE are so minimal and haphazard
> > that they don't even begin to qualify. Has anyone actually made a
> > large Lisp program with nothing but them (that's meant to be
> > rhetorical)? The proof of this is just how many implementations of
> > Lisp attempt to wrap them into a usable format: LispWorks uses
> > DEFSYSTEM, Allegro does its own thing, CCL has its.
>
> > The idea that I need to download and install a 3rd party system (ASDF)
> > so that I can install a 3rd party package (CFFI) so that I can utilize
> > 3rd party libraries is ridiculous. That the language doesn't provide
> > at least a standard method of utilizing lower-level, dynamic libraries
> > is also equally puzzling. Having just these 2 simple additions to
> > Common Lisp would add so much overnight, I think c.l.l would suddenly
> > get a surge of activity.
>
> > Imagine if downloading Python meant that all you got were the basic
> > types, an REPL. There were many implementations of Python out there,
> > and they each had their own version of the "import" keyword (because
> > import wasn't part of the language in this upside-down world). You'd
> > like to prototype a simple socket app, but now you need a socket
> > library. Okay, well, since each Python implementation loads libraries
> > differently, you need to now download a wrapper library for this. But
> > it requires the "common" wrapper for loading additional code. It's
> > taken less than 20 minutes for you - as a programmer - to give up on
> > Python as a plausible tool for use in real production environment. And
> > Python would never, ever gain any kind of widespread acceptance. Why?
>
> > - Significant time sync just to prototype a stupidly simple idea
> > - Too many 3rd party requirements (they can be discontinued, go away,
> > be bought out, ...)
> > - Lots of preparation work, and if there's more than 1 person on the
> > team, lots of upkeep, too
> > - Even if an implementation came with everything that did it for you,
> > it's not portable
>
> > And this is sad, because we all know how wonderful Python (*cough*
> > Lisp *cough*) is, how much of a dream it can be to work with, and the
> > production benefits.
>
> > (Jumps for cover behind comp.lang.smalltalk ;-))
>
> > Jeff M.
>
> I mostly agree, except that I extent your requirements:
>
> - Threads are a must.
> - Net access is a must.
> - CFFI is a must.
> - Unified documentation is a must.
> - GUI libraries are not a must, but very convenient.
> - Database access is not a must, but very convenient.
>
> At the end, you end up with the requirements of my original message. I'm
> not telling to add some esoteric library about Fourier transformations,
> just some common things that are absolutely a must for doing anything
> serious.
>
> Isn't it Common Lisp supposed to be common? It is a joke that it has
> that name, but at the end it severely lacks common things. That's
> because the standard is too old. I think we need fresh air. And, if the
> community doesn't do it... who else?
Well. Stop wasting time with clojure and pointless dot syntax and
write a few CDRs. The process is laid out very clearly and it works.
Cheers
--
Marco
On Mar 23, 2:48 pm, Javier <·······@gmail.com> wrote:
>
> .... I think we need fresh air. And, if the community doesn't do it... who else?
One thing I'd note: the community is doing this in a way. They are
moving away from "Common" lisp. Clojure, Arc, Qi, and other Lisp-like
implementations are becoming far more popular [than CL] very quickly.
And the reasons provided are why.
I find this sad, though, because these are people who are reinventing
the wheel to get the support they need. But, in the process, so much
is going to be lost (for one, some excellent Lisp compilers).
It's not like CL needs a tummy tuck, face lift, and botox injections.
Those would imply serious problems with its age, which there aren't
any. It just needs a new pair of pants. And for some reason it's a
real PITA to get everyone to agree to denim. ;-)
Jeff M.
On 23 Mar, 21:01, "Jeff M." <·······@gmail.com> wrote:
> On Mar 23, 2:48 pm, Javier <·······@gmail.com> wrote:
>
>
>
> > .... I think we need fresh air. And, if the community doesn't do it... who else?
>
> One thing I'd note: the community is doing this in a way. They are
> moving away from "Common" lisp. Clojure, Arc, Qi, and other Lisp-like
> implementations are becoming far more popular [than CL] very quickly.
> And the reasons provided are why.
>
> I find this sad, though, because these are people who are reinventing
> the wheel to get the support they need. But, in the process, so much
> is going to be lost (for one, some excellent Lisp compilers).
>
> It's not like CL needs a tummy tuck, face lift, and botox injections.
> Those would imply serious problems with its age, which there aren't
> any. It just needs a new pair of pants. And for some reason it's a
> real PITA to get everyone to agree to denim. ;-)
>
> Jeff M.
Oh, Jeff! One more time... I... love... you... (smack!) ;-)))))
On Mar 23, 4:01 pm, "Jeff M." <·······@gmail.com> wrote:
> One thing I'd note: the community is doing this in a way. They are
> moving away from "Common" lisp. Clojure, Arc, Qi, and other Lisp-like
> implementations are becoming far more popular [than CL] very quickly.
> And the reasons provided are why.
There is no real evidence of this. These lisp dialects get some buzz
for a while then fade into obscurity. Many people think they can do
better than the common lisp standard and existing common lisp
implementations. They're usually wrong. If you've been around long
enough you remember dylan, and goo. Both were going to be the shiny
new version of lisp. Both are now largely forgotten and common lisp is
still chugging along. The same thing will most likely happen to Qi and
clojure. There's only so much lisp mindshare out there, and it's been
taken by scheme and common lisp.
The features you ask for are all present in decent quality
implementations. Everything people are whining about here are non-
issues for people who work with common lisp regularly. They almost all
spring from the unwarranted expectation that a multi-implementation
language with a standard will work just like a single implementation
language with no standard (e.g., python, perl, ruby, etc.).
As to writing a major piece of software using just load, require, etc.
from the standard, this is trivially possible since asdf.lisp is a
single file which you load. Then you download asdf-install and do:
(asdf:oos 'asdf:load-op :asdf-install)
then you install dozens of libs with:
(asdf-install:install :some-useful-lib)
With some implementations, you don't even need the first step since
they come with asdf.
On Mar 24, 11:25 pm, Elena <········@gmail.com> wrote:
> And even when I state the obvious from the perspective of any
> experienced programmer interested in learning CL - as when I've said
> that having to learn inconsistent naming is a waste of time and mind
> resources better spent elsewhere, and a bad example for inexperienced
> programmers - I am reprimanded because "I'm lazy", "Why do you make
> such a big deal?", "Can't you see the Lisp beyond all the kludge?" and
> so forth.
>
> As a skilled C++ programmer, I've paid my dues. My experience and my
> common sense now let me realize that much effort has been for no real
> gain. When I teach C++ newbies, since I can't fix the language, I care
> to save them useless pain and wasting of time. But not all people are
> like me, I understand that.
>
> Therefore we young - young in respect to CL, not age - can't expect
> any help from old timers as we thought we could. They are proud of
> their hard won knowledge and they are not going to leverage their
> experience to help us achieve more in less time. My only hope is that
> I'm not alone, and there is a young community large enough to let us
> help each other and build a better world, when it comes to CL, for
> those who will follow us.
>
> Long live CL!
>
Yeah! Let's toast to that. Now, after having paid your dues to the
42 ways to reference a L-value in C++ via template metaprogramming to
access the Java JNI (yes: we know about it!), can you put the same
kind of effort in solving some of CL *real* problems? Possibly in a
Lispy (meaning Communist) way?
Thank you :)
Cheers
--
Marco
On 25 Mar, 01:07, Elena <········@gmail.com> wrote:
> Maybe it's just that I've deeply realized that life is short and I'm
> not that young anymore. I'm willing to pay my dues, but I'd like to
> save as much time as possible, without compromising the result. For me
> and for my fellows as well.
I can honestly recommend just starting on a project. When I first
found CL about 3 years ago, also coming from C++, I quickly raced
through enough tutorials to learn the basics and then started writing
programs that I needed (for work) or that interested me (for fun).
It's not that I'm easily pleased either, in fact quite the opposite:
in over 20 years of programming I've used plenty of languages
including some of the 'fashionable' ones like Python, Ruby and Haskell
but usually find some reason not to like them, rational or otherwise.
Maybe it was just that CL suited the way my mind works but I've yet to
find anything in the language itself which stops me from writing code.
Quite the opposite in fact! Maybe it's human nature to never be
satisfied and maybe that's a good thing. But if you're worried about
life being short, as you say, then I can confirm that you've found the
most powerful language currently available and it's now time to use it
to write some cool programs!
--
Phil
http://phil.nullable.eu/
On Mar 24, 5:59 pm, Elena <········@gmail.com> wrote:
> Are you saying that Java is as expressive as Clojure, and as dense?
I'm saying that Java is better known by dense programmers.
On Mar 25, 1:34 pm, Raffael Cavallaro <················@gmail.com>
wrote:
> On Mar 24, 5:59 pm, Elena <········@gmail.com> wrote:
>
> > Are you saying that Java is as expressive as Clojure, and as dense?
>
> I'm saying that Java is better known by dense programmers.
What?
On 25 Mar, 15:31, Elena <········@gmail.com> wrote:
> On Mar 25, 1:34 pm, Raffael Cavallaro <················@gmail.com>
> wrote:
>
> > On Mar 24, 5:59 pm, Elena <········@gmail.com> wrote:
>
> > > Are you saying that Java is as expressive as Clojure, and as dense?
>
> > I'm saying that Java is better known by dense programmers.
>
> What?
Nevermind.
Thread closed.
On Mar 24, 6:25 pm, Elena <········@gmail.com> wrote:
> As a skilled C++ programmer, I've paid my dues.
You've paid your dues in C++, not common lisp.
At this point I can state with complete confidence that if you had
spent the time you spent posting here on learning the names of
functions in the common lisp standard you would be done by now.
By not doing so you're looking more and more like a troll with each
post.
On 25 Mar, 14:39, Raffael Cavallaro <················@gmail.com>
wrote:
> On Mar 24, 6:25 pm, Elena <········@gmail.com> wrote:
>
> > As a skilled C++ programmer, I've paid my dues.
>
> You've paid your dues in C++, not common lisp.
>
> At this point I can state with complete confidence that if you had
> spent the time you spent posting here on learning the names of
> functions in the common lisp standard you would be done by now.
>
> By not doing so you're looking more and more like a troll with each
> post.
Thanks for your posts.
Thread closed.
Elena <········@gmail.com> wrote:
+---------------
| Thread closed.
+---------------
Says who?!? This is netnews. A thread "closes" when *everyone*
gets tired of it, not just one person... ;-}
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Mar 26, 2:47 am, ····@rpw3.org (Rob Warnock) wrote:
> Elena <········@gmail.com> wrote:
>
> +---------------
> | Thread closed.
> +---------------
>
> Says who?!? This is netnews. A thread "closes" when *everyone*
> gets tired of it, not just one person... ;-}
>
> -Rob
>
> -----
> Rob Warnock <····@rpw3.org>
> 627 26th Avenue <URL:http://rpw3.org/>
> San Mateo, CA 94403 (650)572-2607
OK, I should have said "Thread closed for me"? The optimizer left out
"for me" ;-)
I was just meaning I didn't want to answer anymore without making
people think I was dismissing them.
Elena <········@gmail.com> writes:
> On Mar 26, 2:47��am, ····@rpw3.org (Rob Warnock) wrote:
> > Elena ��<········@gmail.com> wrote:
> >
> > +---------------
> > | Thread closed.
> > +---------------
> >
> > Says who?!? This is netnews. A thread "closes" when *everyone*
> > gets tired of it, not just one person... ��;-}
> >
> > -Rob
> >
> > -----
>
> OK, I should have said "Thread closed for me"? The optimizer left out
> "for me" ;-)
Obviously not.
> I was just meaning I didn't want to answer anymore without making
> people think I was dismissing them.
--
Thomas A. Russ, USC/Information Sciences Institute
Ok, I have created a package named :puppy-common-lisp in which I
renamed all those destructive functions, and started creating the let*
macro. Then I looked at metabang-bind and found out that it is much
more flexible than it really looks. It does not only support
the :values keyword to specify multiple value binding, but also
supports :accessor (you give arguments as to (with-accessors)), :plist
(destructures a plist), :alist (destructures an assoc
list), :structure (if I recall it is like with-slots), and a few more.
And it is extensible, so you can easily create your own keywords.
This made me just think: why am I trying to do this anyway? The whole
package will just have some renamed functions (I dislike most of them,
by the way) and a let macro which will be either less flexible then or
a simple extension to (to allow type declarations) metabang-bind
itself. Anyway, the only useful thing about all of this would be to
import and export commonly used libraries, and, as was said here, many
already tried unsuccessfully to do this.
The thing I want to say is: I am dropping it. And I am saying this
because I said I was gonna help, just know that I won't anymore. It is
just useless anyway. If anyone wants the code I made, ok, just ask me,
and I'll send it.
From: Pascal J. Bourguignon
Subject: Re: Is a new CL standard possible?
Date:
Message-ID: <87hc1fdgnz.fsf@galatea.local>
gugamilare <··········@gmail.com> writes:
> Ok, I have created a package named :puppy-common-lisp in which I
> renamed all those destructive functions, and started creating the let*
> macro. Then I looked at metabang-bind and found out that it is much
> more flexible than it really looks. It does not only support
> the :values keyword to specify multiple value binding, but also
> supports :accessor (you give arguments as to (with-accessors)), :plist
> (destructures a plist), :alist (destructures an assoc
> list), :structure (if I recall it is like with-slots), and a few more.
> And it is extensible, so you can easily create your own keywords.
>
> This made me just think: why am I trying to do this anyway? The whole
> package will just have some renamed functions (I dislike most of them,
> by the way) and a let macro which will be either less flexible then or
> a simple extension to (to allow type declarations) metabang-bind
> itself. Anyway, the only useful thing about all of this would be to
> import and export commonly used libraries, and, as was said here, many
> already tried unsuccessfully to do this.
>
> The thing I want to say is: I am dropping it. And I am saying this
> because I said I was gonna help, just know that I won't anymore. It is
> just useless anyway. If anyone wants the code I made, ok, just ask me,
> and I'll send it.
I think we can give you the medal of the fastest realization of the
futility of this endeavour.
Congratulations! You've made a big CL newbie step.
--
__Pascal Bourguignon__
On Thu, 26 Mar 2009 15:52:49 -0700, gugamilare wrote:
> Ok, I have created a package named :puppy-common-lisp in which I renamed
> all those destructive functions, and started creating the let* macro.
> Then I looked at metabang-bind and found out that it is much more
> flexible than it really looks. It does not only support the :values
> keyword to specify multiple value binding, but also supports :accessor
> (you give arguments as to (with-accessors)), :plist (destructures a
> plist), :alist (destructures an assoc list), :structure (if I recall it
> is like with-slots), and a few more. And it is extensible, so you can
> easily create your own keywords.
And metaband-bind also handles arrays, eg
;; contrived example
(bind ((#2A((nil nil) (nil elt22))
(make-array '(2 2) :initial-contents '((1 2) (3 4)))))
elt22) ; => 4
It is an amazing package, and could safely be called "standard". And
the author, Gary King, is extremely responsive and helpful, when I
asked for arrays he added them within a day.
Tamas
On 27 mar, 05:21, Tamas K Papp <······@gmail.com> wrote:
> On Thu, 26 Mar 2009 15:52:49 -0700, gugamilare wrote:
> > Ok, I have created a package named :puppy-common-lisp in which I renamed
> > all those destructive functions, and started creating the let* macro.
> > Then I looked at metabang-bind and found out that it is much more
> > flexible than it really looks. It does not only support the :values
> > keyword to specify multiple value binding, but also supports :accessor
> > (you give arguments as to (with-accessors)), :plist (destructures a
> > plist), :alist (destructures an assoc list), :structure (if I recall it
> > is like with-slots), and a few more. And it is extensible, so you can
> > easily create your own keywords.
>
> And metaband-bind also handles arrays, eg
>
> ;; contrived example
> (bind ((#2A((nil nil) (nil elt22))
> (make-array '(2 2) :initial-contents '((1 2) (3 4)))))
> elt22) ; => 4
>
> It is an amazing package, and could safely be called "standard". And
> the author, Gary King, is extremely responsive and helpful, when I
> asked for arrays he added them within a day.
>
> Tamas
Oh, that is how arrays work... I didn't have figured it out (I didn't
try hard to do so, though :).
Gary King seems to be a nice guy, indeed. I've reported a few bugs
sent a few patches to him already.
Elena <········@gmail.com> writes:
> On 24 Mar, 21:33, Raffael Cavallaro <················@gmail.com>
> wrote:
>> On Mar 24, 2:50�pm, Elena <········@gmail.com> wrote:
>>
>> > I don't think Clojure is buzz, Raffael. Clojure is not just a new
>> > shiny version of Lisp. It offers *real* advantages over *every* CL out
>> > there, namely deep integration with Java platform with its scads of
>> > libraries
>>
>> java libraries can be used from existing lisp implementations.
>
> That's not *deep* integration. Which CL do run over the JVM? ABCL?
> Still not stable when it comes to concurrency (see web site). And have
> you compared ABCL's community with Clojure's one? Clojure is much more
> likely to achieve required stability. Buzz helps, you know. And have
> you compared Clojure's syntactic sugar for calling Java with ABCL's
> "low level" one? What? Should I just write a bunch of macros? Did I
> say I'm a newbie already? Yes, I did. I'll just use Clojure.
abcl works well. You would know that if you had actually tried it, but
from your post I can tell that you have not.
-russ
On Mar 25, 12:25 pm, Russell McManus <···············@yahoo.com>
wrote:
> Elena <········@gmail.com> writes:
> > On 24 Mar, 21:33, Raffael Cavallaro <················@gmail.com>
> > wrote:
> >> On Mar 24, 2:50 pm, Elena <········@gmail.com> wrote:
>
> >> > I don't think Clojure is buzz, Raffael. Clojure is not just a new
> >> > shiny version of Lisp. It offers *real* advantages over *every* CL out
> >> > there, namely deep integration with Java platform with its scads of
> >> > libraries
>
> >> java libraries can be used from existing lisp implementations.
>
> > That's not *deep* integration. Which CL do run over the JVM? ABCL?
> > Still not stable when it comes to concurrency (see web site). And have
> > you compared ABCL's community with Clojure's one? Clojure is much more
> > likely to achieve required stability. Buzz helps, you know. And have
> > you compared Clojure's syntactic sugar for calling Java with ABCL's
> > "low level" one? What? Should I just write a bunch of macros? Did I
> > say I'm a newbie already? Yes, I did. I'll just use Clojure.
>
> abcl works well. You would know that if you had actually tried it, but
> from your post I can tell that you have not.
>
> -russ
You are right, I've not tried it. Scroll to the bottom of this page
and read on:
http://common-lisp.net/project/armedbear/testimonials.shtml
No mention about fixes. Would you try out a tool if its web site
itself warns you already that features you're interested in are still
not stable?
Anyway, CL has a JVM based implementation. Kudos to its authors. I
hope we'll manage to help them make the product solid.
Elena <········@gmail.com> writes:
> You are right, I've not tried it. Scroll to the bottom of this page
> and read on:
>
> http://common-lisp.net/project/armedbear/testimonials.shtml
>
> No mention about fixes. Would you try out a tool if its web site
> itself warns you already that features you're interested in are still
> not stable?
So you are putting forth Clojure as a superior alternative.
I read the clojure mailing list; fundamental changes have been made to
the guts of Clojure in the last month or two. Yet apparently stability
is very important to you. Hmm, quite a conundrum.
-russ
On Mar 25, 1:37 pm, Russell McManus <···············@yahoo.com> wrote:
> Elena <········@gmail.com> writes:
> > You are right, I've not tried it. Scroll to the bottom of this page
> > and read on:
>
> >http://common-lisp.net/project/armedbear/testimonials.shtml
>
> > No mention about fixes. Would you try out a tool if its web site
> > itself warns you already that features you're interested in are still
> > not stable?
>
> So you are putting forth Clojure as a superior alternative.
>
> I read the clojure mailing list; fundamental changes have been made to
> the guts of Clojure in the last month or two. Yet apparently stability
> is very important to you. Hmm, quite a conundrum.
>
> -russ
Clojure is still a promise, but it is more likely to deliver.
Concurrency is embedded into the language specification, therefore a
priority, not just an useful add-on like it happens with CL
implementations, as ABCL.
Clojure also has more useful features *right out of the box* and more
buzz. That means more people working on the project and I let you
guess what that means.
Elena <········@gmail.com> writes:
> Clojure is still a promise, but it is more likely to deliver.
> Concurrency is embedded into the language specification, therefore a
> priority, not just an useful add-on like it happens with CL
> implementations, as ABCL.
>
> Clojure also has more useful features *right out of the box* and more
> buzz. That means more people working on the project and I let you
> guess what that means.
Alright, I'll just pretend that I didn't read your earlier comments,
then. Thanks for clarifying things!
-russ
From: Cesar Rabak
Subject: Re: Is a new CL standard possible?
Date:
Message-ID: <gqdb5a$96g$1@aioe.org>
Elena escreveu:
> On 25 Mar, 00:02, Cesar Rabak <·······@yahoo.com.br> wrote:
>> Elena escreveu:
>> [snipped]
>>
>>> However, your answer and previous answers by advanced lispers show
>>> exactly what I intended when I said that CLers are set in their ways:
>>> you people can't see things through the eyes of a novice anymore.
>> Well, no matter how true you might feel this assertion yours, it still
>> begs the question: so what?
>>
>> How back should we go in order to 'things through the eyes of a novice'
>> and settle with the crowd?
>
> Thank you for your understanding and willingness to talk about it.
>
> I wouldn't really ask you experts to go back and settle with the
> crowd. Instead I'd ask you to take the lead and go ahead: your
> experience and far-reaching sight allows you to recognize which things
> could be simplified, which ones could be re-engineered, and which ones
> are here to stay. As a senior C++ programmer I can easily do that, and
> I'm doing it when dealing with junior programmers. I have lifted a lot
> of weights and I can recognize which weights were useful tools and
> which are, well, just weights.
>
The problem in this industry is: what is perceived by some as an
absolute must have tool is seen by another group as (heavy) weights.
Heated debates happen due those different views!
Elena <········@gmail.com> writes:
> However, your answer and previous answers by advanced lispers show
> exactly what I intended when I said that CLers are set in their ways:
> you people can't see things through the eyes of a novice anymore.
The opposite is also true; you cannot see things through the eyes of
the experienced. There are many new-comers with the same initial
reactions you have, we see them in the group frequently. We also see
what happens to them over time. A part of them is not interested in
learning the language. The approach "please change your language so
that I become motivated in learning it" generally works as well as
when an immigrant to a country says "please change the laws so that I
can accept following them". These people tend to go away
eventually. The rest of them learn the language. With gaining
experience, they realize that the superficial hurdles they saw as
novices are not, and they become like the people you are now
criticizing. Not people without criticism or ideas for improvement,
but people with _interesting_ ideas about the language. Even the
Clojure guy most certainly knew both Java and Lisp very well before he
set out to improve on them.
Bj�rn Lindberg
On Mar 25, 11:10 am, ·····@runa.se (Björn Lindberg) wrote:
> Elena <········@gmail.com> writes:
> > However, your answer and previous answers by advanced lispers show
> > exactly what I intended when I said that CLers are set in their ways:
> > you people can't see things through the eyes of a novice anymore.
>
> The opposite is also true; you cannot see things through the eyes of
> the experienced.
That's why I'm asking to experienced users in the first instance.
> There are many new-comers with the same initial
> reactions you have, we see them in the group frequently. We also see
> what happens to them over time. A part of them is not interested in
> learning the language. The approach "please change your language so
> that I become motivated in learning it" generally works as well as
> when an immigrant to a country says "please change the laws so that I
> can accept following them". These people tend to go away
> eventually. The rest of them learn the language. With gaining
> experience, they realize that the superficial hurdles they saw as
> novices are not, and they become like the people you are now
> criticizing. Not people without criticism or ideas for improvement,
> but people with _interesting_ ideas about the language. Even the
> Clojure guy most certainly knew both Java and Lisp very well before he
> set out to improve on them.
I agree. But then maybe you too fail to realize that some newcomers
are not newcomers to programming in general, maybe they know a bunch
of other languages already, therefore I'd think twice before
dismissing their observations.
On Mar 25, 2:19 pm, Elena <········@gmail.com> wrote:
> On Mar 25, 11:10 am, ·····@runa.se (Björn Lindberg) wrote:
>
> > Elena <········@gmail.com> writes:
> > > However, your answer and previous answers by advanced lispers show
> > > exactly what I intended when I said that CLers are set in their ways:
> > > you people can't see things through the eyes of a novice anymore.
>
> > The opposite is also true; you cannot see things through the eyes of
> > the experienced.
>
> That's why I'm asking to experienced users in the first instance.
>
> > There are many new-comers with the same initial
> > reactions you have, we see them in the group frequently. We also see
> > what happens to them over time. A part of them is not interested in
> > learning the language. The approach "please change your language so
> > that I become motivated in learning it" generally works as well as
> > when an immigrant to a country says "please change the laws so that I
> > can accept following them". These people tend to go away
> > eventually. The rest of them learn the language. With gaining
> > experience, they realize that the superficial hurdles they saw as
> > novices are not, and they become like the people you are now
> > criticizing. Not people without criticism or ideas for improvement,
> > but people with _interesting_ ideas about the language. Even the
> > Clojure guy most certainly knew both Java and Lisp very well before he
> > set out to improve on them.
>
> I agree. But then maybe you too fail to realize that some newcomers
> are not newcomers to programming in general, maybe they know a bunch
> of other languages already, therefore I'd think twice before
> dismissing their observations.
Yep. But you are dismissing the fact that most CLers old-timers
*know* the other languages (C/C++, Java, some of us Fortran, all of us
- obviously - COBOL, ML and some of the functional languages, the
various SLDJs, plus Intercal)
Cheers
--
Marco
Elena <········@gmail.com> writes:
> On Mar 25, 11:10�am, ·····@runa.se (Bj�rn Lindberg) wrote:
>> Elena <········@gmail.com> writes:
>> > However, your answer and previous answers by advanced lispers show
>> > exactly what I intended when I said that CLers are set in their ways:
>> > you people can't see things through the eyes of a novice anymore.
>>
>> The opposite is also true; you cannot see things through the eyes of
>> the experienced.
>
> That's why I'm asking to experienced users in the first instance.
But you are dismissing their answers when these are not to your
liking.
>> There are many new-comers with the same initial
>> reactions you have, we see them in the group frequently. We also see
>> what happens to them over time. A part of them is not interested in
>> learning the language. The approach "please change your language so
>> that I become motivated in learning it" generally works as well as
>> when an immigrant to a country says "please change the laws so that I
>> can accept following them". These people tend to go away
>> eventually. The rest of them learn the language. With gaining
>> experience, they realize that the superficial hurdles they saw as
>> novices are not, and they become like the people you are now
>> criticizing. Not people without criticism or ideas for improvement,
>> but people with _interesting_ ideas about the language. Even the
>> Clojure guy most certainly knew both Java and Lisp very well before he
>> set out to improve on them.
>
> I agree. But then maybe you too fail to realize that some newcomers
> are not newcomers to programming in general, maybe they know a bunch
> of other languages already, therefore I'd think twice before
> dismissing their observations.
What you may not realize is that virtually all of the CL veterans
writing here are also experts in other languages, such as C, C++,
Java, etc. It is not like everyone only knows Lisp. Especially
considering that it is Common Lisp under discussion here, you might
want to take your own advice.
I do not want to dissuade you, merely suggest that your views of
Common Lisp and c.l.l. may be distorted by your unfamiliarity with
them. If you want to change the Lisp world, by all means go ahead. You
seem to have a nice action group going with yourself, Javier and
someone else. Maybe if you produce something great, you will convince
the disbelievers.
Bj�rn Lindberg
On Mar 25, 2:40 pm, ·····@runa.se (Björn Lindberg) wrote:
> Elena <········@gmail.com> writes:
> > On Mar 25, 11:10 am, ·····@runa.se (Björn Lindberg) wrote:
> >> Elena <········@gmail.com> writes:
> >> > However, your answer and previous answers by advanced lispers show
> >> > exactly what I intended when I said that CLers are set in their ways:
> >> > you people can't see things through the eyes of a novice anymore.
>
> >> The opposite is also true; you cannot see things through the eyes of
> >> the experienced.
>
> > That's why I'm asking to experienced users in the first instance.
>
> But you are dismissing their answers when these are not to your
> liking.
>
>
>
> >> There are many new-comers with the same initial
> >> reactions you have, we see them in the group frequently. We also see
> >> what happens to them over time. A part of them is not interested in
> >> learning the language. The approach "please change your language so
> >> that I become motivated in learning it" generally works as well as
> >> when an immigrant to a country says "please change the laws so that I
> >> can accept following them". These people tend to go away
> >> eventually. The rest of them learn the language. With gaining
> >> experience, they realize that the superficial hurdles they saw as
> >> novices are not, and they become like the people you are now
> >> criticizing. Not people without criticism or ideas for improvement,
> >> but people with _interesting_ ideas about the language. Even the
> >> Clojure guy most certainly knew both Java and Lisp very well before he
> >> set out to improve on them.
>
> > I agree. But then maybe you too fail to realize that some newcomers
> > are not newcomers to programming in general, maybe they know a bunch
> > of other languages already, therefore I'd think twice before
> > dismissing their observations.
>
> What you may not realize is that virtually all of the CL veterans
> writing here are also experts in other languages, such as C, C++,
> Java, etc. It is not like everyone only knows Lisp. Especially
> considering that it is Common Lisp under discussion here, you might
> want to take your own advice.
>
> I do not want to dissuade you, merely suggest that your views of
> Common Lisp and c.l.l. may be distorted by your unfamiliarity with
> them. If you want to change the Lisp world, by all means go ahead. You
> seem to have a nice action group going with yourself, Javier and
> someone else. Maybe if you produce something great, you will convince
> the disbelievers.
>
> Björn Lindberg
Great advice, Björn! Thank you.
I had realized that already. Many posts ago, I stated "Talk is cheap,
let's show them the code!". OTOH, I was still eager to listen to more
opinions.
Perhaps it's time to close the loop and start getting things done.
On Mar 23, 9:01 pm, "Jeff M." <·······@gmail.com> wrote:
> One thing I'd note: the community is doing this in a way. They are
> moving away from "Common" lisp. Clojure, Arc, Qi, and other Lisp-like
> implementations are becoming far more popular [than CL] very quickly.
> And the reasons provided are why.
There are many new and promising lisp dialects, but they don't stay
new nor promising long.
bobi
On Mar 24, 11:57 pm, gugamilare <··········@gmail.com> wrote:
> On 24 mar, 18:24, main <·············@gmail.com> wrote:
>
>
>
> > Maybe this is just stating the obvious, but:
>
> > Fucking standardize WITH-GENSYMS. And SPLIT-SEQUENCE, too. I'd also
> > like to see FLATTEN and COLLECTING / COLLECT as well, and COMPOSE and
> > CURRY would be nice. Maybe ONCE-ONLY? There's probably a few more
> > operators that could use a bit of standardization, but those ones come
> > to mind first. I realize some (all?) of these are de facto standards
> > already (especially SPLIT-SEQUENCE), but that's not always good
> > enough. For example, CLISP has a WITH-GENSYMS visible in cl-user that
> > has a slightly different syntax to what I'm used to.
>
> > Also, the whole pathnames thing needs to be redone from scratch. And a
> > standard way to run external programs would be nice. And of course a
> > standard FFI (CFFI?), GUI (no idea), threading (no idea), as well as a
> > standard way to install and use libraries (ASDF? Mudballs?). A
> > standard way to interact with an editor could be useful as well (SLIME
> > (SWANK really)).
>
> > Main
>
> I would standardize CFFI,
CFFI is <quote> standard <unquote>
> ASDF,
ASDF is <quote> standard <unquote>
> bordeaux-threads,
bordeaux-threads are standard inasmuch as the underlying
implementation supports threading.
> split-sequence,
split-sequence is <quote> standard <unquote>
> alexandria (it has all the utilities you mentioned, except collecting
> macro and a few more)
alexandria is good ...
> and anaphora.
For that I vote "I don't care!" I personally find anaphoric macros
pointless and I am annoyed by libraies that impose them on you.
> I'd go even further and
> standardize iterate (with iterate, you don't really need the
> collecting macro)
LOOP is standard. Iterate is mostly useless, even if it should have
been in the CLHS instead of LOOP (Ok: this is a flame bait! :) )
> and cl-ppcre.
cl-ppcre is <quote> standard <unquote>
> Swank can also be packed together
> since 99% of CLers use Slime.
I am in the 1%. You are not taking seriously the underlying problem,
which is to expose a real standardized networking API.
> I would also standardize let with the features being discussed,
Useful. Write a CDR and have it really really taken it apart. What
if I propose my different version of ExtLET? (Which, by definition is
better that any proposal I have seen so far :) )
> and
> defmacro to allow easy hygienic macros
That is a big no; everything you can do with hygienic macros you can
do with regular macros. Plus, we should really standardize CL-
UNIFICATION instead :)
(like closure's - seehttp://groups.google.com/group/comp.lang.lisp/browse_thread/thread/c8...).
> About GUI, I wouldn't pack any GUI, it is up to the user to choose
> one. For instance, I like Qt's visual. Many like McCLIM's flexibility.
> Others use Cells-gtk. Standardizing one of them would make them
> preferable to others, and competition / evolution would be lost.
There is no competition. TRT woyld be OpenCAPI, possibly with better
underlying system integration, but I do not know if the LW folks would
agree on it.
Cheers
--
Marco
On 25 mar, 06:39, Marco Antoniotti <·······@gmail.com> wrote:
> On Mar 24, 11:57 pm, gugamilare <··········@gmail.com> wrote:
> > I'd go even further and
> > standardize iterate (with iterate, you don't really need the
> > collecting macro)
>
> LOOP is standard. Iterate is mostly useless, even if it should have
> been in the CLHS instead of LOOP (Ok: this is a flame bait! :) )
No, no, LOOP sucks. LOOP is not lisp, it's a strange language that
invaded lisp. You can't do, for instance:
(loop for elt in list
(case elt
((:foo :bar) (do-something-with elt)
(nil nil)
(t (collect elt))))
This completely sucks. The functionality inside LOOP is eternally
trapped inside LOOP and you will never be able take it out and use it
anywhere else! (Ok, Yes, I caught your flame bait! :)
>
> > and cl-ppcre.
>
> cl-ppcre is <quote> standard <unquote>
>
> > Swank can also be packed together
> > since 99% of CLers use Slime.
>
> I am in the 1%. You are not taking seriously the underlying problem,
> which is to expose a real standardized networking API.
weblocks, maybe? The problem is weblocks have a lot of dependencies,
many of them you will never need for other applications. It seems a
waste for people who want, say, create desktop applications.
>
> > I would also standardize let with the features being discussed,
>
> Useful. Write a CDR and have it really really taken it apart. What
> if I propose my different version of ExtLET? (Which, by definition is
> better that any proposal I have seen so far :) )
It is difficult to agree with you without seeing it.
>
> > and
> > defmacro to allow easy hygienic macros
>
> That is a big no; everything you can do with hygienic macros you can
> do with regular macros. Plus, we should really standardize CL-
> UNIFICATION instead :)
When I said hygienic macros, I didn't mean exclusively hygienic
macros. Have you seen Clojure's macros? You do
(let ((a# b))
..)
and a# becomes a gensym. I thought something more like this. See the
discussion I linked in my text.
cl-unification is, IMO, very specific.
>
> (like closure's - seehttp://groups.google.com/group/comp.lang.lisp/browse_thread/thread/c8...).
>
> > About GUI, I wouldn't pack any GUI, it is up to the user to choose
> > one. For instance, I like Qt's visual. Many like McCLIM's flexibility.
> > Others use Cells-gtk. Standardizing one of them would make them
> > preferable to others, and competition / evolution would be lost.
>
> There is no competition. TRT woyld be OpenCAPI, possibly with better
> underlying system integration, but I do not know if the LW folks would
> agree on it.
>
> Cheers
> --
> Marco
On 25 mar, 10:50, Raffael Cavallaro <················@gmail.com>
wrote:
> On Mar 25, 9:12 am, gugamilare <··········@gmail.com> wrote:
>
> > No, no, LOOP sucks. LOOP is not lisp
>
> ANSI begs to differ.
Many things in ANSI where put there just for compatibility with even
older Lisps, which aren't around anymore. Loop was a well known macro
way before ANSI CL. It was created to make it easier for newbies to
construct loops. It is a hell of a macro, I know, and it also is very
powerful, but it still has limitations which I don't like. And I
believe that iterate is the best substitute for it.
Ok, most people still want it to be around, I don't care if it stays
there. But I won't use it whenever I can use another loop constructor.
On Mar 25, 10:53 am, gugamilare <··········@gmail.com> wrote:
> But I won't use it whenever I can use another loop constructor.
But you'll still need to understand loop in other people's code.
I'm not too fond of format, but I need to know it because other people
use it.
In general, once something is part of a standard (and not deprecated)
you need to know it or you can't read other people's code. This is why
iterate is a non-starter; you can't make other people use it, and it
doesn't save you from needing to understand loop in order to read
other people's code.
Far better then to put in the time to learn loop and format 'cause
you'll need to know them anyway, even if you only ever use do and
concatenate 'string.
On Wed, 25 Mar 2009 08:07:11 -0700, Raffael Cavallaro wrote:
> On Mar 25, 10:53 am, gugamilare <··········@gmail.com> wrote:
>
>> But I won't use it whenever I can use another loop constructor.
>
> But you'll still need to understand loop in other people's code.
>
> I'm not too fond of format, but I need to know it because other people
> use it.
>
> In general, once something is part of a standard (and not deprecated)
> you need to know it or you can't read other people's code. This is why
> iterate is a non-starter; you can't make other people use it, and it
> doesn't save you from needing to understand loop in order to read other
> people's code.
Strange as it may seem, some people are so smart that they know _both_
iterate and loop! So learning the former doesn't exclude learning the
latter, or vice versa.
This whole "what's in the standard" issue is overrated. There are
things in the standard which (most) people are using quite
infrequently so they would need to look them up, and looking up the
documentation of something in a library is not that different.
Relying on libraries does not make your code unreadable to a third
party, especially if the library provides useful abstractions.
I find it weird that people who use* the world's most extensible
programming language have these idiotic discussions on the library
parts of the standard. I suppose that these are the same people who
call the factory to complain when their 21-speed road bike arrived
with the chain positioned on cogs 2-7 -- the rest just learn how to
shift gears and start biking.
Tamas
*Of course, it frequently turns out that the people who initiate these
discussions do not actually program in Lisp. So why are they taken
seriously? This is a great mystery.
On Mar 25, 11:38 am, Tamas K Papp <······@gmail.com> wrote:
> Relying on libraries does not make your code unreadable to a third
> party, especially if the library provides useful abstractions.
In the reductio ad absurdum nothing is "unreadable" as long as you're
willing to read the documentation and/or source code of the libraries
that are used.
Using non-standard libraries that provide functionality already
largely present in the standard (e.g., iterate v. loop) simply erects
another barrier to the understanding of your code by others.
I think a better case can be made for using libraries that provide
functionality not present in the standard than for a library like
iterate.
Obviously reasonable people differ on this, else no one would use
iterate.
gugamilare <··········@gmail.com> writes:
> On 25 mar, 10:50, Raffael Cavallaro <················@gmail.com>
> wrote:
>> On Mar 25, 9:12�am, gugamilare <··········@gmail.com> wrote:
>>
>> > No, no, LOOP sucks. LOOP is not lisp
>>
>> ANSI begs to differ.
>
> Many things in ANSI where put there just for compatibility with even
> older Lisps, which aren't around anymore. Loop was a well known macro
> way before ANSI CL. It was created to make it easier for newbies to
> construct loops. It is a hell of a macro, I know, and it also is very
> powerful, but it still has limitations which I don't like. And I
> believe that iterate is the best substitute for it.
>
> Ok, most people still want it to be around, I don't care if it stays
> there. But I won't use it whenever I can use another loop constructor.
(loop (when <condition> (return))
<body>)
(loop :while <condition> :do
<body>)
(do () ((not <condition>))
<body>)
(tagbody :loop
(when <condition> (go :end))
<body>
(go :loop)
:end)
(defmacro while (condition &body body) ....)
(while <condition>
<body>)
--
__Pascal Bourguignon__
On Mar 25, 2:12 pm, gugamilare <··········@gmail.com> wrote:
> On 25 mar, 06:39, Marco Antoniotti <·······@gmail.com> wrote:
>
> > On Mar 24, 11:57 pm, gugamilare <··········@gmail.com> wrote:
> > > I'd go even further and
> > > standardize iterate (with iterate, you don't really need the
> > > collecting macro)
>
> > LOOP is standard. Iterate is mostly useless, even if it should have
> > been in the CLHS instead of LOOP (Ok: this is a flame bait! :) )
>
> No, no, LOOP sucks. LOOP is not lisp, it's a strange language that
> invaded lisp. You can't do, for instance:
>
> (loop for elt in list
> (case elt
> ((:foo :bar) (do-something-with elt)
> (nil nil)
> (t (collect elt))))
>
> This completely sucks. The functionality inside LOOP is eternally
> trapped inside LOOP and you will never be able take it out and use it
> anywhere else! (Ok, Yes, I caught your flame bait! :)
(loop with result = ()
for e in list
do (case e
((:foo :bar) (do-something-with e))
(nil nil)
(t (push e result)))
finally (return result))
It sucks a bit, but it ain't that bad either. Plus it is relatively
readable.
>
> > > and cl-ppcre.
>
> > cl-ppcre is <quote> standard <unquote>
>
> > > Swank can also be packed together
> > > since 99% of CLers use Slime.
>
> > I am in the 1%. You are not taking seriously the underlying problem,
> > which is to expose a real standardized networking API.
>
> weblocks, maybe? The problem is weblocks have a lot of dependencies,
> many of them you will never need for other applications. It seems a
> waste for people who want, say, create desktop applications.
In general I hate pointless dependencies. That is why I look with
favor at ways to improve the standard and enlarging it.
In any case the point I was making is that a better, common networking
API would be more than welcome.
>
> > > I would also standardize let with the features being discussed,
>
> > Useful. Write a CDR and have it really really taken it apart. What
> > if I propose my different version of ExtLET? (Which, by definition is
> > better that any proposal I have seen so far :) )
>
> It is difficult to agree with you without seeing it.
>
Google CLL for LETBIND and see when I proposed one before. The
problem is that until you (or me) hashes out the details (and there
are always details where the devil hides), by actually writing a spec,
we are just chatting on CLL. And no, I do not think that just
providing an implementation is suffcient either.
> > > and
> > > defmacro to allow easy hygienic macros
>
> > That is a big no; everything you can do with hygienic macros you can
> > do with regular macros. Plus, we should really standardize CL-
> > UNIFICATION instead :)
>
> When I said hygienic macros, I didn't mean exclusively hygienic
> macros. Have you seen Clojure's macros? You do
> (let ((a# b))
> ..)
>
> and a# becomes a gensym. I thought something more like this. See the
> discussion I linked in my text.
Write a CDR for it within the scope of CL. The above (Clojure) is
not a clearcut advantage over WITH-UNIQUE-NAMES vel similia.
Hygienic macros a' la' scheme introduce needless extra complexity to
the standard. Besides, there are libraries floating around that
implement DEFINE-SYNTAX, SYNTAX-RULES etc etc.
>
> cl-unification is, IMO, very specific.
>
Yes. But I wrote it and it is a very cute thing. :) Plus its MATCH*
macros do what the extended LET/DESTRUCTURING-BIND do, and then
more :)
Cheers
--
Marco
On 25 mar, 12:15, Marco Antoniotti <·······@gmail.com> wrote:
> Google CLL for LETBIND and see when I proposed one before. The
> problem is that until you (or me) hashes out the details (and there
> are always details where the devil hides), by actually writing a spec,
> we are just chatting on CLL. And no, I do not think that just
> providing an implementation is suffcient either.
>
Hum, I found it. It was a little tricky to find it. Anyway, the main
advantage of your macro over mine is that it supports declarations in
the same place the variable is. It is a good thing, indeed.
There are some issues with it, though. It would be tricky not to make
this case a bug:
(letbind ((a :values (keyword a)))
...)
Maybe something like
(let (((:values a b c) (foo x) (fixnum a b c)))
...)
would be the best, IMO. metabang-bind's style. It would make the
previous version unambiguous, you either write:
(let ((a :values (keyword a)))
...)
or
(let (((:values a) (keyword a)))
...)
in either case, the macro expansion will know what to do. Thank you
for the ideas, though.
> Write a CDR for it within the scope of CL. The above (Clojure) is
> not a clearcut advantage over WITH-UNIQUE-NAMES vel similia.
Well, I think it is space saving and very convenient to use. I follow
the rule: if my code is at least as readable as yours, if mine is
smaller and not slower, mine is better.
> Hygienic macros a' la' scheme introduce needless extra complexity to
> the standard. Besides, there are libraries floating around that
> implement DEFINE-SYNTAX, SYNTAX-RULES etc etc.
>
>
>
> > cl-unification is, IMO, very specific.
>
> Yes. But I wrote it and it is a very cute thing.
Hum, that explains... :)
> :) Plus its MATCH*
> macros do what the extended LET/DESTRUCTURING-BIND do, and then
> more :)
>
> Cheers
> --
> Marco
On Mar 25, 5:34 pm, gugamilare <··········@gmail.com> wrote:
> On 25 mar, 12:15, Marco Antoniotti <·······@gmail.com> wrote:> Google CLL for LETBIND and see when I proposed one before. The
> > problem is that until you (or me) hashes out the details (and there
> > are always details where the devil hides), by actually writing a spec,
> > we are just chatting on CLL. And no, I do not think that just
> > providing an implementation is suffcient either.
>
> Hum, I found it. It was a little tricky to find it. Anyway, the main
> advantage of your macro over mine is that it supports declarations in
> the same place the variable is. It is a good thing, indeed.
Good. Did you check the date?
> There are some issues with it, though. It would be tricky not to make
> this case a bug:
>
> (letbind ((a :values (keyword a)))
> ...)
>
> Maybe something like
>
> (let (((:values a b c) (foo x) (fixnum a b c)))
> ...)
>
> would be the best, IMO. metabang-bind's style. It would make the
> previous version unambiguous, you either write:
>
> (let ((a :values (keyword a)))
> ...)
>
> or
>
> (let (((:values a) (keyword a)))
> ...)
>
> in either case, the macro expansion will know what to do. Thank you
> for the ideas, though.
You are welcome. But note that it has not been picked up and I
neither use it in my code nor try to impose it on other people by
making my code dependent on it.
It is an iteresting exercise, but you already see how difficult it is
to nail it down. As I said, wrtite a CDR.
> > Write a CDR for it within the scope of CL. The above (Clojure) is
> > not a clearcut advantage over WITH-UNIQUE-NAMES vel similia.
>
> Well, I think it is space saving and very convenient to use. I follow
> the rule: if my code is at least as readable as yours, if mine is
> smaller and not slower, mine is better.
Beauty is in the eye of the beholder. The question is wheter you can
write a CDR that takes into account *all* the corner cases and
introduce something like Clojure stuff within the scope of CL.
Personally, I do not think it buys you much, at the cost of making the
code look perlish (which, then again, may be an advantage, by
augmenting our self esteem).
> > Hygienic macros a' la' scheme introduce needless extra complexity to
> > the standard. Besides, there are libraries floating around that
> > implement DEFINE-SYNTAX, SYNTAX-RULES etc etc.
>
> > > cl-unification is, IMO, very specific.
>
> > Yes. But I wrote it and it is a very cute thing.
>
> Hum, that explains... :)
Yep. Why don't you jump onboard to improve it?
Cheers
--
Marco
>
> > :) Plus its MATCH*
> > macros do what the extended LET/DESTRUCTURING-BIND do, and then
> > more :)
>
> > Cheers
> > --
> > Marco
P� Wed, 25 Mar 2009 14:12:50 +0100, skrev gugamilare
<··········@gmail.com>:
>
> No, no, LOOP sucks. LOOP is not lisp, it's a strange language that
> invaded lisp. You can't do, for instance:
>
> (loop for elt in list
> (case elt
> ((:foo :bar) (do-something-with elt)
> (nil nil)
> (t (collect elt))))
>
> This completely sucks. The functionality inside LOOP is eternally
> trapped inside LOOP and you will never be able take it out and use it
> anywhere else! (Ok, Yes, I caught your flame bait! :)
>
I thought the ability to make sub-languages inside Lisp was one of it's
strengths. Would you want a alternate syntax for SQL for example?
--------------
John Thingstad
On 25 mar, 10:54, "John Thingstad" <·······@online.no> wrote:
> På Wed, 25 Mar 2009 14:12:50 +0100, skrev gugamilare
> <··········@gmail.com>:
>
>
>
> > No, no, LOOP sucks. LOOP is not lisp, it's a strange language that
> > invaded lisp. You can't do, for instance:
>
> > (loop for elt in list
> > (case elt
> > ((:foo :bar) (do-something-with elt)
> > (nil nil)
> > (t (collect elt))))
>
> > This completely sucks. The functionality inside LOOP is eternally
> > trapped inside LOOP and you will never be able take it out and use it
> > anywhere else! (Ok, Yes, I caught your flame bait! :)
>
> I thought the ability to make sub-languages inside Lisp was one of it's
> strengths. Would you want a alternate syntax for SQL for example?
>
> --------------
> John Thingstad
Good point, it is one of Lisp strengths. I don't think LOOP fells in
that case, it is a non-sexp program inside CL, for no reason at all.
It has its own "if", "when", "unless" syntax, among others, and this
makes the user lose control of it. And loop is something very basic
for every language, it can't look different than the rest of the
language.
gugamilare <··········@gmail.com> writes:
>> P� Wed, 25 Mar 2009 14:12:50 +0100, skrev gugamilare �
>> <··········@gmail.com>:
>> >
>> > No, no, LOOP sucks. LOOP is not lisp, it's a strange language that
>> > invaded lisp. You can't do, for instance:
>> >
>> > (loop for elt in list
>> > � � � (case elt
>> > � � � � ((:foo :bar) (do-something-with elt)
>> > � � � � (nil nil)
>> > � � � � (t (collect elt))))
Yes, you can do something like this. See below.
>> > This completely sucks. The functionality inside LOOP is eternally
>> > trapped inside LOOP and you will never be able take it out and use it
>> > anywhere else! (Ok, Yes, I caught your flame bait! :)
>
> Good point, it is one of Lisp strengths. I don't think LOOP fells in
> that case, it is a non-sexp program inside CL, for no reason at all.
> It has its own "if", "when", "unless" syntax, among others, and this
> makes the user lose control of it. And loop is something very basic
> for every language, it can't look different than the rest of the
> language.
Indeed, LOOP is very basic and already provides all you want:
(let ((list '(a :foo b :bar c))
(collect '()))
(loop
(unless list (return collect))
(let ((elt (pop list)))
(case elt
((:foo :bar) (do-something-with elt))
(t (push elt collect))))))
prints:
(DONE SOMETHING WITH :FOO)
(DONE SOMETHING WITH :BAR)
--> (C B A)
--
__Pascal Bourguignon__
On 25 mar, 12:19, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> gugamilare <··········@gmail.com> writes:
>
> Indeed, LOOP is very basic and already provides all you want:
>
> (let ((list '(a :foo b :bar c))
> (collect '()))
> (loop
> (unless list (return collect))
> (let ((elt (pop list)))
> (case elt
> ((:foo :bar) (do-something-with elt))
> (t (push elt collect))))))
>
> prints:
> (DONE SOMETHING WITH :FOO)
> (DONE SOMETHING WITH :BAR)
>
> --> (C B A)
>
> --
> __Pascal Bourguignon__
I shouldn't need to answer this.
If I am using collect, there is a reason - I want to preserve order.
And, if I have to explicitly create the entire body of the loop inside
loop macro, why should I bother to use it?
No, thanks, I still prefer to use a macro (iterate) that does the
dirty job for me. That's why macros were first invented, isn't it?
On Wed, 25 Mar 2009 09:09:46 -0700, gugamilare wrote:
> On 25 mar, 12:19, ····@informatimago.com (Pascal J. Bourguignon) wrote:
>> gugamilare <··········@gmail.com> writes:
>>
>> Indeed, LOOP is very basic and already provides all you want:
>>
>> (let ((list '(a :foo b :bar c))
>> (collect '()))
>> (loop
>> (unless list (return collect))
>> (let ((elt (pop list)))
>> (case elt
>> ((:foo :bar) (do-something-with elt)) (t (push elt
>> collect))))))
>>
>> prints:
>> (DONE SOMETHING WITH :FOO)
>> (DONE SOMETHING WITH :BAR)
>>
>> --> (C B A)
>>
>> --
>> __Pascal Bourguignon__
>
> I shouldn't need to answer this.
>
> If I am using collect, there is a reason - I want to preserve order.
> And, if I have to explicitly create the entire body of the loop inside
> loop macro, why should I bother to use it?
>
> No, thanks, I still prefer to use a macro (iterate) that does the dirty
> job for me. That's why macros were first invented, isn't it?
Sorry, what was your problem again? You don't like loop, nobody is
forcing you to use it, and you have iterate, which works for you.
What was the point of this whole discussion?
Tamas
"John Thingstad" <·······@online.no> writes:
> P� Wed, 25 Mar 2009 14:12:50 +0100, skrev gugamilare
> <··········@gmail.com>:
>
>>
>> No, no, LOOP sucks. LOOP is not lisp, it's a strange language that
>> invaded lisp. You can't do, for instance:
>>
>> (loop for elt in list
>> (case elt
>> ((:foo :bar) (do-something-with elt)
>> (nil nil)
>> (t (collect elt))))
>>
>> This completely sucks. The functionality inside LOOP is eternally
>> trapped inside LOOP and you will never be able take it out and use it
>> anywhere else! (Ok, Yes, I caught your flame bait! :)
>>
>
> I thought the ability to make sub-languages inside Lisp was one of
> it's strengths.
It is. The reproach here is that LOOP is not extensible, like SETF is.
With SETF, you can define your own kinds of places to be set, with
DEFSETF or DEFINE-SETF-EXPANDER.
Unfortunately, the LOOP that has been standardized doesn't have such
provision, you cannot define your own kind of container to be iterated
over, or your own kind of termination condition, or your own kind of
item collection.
Instead, people had to invent their own ITERATE library or other.
For my part, I'm rather happy that CL is not perfect, that LOOP can't
be extended this way. This forces us to experiment with new designs
and new variants, and to prepare something to be standardized in the
next round. This shows that CL didn't kill lisp.
--
__Pascal Bourguignon__
On Mar 25, 3:37 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> "John Thingstad" <·······@online.no> writes:
> > På Wed, 25 Mar 2009 14:12:50 +0100, skrev gugamilare
> > <··········@gmail.com>:
>
> >> No, no, LOOP sucks. LOOP is not lisp, it's a strange language that
> >> invaded lisp. You can't do, for instance:
>
> >> (loop for elt in list
> >> (case elt
> >> ((:foo :bar) (do-something-with elt)
> >> (nil nil)
> >> (t (collect elt))))
>
> >> This completely sucks. The functionality inside LOOP is eternally
> >> trapped inside LOOP and you will never be able take it out and use it
> >> anywhere else! (Ok, Yes, I caught your flame bait! :)
>
> > I thought the ability to make sub-languages inside Lisp was one of
> > it's strengths.
>
> It is. The reproach here is that LOOP is not extensible, like SETF is.
> With SETF, you can define your own kinds of places to be set, with
> DEFSETF or DEFINE-SETF-EXPANDER.
Yep. That is why a really useful improvement to ANSI would be to
bring in th epossibility to extend LOOP. As we know it is possible,
albeit very cumbersome, by the existence proof of the very useful
syntax
(loop for troll being each tuple of [select [*] :from [trolls]]
collect troll into trolls
finally (make-trolls-learn-cl trolls))
Cheers
--
Marco
On 25 Mar, 15:59, Marco Antoniotti <·······@gmail.com> wrote:
> On Mar 25, 3:37 pm, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>
>
>
> > "John Thingstad" <·······@online.no> writes:
> > > På Wed, 25 Mar 2009 14:12:50 +0100, skrev gugamilare
> > > <··········@gmail.com>:
>
> > >> No, no, LOOP sucks. LOOP is not lisp, it's a strange language that
> > >> invaded lisp. You can't do, for instance:
>
> > >> (loop for elt in list
> > >> (case elt
> > >> ((:foo :bar) (do-something-with elt)
> > >> (nil nil)
> > >> (t (collect elt))))
>
> > >> This completely sucks. The functionality inside LOOP is eternally
> > >> trapped inside LOOP and you will never be able take it out and use it
> > >> anywhere else! (Ok, Yes, I caught your flame bait! :)
>
> > > I thought the ability to make sub-languages inside Lisp was one of
> > > it's strengths.
>
> > It is. The reproach here is that LOOP is not extensible, like SETF is.
> > With SETF, you can define your own kinds of places to be set, with
> > DEFSETF or DEFINE-SETF-EXPANDER.
>
> Yep. That is why a really useful improvement to ANSI would be to
> bring in th epossibility to extend LOOP. As we know it is possible,
> albeit very cumbersome, by the existence proof of the very useful
> syntax
>
> (loop for troll being each tuple of [select [*] :from [trolls]]
> collect troll into trolls
> finally (make-trolls-learn-cl trolls))
>
> Cheers
> --
> Marco
Hmmm... have you ever tried to run it? Maybe it works ;-)
Elena <········@gmail.com> writes:
> On 25 Mar, 15:59, Marco Antoniotti <·······@gmail.com> wrote:
> >
> > Yep. ��That is why a really useful improvement to ANSI would be to
> > bring in th epossibility to extend LOOP. ��As we know it is possible,
> > albeit very cumbersome, by the existence proof of the very useful
> > syntax
> >
> > (loop for troll being each tuple of [select [*] :from [trolls]]
> > �� �� �� collect troll into trolls
> > �� �� �� finally (make-trolls-learn-cl trolls))
> >
> > Cheers
> > --
> > Marco
>
> Hmmm... have you ever tried to run it? Maybe it works ;-)
Not really.
When I've tried this, it sometimes throws an exception somewhere in the in
the finally clause. More commonly it just goes into an infinite (or at
least seemingly so) loop there.
More helpfully, I do recall the earlier LOOP implementations having the
ability to define additional iterators and even keywords to go with
them. The actual interface was a bit more complicated than what has
been distilled in Java and similar languages, so perhaps taking a look
at some of that development would be a good idea.
I do recall writing some code with things along the lines of
(loop for concept being x and its subconcepts
do ....)
and having it iterate over our KR hierarchy.
Going to the original MIT Loop Macro source from 1980-81, I find the
following items.
See http://stuff.mit.edu/afs/sipb/user/andre/lisp/clloop.lisp
(defmacro define-loop-path (names &rest cruft)
"(DEFINE-LOOP-PATH NAMES PATH-FUNCTION LIST-OF-ALLOWABLE-PREPOSITIONS
DATUM-1 DATUM-2 ...)
Defines PATH-FUNCTION to be the handler for the path(s) NAMES, which may
be either a symbol or a list of symbols. LIST-OF-ALLOWABLE-PREPOSITIONS
contains a list of prepositions allowed in NAMES. DATUM-i are optional;
they are passed on to PATH-FUNCTION as a list."
(defmacro define-loop-sequence-path (path-name-or-names fetchfun sizefun
&optional sequence-type element-type)
"Defines a sequence iiteration path. PATH-NAME-OR-NAMES is either an
atomic path name or a list of path names. FETCHFUN is a function of
two arguments, the sequence and the index of the item to be fetched.
/(Indexing is assumed to be zero-origined. SIZEFUN is a function of
one argument, the sequence; it should return the number of elements in
the sequence. SEQUENCE-TYPE is the name of the data-type of the
sequence, and ELEMENT-TYPE is the name of the data-type of the elements
of the sequence."
One use of this was:
(define-loop-path hash-elements loop-hash-elements-path (of with-key))
--
Thomas A. Russ, USC/Information Sciences Institute
On Mar 26, 1:48 am, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> Elena <········@gmail.com> writes:
> > On 25 Mar, 15:59, Marco Antoniotti <·······@gmail.com> wrote:
>
> > > Yep. That is why a really useful improvement to ANSI would be to
> > > bring in th epossibility to extend LOOP. As we know it is possible,
> > > albeit very cumbersome, by the existence proof of the very useful
> > > syntax
>
> > > (loop for troll being each tuple of [select [*] :from [trolls]]
> > > collect troll into trolls
> > > finally (make-trolls-learn-cl trolls))
>
> > > Cheers
> > > --
> > > Marco
>
> > Hmmm... have you ever tried to run it? Maybe it works ;-)
>
> Not really.
>
> When I've tried this, it sometimes throws an exception somewhere in the in
> the finally clause. More commonly it just goes into an infinite (or at
> least seemingly so) loop there.
>
> More helpfully, I do recall the earlier LOOP implementations having the
> ability to define additional iterators and even keywords to go with
> them. The actual interface was a bit more complicated than what has
> been distilled in Java and similar languages, so perhaps taking a look
> at some of that development would be a good idea.
>
> I do recall writing some code with things along the lines of
>
> (loop for concept being x and its subconcepts
> do ....)
>
> and having it iterate over our KR hierarchy.
I think this would have become
(loop for x being concept of *concepts* and its subconcepts using
(...) do ....)
>
> Going to the original MIT Loop Macro source from 1980-81, I find the
> following items.
> See http://stuff.mit.edu/afs/sipb/user/andre/lisp/clloop.lisp
>
> (defmacro define-loop-path (names &rest cruft)
> "(DEFINE-LOOP-PATH NAMES PATH-FUNCTION LIST-OF-ALLOWABLE-PREPOSITIONS
> DATUM-1 DATUM-2 ...)
>
> Defines PATH-FUNCTION to be the handler for the path(s) NAMES, which may
> be either a symbol or a list of symbols. LIST-OF-ALLOWABLE-PREPOSITIONS
> contains a list of prepositions allowed in NAMES. DATUM-i are optional;
> they are passed on to PATH-FUNCTION as a list."
>
> (defmacro define-loop-sequence-path (path-name-or-names fetchfun sizefun
> &optional sequence-type element-type)
> "Defines a sequence iiteration path. PATH-NAME-OR-NAMES is either an
> atomic path name or a list of path names. FETCHFUN is a function of
> two arguments, the sequence and the index of the item to be fetched.
> /(Indexing is assumed to be zero-origined. SIZEFUN is a function of
> one argument, the sequence; it should return the number of elements in
> the sequence. SEQUENCE-TYPE is the name of the data-type of the
> sequence, and ELEMENT-TYPE is the name of the data-type of the elements
> of the sequence."
>
> One use of this was:
>
> (define-loop-path hash-elements loop-hash-elements-path (of with-key))
Yes. This should be the general idea. Why it did not make it into
ANSI is a bad thing (you cannot extend loop; although you do cfr, CL-
SQL) or a good thing (you cannot extend loop and so you do not
introduce extra noise in the loop DSL).
Having said that, most of the problems that the LOOP extension
interface was trying to address are nowadays solved by the "iterator"
meme (no "pattern" please). That is what CL-ENUMERATION (shameless
plughttp://common-lisp.net/projects/cl-enumeration) does by emulating
Java enumeration protocol.
Now, it would be very goo if I cound write
(loop for x being each element of (enum:enumerate *something*)
do ...)
or
(loop for x over (enum:enumerate *something*) do ...)
But I cannot (portably). I have to do it the Java way
(loop with elems = (enum:enumerate *something*)
while (enum:has-more-elements-p elems)
do (let ((e (enum:next elems))) ...))
In contrast, writing an ITERATE driver for CL-ENUMERATION took just a
few lines of code.
Cheers
--
Marco
gugamilare <··········@gmail.com> wrote in news:f65c7fd8-0a7c-4536-a720-
············@o11g2000yql.googlegroups.com:
> (loop for elt in list
> (case elt
> ((:foo :bar) (do-something-with elt)
> (nil nil)
> (t (collect elt))))
(loop for elt in list
when (case elt
((:foo :bar) (do-something-with elt)
(nil nil)
(t t))
collect elt)
On Mar 24, 6:32 pm, Elena <········@gmail.com> wrote:
> Then let's have not a standard GUI, but a reference implementation
> mantained and evolved by the community. There is already Glade, a
> portable GUI builder which leverages Gtk+, and a CL library: CL-GLADE
> (needs te be updated).
No one is stopping you from performing this task. Perhaps you could
take a break from suggesting naming conventions and editor assistance
for standard CL functions and update CL-GLADE to meet the more
pressing needs of the community.
On Mar 22, 8:49 pm, Javier <·······@gmail.com> wrote:
[snipped]
> I think it is not that difficult, but people _must_ participate in order
> to be successful.
Ok we will participate, but as a sign of good will all of those who
want a new standard please should submit one common lisp library
first.
bobi
http://tourdelisp.blogspot.com/
On 25 mar, 13:59, Slobodan Blazeski <·················@gmail.com>
wrote:
> On Mar 22, 8:49 pm, Javier <·······@gmail.com> wrote:
> [snipped]
>
> > I think it is not that difficult, but people _must_ participate in order
> > to be successful.
>
> Ok we will participate, but as a sign of good will all of those who
> want a new standard please should submit one common lisp library
> first.
>
> bobihttp://tourdelisp.blogspot.com/
Is a small one enough?
http://wiki.github.com/gugamilare/storable-functions
The documentation is almost bigger than the library itself.
On Mar 25, 6:54 pm, gugamilare <··········@gmail.com> wrote:
> On 25 mar, 13:59, Slobodan Blazeski <·················@gmail.com>
> wrote:
>
> > On Mar 22, 8:49 pm, Javier <·······@gmail.com> wrote:
> > [snipped]
>
> > > I think it is not that difficult, but people _must_ participate in order
> > > to be successful.
>
> > Ok we will participate, but as a sign of good will all of those who
> > want a new standard please should submit one common lisp library
> > first.
>
> > bobihttp://tourdelisp.blogspot.com/
>
> Is a small one enough?
>
> http://wiki.github.com/gugamilare/storable-functions
>
> The documentation is almost bigger than the library itself.
Good now the rest of the folks.
bobi
On Wed, 25 Mar 2009 09:59:19 -0700, Slobodan Blazeski wrote:
> On Mar 22, 8:49 pm, Javier <·······@gmail.com> wrote: [snipped]
>> I think it is not that difficult, but people _must_ participate in
>> order to be successful.
>
> Ok we will participate, but as a sign of good will all of those who want
> a new standard please should submit one common lisp library first.
Or better yet, implement their suggestion as a library when possible,
so that other people can try it out. If the change is so radical that it
cannot be implemented as a library (which I doubt, but let's entertain
the idea), then these people should implement a basic version of their
new language in/on top of CL and make it available.
Talk is cheap, and whining about the standard in vague terms is
tiresome and pointless.
Tamas