I just finished watching Rich Hickey's presentation on his new Lisp
dialect and it provoked some thought in me. Being new to Lisp, I'm not
fully aware of all the choices that have evolved Lisp into what it is
today but as I learn it there are things that even PCL admits to being
archaic (cons cells and all the car/cdr fun).

To be poignant at the risk of sounding stupid, I thought Rich had some
great ideas.

I've been trying to mine through the group postings via google groups
but with little success besides the odd off-hand mention of Clojure.

So in order to quiet my confusion and keep myself on the path to true
Nirvana, I was hoping to illicit some feedback from the CL community
on some of the features of Clojure and whether they may ever find their
way into CL itself or some implementation thereof.

1. seqs -- Seems like a great idea. PCL suggests I should only ever
consider using first/last anyway so it seems only a natural extension
to me that CL would consider unifying all sequence types behind an
abstracted API.

I'm not asserting that this should happen, but I'm curious why it
hasn't or if there is a good reason not to.

2. Namespaces -- I'm just starting to grok packages which, to me, seem
like a bit of a headache. Rich mentioned in his talk that the package
system prevents CL from loading lisp source files without implementing
a reader in the application which prevents the interning of
symbols... okay...

Is this a big deal in the CL community or is there a justification for
packages that keeps them around?


I think those are the main points that caught my interest in Clojure.
The concurrency stuff looks nice and neat, but isn't really all that
important to me at this point (though feel free to discuss it if you
feel it's an impportant idea to consider).

I'm trying to stay focused on learning pure CL before I worry about
different implementations... however, Clojure seems to offer some
fundamental differences that appear to someone new to Lisp as being
rather "cool." Any assistance in clearing the air would be greatly
appreciated. :)

J Kenneth King wrote:
> I just finished watching Rich Hickey's presentation on his new Lisp
> dialect and it provoked some thought in me. Being new to Lisp, I'm not
> fully aware of all the choices that have evolved Lisp into what it is
> today but as I learn it there are things that even PCL admits to being
> archaic (cons cells and all the car/cdr fun).

You misread. Or miswrote. The names are archaic (and we like them that
way), not the things themselves.

>
> To be poignant at the risk of sounding stupid, I thought Rich had some
> great ideas.
>
> I've been trying to mine through the group postings via google groups
> but with little success besides the odd off-hand mention of Clojure.
>
> So in order to quiet my confusion and keep myself on the path to true
> Nirvana, I was hoping to illicit some feedback from the CL community
> on some of the features of Clojure and whether they may ever find their
> way into CL itself or some implementation thereof.
>
> 1. seqs -- Seems like a great idea. PCL suggests I should only ever
> consider using first/last anyway so it seems only a natural extension
> to me that CL would consider unifying all sequence types behind an
> abstracted API.

Good lord, no. A linked list is not a vector.

>
> I'm not asserting that this should happen, but I'm curious why it
> hasn't or if there is a good reason not to.
>
> 2. Namespaces -- I'm just starting to grok packages which, to me, seem
> like a bit of a headache. Rich mentioned in his talk that the package
> system prevents CL from loading lisp source files without implementing
> a reader in the application which prevents the interning of
> symbols... okay...
>
> Is this a big deal in the CL community

no.

> or is there a justification for
> packages that keeps them around?

Big applications, where names would start to clash?

>> I think those are the main points that caught my interest in Clojure.
> The concurrency stuff looks nice and neat, but isn't really all that
> important to me at this point (though feel free to discuss it if you
> feel it's an impportant idea to consider).
>
> I'm trying to stay focused on learning pure CL before I worry about
> different implementations... however, Clojure seems to offer some
> fundamental differences that appear to someone new to Lisp as being
> rather "cool." Any assistance in clearing the air would be greatly
> appreciated. :)

Well, you are not the first person to like Clojure, if that helps.

I am not having any problems with CL, so I do not look around much.

kt

J Kenneth King <james> writes:

> I just finished watching Rich Hickey's presentation on his new Lisp
> dialect and it provoked some thought in me.

I watched that presentation recently too. I think Clojure has a lot of
neat stuff, but until I'm looking to do some concurrent programming or
want to be on the JVM, I don't think I'll mess with it. Though I am more
impressed by Clojure now than I was initially. Its generification of
sequences, its literal notation for vectors, hashes, and more, its (:key
hash-table) / (hash-table :key) syntax for lookups, the addition of
metadata, and other features are all pretty cool. But even taken all
together, they don't strike me as cause to migrate. And I have a nagging
feeling that I would miss some things (CLOS, conditions, CL's iteration
constructs, perhaps) if I did. Clojure may be killer for some
applications though, and I do hope I get an excuse to do a project in
it.

