Loop puzzle

[Helmut Eller]

I tried this code:

(let ((a '(x y)))
(loop for a in '((a b) (0 1))
for b in a
collect (list a b)))

and expected that it evaluates to '(((a b) a) ((0 1) b)) but all the
implementations I tried return nil.

Can somebody give a pointer to the place in the spec that explains why
this should/could return nil?

Helmut

[RG]

In article <m2sji6z...@gmail.com>,

LOOP binds the variables in the FOR clauses in parallel before doing
anything else. It then evaluates all the IN clauses, again in parallel.
At that point, A is NIL. So B is looping over NIL.

Try something like this:

(let ((l '((a b) (0 1))))
(loop for a in l
for b in (car l)
collect (list a b)))

rg

[Raymond Wiker]

I think this happens because the two "for" clauses are executed in
parallel, and the initial value for "a" seen by the second clause is
nil.

If you replace the second for with "and", "b" will loop over the outer
binding of "a" instead[1], which is not right, either. I *think* you'll
have to use nested loops.

Footnotes:
[1] At least with my installations of Lispworks, SBCL and CCL.

[Pascal J. Bourguignon]

http://www.lispworks.com/documentation/HyperSpec/Body/06_aba.htm
http://www.lispworks.com/documentation/HyperSpec/Body/06_abb.htm
http://www.lispworks.com/documentation/HyperSpec/Body/06_aaf.htm

It returns NIL because A in the loop is initialized to NIL first. (It
could be initialized to something else). The :for b :in a makes
reference to that A, not the one in the outer scope.


(let ((xy '(x y)))

(loop for a in '((a b) (0 1))

for b in xy
collect (list a b)))
--> (((a b) x) ((0 1) y))



To get what you expected you must write it as:

(let ((a '(x y)))
(loop with as = '((a b) (0 1))
for a in as
for b in (car as)
collect (list a b)))
--> (((a b) a) ((0 1) b))


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

[Helmut Eller]

* RG [2012-02-19 17:51] writes:

> In article <m2sji6z...@gmail.com>,
> Helmut Eller <eller....@gmail.com> wrote:
>
>> I tried this code:
>>
>> (let ((a '(x y)))
>> (loop for a in '((a b) (0 1))
>> for b in a
>> collect (list a b)))
>>
>> and expected that it evaluates to '(((a b) a) ((0 1) b)) but all the
>> implementations I tried return nil.
>>
>> Can somebody give a pointer to the place in the spec that explains why
>> this should/could return nil?
>>
>> Helmut
>
> LOOP binds the variables in the FOR clauses in parallel before doing
> anything else. It then evaluates all the IN clauses, again in parallel.
> At that point, A is NIL. So B is looping over NIL.

Well, I can't find that passage in the spec. Where is it?

Helmut

[RG]

In article <m2mx8ez...@gmail.com>,

It's throughout chapter 6. Variable initialization is in 6.1.1.6

"All variables are initialized first, regardless of where the
establishing clauses appear in the source."

The termination condition behavior is permitted by 6.1.1.4

"Implementations can interleave the setting of initial values with the
bindings. However, the assignment of the initial values is always
calculated in the order specified by the user. A variable is thus
sometimes bound to a meaningless value of the correct type, and then
later in the prologue it is set to the true initial value by using setq.
One implication of this interleaving is that it is
implementation-dependent whether the lexical environment in which the
initial value forms (variously called the form1, form2, form3, step-fun,
vector, hash-table, and package) in any for-as-subclause, except
for-as-equals-then, are evaluated includes only the loop variables
preceding that form or includes more or all of the loop variables; the
form1 and form2 in a for-as-equals-then form includes the lexical
environment of all the loop variables."

rg

[Helmut Eller]

* Pascal J. Bourguignon [2012-02-19 17:58] writes:

> Helmut Eller <eller....@gmail.com> writes:
>
>> I tried this code:
>>
>> (let ((a '(x y)))
>> (loop for a in '((a b) (0 1))
>> for b in a
>> collect (list a b)))
>>
>> and expected that it evaluates to '(((a b) a) ((0 1) b)) but all the
>> implementations I tried return nil.
>>
>> Can somebody give a pointer to the place in the spec that explains why
>> this should/could return nil?
>
> http://www.lispworks.com/documentation/HyperSpec/Body/06_aba.htm

Here we can read that:

If multiple iteration clauses are used to control iteration, variable
initialization and stepping[1] occur sequentially by default. The and
construct can be used to connect two or more iteration clauses when
sequential binding and stepping[1] are not necessary. The iteration
behavior of clauses joined by and is analogous to the behavior of the
macro do with respect to do*.

which seems to confirm my expectation.

> http://www.lispworks.com/documentation/HyperSpec/Body/06_abb.htm
> http://www.lispworks.com/documentation/HyperSpec/Body/06_aaf.htm
>
> It returns NIL because A in the loop is initialized to NIL first. (It
> could be initialized to something else). The :for b :in a makes
> reference to that A, not the one in the outer scope.

Where in the spec does it say that A can be initialized to NIL first?

Helmut

[Pascal J. Bourguignon]

Helmut Eller <eller....@gmail.com> writes:

> * Pascal J. Bourguignon [2012-02-19 17:58] writes:
>
>> Helmut Eller <eller....@gmail.com> writes:
>>
>>> I tried this code:
>>>
>>> (let ((a '(x y)))
>>> (loop for a in '((a b) (0 1))
>>> for b in a
>>> collect (list a b)))
>>>
>>> and expected that it evaluates to '(((a b) a) ((0 1) b)) but all the
>>> implementations I tried return nil.
>>>
>>> Can somebody give a pointer to the place in the spec that explains why
>>> this should/could return nil?
>>
>> http://www.lispworks.com/documentation/HyperSpec/Body/06_aba.htm
>
> Here we can read that:
>
> If multiple iteration clauses are used to control iteration, variable
> initialization and stepping[1] occur sequentially by default. The and
> construct can be used to connect two or more iteration clauses when
> sequential binding and stepping[1] are not necessary. The iteration
> behavior of clauses joined by and is analogous to the behavior of the
> macro do with respect to do*.
>
> which seems to confirm my expectation.

No. Variable initialization is not assigning or binding the first
element of the list. That is stepping.

>> http://www.lispworks.com/documentation/HyperSpec/Body/06_abb.htm
>> http://www.lispworks.com/documentation/HyperSpec/Body/06_aaf.htm
>>
>> It returns NIL because A in the loop is initialized to NIL first. (It
>> could be initialized to something else). The :for b :in a makes
>> reference to that A, not the one in the outer scope.
>
> Where in the spec does it say that A can be initialized to NIL first?

Read the quote provided by RG.

[Helmut Eller]

* RG [2012-02-19 18:05] writes:

> The termination condition behavior is permitted by 6.1.1.4
>
> "Implementations can interleave the setting of initial values with the
> bindings. However, the assignment of the initial values is always
> calculated in the order specified by the user. A variable is thus
> sometimes bound to a meaningless value of the correct type, and then
> later in the prologue it is set to the true initial value by using setq.
> One implication of this interleaving is that it is
> implementation-dependent whether the lexical environment in which the
> initial value forms (variously called the form1, form2, form3, step-fun,
> vector, hash-table, and package) in any for-as-subclause, except
> for-as-equals-then, are evaluated includes only the loop variables
> preceding that form or includes more or all of the loop variables; the
> form1 and form2 in a for-as-equals-then form includes the lexical
> environment of all the loop variables."

OK, thanks. That answers my question. In summary, only for
for-as-equals-then can we say what variables have which value in the
init form. Things like

(loop for a in '((a b) (0 1))
for b in a
collect (list a b))

can return random results. It can be, but doesn't have to be, nil.

Helmut

[Pascal J. Bourguignon]

Helmut Eller <eller....@gmail.com> writes:

> * RG [2012-02-19 18:05] writes:
>
>> The termination condition behavior is permitted by 6.1.1.4
>>
>> "Implementations can interleave the setting of initial values with the
>> bindings. However, the assignment of the initial values is always
>> calculated in the order specified by the user. A variable is thus
>> sometimes bound to a meaningless value of the correct type, and then
>> later in the prologue it is set to the true initial value by using setq.
>> One implication of this interleaving is that it is
>> implementation-dependent whether the lexical environment in which the
>> initial value forms (variously called the form1, form2, form3, step-fun,
>> vector, hash-table, and package) in any for-as-subclause, except
>> for-as-equals-then, are evaluated includes only the loop variables
>> preceding that form or includes more or all of the loop variables; the
>> form1 and form2 in a for-as-equals-then form includes the lexical
>> environment of all the loop variables."
>
> OK, thanks. That answers my question. In summary, only for
> for-as-equals-then can we say what variables have which value in the
> init form.

Not even.

(loop
for a = '((a b) (0 1)) then (cdr a)
as b in (car a)
while a
collect (list (car a) b)))

returns NIL, because A is still bound to NIL when the AS B IN (CAR A) …
is evaluated.

[Helmut Eller]

> returns NIL, because A is still bound to NIL when the AS B IN (CAR A) &
> is evaluated.

I meant for-as-equals-then as the second clause:

(loop for a in '((a b) (0 1))

for b = a then a
collect (list a b))

must return (((A B) (A B)) ((0 1) (0 1))).

Helmut

[Kaz Kylheku]

On 2012-02-19, Raymond Wiker <r...@unknown-00-23-6c-8d-9e-26.lan> wrote:
> Helmut Eller <eller....@gmail.com> writes:
>
>> I tried this code:
>>
>> (let ((a '(x y)))
>> (loop for a in '((a b) (0 1))
>> for b in a
>> collect (list a b)))
>>
>> and expected that it evaluates to '(((a b) a) ((0 1) b)) but all the
>> implementations I tried return nil.
>>
>> Can somebody give a pointer to the place in the spec that explains why
>> this should/could return nil?
>>
>> Helmut
>
> I think this happens because the two "for" clauses are executed in
> parallel, and the initial value for "a" seen by the second clause is
> nil.

But there is no AND between the clauses to make them parallel. This is pretty
fucked up.

[Kaz Kylheku]

On 2012-02-19, Pascal J. Bourguignon <p...@informatimago.com> wrote:
> Helmut Eller <eller....@gmail.com> writes:
>
>> * Pascal J. Bourguignon [2012-02-19 17:58] writes:
>>
>>> Helmut Eller <eller....@gmail.com> writes:
>>>
>>>> I tried this code:
>>>>
>>>> (let ((a '(x y)))
>>>> (loop for a in '((a b) (0 1))
>>>> for b in a
>>>> collect (list a b)))
>>>>
>>>> and expected that it evaluates to '(((a b) a) ((0 1) b)) but all the
>>>> implementations I tried return nil.
>>>>
>>>> Can somebody give a pointer to the place in the spec that explains why
>>>> this should/could return nil?
>>>
>>> http://www.lispworks.com/documentation/HyperSpec/Body/06_aba.htm
>>
>> Here we can read that:
>>
>> If multiple iteration clauses are used to control iteration, variable
>> initialization and stepping[1] occur sequentially by default. The and
>> construct can be used to connect two or more iteration clauses when
>> sequential binding and stepping[1] are not necessary. The iteration
>> behavior of clauses joined by and is analogous to the behavior of the
>> macro do with respect to do*.
>>
>> which seems to confirm my expectation.
>
> No. Variable initialization is not assigning or binding the first
> element of the list. That is stepping.

Aha, so in:

for x = 1 then (+ x 1)

x becoming 1 is also stepping, not initialization. The binding and
initialization takes place before the loop and x becomes nil then.

[WJ]

Paul Graham:

I consider Loop one of the worst flaws in CL, and an example
to be borne in mind by both macro writers and language designers.


Dan Weinreb, one of the designers of Common Lisp:

... the problem with LOOP was that it turned out to be hard to
predict what it would do, when you started using a lot of
different facets of LOOP all together. This is a serious problem
since the whole idea of LOOP was to let you use many facets
together; if you're not doing that, LOOP is overkill.

[RG]

In article <201202191...@kylheku.com>,

Helmut is wrong. It is not "because the two "for" clauses are executed
in parallel." It's because the A in "for b in a" is evaluated after A
is bound but before it is assigned to '(a b).

rg

[Kaz Kylheku]

Yes; the parallelism is for the stepping, which has nothing to do with the
initial binding, because even the first iteration is achieved by stepping.

I suspect where people go wrong is taking analogies between LOOP and DO/DO*
too far.

[Kaz Kylheku]

On 2012-02-20, WJ <w_a_...@yahoo.com> wrote:
> Paul Graham:
>
> I consider Loop one of the worst flaws in CL, and an example
> to be borne in mind by both macro writers and language designers.
>
>
> Dan Weinreb, one of the designers of Common Lisp:
>
> ... the problem with LOOP was that it turned out to be hard to
> predict what it would do, when you started using a lot of
> different facets of LOOP all together. This is a serious problem
> since the whole idea of LOOP was to let you use many facets
> together; if you're not doing that, LOOP is overkill.

This is a problem of documentation. Users of loop have to reverse engineer
it by experimentation with multiple implementations, and careful reading
of the obtusely written spec.

If the user is guided to a correct mental model upfront, the guess-work about
what loop will do can be eliminated.

(I suspect that a block diagram could go a long way.)

If your mental model says that the binding initialization of the variables
is responsible for their values for the first stepping, like it is
in DO/DO*, you will be surprised by LOOP's behavior.

I don't agree with Weinreb that simple uses of LOOP are overkill. Simple uses
of LOOP are readable to the point that a newbie Lisp programmer can accurately
guess what the code is doing, and there is value in that.

[Pascal Costanza]

+1

--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
The views expressed are my own, and not those of my employer.

[RG]

In article <9qi6rm...@mid.individual.net>,

+2

(Yes, I know "me too" posts are bad netiquette, but I so often disagree
with Kaz and Pascal C. that I thought it worthwhile highlighting an
occasion when we do not.)

rg

[Pascal Costanza]

:)

[Tim Bradshaw]

On 2012-02-21 18:52:40 +0000, RG said:

> +2
>
> (Yes, I know "me too" posts are bad netiquette, but I so often disagree
> with Kaz and Pascal C. that I thought it worthwhile highlighting an
> occasion when we do not.)

Damn, I was going to agree with that as well. LOOP is kind of like the
package system for me[*]: yes it's clearly an abomination, but it's
good enough, and the simple cases make for very clear code I think.

--tim

[*] You'll disagree about the package system but I hope you see what I mean.

[kodifik]

On 21 feb, 11:24, Kaz Kylheku <k...@kylheku.com> wrote:

> On 2012-02-20, WJ <w_a_x_...@yahoo.com> wrote:
> I don't agree with Weinreb that simple uses of LOOP are overkill.  Simple uses
> of LOOP are readable to the point that a newbie Lisp programmer can accurately
> guess what the code is doing, and there is value in that.

Related to it, the loop macro is of GREAT value in reusing code:
I frequently find myself rewriting in (loop) things I had done
previously
with (do) and others for the sake of being able to read more easily my
own code in the future.

[WJ]

WJ wrote:

> Dan Weinreb, one of the designers of Common Lisp:

Sorry; that should have been "COBOL Lisp".

[Kaz Kylheku]

I don't think we disagreea bout much else besides the package system.

I understand moving packaging into a lexical binding system, but I don't agree
that it's the way to go. (One good thing about it is that it is possible to
implement in the existing Lisp.)

I believe that packages which purely contain symbols is such a fantastic idea,
that nothing else will do for a Lisp-like language.

The problems that people run into are issues with the implementation, not with
the basic concept on which it is built. (However, this is hard to fix without
breaking backward compatibility.)

I have come up with some ideas which will fix the package system by replacing
it with one that is ideologically similar. But, alas, this requires a reworking
from the ground up: not backward compatible.

I don't want to change the topic of this thread, so I won't give any details
here.

Taking a broader outlook, think we should come up with a "next generation"
Common Lisp which is largely compatible with the 1994 Common Lisp, but with a
license to dispense with compatibility when it is inconvenient, and
redesign certain things. (I.e have some of the same "carte blanche: as the
original designers were able to afford.)

Most CL programs should also be CL NG programs, and most of those that are not
should be easy to port. One possible design goal might be that it should be
easy for CL NG implementations to provide a backward compatibility mode for CL
programs that will allow all of them to work.

[RG]

In article <201202240...@kylheku.com>,

Oh, there are probably a few other things we don't see eye to eye on.
But here's something else we do agree on:

> Taking a broader outlook, think we should come up with a "next generation"
> Common Lisp which is largely compatible with the 1994 Common Lisp, but with a
> license to dispense with compatibility when it is inconvenient, and
> redesign certain things. (I.e have some of the same "carte blanche: as the
> original designers were able to afford.)
>
> Most CL programs should also be CL NG programs, and most of those that are
> not
> should be easy to port. One possible design goal might be that it should be
> easy for CL NG implementations to provide a backward compatibility mode for
> CL
> programs that will allow all of them to work.

There is a clear need for something like CL-NG, or the next generation
of programmers is going to come up learning Clojure. I wish you success
in your efforts.

rg

[Tim Bradshaw]

On 2012-02-25 02:55:57 +0000, RG said:

> There is a clear need for something like CL-NG, or the next generation
> of programmers is going to come up learning Clojure. I wish you success
> in your efforts.

Do you seriously think anyone uses Clojure because it's somehow a
cleaner Lisp than CL? Of course they don't: they use it because it
sits on top of the JVM and thus has access to an enormous standard
library. CL as a language has deficiencies, but is it deficient
compared to Python? Ruby? Perl? No. Other than *people you have met
on usenet*, no one is thinking "if only CL had first-class types and
pattern-matching / <whatever> I could write my killer app". No,
they're thinking "Wow, CL's a pretty cool language, if only it had a
standard JSON/XML-RPC/<whatever> package I could write my killer app,
but it doesn't so I'll have to use Ruby/Perl/Python, or may be that
Clojure thing, or Racket".

And you know who's fixing this? Zach Beane, with Quicklisp. He's not
wasting his time with some souped-up "modernised" CL that no one would
ever care about: he's not even got side-tracked by not having a decent
system definition tool or worrying about namespaces or something[*],
he's just got on with it with the tools he has, and produced something
more useful to the Lisp community than you, I or Kaz have ever done.
CL now has a standard way of installing packages over the network, and
a standard package repository. Three things are now needed: firstly
every implementation should either ship with Quicklisp or it should be
trivially obvious how to install it, secondly people need to take a
good look at the packages available via Quicklisp and implement ones
people need which are missing, and finally we need to get away from
this stupid bickering about the language and start evangelizing and
demonstrating the use of CL with its new standard library to get real
work done.

We need to get over ourselves: CL has never been other than a hack
language for getting stuff done (it's *common* lisp), and it needs to
get back to being that. The linguistic purists can burn.

--tim

[*] That would be me, and I am ashamed of that, especially as it is
pretty clear that ASDF could be compatibly fixed if I only put the work
into it.

[RG]

In article <jia9d3$68u$1...@dont-email.me>, Tim Bradshaw <t...@tfeb.org>
wrote:

I agree with you that Quicklisp is very cool, and I freely concede that
Zach has contributed more to the community than I have.

I also agree with you that the reason people use Clojure is not that it
is a cleaner Lisp than CL. (I happen to believe that Clojure is
superior to CL in some ways, but that is neither here nor there. And,
BTW, despite believing that Clojure is superior to CL in some ways, I
nonetheless do not use it. But explaining why would take us far afield,
so I won't.)

I disagree with you, however, that people use Clojure because it has
access to the standard Java library. If libraries were all that stood
between CL and success then ABCL should have been able to achieve the
same success as Clojure. But it didn't.

So despite Quicklisp being tremendously cool and useful, I nonetheless
predict that it will not change the slow but steady decline in CL usage.
We did that experiment already with ABCL and the outcome was negative.

So... if it's not the language and it's not the libraries, then why is
Clojure winning?

My hypothesis: Clojure is (widely perceived as being) *cool* and CL
isn't. The Clojure community is (widely perceived as being) vibrant and
dynamic, and the CL community isn't. The Clojure community is (W.P.A.)
solving real problems. The CL community is (WPA) spending its time
quibbling over minutiae in the ANSI spec as if it were holy scripture,
and burning apostates at the stake, at least metaphorically.

That hypothesis, of course, raises the obvious question: *why* is
Clojure (WPAB) cool? Here again I can offer only a hypothesis: change.
Of all the programming languages in widespread use today, CL (if it even
deserves to be on that list at all any more) is the only one that has
not had a major revision in the last 18 years.

This is not and never has been about packages or lexicons or the
persistence of defvar or any other particular aspect of the language.
This has always been (and still is) about the possibility of change.
Or, as the case may be, the lack thereof.

I believe that the ability to change is an advantage in and of itself,
completely independent of the relative merits (or lack thereof) of the
thing that you are changing from or to. Like all things, change is
subject to Ron's First Law: all extreme positions are wrong. Sometimes
change can go wrong (c.f. R6RS, Windows Vista, New Coke).

My personal opinion is that the authors of the Spec got a lot right.
They probably got more right in a single design effort than anyone ever
has before or since. But they didn't get everything right.

I am not advocating arbitrary or capricious change, or even change for
its own sake. But if someone encounters something in Clojure (or Python
or Perl or even C) that is badly broken, there is at least the
possibility that it could change if enough people agree that it is badly
broken. If someone encounters something in CL that is badly broken, the
Bayesian prior on its ever changing is for most people at the moment
indistinguishable from zero. So if you're going to use CL you have to
accept one of two premises: either the people who wrote the Spec were
infallible and made no mistakes, or they weren't, and they did, and you
are stuck with those mistakes until you get old and die.

And that is not cool.

rg

[Pascal J. Bourguignon]

RG <rNOS...@flownet.com> writes:

> That hypothesis, of course, raises the obvious question: *why* is
> Clojure (WPAB) cool? Here again I can offer only a hypothesis: change.
> Of all the programming languages in widespread use today, CL (if it even
> deserves to be on that list at all any more) is the only one that has
> not had a major revision in the last 18 years.

This is first reason why I choose Common Lisp. So that I can write my
programs with a stable base, not at a moving target.

> If someone encounters something in CL that is badly broken, the
> Bayesian prior on its ever changing is for most people at the moment
> indistinguishable from zero. So if you're going to use CL you have to
> accept one of two premises: either the people who wrote the Spec were
> infallible and made no mistakes, or they weren't, and they did, and you
> are stuck with those mistakes until you get old and die.

The second reason is that because of the way CL is designed, if there's
anything wrong with it, I know *I*, as a mere programmer, will be able
to correct it myself, even without having to patch the implementation.

This is not something I can do with other programming languages, and
even in most other lisps. Just one example: there are no reader macros
in emacs lisp; are there reader macros in Clojure?

[Kaz Kylheku]

On 2012-02-26, Pascal J. Bourguignon <p...@informatimago.com> wrote:
> RG <rNOS...@flownet.com> writes:
>
>> That hypothesis, of course, raises the obvious question: *why* is
>> Clojure (WPAB) cool? Here again I can offer only a hypothesis: change.
>> Of all the programming languages in widespread use today, CL (if it even
>> deserves to be on that list at all any more) is the only one that has
>> not had a major revision in the last 18 years.
>
> This is first reason why I choose Common Lisp. So that I can write my
> programs with a stable base, not at a moving target.

Indeed. For instance garbage like C99 and C11, we can do without.

At some point, committees have to realize that hey have served their purpose
and have the decency to dissolve.

[RG]

In article <87wr7ac...@kuiper.lan.informatimago.com>,

"Pascal J. Bourguignon" <p...@informatimago.com> wrote:

> RG <rNOS...@flownet.com> writes:
>
> > That hypothesis, of course, raises the obvious question: *why* is
> > Clojure (WPAB) cool? Here again I can offer only a hypothesis: change.
> > Of all the programming languages in widespread use today, CL (if it even
> > deserves to be on that list at all any more) is the only one that has
> > not had a major revision in the last 18 years.
>
> This is first reason why I choose Common Lisp. So that I can write my
> programs with a stable base, not at a moving target.

If you constrain yourself to CL's stable base as defined by the standard
you will be writing some pretty uninteresting code. Maybe you haven't
noticed, but the world has changed since 1994. The only thing keeping
CL even remotely viable are informal and nonstandardized extensions like
CFFI (or is it UFFI?), CL-SOCKETS (or is it USOCKET?), ASDF (or is it
Quicklisp?) etc. etc. If you want to write portable code that relies
on, say, introspection of lexical environments you're pretty much SOL.

The fact that every single time I raise this issue someone points to
CL's stability as a winning feature is one of the symptoms of the
problem. The CL community does not seem to grasp the difference between
being stable and being static (or being moribund), or that changes can
be backwards compatible.

> > If someone encounters something in CL that is badly broken, the
> > Bayesian prior on its ever changing is for most people at the moment
> > indistinguishable from zero. So if you're going to use CL you have to
> > accept one of two premises: either the people who wrote the Spec were
> > infallible and made no mistakes, or they weren't, and they did, and you
> > are stuck with those mistakes until you get old and die.
>
> The second reason is that because of the way CL is designed, if there's
> anything wrong with it, I know *I*, as a mere programmer, will be able
> to correct it myself, even without having to patch the implementation.

That is true in many cases, but not all. For example, there is no way
to write a portable lexical binding form without a code walker.

But this is missing the point. The fact of the matter is that Clojure
is attracting a lot more attention than CL. My personal quality metric
says that attracting that kind of attention for CL would be a Good
Thing. CL-NG seems to me more likely to have that result than anything
else on the horizon, so I'm all for it. (But I'm not holding my breath.)

rg

[Teemu Likonen]

* RG [2012-02-25 23:50:47 -0800] wrote:

> The fact of the matter is that Clojure is attracting a lot more
> attention than CL.

Maybe you are right. I don't know. I'm a semi-active hobbyist CL
programmer who hasn't realized this fact. So I'm curious how you measure
this quantity of attention?

[RG]

In article <87aa468...@mithlond.arda>,

http://cemerick.com/2011/07/11/results-of-the-2011-state-of-clojure-surve
y/

rg

[Aleksej Saushev]

Kaz Kylheku <k...@kylheku.com> writes:

> On 2012-02-26, Pascal J. Bourguignon <p...@informatimago.com> wrote:
>> RG <rNOS...@flownet.com> writes:
>>
>>> That hypothesis, of course, raises the obvious question: *why* is
>>> Clojure (WPAB) cool? Here again I can offer only a hypothesis: change.
>>> Of all the programming languages in widespread use today, CL (if it even
>>> deserves to be on that list at all any more) is the only one that has
>>> not had a major revision in the last 18 years.
>>
>> This is first reason why I choose Common Lisp. So that I can write my
>> programs with a stable base, not at a moving target.
>
> Indeed. For instance garbage like C99 and C11, we can do without.

C11 has some positive sides at least. E.g. gets is gone now (at last).


--
HE CE3OH...

[Antony]

On 2/25/2012 1:24 AM, Tim Bradshaw wrote:
> On 2012-02-25 02:55:57 +0000, RG said:
>
>> There is a clear need for something like CL-NG, or the next generation
>> of programmers is going to come up learning Clojure. I wish you success
>> in your efforts.

I am still developing my first CL app and so far I have exactly one
issue - the status of multi threading in the implementations.
That is the only thing that worries me about going to production.

Other than that, for the kind of things *I need*, at present I feel CL
to outside world interaction including the OS and machine are in a
similar state like java was before they had working non blocking i/o
lib. While that would be a good thing to have in CL, I'll be happy with
just normal multi threading working at quality.

I am thankful to all the free libs, especially the complex and large
ones. Most things that are not available or to my liking, I have been
able to create myself. I can not do that for the multi threading.

-Antony
PS: my POV is that of a web service developer

[Teemu Likonen]

* RG [2012-02-26 02:08:56 -0800] wrote:

> Teemu Likonen <tlik...@iki.fi> wrote:
>> * RG [2012-02-25 23:50:47 -0800] wrote:
>>> The fact of the matter is that Clojure is attracting a lot more
>>> attention than CL.

>> So I'm curious how you measure this quantity of attention?
>
> http://cemerick.com/2011/07/11/results-of-the-2011-state-of-clojure-survey/

I hate these vague "paste a link" answers. OK, I'm trying to answer the
question: "How do you measure this quantity of attention?" A quotation
from that page:

First, some facts about the survey and how it was conducted. It was
available for approximately 5 days (Wednesday night through Monday
afternoon), during which time results were not available. The survey
was announced primarily via Twitter and two messages to the main
Clojure mailing list [link]. 670 responses were received -- which, for
sake of comparison, is ~13% of the ~5,000 subscribers to that
mailing list. As I've said before, I'm not a statistician, nor am I
a professional when it comes to surveying, polling, or data
collection of this sort in general, but this would seem to be a very
fair sampling of the Clojure community.

[link: http://groups.google.com/group/clojure]

http://cemerick.com/2011/07/11/results-of-the-2011-state-of-clojure-survey/

Some thoughts:

1. Maybe you measured the attention by the number of subscribers (about
5000) on Clojure mailing list and compared it to relevant numbers in
the CL community?

2. Maybe you compared the number of responses (670). Probably there
have been smaller number of responses in similar surveys in the CL
community?

3. Maybe answers to some of the questions in that survey gave you the
confidence to say "a lot more attention". If so please tell which it
is? It's not clear to me.

Note that I'm not questioning this thing you call a fact. It's just that
I'd prefer a clear answer.

[Pascal Costanza]

On 26/02/2012 08:50, RG wrote:
> In article<87wr7ac...@kuiper.lan.informatimago.com>,
> "Pascal J. Bourguignon"<p...@informatimago.com> wrote:
>
>> RG<rNOS...@flownet.com> writes:
>>
>>> That hypothesis, of course, raises the obvious question: *why* is
>>> Clojure (WPAB) cool? Here again I can offer only a hypothesis: change.
>>> Of all the programming languages in widespread use today, CL (if it even
>>> deserves to be on that list at all any more) is the only one that has
>>> not had a major revision in the last 18 years.
>>
>> This is first reason why I choose Common Lisp. So that I can write my
>> programs with a stable base, not at a moving target.
>
> If you constrain yourself to CL's stable base as defined by the standard
> you will be writing some pretty uninteresting code. Maybe you haven't
> noticed, but the world has changed since 1994. The only thing keeping
> CL even remotely viable are informal and nonstandardized extensions like
> CFFI (or is it UFFI?), CL-SOCKETS (or is it USOCKET?), ASDF (or is it
> Quicklisp?) etc. etc.

Almost every other widely used language and their libraries are informal
and nonstandardized. This doesn't seem to prevent their adoption.

> If you want to write portable code that relies
> on, say, introspection of lexical environments you're pretty much SOL.

Almost no other language even remotely dreams about introspection of
lexical environments. That doesn't seem to prevent their adoption.

> The fact that every single time I raise this issue someone points to
> CL's stability as a winning feature is one of the symptoms of the
> problem. The CL community does not seem to grasp the difference between
> being stable and being static (or being moribund), or that changes can
> be backwards compatible.

Almost all changes being made _right now_ are backwards compatible.
That's the very essence of the reason why people are not asking for
changes to the standard, because it's so easy to get things done without
such changes.

>>> If someone encounters something in CL that is badly broken, the
>>> Bayesian prior on its ever changing is for most people at the moment
>>> indistinguishable from zero. So if you're going to use CL you have to
>>> accept one of two premises: either the people who wrote the Spec were
>>> infallible and made no mistakes, or they weren't, and they did, and you
>>> are stuck with those mistakes until you get old and die.
>>
>> The second reason is that because of the way CL is designed, if there's
>> anything wrong with it, I know *I*, as a mere programmer, will be able
>> to correct it myself, even without having to patch the implementation.
>
> That is true in many cases, but not all. For example, there is no way
> to write a portable lexical binding form without a code walker.

Which other language allows you to write a code walker, and then add
language extensions based on that as libraries?

> But this is missing the point. The fact of the matter is that Clojure
> is attracting a lot more attention than CL. My personal quality metric
> says that attracting that kind of attention for CL would be a Good
> Thing. CL-NG seems to me more likely to have that result than anything
> else on the horizon, so I'm all for it. (But I'm not holding my breath.)

Rich Hickey was previously a CL user. Something like Clojure, plus some
other random features from other popular languages, is what you would
probably get if you ever found that theoretical way of opening up the
language specification that you seem to be dreaming of. Maybe you
_should_ switch to Clojure, at least for a while? If that doesn't make
you happy, then you are facing an inherent problem of your suggestion,
even if you're not aware of it.

What you're missing is that you're part of the problem, not part of the
solution. In almost every language community that I'm aware of, users of
the respective language are saying almost exclusively positive things
about it. A problem of Common Lisp is that _even its own users_ say
negative things about it. How you can reasonably expect to make newbies
excited about such a language is beyond me.

I'm using Common Lisp on a regular basis, and I am very happy about how
modern the language is, and how useful all the extensions are that have
been made to the language, not only in the past two decades, but also
very recently, in the last few years. It beats the crap out of every
other language I'm aware of, in almost all respects. There must be
something substantially right about the language if that is possible.

Please stop painting such a negative picture of Common Lisp. Doing so
serves no purpose.


Pascal

[Pascal J. Bourguignon]

RG <rNOS...@flownet.com> writes:

> That is true in many cases, but not all. For example, there is no way
> to write a portable lexical binding form without a code walker.

But you can write a portable lexical binding form with a code walker.

> But this is missing the point. The fact of the matter is that Clojure
> is attracting a lot more attention than CL. My personal quality metric
> says that attracting that kind of attention for CL would be a Good
> Thing. CL-NG seems to me more likely to have that result than anything
> else on the horizon, so I'm all for it. (But I'm not holding my breath.)

Clojure is a one man job. It's proof it's possible to design a language
alone. Starting from the Common Lisp base, you should have it even
easier. So if you fork a CL implementation and make one that provides a
standard COMMON-LISP package, plus a COMMON-LISP-NEW-GENERATION package
that do wonderful things, I'll be totally in favor of it.

My critir of Clojure is that it's not Common Lisp, I don't mind the
extensions, they can be interesting.

[RG]

In article <87ipit7...@mithlond.arda>,

Teemu Likonen <tlik...@iki.fi> wrote:

> * RG [2012-02-26 02:08:56 -0800] wrote:
>
> > Teemu Likonen <tlik...@iki.fi> wrote:
> >> * RG [2012-02-25 23:50:47 -0800] wrote:
> >>> The fact of the matter is that Clojure is attracting a lot more
> >>> attention than CL.
>
> >> So I'm curious how you measure this quantity of attention?
> >
> > http://cemerick.com/2011/07/11/results-of-the-2011-state-of-clojure-survey/
>
> I hate these vague "paste a link" answers.

Really? Why?

> OK, I'm trying to answer the
> question: "How do you measure this quantity of attention?"

And the answer is: I look at data, such as the data that is to be found
by following this link...

But honestly, I don't see how that verbiage adds information.

Sorry, pointing at the data is as clear as I can get. I have not done a
scientific study. I have not done any formal analysis. I have no
control case and no statistically significant results. But the data I
have seems to paint a pretty clear picture. Here's some more:

1. Clojure is the #21 language on github. CL is #27. (It could be
worse. Scheme is 29 and Arc is a dismal 61.)

2. I am pretty plugged in to the startup community in the Silicon
Valley. I know of several active Clojure-based startups. I know of
zero active CL based startups. The last CL based startup I know of came
through Y Combinator about three years ago, and even they are now
abandoning CL for Javascript.

3. There are 40 active Clojure meetups on mettup.com. There are 10 or
so active CL meetups. (By "active" mean groups that actually have
meetings.) One of those is the BA Lisp group, which has met five times
in the last two years. The BA Clojure group meets monthly. There used
to be a Lisp group in LA, but it is dead. It hasn't had a meeting in
over two years. By way of contrast, there is an LA based Clojure group
that has 108 members and has been meeting monthly for the last year and
a half.

rg

[RG]

In article <87pqd1d...@kuiper.lan.informatimago.com>,

"Pascal J. Bourguignon" <p...@informatimago.com> wrote:

> RG <rNOS...@flownet.com> writes:
>
> > That is true in many cases, but not all. For example, there is no way
> > to write a portable lexical binding form without a code walker.
>
> But you can write a portable lexical binding form with a code walker.

Sure. I can write my own language from scratch too. And your point
would be...?

> > But this is missing the point. The fact of the matter is that Clojure
> > is attracting a lot more attention than CL. My personal quality metric
> > says that attracting that kind of attention for CL would be a Good
> > Thing. CL-NG seems to me more likely to have that result than anything
> > else on the horizon, so I'm all for it. (But I'm not holding my breath.)
>
> Clojure is a one man job.

Not any more. It started as a one-man job, and it has a BDFL, but it is
no more a one man job today than Python is.

> It's proof it's possible to design a language
> alone. Starting from the Common Lisp base, you should have it even
> easier. So if you fork a CL implementation and make one that provides a
> standard COMMON-LISP package, plus a COMMON-LISP-NEW-GENERATION package
> that do wonderful things, I'll be totally in favor of it.

What would you consider wonderful?

Here's something I consider wonderful. I wrote an implementation of the
lambda calculus, and used it to write a fully expanded factorial
function using Church numerals and the Y Combinator. It's 18 lines of
code. It actually works, and compiles to native code. It can compute
factorial of 6 in a couple of seconds, and factorial of 7 without
crashing. It's an incredibly cool pedagogical tool, a IMO beautiful
marriage of theory and practice. But to get the code to not look like
the FUNCALL bird pooped all over it, I had to hack my CL implementation
to allow me to write:

((...) ...)

instead of:

(funcall (...) ...)

This cannot be done within CL, not because of any technical barrier (my
code is an existence proof) but because the standard defines ((...) ...)
to be an error.

rg

[RG]

In article <9qutcr...@mid.individual.net>,

Pascal Costanza <p...@p-cos.net> wrote:

> What you're missing is that you're part of the problem, not part of the
> solution. In almost every language community that I'm aware of, users of
> the respective language are saying almost exclusively positive things
> about it.

That might be true about Clojure (a Google search for "clojure sucks"
yields surprisingly few results) but it is not true about, e.g. Python

http://www.google.com/search?&q=python+sucks

Or Ruby:

http://www.rubyist.net/~matz/slides/rc2003/mgp00003.html

Or Java or Javascript or C++ or, actually, pretty much any other
language.

> Please stop painting such a negative picture of Common Lisp. Doing so
> serves no purpose.

On the contrary, criticism can serve very useful purposes. Some people
actually make their living as critics.

What serves no purpose is getting defensive about it.

Seriously, folks, if you really believe that what I say has no merit you
should just ignore me. Don't feed the troll.

> How you can reasonably expect to make newbies
> excited about such a language is beyond me.

I am never sure whether to be flattered or merely wryly amused whenever
someone suggests that I am so influential as to be able to
singlehandedly be a significant factor in Common Lisp's demise.

Look at that second link I posted above. It's a pointer to a
presentation by the creator of Ruby entitled "How Ruby Sucks." And yet,
Ruby somehow manages to survive. You must find that utterly baffling.

rg

[RG]

In article <jid53d$uta$1...@speranza.aioe.org>,

Antony <remove+spam...@gmail.com> wrote:

> On 2/25/2012 1:24 AM, Tim Bradshaw wrote:
> > On 2012-02-25 02:55:57 +0000, RG said:
> >
> >> There is a clear need for something like CL-NG, or the next generation
> >> of programmers is going to come up learning Clojure. I wish you success
> >> in your efforts.
> I am still developing my first CL app and so far I have exactly one
> issue - the status of multi threading in the implementations.
> That is the only thing that worries me about going to production.

Really? Why does that worry you? More specifically, why does it worry
you more than any other language? Multithreading is a minefield no
matter what language you're using.

I'm very happy to hear that people are actually working on production
apps in CL. May I ask what you are working on?

rg

[Marco Antoniotti]

On Sunday, February 26, 2012 10:06:31 AM UTC-5, Pascal J. Bourguignon wrote:
> RG <rNOS...@flownet.com> writes:
>
> > That is true in many cases, but not all. For example, there is no way
> > to write a portable lexical binding form without a code walker.
>
> But you can write a portable lexical binding form with a code walker.
>

Ahem! You can *easily* write a *portable* code walker *now* that LW has shipped 6.1, re-introducing the CLtL2 environment access functions. Also you always need to wrap around Franz gratuitous change in the signature of these functions.

Granted, number 2 is nit-picking, but number 1 was a show stopper until two months ago, unless you rally wanted to re-build (as you have done) a full blown AST from scratch.

Cheers
--
MA

[WJ]

Helmut Eller wrote:

> I tried this code:
>
> (let ((a '(x y)))
> (loop for a in '((a b) (0 1))
> for b in a
> collect (list a b)))
>
> and expected that it evaluates to '(((a b) a) ((0 1) b)) but all the
> implementations I tried return nil.

MatzLisp:

it = [[:a, :b], [0, 1]]
it.zip( it.first )
==>[[[:a, :b], :a], [[0, 1], :b]]

[Pascal Costanza]

On 26/02/2012 20:08, RG wrote:

> Seriously, folks, if you really believe that what I say has no merit you
> should just ignore me. Don't feed the troll.

OK

[Pascal Costanza]

LispWorks currently has one of the best multi-threading extensions of
_any_ language (not just Lisp dialects). I can strongly recommend it.

It's very close in quality and breadth to, for example, Threading
Building Blocks (for C++), and performance can be close to that too, if
you are willing to spend the time on the necessary optimization (no need
to go outside LispWorks for that).

[Marco Antoniotti]

ZZZZZZZZZZZZZZZ, Ronf.

[Chiron]

On Sun, 26 Feb 2012 11:08:38 -0800, RG wrote:

> On the contrary, criticism can serve very useful purposes. Some people
> actually make their living as critics.

Careful with that line of reasoning... some people make their living
collecting samples to artificially inseminate cattle, but you don't find
them bragging about it.

Still, you have a valid point. Common Lisp (or anything) doesn't improve
when everyone says it's fine. Unless it's already perfect, it is
necessary to acknowledge any shortcomings and work on them.

Much depends on how the criticism is presented - and whether it comes
with helpful ideas on how to fix it.



--
Many alligators will be slain,
but the swamp will remain.

[Kaz Kylheku]

TXR Lisp's has the sequential binding Helmut Eller was looking for in loop:

(collect-each* ((i '((a b) (0 1)))
(j (first i)))
'(,i ,j))

This collect-each* can easily be ported to Common Lisp as a macro.

[RG]

In article <KoG2r.14320$1I2....@newsfe08.iad>,

Chiron <chir...@gmail.com> wrote:

> On Sun, 26 Feb 2012 11:08:38 -0800, RG wrote:
>
> > On the contrary, criticism can serve very useful purposes. Some people
> > actually make their living as critics.
>
> Careful with that line of reasoning... some people make their living
> collecting samples to artificially inseminate cattle, but you don't find
> them bragging about it.

I have never met a cattle insemination sample collector, but I would
hope that they took pride in their work. I suspect what they do is
neither fun nor easy, and they probably brings more real value to the
world than most critics.

> Still, you have a valid point. Common Lisp (or anything) doesn't improve
> when everyone says it's fine. Unless it's already perfect, it is
> necessary to acknowledge any shortcomings and work on them.

Thank you for recognizing that.

> Much depends on how the criticism is presented - and whether it comes
> with helpful ideas on how to fix it.

Oh, you mean like this?

http://rondam.blogspot.com/2010/02/new-and-improved-lexicons-now-50-lexie
r.html

Or this?

http://rondam.blogspot.com/2009/08/global-variables-done-right.html

Or this?

http://rondam.blogspot.com/2009/09/and-now-word-from-our-thponthor.html

Or this?

http://www.flownet.com/ron/specials.pdf

Or this?

http://www.flownet.com/ron/packages.pdf

Or this?

http://www.flownet.com/ron/lisp/lexicons.pdf

Or this?

http://www.flownet.com/ron/lisp/combination-hook.lisp

Or (bringing it back to the actual original topic of this thread) this?

http://rondam.blogspot.com/2008/02/joy-of-iterators.html

It's true that I have not contributed as much to CL as, say, Zach,
Conrad, Edi, Duane, and Peter Seibel (and as long as I'm naming names,
I'll also point to Gary Byers, who to his credit does not hang out here
on C.L.L. and so is largely unknown and unsung beyond the small but
dedicated group of users of Clozure Common Lisp). But I don't think
it's fair to suggest that all I'm doing is sniping from the sidelines.

rg

[Chiron]

On Mon, 27 Feb 2012 10:12:42 -0800, RG wrote:

> It's true that I have not contributed as much to CL as, say, Zach,
> Conrad, Edi, Duane, and Peter Seibel (and as long as I'm naming names,
> I'll also point to Gary Byers, who to his credit does not hang out here
> on C.L.L. and so is largely unknown and unsung beyond the small but
> dedicated group of users of Clozure Common Lisp). But I don't think
> it's fair to suggest that all I'm doing is sniping from the sidelines.

Um... that's not even close to what I said or implied. You may be
hearing that sort of thing from other people here, but you have not heard
it from me. That is not at all what I was suggesting.

Any time a criticism is made, it has a potential to be misunderstood, or
to be seen as an unfair judgement. That being the case, some care is
needed to avoid such misunderstanding. That's all I was suggesting.

In fact, perhaps my own comment could be a case in point - perhaps the
way in which I expressed it *did* sound as though it were an unfair
judgement against you. But that only underscores what I was suggesting -
*any* sort of criticism requires care in its delivery, lest it be taken
amiss.

I do NOT think that a person must offer a solution, just to have the
right to identify a problem. It's always nice when someone can say,
"here's where a problem is, and here's a suggested solution." Great, if
you can do it. But more people are able to say what's not working for
them, than are able to fix it themselves. Not every user should be
expected to know how to get under the hood and make the repairs himself.
Not every programmer is able to say what would make their chosen language
better, even though most would be able to say what they wished were so.

So if I did come across as criticizing you for "sniping from the
sidelines," I apologize for that. It was not at all what I had intended.


--
Democracy is good. I say this because other systems are worse.
-- Jawaharlal Nehru

[RG]

In article <B4%2r.18020$kv1....@newsfe03.iad>,

No worries.

rg

[Teemu Likonen]

* RG [2012-02-26 10:06:42 -0800] wrote:

> Teemu Likonen <tlik...@iki.fi> wrote:
>> * RG [2012-02-26 02:08:56 -0800] wrote:
>>> http://cemerick.com/2011/07/11/results-of-the-2011-state-of-clojure-survey/
>>
>> I hate these vague "paste a link" answers.
>
> Really? Why?

It's so often unclear where the actual answer is.

> Sorry, pointing at the data is as clear as I can get.

But that's only for the Clojure part. "A lot more attention" needs a CL
part too so that one can see what is more and what is less.

> Here's some more:
>
> 1. Clojure is the #21 language on github. CL is #27. (It could be
> worse. Scheme is 29 and Arc is a dismal 61.)
>
> 2. I am pretty plugged in to the startup community in the Silicon
> Valley. I know of several active Clojure-based startups. I know of
> zero active CL based startups. The last CL based startup I know of came
> through Y Combinator about three years ago, and even they are now
> abandoning CL for Javascript.
>
> 3. There are 40 active Clojure meetups on mettup.com. There are 10 or
> so active CL meetups. (By "active" mean groups that actually have
> meetings.) One of those is the BA Lisp group, which has met five times
> in the last two years. The BA Clojure group meets monthly. There used
> to be a Lisp group in LA, but it is dead. It hasn't had a meeting in
> over two years. By way of contrast, there is an LA based Clojure group
> that has 108 members and has been meeting monthly for the last year and
> a half.

Thank you. This kind of comparison I wanted.

[Antony]

On 2/26/2012 11:11 AM, RG wrote:
>> I am still developing my first CL app and so far I have exactly one
>> issue - the status of multi threading in the implementations.
>> That is the only thing that worries me about going to production.
>
> Really? Why does that worry you? More specifically, why does it worry
> you more than any other language? Multithreading is a minefield no
> matter what language you're using.

It's not possible (or too hard) for me give any logical reason for this.
I can only say this is by experience. I don't have a problem on the
application side, cause that is under my control.
As a recent example - I delivered and maintained a server app using
.net/C# for about 3 years, in which I never ran into any MT issues. This
is just an example, I don't want to list my 22+ years of work resume
here. All I can say it's quite diverse in terms of programming languages
alone.
I can point out what I perceive the situation to be:
ECL is going through multithreading birthing pains.
There is a thread (no pun intended) on the CCL mailing list about multi
threading and freebsd and how difficult it is on the implementation side.
ACL I am under the impression is just beginning with MT support
LW may be doing great, but I have tried and given it up too many times.
I think sbcl is having extensive multithreading surgery.
Same for CLISP
I didn't get an answer about CMUCL status regarding MT

This is too much complaining, but there isn't much else I can do for
this subject.

>
> I'm very happy to hear that people are actually working on production
> apps in CL. May I ask what you are working on?
>

Stealth :)
-Antony

[Pascal Costanza]

On 19/03/2012 08:32, Antony wrote:

> LW may be doing great, but I have tried and given it up too many times.

LW has SMP since 6.0, and since then provides one of the best SMP
libraries for _any_ language. It's on par in breadth and depth as what
the combination of C++11 and TBB would provide, for example (except for
providing a work-stealing scheduler). It's worth trying again.

[Marco Antoniotti]

On Monday, March 19, 2012 8:42:27 AM UTC+1, Pascal Costanza wrote:
> On 19/03/2012 08:32, Antony wrote:
>
> > LW may be doing great, but I have tried and given it up too many times.
>
> LW has SMP since 6.0, and since then provides one of the best SMP
> libraries for _any_ language. It's on par in breadth and depth as what
> the combination of C++11 and TBB would provide, for example (except for
> providing a work-stealing scheduler). It's worth trying again.
>

Yep. Actually, writing a work-stealing scheduler for LW 6.x would be a worthwhile project.

Cheers
--
MA

[namekuseijin]

Em sábado, 25 de fevereiro de 2012 23h07min22s UTC-2, Pascal J. Bourguignon escreveu:
> RG <rNOS...@flownet.com> writes:
>
> > That hypothesis, of course, raises the obvious question: *why* is
> > Clojure (WPAB) cool? Here again I can offer only a hypothesis: change.
> > Of all the programming languages in widespread use today, CL (if it even
> > deserves to be on that list at all any more) is the only one that has
> > not had a major revision in the last 18 years.
>
> This is first reason why I choose Common Lisp. So that I can write my
> programs with a stable base, not at a moving target.

oh, come on, Pascal! We all know you hang around in CLL for more than 18 years... it was certainly all stable then. :)

[Marco Antoniotti]

Well yes. Pretty much as C/C++ libraries have been stable.

Cheers
--
MA

[WJ]

RG wrote:

> In article <m2sji6z...@gmail.com>,

> Helmut Eller <eller....@gmail.com> wrote:
>
> > I tried this code:
> >
> > (let ((a '(x y)))
> > (loop for a in '((a b) (0 1))
> > for b in a
> > collect (list a b)))
> >
> > and expected that it evaluates to '(((a b) a) ((0 1) b)) but all the
> > implementations I tried return nil.
> >

> > Can somebody give a pointer to the place in the spec that explains why
> > this should/could return nil?
> >
> > Helmut
>
> LOOP binds the variables in the FOR clauses in parallel before doing
> anything else. It then evaluates all the IN clauses, again in parallel.
> At that point, A is NIL. So B is looping over NIL.
>
> Try something like this:
>
> (let ((l '((a b) (0 1))))
> (loop for a in l
> for b in (car l)
> collect (list a b)))
>
> rg

Very bad advice, Ron. You should tell him to use a Lisp
instead of CL (COBOL-Like).

Racket:

(define lst '((a b) (0 1)))
(map list lst (car lst))
=> '(((a b) a) ((0 1) b))

"WE DON'T NEED NO STINKIN' LOOPS!"

[Tim Bradshaw]

On 2012-05-11 03:43:41 +0000, WJ said:

> (map list lst (car lst))

Two different spellings of "list" for some obscure reason, next to each
other (why? what does that mean?), and then some thing apparently to do
with automobiles. And maps? Is this some kind of GPS thing? Man,
Lisp is a pain.

[WJ]

WJ wrote:

> RG wrote:
>
> > In article <m2sji6z...@gmail.com>,
> > Helmut Eller <eller....@gmail.com> wrote:
> >
> > > I tried this code:
> > >
> > > (let ((a '(x y)))
> > > (loop for a in '((a b) (0 1))
> > > for b in a
> > > collect (list a b)))
> > >
> > > and expected that it evaluates to '(((a b) a) ((0 1) b)) but all the
> > > implementations I tried return nil.
> > >
> > > Can somebody give a pointer to the place in the spec that explains why
> > > this should/could return nil?
> > >
> > > Helmut
> >
> > LOOP binds the variables in the FOR clauses in parallel before doing
> > anything else. It then evaluates all the IN clauses, again in parallel.
> > At that point, A is NIL. So B is looping over NIL.
> >
> > Try something like this:
> >
> > (let ((l '((a b) (0 1))))
> > (loop for a in l
> > for b in (car l)
> > collect (list a b)))
> >
> > rg

Instead of CL, tCL.

set lst {{a b} {0 1}}
lmap x $lst y [lindex $lst 0] {list $x $y}
==>
{{a b} a} {{0 1} b}

[WJ]

Pascal J. Bourguignon wrote:

> Helmut Eller <eller....@gmail.com> writes:
>
> > I tried this code:
> >
> > (let ((a '(x y)))
> > (loop for a in '((a b) (0 1))
> > for b in a
> > collect (list a b)))
> >
> > and expected that it evaluates to '(((a b) a) ((0 1) b)) but all the
> > implementations I tried return nil.
> >
> > Can somebody give a pointer to the place in the spec that explains why
> > this should/could return nil?
>

> http://www.lispworks.com/documentation/HyperSpec/Body/06_aba.htm
> http://www.lispworks.com/documentation/HyperSpec/Body/06_abb.htm
> http://www.lispworks.com/documentation/HyperSpec/Body/06_aaf.htm
>
> It returns NIL because A in the loop is initialized to NIL first. (It
> could be initialized to something else). The :for b :in a makes
> reference to that A, not the one in the outer scope.
>
>
> (let ((xy '(x y)))

> (loop for a in '((a b) (0 1))

> for b in xy
> collect (list a b)))
> --> (((a b) x) ((0 1) y))
>
>
>
> To get what you expected you must write it as:
>
> (let ((a '(x y)))
> (loop with as = '((a b) (0 1))
> for a in as
> for b in (car as)
> collect (list a b)))
> --> (((a b) a) ((0 1) b))

Instead of CL (COBOL-Like), let's use Lisp!

Gauche Scheme and Chicken Scheme:

(define as '((a b) (0 1)))

(map
(cut list <> <>)
as
(car as))

===>

(((a b) a) ((0 1) b))

For Racket, add this:

(require srfi/26)