J Kenneth King wrote:
> I just finished watching Rich Hickey's presentation on his new Lisp
> dialect and it provoked some thought in me. Being new to Lisp, I'm not
> fully aware of all the choices that have evolved Lisp into what it is
> today but as I learn it there are things that even PCL admits to being
> archaic (cons cells and all the car/cdr fun).
>
> To be poignant at the risk of sounding stupid, I thought Rich had some
> great ideas.

He does.

> I've been trying to mine through the group postings via google groups
> but with little success besides the odd off-hand mention of Clojure.

So far, I thought Hans Hubner's summary was best:
http://netzhansa.blogspot.com/2008/1...g-clojure.html

> So in order to quiet my confusion and keep myself on the path to true
> Nirvana, I was hoping to illicit some feedback from the CL community
> on some of the features of Clojure and whether they may ever find their
> way into CL itself or some implementation thereof.
>
> 1. seqs -- Seems like a great idea. PCL suggests I should only ever
> consider using first/last anyway so it seems only a natural extension
> to me that CL would consider unifying all sequence types behind an
> abstracted API.

FSet is a CL approximation of Clojure's data structures. It doesn't
enjoy the tight integration with the reader; but it provides
"immutable" data structures in CL much as Clojure provides them in Java.

http://common-lisp.net/project/fset/



> 2. Namespaces -- I'm just starting to grok packages which, to me, seem
> like a bit of a headache. Rich mentioned in his talk that the package
> system prevents CL from loading lisp source files without implementing
> a reader in the application which prevents the interning of
> symbols... okay...
>
> Is this a big deal in the CL community or is there a justification for
> packages that keeps them around?

CL has a bunch of things that rely on each other, sometimes in a
haphazard manner; but they do work -- once you figure out what they do
and how to use them. While namespaces were developed for static
systems (e.g. C++ and Java), packages were developed for dynamic ones;
certain static behaviors like "use f() from one of my enclosing
namespaces" lose their luster when you recompile code and a different
f() gets used. I still think the inability to *purely* (i.e. without
function trampolines or reader macros) rename (or alias) a symbol is a
defect in CL.

As for Rich's note about packages and the reader: I consider that to
be a (hindsight) defect in the CL reader, not in packages per se. As
each symbol is parsed, the reader eagerly evaluates it, binding it to
symbols in the current package, creating new symbols as needed. This
is an old standard (affecting shell scripts, perl, BASIC, etc.) of
declaring variables upon first use, and it can be a pain in certain
situations. Thus Rich's comment. But this doesn't affect most
programs much at all.

This reader issue reminded me of one of Pitman's stories:
http://www.nhplace.com/kent/PS/Ambitious.html

The ideal reader might be easier to implement with immutable data
structures...


> I think those are the main points that caught my interest in Clojure.
> The concurrency stuff looks nice and neat, but isn't really all that
> important to me at this point (though feel free to discuss it if you
> feel it's an impportant idea to consider).

Java's concurrency work (e.g. JSR 133) distills many lessons. A major
one being "locks (mutexes) are bad -- atomic operations (e.g.
compare-and-swap) are better". Immutability makes structure sharing
easier, thus decreasing the cost of CAS operations (change the "head"
pointer to the current shallow copy of the old structure). This comes
through in Clojure as refs, commutes, etc.

- Daniel

A free lisp that works on windows with real multithreading. Everything
built in this direction. Persistent data structures all the way. That's
great. Language level STM and agents, concurrency is dead easy with this
language.

Sequences are great as well. Use the same api for cons cells, arrays,
name/value collections ... that's pretty cool.

Part of the gigantic CL library isn't there, and it's really missing.
Acces to the java library helps, but it's not quite the same, and a bit
ugly too. That provide a standard way to do gui which just plain works.
Lots of freely available libraries around too.

No reader macros.

Need to define a function before calling it. Or just its name, but still
that's not very friendly.

Namespaces, they do the job. The whole thing isn't as dynamic as CL but
it's very manageable. Multimethods are kind of cool, i still prefer CL
on this.

Documentation is skinny, a lot is missing, no examples, no central index.

All in all very well thought out, but not as deeply as CL.

Sacha

On Oct 7, 9:02 pm, D Herring <dherr> wrote:
> FSet is a CL approximation of Clojure's data structures.  It doesn't
> enjoy the tight integration with the reader; but it provides
> "immutable" data structures in CL much as Clojure provides them in Java.
>
> [..]

Thanks for the plug!! BTW I am diligently working on the 1.2 release
of FSet, which along with (koff koff) bug fixes and some new features
will finally have a proper tutorial.

Also -- your first sentence risks being misinterpreted as suggesting
that FSet was in some way inspired by Clojure, which is not the case.
FSet was very much inspired by Refine (hmm, I see there's no Wikipedia
page on Refine... must remedy that) which was in turn inspired by
SetL.

-- Scott

D Herring <dherring> writes:

> I still think the inability to *purely* (i.e. without
> function trampolines or reader macros) rename (or alias) a symbol is a
> defect in CL.

(define-symbol-macro new-name old-name)

(let ((old-name 42))
new-name)

--> 42

J Kenneth King wrote:
> I just finished watching Rich Hickey's presentation on his new Lisp
> dialect and it provoked some thought in me. Being new to Lisp, I'm not
> fully aware of all the choices that have evolved Lisp into what it is
> today but as I learn it there are things that even PCL admits to being
> archaic (cons cells and all the car/cdr fun).
>
> To be poignant at the risk of sounding stupid, I thought Rich had some
> great ideas.

Indeed, Clojure has a number of very good ideas. The multithreading
model seems especially well thought through. On the downsides, I am not
convinced that access to Java APIs works as smoothly as advertized,
because Java's multithreading follows a very different approach, and I
don't believe you can just blindly throw the two together.

Additionally, Clojure focuses on one paradigm only and neglects others -
it's mostly a purely functional language, and support for other
programming styles is quite limited, at least so far. Some may see this
as an advantage, some as a disadvantage. In that respect, Clojure is
closer to Scheme than to Common Lisp.

A new language with good support for parallel programming which is much
closer in spirit to Common Lisp is Fortress, except for that fact that
it's not a Lisp. ;)


Pascal

On Oct 8, 4:11 am, J Kenneth King <ja> wrote:
> I just finished watching Rich Hickey's presentation on his new Lisp
> dialect and it provoked some thought in me. Being new to Lisp, I'm not
> fully aware of all the choices that have evolved Lisp into what it is
> today but as I learn it there are things that even PCL admits to being
> archaic (cons cells and all the car/cdr fun).
Not at all.
>
> To be poignant at the risk of sounding stupid, I thought Rich had some
> great ideas.
Almost everybody has good ideas but the people will judge on the
complete product not some pieces.
>
> I've been trying to mine through the group postings via google groups
> but with little success besides the odd off-hand mention of Clojure.
>
> So in order to quiet my confusion and keep myself on the path to true
> Nirvana, I was hoping to illicit some feedback from the CL community
> on some of the features of Clojure and whether they may ever find their
> way into CL itself or some implementation thereof.

>
> 1. seqs -- Seems like a great idea. PCL suggests I should only ever
> consider using first/last anyway so it seems only a natural extension
> to me that CL would consider unifying all sequence types behind an
> abstracted API.
There are a tradeoffs. But it's actually easy to do it in cl. Make a
generic function and overload it for various containers.
Actually it ahs already been done in Gary Kings excellent cl-
containers http://common-lisp.net/project/cl-containers/ and Gary has
a far more firepower:
http://common-lisp.net/project/cl-co...containers.pdf


>
> I'm not asserting that this should happen, but I'm curious why it
> hasn't or if there is a good reason not to.
>
> 2. Namespaces -- I'm just starting to grok packages which, to me, seem
> like a bit of a headache. Rich mentioned in his talk that the package
> system prevents CL from loading lisp source files without implementing
> a reader in the application which prevents the interning of
> symbols... okay...
>
> Is this a big deal in the CL community or is there a justification for
> packages that keeps them around?
>
> I think those are the main points that caught my interest in Clojure.
> The concurrency stuff looks nice and neat, but isn't really all that
> important to me at this point (though feel free to discuss it if you
> feel it's an impportant idea to consider).
I found unmutable languages annoying at best, when I think of
something that in my model needs to be mutated I want it to mutate it
not jump through hoops because someone promised me a Nirvana if I keep
my code mutate free.
>
> I'm trying to stay focused on learning pure CL before I worry about
> different implementations...
Smart move
> however, Clojure seems to offer some
> fundamental differences that appear to someone new to Lisp as being
> rather "cool." Any assistance in clearing the air would be greatly
> appreciated. :)
As someone who's working on his own lisp-like language my advice to
learn cl first (or scheme if that's your thing), and learn it good
before you start criticizing it. It's a mature language with a lot
documentation, libraries and great community.
It's far from ideal, there a lot of things I don't like about it, but
all the languages have their problems, because every language designer
must make a compromises. It's up to you what kind of compromises would
you choose to accept. And don't worry to much about lack of something
in cl it's usually not a big deal, and has been solved someway. For
everything you get you pay with something else.


bobi
Ideal world is a left as an exercise for a reader.
pg

On Oct 8, 9:37 am, Pascal Costanza <p> wrote:
> J Kenneth King wrote:
>> Indeed, Clojure has a number of very good ideas. The multithreading
> model seems especially well thought through. On the downsides, I am not
> convinced that access to Java APIs works as smoothly as advertized,
> because Java's multithreading follows a very different approach, and I
> don't believe you can just blindly throw the two together.
>
> Additionally, Clojure focuses on one paradigm only and neglects others -
> it's mostly a purely functional language, and support for other
> programming styles is quite limited, at least so far. Some may see this
> as an advantage, some as a disadvantage. In that respect, Clojure is
> closer to Scheme than to Common Lisp.
>
> A new language with good support for parallel programming which is much
> closer in spirit to Common Lisp is Fortress, except for that fact that
> it's not a Lisp. ;)
Interesthing idea for queue of task but in what way it is close in
spirit to cl? No s-expression in the examples.

bobi
[..]

Slobodan Blazeski wrote:
> On Oct 8, 9:37 am, Pascal Costanza <p> wrote:
> Interesthing idea for queue of task but in what way it is close in
> spirit to cl? No s-expression in the examples.

It's multiparadigm, has a library-provider API which makes the language
extensible, and provides syntactic extensibility (in a very weird way,
but nonetheless...)

It's also strongly influenced by some of the 'historical' extensions for
Common Lisp for parallel programming, like Connection Machine Lisp,
StarLisp and Paralation Lisp.


Pascal

On Oct 8, 2:32 pm, Pascal Costanza <p> wrote:
> >> A new language with good support for parallel programming which is much
> >> closer in spirit to Common Lisp is Fortress, except for that fact that
> >> it's not a Lisp. ;)
> > Interesthing idea for queue of task but in what way it is close in
> > spirit to cl?  No s-expression in the examples.
>
> It's multiparadigm, has a library-provider API which makes the language
> extensible, and provides syntactic extensibility (in a very weird way,
> but nonetheless...)
>
> It's also strongly influenced by some of the 'historical' extensions for
> Common Lisp for parallel programming, like Connection Machine Lisp,
> StarLisp and Paralation Lisp.

Ok. Just a theoretical question. If the language is based on s-
expressions is it necessarily lisp?
For example what if Prolog decides to change into something like:
(deffact Father (john tim))
(deffact Father (tim marc))

>(Father john tim)
t

>(Father tim X)
marc

(defrule GrandFather (X Y)
(father X Z)
(father Z y))

(GrandFather john X)
marc

Is the new language lisp or prolog?

bobi
[..]

Slobodan Blazeski wrote:
[..]
> marc
>
> (defrule GrandFather (X Y)
> (father X Z)
> (father Z y))
>
> (GrandFather john X)
> marc
>
> Is the new language lisp or prolog?

Can you treat programs as data?


Pascal

På Wed, 08 Oct 2008 15:12:04 +0200, skrev Pascal Costanza <pc>:

>
> Can you treat programs as data?
>> Pascal
>

Or more succinctly "Are functions first order objects?"

--------------
John Thingstad

Slobodan Blazeski <slobodan.blazeski> writes:
> Ok. Just a theoretical question. If the language is based on s-
> expressions is it necessarily lisp?
> For example what if Prolog decides to change into something like:
> (deffact Father (john tim))
> (deffact Father (tim marc))
>
> t
>
> marc
>
> (defrule GrandFather (X Y)
> (father X Z)
> (father Z y))
>
> (GrandFather john X)
> marc
>
> Is the new language lisp or prolog?

If it has sexps and macros (in addition to first order functions), you
could call it a lisp.


Just having sexps is nice to be able to process it with lisp, but if
it has no macros, it cannot be processed in itself easily.