Dear all -
Is there any package that provides (or plans to provide) a general
interface to threaded or similar parallel-execution technologies (user
space message passing or user-space shared-mem) with the generality
being across the "free" lisps (I'd include things like the personal
editions from commercial vendors, since I'd like to be able to check
these as needed)?
My current guess is that bordeaux-threads would be the best starting
point, but is anyone aware of a currently maintained package which
might be relevant in particular for multicore architectures? (it
looks like it's been dormant for a bit).
Any pointers welcome!
On Apr 22, 10:42 am, AJ Rossini <··········@gmail.com> wrote:
> Dear all -
>
> Is there any package that provides (or plans to provide) a general
> interface to threaded or similar parallel-execution technologies (user
> space message passing or user-space shared-mem) with the generality
> being across the "free" lisps (I'd include things like the personal
> editions from commercial vendors, since I'd like to be able to check
> these as needed)?
>
> My current guess is that bordeaux-threads would be the best starting
> point, but is anyone aware of a currently maintained package which
> might be relevant in particular for multicore architectures?
> (it looks like it's been dormant for a bit).
bordeaux-threads is alive. People don't bother releasing stuff as
often anymore so try getting it from darcs (or via clbuild) if you
need a newer version.
It provides the basic stuff;
* creation of threads
* lock/mutex .. normal and recursive
* wait-conditions
* a with-timeout facility
Adding support for some of the missing things like, say, semaphores
should be trivial.
On Apr 22, 12:37 pm, Lars Rune Nøstdal <···········@gmail.com> wrote:
> On Apr 22, 10:42 am, AJ Rossini <··········@gmail.com> wrote:
>
> > Dear all -
>
> > Is there any package that provides (or plans to provide) a general
> > interface to threaded or similar parallel-execution technologies (user
> > space message passing or user-space shared-mem) with the generality
> > being across the "free" lisps (I'd include things like the personal
> > editions from commercial vendors, since I'd like to be able to check
> > these as needed)?
>
> > My current guess is that bordeaux-threads would be the best starting
> > point, but is anyone aware of a currently maintained package which
> > might be relevant in particular for multicore architectures?
> > (it looks like it's been dormant for a bit).
>
> bordeaux-threads is alive. People don't bother releasing stuff as
> often anymore so try getting it from darcs (or via clbuild) if you
> need a newer version.
>
> It provides the basic stuff;
>
> * creation of threads
> * lock/mutex .. normal and recursive
> * wait-conditions
> * a with-timeout facility
>
> Adding support for some of the missing things like, say, semaphores
> should be trivial.
..and perhaps stuff like sb-ext:compare-and-swap and sb-ext:atomic-
incf also. These are from SBCL, but other Lisps might provide similar
things (with similar names).
For higher-level(?) stuff I'm working on "memory-transactions" (SW-
STM), and, stuff:
http://common-lisp.net/~lnostdal/ (no source yet)
From: Madhu
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <m3mya9ne7b.fsf@moon.robolove.meer.net>
* Lars Rune Nøstdal
Wrote on Wed, 22 Apr 2009 03:37:46 -0700 (PDT):
| On Apr 22, 10:42 am, AJ Rossini <·······@·····························@gmail.com> wrote:
|>
|> Is there any package that provides (or plans to provide) a general
|> interface to threaded or similar parallel-execution technologies (user
|> space message passing or user-space shared-mem) with the generality
|> being across the "free" lisps (I'd include things like the personal
|> editions from commercial vendors, since I'd like to be able to check
|> these as needed)?
There is GBBOpen's (IMO) more mature API for Portable Threads, which API
I'd recommend Bordeaux threads
<URL:http://gbbopen.org/hyperdoc/ref-portable-thread-entities.html>
The source is here:
http://gbbopen.org/svn/GBBopen/trunk/source/tools/portable-threads.lisp
|> My current guess is that bordeaux-threads would be the best starting
|> point, but is anyone aware of a currently maintained package which
|> might be relevant in particular for multicore architectures? (it
|> looks like it's been dormant for a bit).
|
| bordeaux-threads is alive. People don't bother releasing stuff as
| often anymore so try getting it from darcs (or via clbuild) if you
| need a newer version.
|
| It provides the basic stuff;
|
| * creation of threads
| * lock/mutex .. normal and recursive
| * wait-conditions
| * a with-timeout facility
|
| Adding support for some of the missing things like, say, semaphores
| should be trivial.
This is not a selling point. Adding support for the some of the "basic
stuff" that you noted above is also trivial giving the multiprocessing
primitives.
--
Madhu
On Apr 22, 1:02 pm, Madhu <·······@meer.net> wrote:
> * Lars Rune Nøstdal
> Wrote on Wed, 22 Apr 2009 03:37:46 -0700 (PDT):
>
> | On Apr 22, 10:42 am, AJ Rossini <·······@·····························@gmail.com> wrote:
> |>
> |> Is there any package that provides (or plans to provide) a general
> |> interface to threaded or similar parallel-execution technologies (user
> |> space message passing or user-space shared-mem) with the generality
> |> being across the "free" lisps (I'd include things like the personal
> |> editions from commercial vendors, since I'd like to be able to check
> |> these as needed)?
>
> There is GBBOpen's (IMO) more mature API for Portable Threads, which API
> I'd recommend Bordeaux threads
>
> <URL:http://gbbopen.org/hyperdoc/ref-portable-thread-entities.html>
>
> The source is here:http://gbbopen.org/svn/GBBopen/trunk/source/tools/portable-threads.lisp
>
> |> My current guess is that bordeaux-threads would be the best starting
> |> point, but is anyone aware of a currently maintained package which
> |> might be relevant in particular for multicore architectures? (it
> |> looks like it's been dormant for a bit).
> |
> | bordeaux-threads is alive. People don't bother releasing stuff as
> | often anymore so try getting it from darcs (or via clbuild) if you
> | need a newer version.
> |
> | It provides the basic stuff;
> |
> | * creation of threads
> | * lock/mutex .. normal and recursive
> | * wait-conditions
> | * a with-timeout facility
> |
> | Adding support for some of the missing things like, say, semaphores
> | should be trivial.
>
> This is not a selling point. Adding support for the some of the "basic
> stuff" that you noted above is also trivial giving the multiprocessing
> primitives.
>
> --
> Madhu
Maybe it would work as a "starting point" (to quote the OP).
PS: Tits or GTFO.
On Apr 22, 1:02 pm, Madhu <·······@meer.net> wrote:
> * Lars Rune Nøstdal
> Wrote on Wed, 22 Apr 2009 03:37:46 -0700 (PDT):
>
> | On Apr 22, 10:42 am, AJ Rossini <·······@·····························@gmail.com> wrote:
> |>
> |> Is there any package that provides (or plans to provide) a general
> |> interface to threaded or similar parallel-execution technologies (user
> |> space message passing or user-space shared-mem) with the generality
> |> being across the "free" lisps (I'd include things like the personal
> |> editions from commercial vendors, since I'd like to be able to check
> |> these as needed)?
>
> There is GBBOpen's (IMO) more mature API for Portable Threads, which API
> I'd recommend Bordeaux threads
>
> <URL:http://gbbopen.org/hyperdoc/ref-portable-thread-entities.html>
>
> The source is here:http://gbbopen.org/svn/GBBopen/trunk/source/tools/portable-threads.lisp
>
> |> My current guess is that bordeaux-threads would be the best starting
> |> point, but is anyone aware of a currently maintained package which
> |> might be relevant in particular for multicore architectures? (it
> |> looks like it's been dormant for a bit).
> |
> | bordeaux-threads is alive. People don't bother releasing stuff as
> | often anymore so try getting it from darcs (or via clbuild) if you
> | need a newer version.
> |
> | It provides the basic stuff;
> |
> | * creation of threads
> | * lock/mutex .. normal and recursive
> | * wait-conditions
> | * a with-timeout facility
> |
> | Adding support for some of the missing things like, say, semaphores
> | should be trivial.
>
> This is not a selling point. Adding support for the some of the "basic
> stuff" that you noted above is also trivial giving the multiprocessing
> primitives.
>
> --
> Madhu
Thanks all -- will review a darcs pull of bordeaux and Madhu's
suggestions.
From: André Thieme
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <gsmsn5$aqo$1@news.motzarella.org>
AJ Rossini schrieb:
> Dear all -
>
> Is there any package that provides (or plans to provide) a general
> interface to threaded or similar parallel-execution technologies (user
> space message passing or user-space shared-mem) with the generality
> being across the "free" lisps (I'd include things like the personal
> editions from commercial vendors, since I'd like to be able to check
> these as needed)?
>
> My current guess is that bordeaux-threads would be the best starting
> point, but is anyone aware of a currently maintained package which
> might be relevant in particular for multicore architectures? (it
> looks like it's been dormant for a bit).
>
> Any pointers welcome!
You mention bordeaux-threads, so mabye you are specifically interested
in CL.
If a different Lisp dialect would be okay then have a look at Clojure.
Currently it's your best bet for writing concurrent applications.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On Apr 22, 12:49 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> AJ Rossini schrieb:
>
> > Dear all -
>
> > Is there any package that provides (or plans to provide) a general
> > interface to threaded or similar parallel-execution technologies (user
> > space message passing or user-space shared-mem) with the generality
> > being across the "free" lisps (I'd include things like the personal
> > editions from commercial vendors, since I'd like to be able to check
> > these as needed)?
>
> > My current guess is that bordeaux-threads would be the best starting
> > point, but is anyone aware of a currently maintained package which
> > might be relevant in particular for multicore architectures? (it
> > looks like it's been dormant for a bit).
>
> > Any pointers welcome!
>
> You mention bordeaux-threads, so mabye you are specifically interested
> in CL.
> If a different Lisp dialect would be okay then have a look at Clojure.
> Currently it's your best bet for writing concurrent applications.
>
> André
> --
> Lisp is not dead. It’s just the URL that has changed:http://clojure.org/
Unfortunately, I'm (unrationally, so don't even think of a rational
argument) in love with common lisp these days. I'll be burned alive
at a stake before developing in any other language (though to be fair,
I'm a manager/pointy-headed-boss at work, so get somewhat of a final
say as to what I do when I develop code, and I'm telling a bit of a
white lie, since I'm a statistician/biomedical informaticist, and will
analyse data in R or Python).
From: André Thieme
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <gsn3tm$7g6$1@news.motzarella.org>
AJ Rossini schrieb:
> Unfortunately, I'm (unrationally, so don't even think of a rational
> argument) in love with common lisp these days.
Why unfortunately? It is a very understandable love :)
CL is a nice language and one can get serious work done in it.
You should however keep an open mind for the commercial implementations.
> I'll be burned alive
> at a stake before developing in any other language (though to be fair,
> I'm a manager/pointy-headed-boss at work, so get somewhat of a final
> say as to what I do when I develop code, and I'm telling a bit of a
> white lie, since I'm a statistician/biomedical informaticist, and will
> analyse data in R or Python).
R is a great tool for that, I used it myself for some week. In its
domain it is a very good choice.
If your main interest is in CLOS, then Clojure has not so much to offer
for you. But it may not hurt to play with it for some days. One can
recycle CL knowledge to some extent to get started. And until the
commercial CLs come up with their own STM Clojure is the best choice for
solving tasks involving concurrency. It comes directly with concurrency
ready data structures, and btw: Clojure also supports Terracotta.
Terracotta allows you to kill your database - it's close to implicit
persistency. Also its trivial to cluster applications with it and CL has
no equivalent for that.
Anyway, risk a look into the personal Editions of Lispworks and Allegro.
Very well worth it! And if you want to use it for your business then
both vendors offer a great start to dive into their commercial versions.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On Apr 22, 8:52 am, André Thieme <address.good.until.
···········@justmail.de> wrote:
> If your main interest is in CLOS, then Clojure has not so much to offer
> for you.
This is true of clojure as a base language, but being a lisp, clojure
can be turned to your clos-loving needs. In fact, Mikel Evins has
written a nice system that is in many ways a superset of clos. It
allows you to define your own generic function domains (he includes a
java class domain and a predicate dispatch domain in his examples).
checkout instructions:
<http://code.google.com/p/explorersguild/source/checkout>
subproject you want:
<http://explorersguild.googlecode.com/svn/trunk/software/src/clj/com>
load in order:
util.clj
gf.clj
model.clj
model_gf.clj
also useful:
<http://explorersguild.googlecode.com/svn/trunk/software/src/clj/
defsystem.clj>
<http://explorersguild.googlecode.com/svn/trunk/software/src/clj/
xg.clj>
On Apr 22, 2:52 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> AJ Rossini schrieb:
> Anyway, risk a look into the personal Editions of Lispworks and Allegro.
> Very well worth it! And if you want to use it for your business then
> both vendors offer a great start to dive into their commercial versions.
As mentioned, it's a major requirement -- some of the people I'm
targetting will need it (as will I, if I can bring this project "in-
house").
With respect with R, I helped develop some of the seminal packages for
interactive parallel computing with it about 9 years ago (along with
visualization toolkits, and interactive scalable virtual reality
driver, and an Emacs based IDE), so it'll never leave me.
But these days, it's common lisp.
(and the query was related to seeing a newish R package, multicore,
which seems to provide the equivalent of bordeaux-threads).
From: Madhu
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <m3iqkxne4a.fsf@moon.robolove.meer.net>
* André Thieme <············@news.motzarella.org> :
Wrote on Wed, 22 Apr 2009 12:49:08 +0200:
| You mention bordeaux-threads, so mabye you are specifically interested
| in CL. If a different Lisp dialect would be okay then have a look at
| Clojure. Currently it's your best bet for writing concurrent
| applications.
This is unsolicited and false advertising. Just because you claim it
doesnt make it so.
--
Madhu
On Apr 22, 1:04 pm, Madhu <·······@meer.net> wrote:
> * André Thieme <············@news.motzarella.org> :
> Wrote on Wed, 22 Apr 2009 12:49:08 +0200:
>
> | You mention bordeaux-threads, so mabye you are specifically interested
> | in CL. If a different Lisp dialect would be okay then have a look at
> | Clojure. Currently it's your best bet for writing concurrent
> | applications.
>
> This is unsolicited and false advertising. Just because you claim it
> doesnt make it so.
>
> --
> Madhu
..and just because you claim it not so does not make it so, either.
PS: Tits or GTFO.
From: Madhu
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <m3eivlndrc.fsf@moon.robolove.meer.net>
* Lars Rune Nøstdal writes
|> This is unsolicited and false advertising. Just because you claim it
|> doesnt make it so.
|
| ..and just because you claim it not so does not make it so, either.
|
| PS: Tits or GTFO.
Your solidarity with your fellow trolls/spammers is indeed touching.
--
Madhu
From: namekuseijin
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <gso5m6$fb6$1@adenine.netfront.net>
Madhu escreveu:
> * Lars Rune Nøstdal writes
>
> |> This is unsolicited and false advertising. Just because you claim it
> |> doesnt make it so.
> |
> | ..and just because you claim it not so does not make it so, either.
> |
> | PS: Tits or GTFO.
>
> Your solidarity with your fellow trolls/spammers is indeed touching.
Perhaps we should leave c.l.l to the old farts with their heads well
into their CL and move over to specific newsgroups of implementations of
Lisp dialects. The Lisp community was always fragmented anyway...
--
a game sig: http://tinyurl.com/d3rxz9
From: =?UTF-8?B?QW5kcsOpIFRoaWVtZQ==?=
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <gsn2vr$vms$1@news.motzarella.org>
Madhu schrieb:
> * André Thieme <············@news.motzarella.org> :
> Wrote on Wed, 22 Apr 2009 12:49:08 +0200:
>
> | You mention bordeaux-threads, so mabye you are specifically interested
> | in CL. If a different Lisp dialect would be okay then have a look at
> | Clojure. Currently it's your best bet for writing concurrent
> | applications.
>
> This is unsolicited and false advertising. Just because you claim it
> doesnt make it so.
You are wrong. I have experienced it myself, so I can do my statements
with pure conscience.
After doing CL for six years and Clojure for about half a year I have
enough experience to come to my conclusions.
I am still not convinced that you wrote anything mentionable in Clojure.
So obviously I can not take your provoking and trollish comments serious
in any way.
André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/
From: Madhu
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <m37i1colgv.fsf@moon.robolove.meer.net>
* André Thieme <············@news.motzarella.org> :
Wrote on Wed, 22 Apr 2009 14:36:09 +0200:
|> This is unsolicited and false advertising. Just because you claim it
|> doesnt make it so.
|
| You are wrong. I have experienced it myself, so I can do my statements
| with pure conscience. After doing CL for six years and Clojure for
| about half a year I have enough experience to come to my conclusions.
| I am still not convinced that you wrote anything mentionable in
| Clojure. So obviously I can not take your provoking and trollish
| comments serious in any way.
I'll take your bait just this once because I'm sick and tired of your
java posts on this lisp news group and I suspect others are weary too.
I suspect you never wrote anything mentionable in Common Lisp.
You come across as a java programmer who had never understood what
common lisp was about, or had the skills to use its capabilities. In all
likelihood you programmed JAVA in Common Lisp for 6 years. From that
point of view I can understand your enthuiasm for Clojure, because it is
closer to your wavelength.
If you are looking for a language designed for concurrency there is
Erlang, and concurrent estrel etc. which are arguably better tools than
clojure. However it is indeed likely that for less than average
programmers clojure is indeed the best bet for concurrent programming
because its creator is obviously a very clever guy, etc. But I've been
exposed to the concurrency/distributed research and market since 1993
(when I first tried distributing computation using PVM) and from that
perspective clojure is but one more in that series which bets on certain
aspects of technology (and its target audience.)
Myself, I'm glad I stopped having to deal with java some than 5-6 years
ago, for good. This means avoiding the JVM technology as well as
avoiding the JAVA ECOSYSTEM. All Clojure wants is part of that
ecosystem, I have no intention of jumping back by downloading a JVM to
run Clojure.
So while I can relate to your enthusiasm for clojure I cannot understand
your constant efforts at marketing it on this newsgroup. Do you get
paid per new convert fresh adopter (like the HR dweebs in the last java
job I had would get 1K USD per every new java drone they recruited)
--
Madhu
On Apr 22, 6:40 am, Madhu <·······@meer.net> wrote:
> * André Thieme <············@news.motzarella.org> :
> Wrote on Wed, 22 Apr 2009 14:36:09 +0200:
>
> |> This is unsolicited and false advertising. Just because you claim it
> |> doesnt make it so.
> |
> | You are wrong. I have experienced it myself, so I can do my statements
> | with pure conscience. After doing CL for six years and Clojure for
> | about half a year I have enough experience to come to my conclusions.
> | I am still not convinced that you wrote anything mentionable in
> | Clojure. So obviously I can not take your provoking and trollish
> | comments serious in any way.
>
> I'll take your bait just this once because I'm sick and tired of your
> java posts on this lisp news group and I suspect others are weary too.
>
> I suspect you never wrote anything mentionable in Common Lisp.
>
> You come across as a java programmer who had never understood what
> common lisp was about, or had the skills to use its capabilities. In all
> likelihood you programmed JAVA in Common Lisp for 6 years. From that
> point of view I can understand your enthuiasm for Clojure, because it is
> closer to your wavelength.
I've watched this argument for weeks prior to ILC09, and now I'm
watching it again, and I must say I have a different perspective now.
I purposefully went to Rich Hickey's Clojure tutorial specifically
because of this argument, because I wanted to see what all the fuss
was about, straight from the horse's mouth. Note that the product my
company offers might be considered to be in competition with Clojure,
so I doubt anyone can accuse me of marketing for Clojure.
The tutorial was 6 hours long. I went up and asked question s during
breaks. Some conclusions I came to by the time the day was done were:
1. Clojure is definitely a Lisp. Clojure has all the feel of a Lisp,
though it definitely has more syntax than CL or Scheme.
2. Clojure is definitely not Common Lisp. The "CL" in Clojure may
have some meaning, and Rich Hickey is definitely influenced in part by
Conmmon Lisp, but Clojure is definitely not CL.
3. Clojure is not Java. The "j" in Clojure may have some meaning in
part of Clojure's roots, but as Hickey himself told us in the class,
his first port was not to the JVM, but to CLR. Also, his goal (and
there are efforts underway) is to port again to CLR and to any other
virtual machine for which it makes sense to port. The point of the
language is not the target virtual machine, but the language itself.
4. Most of the departures from traditional lisp systems in Clojure are
geared toward concurrency, from what I saw.
5. (this actually relates more to #1, above): Rich Hickey is now a
member of the ALU (Association of Lisp Users) board and is active in
promoting Lisp.
Duane
From: Madhu
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <m3mya8mfdt.fsf@moon.robolove.meer.net>
* ·····@franz.com Wrote on Wed, 22 Apr 2009 09:11:48 -0700 (PDT):
Thanks for the perspective. From where I sit (without any stakes) my
perspective is still different,
| 1. Clojure is definitely a Lisp. Clojure has all the feel of a Lisp,
| though it definitely has more syntax than CL or Scheme.
It is a lisp implemented in Java, rather than being a lisp which is
implemented in itself or another lisp. Once you start going deeper,
beyond the syntax, you'll see it lacks lisp nature, and instead you'll
see java backtraces.
| 2. Clojure is definitely not Common Lisp. The "CL" in Clojure may
| have some meaning, and Rich Hickey is definitely influenced in part by
| Conmmon Lisp, but Clojure is definitely not CL.
|
| 3. Clojure is not Java. The "j" in Clojure may have some meaning in
| part of Clojure's roots, but as Hickey himself told us in the class,
| his first port was not to the JVM, but to CLR. Also, his goal (and
| there are efforts underway) is to port again to CLR and to any other
| virtual machine for which it makes sense to port. The point of the
| language is not the target virtual machine, but the language itself.
|
| 4. Most of the departures from traditional lisp systems in Clojure are
| geared toward concurrency, from what I saw.
But the JVM/CLR is very relevant. The language centers itself around
certain key datastructures which permit concurrency. These
datastructures could have been implemented in any lisp. However there
would have been no mileage from this unless the developer market is
going to use this, and the best way to get that outcome is to design a
more restrictive language designed around those datastructures.
I see more social engineering in this language's design than any
technical merit. Again this reeks more of java's design decisions than
the design in any lisp i've seen.
For someone who is not a blank-slate fresh adopter or who did not drink
the kool aid at the training camps, this is not a novelty
| 5. (this actually relates more to #1, above): Rich Hickey is now a
| member of the ALU (Association of Lisp Users) board and is active in
| promoting Lisp.
Rich Hickey is obviously a very smart and clever guy. I wouldn't be
surprised if he got the lisp vendors into selling clj in the future :)
--
Madhu
On Apr 22, 4:34 pm, Madhu <·······@meer.net> wrote:
> * ·····@franz.com Wrote on Wed, 22 Apr 2009 09:11:48 -0700 (PDT):
>
> Thanks for the perspective. From where I sit (without any stakes) my
> perspective is still different,
You're welcome. And as for my perspective, my stakes might actually
be considered "anti-stakes", since our product would tend to be a
competitor with Clojure.
> | 1. Clojure is definitely a Lisp. Clojure has all the feel of a Lisp,
> | though it definitely has more syntax than CL or Scheme.
>
> It is a lisp implemented in Java, rather than being a lisp which is
> implemented in itself or another lisp. Once you start going deeper,
> beyond the syntax, you'll see it lacks lisp nature, and instead you'll
> see java backtraces.
By that logic, Allegro CL isn't really a CL, because when you get down
to the disassembler, you see x86-64 instructions (or x86, or sparc,
or ...) - if you run our lisp under gdb, dbx, or windbg, you get what
looks very little like lisp and a lot like the underlying architecture
of the machine. And we even try to conform to binary runtime
specifications where possible; it is always a good goal to have a
compiler's targeted object code be interoperable with other languages.
Again, I'm going by what was told to me, and RH presents a very
consistent story; his goal as he states it is to use the features of
whatever underlying virtual machine he is compiling to, whether it be
JVM, CLR, or any other such VM. Things he uses from the underlying VM
are object systems and garbage-collectors, but he provides the
compiler. I asked him about Clojure-written-in-Clojure, and he did
say that they weren't there yet, but that that was indeed a goal of
his and he had some people working on self-hosting the compiler.
> | 2. Clojure is definitely not Common Lisp. The "CL" in Clojure may
> | have some meaning, and Rich Hickey is definitely influenced in part by
> | Conmmon Lisp, but Clojure is definitely not CL.
> |
> | 3. Clojure is not Java. The "j" in Clojure may have some meaning in
> | part of Clojure's roots, but as Hickey himself told us in the class,
> | his first port was not to the JVM, but to CLR. Also, his goal (and
> | there are efforts underway) is to port again to CLR and to any other
> | virtual machine for which it makes sense to port. The point of the
> | language is not the target virtual machine, but the language itself.
> |
> | 4. Most of the departures from traditional lisp systems in Clojure are
> | geared toward concurrency, from what I saw.
>
> But the JVM/CLR is very relevant. The language centers itself around
> certain key datastructures which permit concurrency. These
> datastructures could have been implemented in any lisp. However there
> would have been no mileage from this unless the developer market is
> going to use this, and the best way to get that outcome is to design a
> more restrictive language designed around those datastructures.
Of course. As I see it, that is what he has done.
> I see more social engineering in this language's design than any
> technical merit. Again this reeks more of java's design decisions than
> the design in any lisp i've seen.
I guess we're two blind Indians examining the same elephant and coming
to different conclusions [1]. You see a lot of Java design
decisions. I see a lot of CL influence.
> For someone who is not a blank-slate fresh adopter or who did not drink
> the kool aid at the training camps, this is not a novelty
Well, we'll see how it turns out, won't we?
> | 5. (this actually relates more to #1, above): Rich Hickey is now a
> | member of the ALU (Association of Lisp Users) board and is active in
> | promoting Lisp.
>
> Rich Hickey is obviously a very smart and clever guy. I wouldn't be
> surprised if he got the lisp vendors into selling clj in the future :)
CLJ? You mean JIL? (http://www.franz.com/support/documentation/
current/doc/jil.htm)
Or do you mean jlinker? (http://www.franz.com/support/documentation/
current/doc/jlinker.htm)
Perhaps I know what you really mean, based on your perspective, and
no, it's not likely for us. We already have connectivity to Java and
to the JVM, and of course I'm just speculating, but if we do anything
with Clojure, it would likely be to provide or encourage a Clojure
client for our Agraph triple-store (the server is written in CL, and
we have CL, Java, Python, and C# clients), so a Clojure client isn't
far-fetched, though I don't think there are any plans right now. But
since Clojure is so Java oriented, perhaps it would Just Work (tm) as
a Java client, or so CLR-oriented it would Just Work (tm) as a C#
client.
[1] As the parable goes, five blind Indians encountered an elephant
and tried to describe it to each other. They ended up fighting over
what the elephant looked like, because the one who felt its tail
thought it was very much like a rope; the one who felt its leg thought
it was like a tree trunk; the one who felt its ear thought it was like
a canvas, the one who felt its trunk thought it was like a huge snake,
and the one who felt it side thought it was like a wall. But in
reality, they were all wrong, because it was the same elephant and had
all of the characteristics described.
Duane
On Apr 23, 3:50 am, ·····@franz.com wrote:
> You're welcome. And as for my perspective, my stakes might actually
> be considered "anti-stakes", since our product would tend to be a
> competitor with Clojure.
Or you could just be hedging your bets. If the jvm ecosystem continues
to grow it would be foolish for lisp companies not to leverage their
lisp expertise via some sort of clojure offerings, be they training,
consulting, add-ons, etc.
> if we do anything
> with Clojure, it would likely be to provide or encourage a Clojure
> client for our Agraph triple-store (the server is written in CL, and
> we have CL, Java, Python, and C# clients), so a Clojure client isn't
> far-fetched, though I don't think there are any plans right now.
for example.
> Again, I'm going by what was told to me, and RH presents a very
> consistent story; his goal as he states it is to use the features of
> whatever underlying virtual machine he is compiling to, whether it be
> JVM, CLR, or any other such VM. Things he uses from the underlying VM
> are object systems and garbage-collectors, but he provides the
> compiler.
But we have it from Rich Hickey himself that clojure doesn't do tail
call optimization because the JVM doesn't support it. That's a pretty
big language design decision to be dictated by the underlying VM, so
the claim that clojure is somehow "neutral" is really not believable.
Clojure is an attempt to mold lisp the the very specific contours of
the JVM to enable seamless integration with existing Java libraries.
One can only conclude that clojure is an attempt to leverage the mind-
share of the java/JVM ecosystem, not a VM neutral lisp.
On Apr 23, 7:15 am, Raffael Cavallaro <················@gmail.com>
wrote:
> On Apr 23, 3:50 am, ·····@franz.com wrote:
>
> > You're welcome. And as for my perspective, my stakes might actually
> > be considered "anti-stakes", since our product would tend to be a
> > competitor with Clojure.
>
> Or you could just be hedging your bets. If the jvm ecosystem continues
> to grow it would be foolish for lisp companies not to leverage their
> lisp expertise via some sort of clojure offerings, be they training,
> consulting, add-ons, etc.
Whenever it comes to interoperability, we are aggressive in that
area. When it comes to diluting the language experience, we are a lot
more careful with that. When Apple was looking to sell off the Dylan
effort in 1995, we looked at it carefully before we rejected it, for
simple business reasons; there was still a lot of work to do before it
would become viable as a product. By contrast, the prolog compiler we
enhanced from Norvig's PAIP was not hard to justify, because it
complements CL in its declarative style, and because it is in fact
completely written in Allegro CL. We make such decisions constantly,
but it always fits within a model of what we are out to do.
> > if we do anything
> > with Clojure, it would likely be to provide or encourage a Clojure
> > client for our Agraph triple-store (the server is written in CL, and
> > we have CL, Java, Python, and C# clients), so a Clojure client isn't
> > far-fetched, though I don't think there are any plans right now.
>
> for example.
Yes, an interoperability example. Pretty much a no-brainer.
> > Again, I'm going by what was told to me, and RH presents a very
> > consistent story; his goal as he states it is to use the features of
> > whatever underlying virtual machine he is compiling to, whether it be
> > JVM, CLR, or any other such VM. Things he uses from the underlying VM
> > are object systems and garbage-collectors, but he provides the
> > compiler.
>
> But we have it from Rich Hickey himself that clojure doesn't do tail
> call optimization because the JVM doesn't support it. That's a pretty
> big language design decision to be dictated by the underlying VM, so
> the claim that clojure is somehow "neutral" is really not believable.
It's interesting that you bring up tail merging as an example of how
Clojure differs from CL... CL doesn't have tail-merging, only many of
its implementations do. In Allegro CL, our eval function does not do
tail merging either. How does that affect our interpreter's
neutrality?
> Clojure is an attempt to mold lisp the the very specific contours of
> the JVM to enable seamless integration with existing Java libraries.
> One can only conclude that clojure is an attempt to leverage the mind-
> share of the java/JVM ecosystem, not a VM neutral lisp.
Obviously so. The trouble with taking this argument to the conclusion
that Clojure is a Java, is that it was originally written for CLR, and
thus a more palatable argument would be that Clojure is a C#. You
might argue that it has taken on more and more characteristics of Java
as its time on the JVM has increased, and that is of course an issue
that the implementors must address.
My whole take on Clojure is based on one six-hour session (actually,
three two-hour sessions) with the author, so you must take what I say
from that context, and throw out what I say that you don't believe. I
can assure you, that I have no ulterior motive here, other than
stating what I believe to be facts. I also consider myself to be a
fair judge of character, and although it could be that RH was lying
through his teeth at that tutorial and telling us what we wanted to
hear, I didn't see any sign of that; his story was consistent, well
thought out, and as one of at least 80 to 100 lispers in the audience,
all of whom were skeptical and who tossed very lisp-specific questions
during those sessions, I can say that he had good answers for most of
the questions, and quite often as he was describing the history he
stated how he had made his decision based on what Common Lisp does,
because he liked what CL does.
I would ask other Lispers who were in that tutorial to speak up to
verify my story, but I actually won't do that because of the grief I'm
getting here; if I who am a self-professed competitor can't speak up
without my motivations being questioned, how can I ask other lisp
users to speak up in this situation? (and no, Raffael, I'm not saying
that you are giving me grief, here, but others might perceive it to be
the case)
Duane
On Apr 23, 1:23 pm, ·····@franz.com wrote:
> It's interesting that you bring up tail merging as an example of how
> Clojure differs from CL... CL doesn't have tail-merging, only many of
> its implementations do. In Allegro CL, our eval function does not do
> tail merging either. How does that affect our interpreter's
> neutrality?
But Rich Hickey has said that he *wants* clojure to do tail merging
and that tail merging is only absent from clojure because of its
absence from the JVM. Contrast this to sisc or kawa, both designed to
run on the JVM, both of which do tail merging because the semantics of
the scheme language require it. My point is that Rich Hickey has
allowed some pretty basic semantics of the language to be defined by
the VM it runs on. This means that clojure is, compared to scheme, for
example, a comparatively thin layer on top of the JVM.
>
> > Clojure is an attempt to mold lisp the the very specific contours of
> > the JVM to enable seamless integration with existing Java libraries.
> > One can only conclude that clojure is an attempt to leverage the mind-
> > share of the java/JVM ecosystem, not a VM neutral lisp.
>
> Obviously so. The trouble with taking this argument to the conclusion
> that Clojure is a Java, is that it was originally written for CLR, and
> thus a more palatable argument would be that Clojure is a C#. You
> might argue that it has taken on more and more characteristics of Java
> as its time on the JVM has increased, and that is of course an issue
> that the implementors must address.
I believe they are addressing it by accepting that clojure is joined
at the hip to the JVM. They accept this because it is considered an
*asset* by the clojure community, not a deficit. Contrast this with
scheme as a language, which has been implemented on the JVM, the CLR,
on C, etc. IOW, the semantics of scheme are not dictated by the VM or
machine it runs on. This is a very important difference imho.
>
> My whole take on Clojure is based on one six-hour session (actually,
> three two-hour sessions) with the author, so you must take what I say
> from that context, and throw out what I say that you don't believe. I
> can assure you, that I have no ulterior motive here, other than
> stating what I believe to be facts. I also consider myself to be a
> fair judge of character, and although it could be that RH was lying
> through his teeth at that tutorial and telling us what we wanted to
> hear, I didn't see any sign of that; his story was consistent, well
> thought out, and as one of at least 80 to 100 lispers in the audience,
> all of whom were skeptical and who tossed very lisp-specific questions
> during those sessions, I can say that he had good answers for most of
> the questions, and quite often as he was describing the history he
> stated how he had made his decision based on what Common Lisp does,
> because he liked what CL does.
I'm not saying that Rich Hickey is dissembling or anything like it.
It's all there in plain view on the clojure website. I think that some
common lisp people are overlooking some obvious signs of how closely
clojure is tied to the JVM.
>
> I would ask other Lispers who were in that tutorial to speak up to
> verify my story, but I actually won't do that because of the grief I'm
> getting here; if I who am a self-professed competitor can't speak up
> without my motivations being questioned, how can I ask other lisp
> users to speak up in this situation? (and no, Raffael, I'm not saying
> that you are giving me grief, here, but others might perceive it to be
> the case)
>
> Duane
Sorry to give that appearance. I too have defended clojure (in this
very thread as a matter of fact - see my reply to Andre Thieme further
down). I do think, however, that we need to be clear about what
clojure is; it is a lisp dialect that is closely tied to the jvm with
all the advantages and limitations that entails; it is far less of a
VM-neutral language in the way that scheme, for example is.
On Apr 23, 1:54 pm, Raffael Cavallaro <················@gmail.com>
wrote:
> On Apr 23, 1:23 pm, ·····@franz.com wrote:
>
> > It's interesting that you bring up tail merging as an example of how
> > Clojure differs from CL... CL doesn't have tail-merging, only many of
> > its implementations do. In Allegro CL, our eval function does not do
> > tail merging either. How does that affect our interpreter's
> > neutrality?
>
> But Rich Hickey has said that he *wants* clojure to do tail merging
> and that tail merging is only absent from clojure because of its
> absence from the JVM. Contrast this to sisc or kawa, both designed to
> run on the JVM, both of which do tail merging because the semantics of
> the scheme language require it. My point is that Rich Hickey has
> allowed some pretty basic semantics of the language to be defined by
> the VM it runs on. This means that clojure is, compared to scheme, for
> example, a comparatively thin layer on top of the JVM.
I have no trouble with anything you've said here. It does not
contradict any of the 5 main points that I made when I jumped into the
conversation. As for _how_ thin, I don't know, and it doesn't
matter. The way RH was speaking at the tutorial, it must not be too
thin, because according to him, they are working on a CLR version of
Clojure. That means that whatever veneer is on top of the JVM is (or
will be) thick enough to cover both JVM and CLR. Will they succeed?
I don't know. Will the two implementations be completely compatible?
That will depend on the strength of RH's will (as Clojure's benevolent
dictator). Will the result be compatible with older Clozure code?
Likely not; RH has stated that parts of the language are still under
development. I really don't care about any of those things; they are
details, which, though in no way minor, have little bearing on my main
points. And I think what people in this ng are having a hard time
with is the idea that Clozure is a Lisp and not a Java. To prove the
former is hard; it requires the conversation "what makes a Lisp"? The
second is easy, though; just take some Clozure source code and run the
Java compiler over it. It won't work, not by a long shot.
> > > Clojure is an attempt to mold lisp the the very specific contours of
> > > the JVM to enable seamless integration with existing Java libraries.
> > > One can only conclude that clojure is an attempt to leverage the mind-
> > > share of the java/JVM ecosystem, not a VM neutral lisp.
>
> > Obviously so. The trouble with taking this argument to the conclusion
> > that Clojure is a Java, is that it was originally written for CLR, and
> > thus a more palatable argument would be that Clojure is a C#. You
> > might argue that it has taken on more and more characteristics of Java
> > as its time on the JVM has increased, and that is of course an issue
> > that the implementors must address.
>
> I believe they are addressing it by accepting that clojure is joined
> at the hip to the JVM. They accept this because it is considered an
> *asset* by the clojure community, not a deficit. Contrast this with
> scheme as a language, which has been implemented on the JVM, the CLR,
> on C, etc. IOW, the semantics of scheme are not dictated by the VM or
> machine it runs on. This is a very important difference imho.
No doubt they consider the JVM an asset. It implements a lot of what
they need in a runtime. But that still doesn't conflict with any of
my points. And it doesn't mean they can't also use all of the assets
of .NET if and when they succeed in rehosting to compile to CLR.
Again, I'm basing most of what I say on what I heard at the ILC
tutorial, but you can also see some evidence of this on the website as
well. In particular, look over http://clojure.org/rationale, where RH
himself states over and over that he believes his language is a lisp,
and that the JVM is just a platform.
> > My whole take on Clojure is based on one six-hour session (actually,
> > three two-hour sessions) with the author, so you must take what I say
> > from that context, and throw out what I say that you don't believe. I
> > can assure you, that I have no ulterior motive here, other than
> > stating what I believe to be facts. I also consider myself to be a
> > fair judge of character, and although it could be that RH was lying
> > through his teeth at that tutorial and telling us what we wanted to
> > hear, I didn't see any sign of that; his story was consistent, well
> > thought out, and as one of at least 80 to 100 lispers in the audience,
> > all of whom were skeptical and who tossed very lisp-specific questions
> > during those sessions, I can say that he had good answers for most of
> > the questions, and quite often as he was describing the history he
> > stated how he had made his decision based on what Common Lisp does,
> > because he liked what CL does.
>
> I'm not saying that Rich Hickey is dissembling or anything like it.
> It's all there in plain view on the clojure website. I think that some
> common lisp people are overlooking some obvious signs of how closely
> clojure is tied to the JVM.
of course it's tied to the JVM; that's its main platform! Does sisc
or kawa being implemented on JVM make them Java? Of course not!
> > I would ask other Lispers who were in that tutorial to speak up to
> > verify my story, but I actually won't do that because of the grief I'm
> > getting here; if I who am a self-professed competitor can't speak up
> > without my motivations being questioned, how can I ask other lisp
> > users to speak up in this situation? (and no, Raffael, I'm not saying
> > that you are giving me grief, here, but others might perceive it to be
> > the case)
>
> > Duane
>
> Sorry to give that appearance. I too have defended clojure (in this
> very thread as a matter of fact - see my reply to Andre Thieme further
> down). I do think, however, that we need to be clear about what
> clojure is; it is a lisp dialect that is closely tied to the jvm with
> all the advantages and limitations that entails; it is far less of a
> VM-neutral language in the way that scheme, for example is.
No problem. And again, I have no problem with any of the statements
you make in this paragraph. The design decisions have been made, and
from what I understand some are still being made. But however you
categorize it qualitatively, I still view it as a Lisp, veneer or not.
Duane
From: Brian Adkins
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <m2mya61dbe.fsf@gmail.com>
·····@franz.com writes:
> [...]
> I have no trouble with anything you've said here. It does not
> contradict any of the 5 main points that I made when I jumped into the
> conversation. As for _how_ thin, I don't know, and it doesn't
> matter. The way RH was speaking at the tutorial, it must not be too
> thin, because according to him, they are working on a CLR version of
> Clojure. That means that whatever veneer is on top of the JVM is (or
> will be) thick enough to cover both JVM and CLR. Will they succeed?
> I don't know. Will the two implementations be completely compatible?
> That will depend on the strength of RH's will (as Clojure's benevolent
> dictator). Will the result be compatible with older Clozure code?
> Likely not; RH has stated that parts of the language are still under
> development. I really don't care about any of those things; they are
> details, which, though in no way minor, have little bearing on my main
> points. And I think what people in this ng are having a hard time
> with is the idea that Clozure is a Lisp and not a Java. To prove the
> former is hard; it requires the conversation "what makes a Lisp"? The
> second is easy, though; just take some Clozure source code and run the
> Java compiler over it. It won't work, not by a long shot.
> [...]
I expect most people here realize that "Clozure" above was simply a
typo and should've been "Clojure", but I thought I'd mention it since
"Clozure CL" is a common lisp implementation entirely independent of
Clojure.
--
Brian Adkins
http://lojic.com/
On Apr 24, 4:49 am, Brian Adkins <···········@gmail.com> wrote:
> ·····@franz.com writes:
> > [...]
> > I have no trouble with anything you've said here. It does not
> > contradict any of the 5 main points that I made when I jumped into the
> > conversation. As for _how_ thin, I don't know, and it doesn't
> > matter. The way RH was speaking at the tutorial, it must not be too
> > thin, because according to him, they are working on a CLR version of
> > Clojure. That means that whatever veneer is on top of the JVM is (or
> > will be) thick enough to cover both JVM and CLR. Will they succeed?
> > I don't know. Will the two implementations be completely compatible?
> > That will depend on the strength of RH's will (as Clojure's benevolent
> > dictator). Will the result be compatible with older Clozure code?
> > Likely not; RH has stated that parts of the language are still under
> > development. I really don't care about any of those things; they are
> > details, which, though in no way minor, have little bearing on my main
> > points. And I think what people in this ng are having a hard time
> > with is the idea that Clozure is a Lisp and not a Java. To prove the
> > former is hard; it requires the conversation "what makes a Lisp"? The
> > second is easy, though; just take some Clozure source code and run the
> > Java compiler over it. It won't work, not by a long shot.
> > [...]
>
> I expect most people here realize that "Clozure" above was simply a
> typo and should've been "Clojure", but I thought I'd mention it since
> "Clozure CL" is a common lisp implementation entirely independent of
> Clojure.
Correct; this was a typo. Thanks for catching it.
Duane
On Apr 23, 8:59 pm, ·····@franz.com wrote:
> of course it's tied to the JVM; that's its main platform! Does sisc
> or kawa being implemented on JVM make them Java? Of course not!
<Sigh> once again, sisc and kawa did *not* compromise the semantics of
the scheme language in order to conform to what is available on the
JVM. Clojure *does*. This is A Bad Thing(TM) because it completely
changes the desired [1] semantics of the language.
[1] not *my* desired semantics, but the desired semantics of the
language designer himself, Rich Hickey.
On Apr 24, 11:35 am, Raffael Cavallaro <················@gmail.com>
wrote:
> On Apr 23, 8:59 pm, ·····@franz.com wrote:
>
> > of course it's tied to the JVM; that's its main platform! Does sisc
> > or kawa being implemented on JVM make them Java? Of course not!
>
> <Sigh> once again, sisc and kawa did *not* compromise the semantics of
> the scheme language in order to conform to what is available on the
> JVM. Clojure *does*. This is A Bad Thing(TM) because it completely
> changes the desired [1] semantics of the language.
>
> [1] not *my* desired semantics, but the desired semantics of the
> language designer himself, Rich Hickey.
Why the sigh? Are you frustrated?
If an implementation doesn't conform to the desired semantics of a
language, that's simply a bug. Presumably, bugs are non-conformances
that will eventually be fixed. How and when this is to take place, I
don't know, but if you're using a bug as an indicator of language
inclination, it is a rather weak association.
Duane
On Apr 24, 2:45 pm, ·····@franz.com wrote:
> Why the sigh? Are you frustrated?
because it's the 3rd time i've repeated it.
>
> If an implementation doesn't conform to the desired semantics of a
> language, that's simply a bug. Presumably, bugs are non-conformances
> that will eventually be fixed. How and when this is to take place, I
> don't know, but if you're using a bug as an indicator of language
> inclination, it is a rather weak association.
RH has already said he's waiting for tco to be added to the jvm. It is
this dependency on the jvm that is troubling for it suggests that
clojure as much a java with lisp syntax as an independent language
design that just happens to be implemented on the jvm. This works as
long as the jvm is riding high. If the jvm falters in popularity then
clojure becomes largely irrelevant since its design is so closely tied
to java/jvm semantics.
On Apr 24, 12:05 pm, Raffael Cavallaro <················@gmail.com>
wrote:
> On Apr 24, 2:45 pm, ·····@franz.com wrote:
>
> > Why the sigh? Are you frustrated?
>
> because it's the 3rd time i've repeated it.
I'm sorry to be frustrating you, but whenever I find myself repeating
myself and not getting anywhere, I try to figure out what basic
assumptions the other person has that I've not understood explicitly.
Usually it's something where I think "of course he's got to think
that" but it turns out not to be true. I think I might know what
assumptions are being missed here, that haven't necessarily been part
of this conversation but which are probably needed to understand why
we differ.
> > If an implementation doesn't conform to the desired semantics of a
> > language, that's simply a bug. Presumably, bugs are non-conformances
> > that will eventually be fixed. How and when this is to take place, I
> > don't know, but if you're using a bug as an indicator of language
> > inclination, it is a rather weak association.
>
> RH has already said he's waiting for tco to be added to the jvm. It is
> this dependency on the jvm that is troubling for it suggests that
> clojure as much a java with lisp syntax as an independent language
> design that just happens to be implemented on the jvm. This works as
> long as the jvm is riding high. If the jvm falters in popularity then
> clojure becomes largely irrelevant since its design is so closely tied
> to java/jvm semantics.
I think that the basic assumption where we might differ in this
conversation is how we each view a one-implementation language, and
how it is identified. Before we dive into that area, let me say that
I don't particularly like the idea of languages which are dictated by
their implementations, because they tend to change over time - that is
why I'm firmly planted in a language which has a strong spec. But
even that precursor is relevant here, because it has to do with how I
identify a language which is not bound by a spec. Of course you know
of many languages which have their benevolent dictators, and even
within CL, which has its Domain Specific Languages, the maintainer of
the DSL could be thought of as its benevolent dictator.
The trouble one gets into when trying to identify a spec-less language
is that it changes over time, so a statement you make about it right
now becomes obsolete much too quickly. If RH were to "see the light"
from some of the trampolining discussions at ILC09 and suddenly
implemented tail merging, your argument would break down. However,
let's assume that he doesn't implement tail merging, and instead
concentrates on other aspects of his language that are more important
to him. What is the language, then? Is it what the implementation
currently shows you when you type into the prompt? That might be an
accurate answer, but it is potentially only accurate for this revision
of the implementation, which by definition is this revision of the
language.
The point is, and I believe even you are doing this, is that in a spec-
less language, a better view of what the language _is_ is not the
implementation (which might have bugs), but a combination of the
implementation and the Benevolent dictator's direction. This
direction should be categorized into short-term directions and long-
term directions. Sometimes it is sometimes hard to fathom, and often
the only way to understand the B/D's direction is to ask him, and
perhaps to ask often. In RH's case, he has written and talked about
his goals very clearly, and one of his goals is to be able to re-host
onto other VMs. And if those VM's also don't support tail-merging,
and he in fact has to wait for them to support tail merging, then that
might say less about how the language is constrained to the VMs, but
perhaps instead it says more about how high (or low) his priority is
in his desire for tail merging.
To recap, I think that considering what language Clojure is must be
based not only on the implementation, but also by understanding RH's
priorities for his direction. And perhaps this conversation will only
be resolved by going straight to RH himself and asking him what he
thinks, and perhaps asking him to resolve the apparent inconsistencies
in his statements: he wants Clojure to be a Lisp, but he lets
implementation details be governed by inadequacies in the JVM - where
is the priority set? My guess is that he will say that the answer is
complex, and that he makes decisions on a case-by-case basis.
Duane
From: Paul Donnelly
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <87vdotreqe.fsf@plap.localdomain>
Raffael Cavallaro <················@gmail.com> writes:
> On Apr 24, 2:45 pm, ·····@franz.com wrote:
>
>> Why the sigh? Are you frustrated?
>
> because it's the 3rd time i've repeated it.
>>
>> If an implementation doesn't conform to the desired semantics of a
>> language, that's simply a bug. Presumably, bugs are non-conformances
>> that will eventually be fixed. How and when this is to take place, I
>> don't know, but if you're using a bug as an indicator of language
>> inclination, it is a rather weak association.
>
> RH has already said he's waiting for tco to be added to the jvm. It is
> this dependency on the jvm that is troubling for it suggests that
> clojure as much a java with lisp syntax as an independent language
> design that just happens to be implemented on the jvm. This works as
> long as the jvm is riding high. If the jvm falters in popularity then
> clojure becomes largely irrelevant since its design is so closely tied
> to java/jvm semantics.
Or else he ports it to something else.
What's another example of a way in which Clojure's design is tied to the
JVM? I know it's got a bit of syntax for accessing Java classes, and its
lack of TCO is because the JVM has no TCO. Call me crazy, but those two
things together don't strike me as "Java with Lisp syntax", unless you
consider a lack of TCO to be a prime Java design feature. If a Common
Lisp lacks TCO and can call C functions, does that make it "C with Lisp
syntax"? Clojure has far more Lisp features and new features of its own
than it has Java features.
On Apr 24, 4:14 pm, Paul Donnelly <·············@sbcglobal.net> wrote:
> What's another example of a way in which Clojure's design is tied to the
> JVM?
All clojure objects are java objects. These clojure objects can be
coerced to java primitive types. In fact they need to be so coerced if
you want certain things to run quickly. Seems to me that this - the
java object/primitive type distinction makes clojure as much a java
with lisp syntax as an independent lisp language design.
Using clojure libraries requires wrestling with the brokenness that is
java's classpath workings. This will seem quite natural if you come
from java land and want first and foremost for your code to be a good
java citizen, but painfully pointless otherwise.
If you haven't already done so, work with clojure a bit. I think
you'll see java leaking through a fair amount. The overall impression
is of a language that was molded to the jvm, not an independent design
- like scheme for example - that just happens to be hosted on the jvm.
From: Dimiter "malkia" Stanev
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <49F2604C.30505@mac.com>
Raffael Cavallaro wrote:
> On Apr 24, 4:14 pm, Paul Donnelly <·············@sbcglobal.net> wrote:
>
>> What's another example of a way in which Clojure's design is tied to the
>> JVM?
>
> All clojure objects are java objects. These clojure objects can be
> coerced to java primitive types. In fact they need to be so coerced if
> you want certain things to run quickly. Seems to me that this - the
> java object/primitive type distinction makes clojure as much a java
> with lisp syntax as an independent lisp language design.
>
> Using clojure libraries requires wrestling with the brokenness that is
> java's classpath workings. This will seem quite natural if you come
> from java land and want first and foremost for your code to be a good
> java citizen, but painfully pointless otherwise.
>
> If you haven't already done so, work with clojure a bit. I think
> you'll see java leaking through a fair amount. The overall impression
> is of a language that was molded to the jvm, not an independent design
> - like scheme for example - that just happens to be hosted on the jvm.
I'm also struggling with namespaces/classpaths in clojure. I'm never
sure for any given namespace where should I place my .clj file and in
which directory. In fact I think there is some relation between the name
of the package and the .clj filename (I'm not sure).
Another stumbling block is the . and .. syntax for calling java. I
understand that it could be taken as any of the LispAssembler (LAP
syntaxes) found in common lisps, but I can't really use well the macro
system in combination with the java stuff.
But the problem is, as soon you start replacing some of the stuff in the
(. (.. with macro stuff for shorter code (SWING is too-verbose), you are
finding yourself at a problem with Runtime messages such as: "No
matching method found"
Here is such case: http://paste.lisp.org/display/79061
Try coming up with language to replace this clojure "LAP" (ahem java) code:
(doto layout
(.setHorizontalGroup
(.. layout (createParallelGroup GroupLayout$Alignment/LEADING)
(addGroup
(.. layout (createSequentialGroup)
(addContainerGap)
(addGroup
(.. layout (createParallelGroup GroupLayout$Alignment/LEADING)
(addGroup
(.. layout (createSequentialGroup)
(addComponent temp-text-field
GroupLayout/PREFERRED_SIZE
GroupLayout/DEFAULT_SIZE
GroupLayout/PREFERRED_SIZE)
(addPreferredGap LayoutStyle$ComponentPlacement/RELATED)
(addComponent celsius-label)))
(addGroup
(.. layout (createSequentialGroup)
(addComponent convert-button)
(addPreferredGap LayoutStyle$ComponentPlacement/RELATED)
(addComponent fahrenheit-label)))))
(addContainerGap 27 Short/MAX_VALUE)))))
with something less verbose.
FYI: The Original Java version for refference:
http://java.sun.com/docs/books/tutorial/uiswing/examples/learn/CelsiusConverterProject/src/learn/CelsiusConverterGUI.java
I guess it could be done, if you do it at once, but if you start
iteratively - e.g. experiment various ideas then you can't. You can't do
it bottom up. You do have to start with a concrete plan.
For example try replacing (createParallelGroup
GroupLayout$Alignment/LEADING) with something like (pg :leading)
Either macro or function. In macro case I was not able to get it
compiled, in function one - it was giving runtime exception.
Here is my attempt:
(def group-alignment-conversion
{:leading GroupLayout$Alignment/LEADING,
:baseline GroupLayout$Alignment/BASELINE})
(defn pg [alignment]
{:tag GroupLayout$ParallelGroup}
(group-alignment-conversion alignment))
You would also need this changed from the paste above:
(import '(javax.swing JComponent JFrame JLabel JTextField JButton
GroupLayout GroupLayout$Alignment SwingConstants LayoutStyle
LayoutStyle$ComponentPlacement GroupLayout$ParallelGroup)
'(java.awt.event ActionListener)
'(java.awt Component))
So with Clojure/SWING I would miss my dear LispWorks's CAPI :)
Thanks,
Dimiter "malkia" Stanev.
From: André Thieme
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <gsv4hs$n70$1@news.motzarella.org>
Dimiter "malkia" Stanev schrieb:
> Raffael Cavallaro wrote:
> I'm also struggling with namespaces/classpaths in clojure. I'm never
> sure for any given namespace where should I place my .clj file and in
> which directory. In fact I think there is some relation between the name
> of the package and the .clj filename (I'm not sure).
I can give you an example. Let's say you are using Windows Vista and
have your home directory at /users/dimi/
(under Linux this could be /home/dimi/).
There you want to start a new project. Let's say you want to put it into
/users/dimi/pro/.
That will be your code repository. In there you have a dir docs, build
and you also have /users/dimi/pro/src/
Now you want to add two directories to your CP: src and build.
Also in your CP you have the clojure.jar and some other .jar files that
contain Java (or other Clojure) libs, for IO.
Now let's say you own the domain dimi.com and want this to be your
namespace.
Then you make the dir /users/dimi/pro/src/com/dimi/
And into that dir you put your source files. For example start.clj
In start.clj you will have (ns com.dimi.start)
The src is in your CP. From that point on your NS begin.
The files should match the NS in such a way that dots (�.�) separate
directories, and where the last part is the name of the file minus
�.clj�.
If you now add a XML-RPC client and server to your code you could have
the dir /users/dimi/pro/src/com/dimi/xmlrpc/ and in there two files
client.clj and server.clj. Their namespaces would be then:
(ns com.dimi.xmlrpc.client ...) and (ns com.dimi.xmlrpc.server ...).
You also put /users/dimi/pro/build/ into your classpath. That is used
for compilation then:
(binding [*compile-path* "/users/dimi/pro/build/"]
(compile 'com.dimi.start)
(compile 'com.dimi.xmlrpc.client)
(compile 'com.dimi.xmlrpc.server))
After compilation you will find in your build dir a new subdir com/.
In that you will find a subdir dimi/ in which you will find a
start.class and a dir xmlrpc/ in which you will find the files
client.class and server.class.
I hope I wab able remove all clearness from you with these
explanations ;)
> Another stumbling block is the . and .. syntax for calling java. I
> understand that it could be taken as any of the LispAssembler (LAP
> syntaxes) found in common lisps, but I can't really use well the macro
> system in combination with the java stuff.
You should in principle never need the . if you want to use lisp syntax.
The . can be used to have a closer match to Java syntax.
In Java you maybe have a string name = "Dimi123";
Then name.substring(4) will give you a new string "123". In
Clojure you could write: (. name substring 4)
But better do it the lisp way: (.substring name 4).
Just imagine you have something such as
(defmethod .substring ((string string) (position number))
...)
in CL, which would be then called as I showed above.
Now (.substring name 4) returns a new string. Let's find out how
long it is:
(.length (.substring name 4)) ==> 3
The .. now allows you to rearrange the function calls in kind of
a piped way, and it can eliminate the dots from the functions and
it can eliminate parens of those functions that take only one arg:
(.. name (substring 4) length) ==> 3
This expands to:
user> (macroexpand-1 '(.. x (substring 4) length))
(.. (. x (substring 4)) length)
which expands to:
user> (macroexpand-1 '(.. (. x (substring 4)) length))
(. (. x (substring 4)) length)
> But the problem is, as soon you start replacing some of the stuff in the
> (. (.. with macro stuff for shorter code (SWING is too-verbose), you are
> finding yourself at a problem with Runtime messages such as: "No
> matching method found"
Why not use NetBeans for creating the GUI?
It is one of the most advanced GUI builders available.
> So with Clojure/SWING I would miss my dear LispWorks's CAPI :)
For some cases CAPI is indeed nicer.
For example, I find it ridiculous that there is no center method
for frames. You manually have to calculate the position and then
set it explicitly. At least NetBeans allows you to click a checkbox
which will add this centering code for you, and automatically adopt
it to any changes you make.
But some things in Swing were done very well and can be done
straightforward. But really, without a GUI builder I would not want
to do it.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
From: Dimiter "malkia" Stanev
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <49F5F452.6080107@mac.com>
Thanks Andre for taking time and helping me out!
I've already have my stuff in a folder called ~/p - and I have there all
projects from anywhere like - ~/p/clojure, ~/p/clojure-contrib, etc.
It's just for my things I have not bothered creating "src" folder,
build.xml, etc. - for now I'm just running slime with clojure, loading
the file and C-c C-k it.
I'm going to give NetBeans a go.
I really like how easy is to plug a .jar file and use it :) I'm still
deciding for myself, what exactly I need for GUI.
It's a different world, a bit more bureaucratic and a bit less anarchist
than common lisp, for good or bad.
I'm using both CL (LW, ACL and ClozureCL mainly) & Clojure now - I might
even try JFli or Allego JLink to see what else could be done.
Thanks, again!
Andr� Thieme wrote:
> Dimiter "malkia" Stanev schrieb:
>> Raffael Cavallaro wrote:
>
>> I'm also struggling with namespaces/classpaths in clojure. I'm never
>> sure for any given namespace where should I place my .clj file and in
>> which directory. In fact I think there is some relation between the
>> name of the package and the .clj filename (I'm not sure).
>
> I can give you an example. Let's say you are using Windows Vista and
> have your home directory at /users/dimi/
> (under Linux this could be /home/dimi/).
> There you want to start a new project. Let's say you want to put it into
> /users/dimi/pro/.
> That will be your code repository. In there you have a dir docs, build
> and you also have /users/dimi/pro/src/
> Now you want to add two directories to your CP: src and build.
> Also in your CP you have the clojure.jar and some other .jar files that
> contain Java (or other Clojure) libs, for IO.
>
> Now let's say you own the domain dimi.com and want this to be your
> namespace.
> Then you make the dir /users/dimi/pro/src/com/dimi/
> And into that dir you put your source files. For example start.clj
> In start.clj you will have (ns com.dimi.start)
> The src is in your CP. From that point on your NS begin.
> The files should match the NS in such a way that dots (�.�) separate
> directories, and where the last part is the name of the file minus
> �.clj�.
> If you now add a XML-RPC client and server to your code you could have
> the dir /users/dimi/pro/src/com/dimi/xmlrpc/ and in there two files
> client.clj and server.clj. Their namespaces would be then:
> (ns com.dimi.xmlrpc.client ...) and (ns com.dimi.xmlrpc.server ...).
>
> You also put /users/dimi/pro/build/ into your classpath. That is used
> for compilation then:
> (binding [*compile-path* "/users/dimi/pro/build/"]
> (compile 'com.dimi.start)
> (compile 'com.dimi.xmlrpc.client)
> (compile 'com.dimi.xmlrpc.server))
>
> After compilation you will find in your build dir a new subdir com/.
> In that you will find a subdir dimi/ in which you will find a
> start.class and a dir xmlrpc/ in which you will find the files
> client.class and server.class.
>
> I hope I wab able remove all clearness from you with these
> explanations ;)
>
>
>> Another stumbling block is the . and .. syntax for calling java. I
>> understand that it could be taken as any of the LispAssembler (LAP
>> syntaxes) found in common lisps, but I can't really use well the macro
>> system in combination with the java stuff.
>
> You should in principle never need the . if you want to use lisp syntax.
> The . can be used to have a closer match to Java syntax.
> In Java you maybe have a string name = "Dimi123";
> Then name.substring(4) will give you a new string "123". In
> Clojure you could write: (. name substring 4)
> But better do it the lisp way: (.substring name 4).
> Just imagine you have something such as
> (defmethod .substring ((string string) (position number))
> ...)
> in CL, which would be then called as I showed above.
>
> Now (.substring name 4) returns a new string. Let's find out how
> long it is:
> (.length (.substring name 4)) ==> 3
> The .. now allows you to rearrange the function calls in kind of
> a piped way, and it can eliminate the dots from the functions and
> it can eliminate parens of those functions that take only one arg:
> (.. name (substring 4) length) ==> 3
>
> This expands to:
> user> (macroexpand-1 '(.. x (substring 4) length))
> (.. (. x (substring 4)) length)
>
> which expands to:
> user> (macroexpand-1 '(.. (. x (substring 4)) length))
> (. (. x (substring 4)) length)
>
>
>
>> But the problem is, as soon you start replacing some of the stuff in
>> the (. (.. with macro stuff for shorter code (SWING is too-verbose),
>> you are finding yourself at a problem with Runtime messages such as:
>> "No matching method found"
>
> Why not use NetBeans for creating the GUI?
> It is one of the most advanced GUI builders available.
>
>
>> So with Clojure/SWING I would miss my dear LispWorks's CAPI :)
>
> For some cases CAPI is indeed nicer.
> For example, I find it ridiculous that there is no center method
> for frames. You manually have to calculate the position and then
> set it explicitly. At least NetBeans allows you to click a checkbox
> which will add this centering code for you, and automatically adopt
> it to any changes you make.
> But some things in Swing were done very well and can be done
> straightforward. But really, without a GUI builder I would not want
> to do it.
>
>
> Andr�
On Apr 27, 8:07 pm, "Dimiter \"malkia\" Stanev" <······@mac.com>
wrote:
> Thanks Andre for taking time and helping me out!
>
> I've already have my stuff in a folder called ~/p - and I have there all
> projects from anywhere like - ~/p/clojure, ~/p/clojure-contrib, etc.
>
> It's just for my things I have not bothered creating "src" folder,
> build.xml, etc. - for now I'm just running slime with clojure, loading
> the file and C-c C-k it.
>
> I'm going to give NetBeans a go.
>
> I really like how easy is to plug a .jar file and use it :) I'm still
> deciding for myself, what exactly I need for GUI.
In my experience with ABCL and Eclipse, Java IDEs don't really play
well with Lisp. You're stuck with the IDE's "console" which sucks bad
as a REPL. What I usually do is to launch ABCL from Eclipse and make
it automatically launch Swank and load my code, then connect to Swank
and use Emacs. When I need to write some Java glue, or when something
goes wrong and produces a Java stack trace, I use Eclipse.
Btw (wrt NetBeans) I figured out now that the Swing code you posted
earlier was in fact mostly generated by NetBeans. So it's not quite
idiomatic Java code. It's pretty unreadable for Java standards; you're
not supposed to even see that code (the IDE tends to hide it from
you).
> It's a different world, a bit more bureaucratic and a bit less anarchist
> than common lisp, for good or bad.
>
> I'm using both CL (LW, ACL and ClozureCL mainly) & Clojure now - I might
> even try JFli or Allego JLink to see what else could be done.
You should also give ABCL a try. Its interface to Java is pretty low-
level but it's not hard to build abstractions on it (I have some
useful code if you want, or there's an invoke.lisp floating on the
net). It allows you to implement Java interfaces in Lisp which is nice
- you can easily write Swing event listeners in Lisp! (Though I
suspect Clojure also gives you something similar). I also wrote some
code to integrate a bit Java classes with CLOS, so you can have
(jclass "some.java.class") method specializers, which can be handy
(and needs testers :D). Also I'm working on a Swing-DSL but it's
barely beyond the proof-of-concept phase and thus not very usable for
real work - however if you're interested I can show you what I've got
so far.
Bye,
Alessio
From: John Thingstad
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <op.us2590s4ut4oq5@pandora>
På Mon, 27 Apr 2009 23:23:31 +0200, skrev Alessio Stalla
<·············@gmail.com>:
>
> In my experience with ABCL and Eclipse, Java IDEs don't really play
> well with Lisp. You're stuck with the IDE's "console" which sucks bad
> as a REPL. What I usually do is to launch ABCL from Eclipse and make
> it automatically launch Swank and load my code, then connect to Swank
> and use Emacs. When I need to write some Java glue, or when something
> goes wrong and produces a Java stack trace, I use Eclipse.
> Btw (wrt NetBeans) I figured out now that the Swing code you posted
> earlier was in fact mostly generated by NetBeans. So it's not quite
> idiomatic Java code. It's pretty unreadable for Java standards; you're
> not supposed to even see that code (the IDE tends to hide it from
> you).
>
Have you tried CUSP? (No, I don't have any experience myself, just
curious..)
-----------------------
John Thingstad
On Apr 28, 9:40 am, "John Thingstad" <·······@online.no> wrote:
> På Mon, 27 Apr 2009 23:23:31 +0200, skrev Alessio Stalla
> <·············@gmail.com>:
>
>
>
> > In my experience with ABCL and Eclipse, Java IDEs don't really play
> > well with Lisp. You're stuck with the IDE's "console" which sucks bad
> > as a REPL. What I usually do is to launch ABCL from Eclipse and make
> > it automatically launch Swank and load my code, then connect to Swank
> > and use Emacs. When I need to write some Java glue, or when something
> > goes wrong and produces a Java stack trace, I use Eclipse.
> > Btw (wrt NetBeans) I figured out now that the Swing code you posted
> > earlier was in fact mostly generated by NetBeans. So it's not quite
> > idiomatic Java code. It's pretty unreadable for Java standards; you're
> > not supposed to even see that code (the IDE tends to hide it from
> > you).
>
> Have you tried CUSP? (No, I don't have any experience myself, just
> curious..)
I briefly tried it over an year ago. Never quite used it because IIRC
it comes with SBCL, not ABCL, and I see no point in using Eclipse with
Lisp if there is no Java involved :)
Plus, I remember it frequently used 100% cpu, although that was
probably a bug in the specific version I used. (Probably I used it on
Windows which does not help wrt SBCL, either).
That said, trying it again (and finding a way to replace SBCL with
ABCL) is on my to-do list. But it's quite at the bottom of the list...
Ale
Is ABCL working fine under 1.6.0 "java -server" (MacOS X)?
I've got this:
(progn (load "/Users/malkia/p/slime/swank-loader.lisp" :verbose t)
(funcall (read-from-string "swank-loader:init")) (funcall (read-from-
string "swank:start-server") "/var/folders/ZJ/ZJV0Kby2GRG1V7DOl0wtlU++
+TI/-Tmp-/slime.549" :coding-system "iso-latin-1-unix"))
Armed Bear Common Lisp 0.15.0-dev
Java 1.6.0_07 Apple Inc.
Java HotSpot(TM) 64-Bit Server VM
Low-level initialization completed in 0.363 seconds.
Startup completed in 1.544 seconds.
Type ":help" for a list of available commands.
CL-USER(1): ; Loading /Users/malkia/p/slime/swank-loader.lisp ...
WARNING: No architecture feature found in (POWERPC PPC X86 X86-64
AMD64 I686 I586 I486 PC386 IAPX386 ...).
; Loaded /Users/malkia/p/slime/swank-loader.lisp (1.056 seconds)
; Compiling /Users/malkia/p/slime/swank-backend.lisp ...
; Wrote /Users/malkia/.slime/fasl/2009-04-21/armedbear-0.15.0-dev-
darwin-unknown/swank-backend.abcl (5.099 seconds)
; Loading /Users/malkia/.slime/fasl/2009-04-21/armedbear-0.15.0-dev-
darwin-unknown/swank-backend.abcl ...
; Loaded /Users/malkia/.slime/fasl/2009-04-21/armedbear-0.15.0-dev-
darwin-unknown/swank-backend.abcl (1.747 seconds)
; Compiling /Users/malkia/p/slime/swank-abcl.lisp ...
; in (DEFUN BREAK ...)
; Caught STYLE-WARNING:
; The variable *SAVED-BACKTRACE* is defined but never used.
; in (DEFUN SLOT-DEFINITION-DOCUMENTATION ...)
; Caught STYLE-WARNING:
; The variable SLOT is defined but never used.
; in (DEFUN SLOT-DEFINITION-TYPE ...)
; Caught STYLE-WARNING:
; The variable SLOT is defined but never used.
; in (DEFUN CLASS-PROTOTYPE ...)
; Caught STYLE-WARNING:
; The variable CLASS is defined but never used.
; in (DEFUN GENERIC-FUNCTION-DECLARATIONS ...)
; Caught STYLE-WARNING:
; The variable GF is defined but never used.
; in (DEFUN SLOT-BOUNDP-USING-CLASS ...)
; Caught STYLE-WARNING:
; The variable CLASS is defined but never used.
; in (DEFUN SLOT-VALUE-USING-CLASS ...)
; Caught STYLE-WARNING:
; The variable CLASS is defined but never used.
; in (DEFUN HANDLE-COMPILER-WARNING ...)
; Caught STYLE-WARNING:
; Undefined variable: *ABCL-SIGNALED-CONDITIONS*
Invalid memory access of location 00000000 rip=01160767
Process inferior-lisp<1> segmentation fault
On Apr 27, 2:23 pm, Alessio Stalla <·············@gmail.com> wrote:
> On Apr 27, 8:07 pm, "Dimiter \"malkia\" Stanev" <······@mac.com>
> wrote:
>
> > Thanks Andre for taking time and helping me out!
>
> > I've already have my stuff in a folder called ~/p - and I have there all
> > projects from anywhere like - ~/p/clojure, ~/p/clojure-contrib, etc.
>
> > It's just for my things I have not bothered creating "src" folder,
> > build.xml, etc. - for now I'm just running slime with clojure, loading
> > the file and C-c C-k it.
>
> > I'm going to give NetBeans a go.
>
> > I really like how easy is to plug a .jar file and use it :) I'm still
> > deciding for myself, what exactly I need for GUI.
>
> In my experience with ABCL and Eclipse, Java IDEs don't really play
> well with Lisp. You're stuck with the IDE's "console" which sucks bad
> as a REPL. What I usually do is to launch ABCL from Eclipse and make
> it automatically launch Swank and load my code, then connect to Swank
> and use Emacs. When I need to write some Java glue, or when something
> goes wrong and produces a Java stack trace, I use Eclipse.
> Btw (wrt NetBeans) I figured out now that the Swing code you posted
> earlier was in fact mostly generated by NetBeans. So it's not quite
> idiomatic Java code. It's pretty unreadable for Java standards; you're
> not supposed to even see that code (the IDE tends to hide it from
> you).
>
> > It's a different world, a bit more bureaucratic and a bit less anarchist
> > than common lisp, for good or bad.
>
> > I'm using both CL (LW, ACL and ClozureCL mainly) & Clojure now - I might
> > even try JFli or Allego JLink to see what else could be done.
>
> You should also give ABCL a try. Its interface to Java is pretty low-
> level but it's not hard to build abstractions on it (I have some
> useful code if you want, or there's an invoke.lisp floating on the
> net). It allows you to implement Java interfaces in Lisp which is nice
> - you can easily write Swing event listeners in Lisp! (Though I
> suspect Clojure also gives you something similar). I also wrote some
> code to integrate a bit Java classes with CLOS, so you can have
> (jclass "some.java.class") method specializers, which can be handy
> (and needs testers :D). Also I'm working on a Swing-DSL but it's
> barely beyond the proof-of-concept phase and thus not very usable for
> real work - however if you're interested I can show you what I've got
> so far.
>
> Bye,
> Alessio
On Apr 28, 6:42 pm, "Dimiter \"malkia\" Stanev" <······@gmail.com>
wrote:
> Is ABCL working fine under 1.6.0 "java -server" (MacOS X)?
>
> I've got this:
>
> (progn (load "/Users/malkia/p/slime/swank-loader.lisp" :verbose t)
> (funcall (read-from-string "swank-loader:init")) (funcall (read-from-
> string "swank:start-server") "/var/folders/ZJ/ZJV0Kby2GRG1V7DOl0wtlU++
> +TI/-Tmp-/slime.549" :coding-system "iso-latin-1-unix"))
>
> Armed Bear Common Lisp 0.15.0-dev
> Java 1.6.0_07 Apple Inc.
> Java HotSpot(TM) 64-Bit Server VM
> Low-level initialization completed in 0.363 seconds.
> Startup completed in 1.544 seconds.
> Type ":help" for a list of available commands.
> CL-USER(1): ; Loading /Users/malkia/p/slime/swank-loader.lisp ...
> WARNING: No architecture feature found in (POWERPC PPC X86 X86-64
> AMD64 I686 I586 I486 PC386 IAPX386 ...).
> ; Loaded /Users/malkia/p/slime/swank-loader.lisp (1.056 seconds)
> ; Compiling /Users/malkia/p/slime/swank-backend.lisp ...
> ; Wrote /Users/malkia/.slime/fasl/2009-04-21/armedbear-0.15.0-dev-
> darwin-unknown/swank-backend.abcl (5.099 seconds)
> ; Loading /Users/malkia/.slime/fasl/2009-04-21/armedbear-0.15.0-dev-
> darwin-unknown/swank-backend.abcl ...
> ; Loaded /Users/malkia/.slime/fasl/2009-04-21/armedbear-0.15.0-dev-
> darwin-unknown/swank-backend.abcl (1.747 seconds)
> ; Compiling /Users/malkia/p/slime/swank-abcl.lisp ...
> ; in (DEFUN BREAK ...)
>
> ; Caught STYLE-WARNING:
> ; The variable *SAVED-BACKTRACE* is defined but never used.
>
> ; in (DEFUN SLOT-DEFINITION-DOCUMENTATION ...)
>
> ; Caught STYLE-WARNING:
> ; The variable SLOT is defined but never used.
>
> ; in (DEFUN SLOT-DEFINITION-TYPE ...)
>
> ; Caught STYLE-WARNING:
> ; The variable SLOT is defined but never used.
>
> ; in (DEFUN CLASS-PROTOTYPE ...)
>
> ; Caught STYLE-WARNING:
> ; The variable CLASS is defined but never used.
>
> ; in (DEFUN GENERIC-FUNCTION-DECLARATIONS ...)
>
> ; Caught STYLE-WARNING:
> ; The variable GF is defined but never used.
>
> ; in (DEFUN SLOT-BOUNDP-USING-CLASS ...)
>
> ; Caught STYLE-WARNING:
> ; The variable CLASS is defined but never used.
>
> ; in (DEFUN SLOT-VALUE-USING-CLASS ...)
>
> ; Caught STYLE-WARNING:
> ; The variable CLASS is defined but never used.
>
> ; in (DEFUN HANDLE-COMPILER-WARNING ...)
>
> ; Caught STYLE-WARNING:
> ; Undefined variable: *ABCL-SIGNALED-CONDITIONS*
>
> Invalid memory access of location 00000000 rip=01160767
>
> Process inferior-lisp<1> segmentation fault
I don't have means to test it on OSX right now. However, on Linux and
Java 1.6 it works fine; your error appears right where Swank prints it
has succeeded loading on my machine. A segmentation fault looks very
suspicious, since ABCL is in "pure Java" such things should not
happen. Are you using Sun's JVM?
hth,
Ale
From: Thomas A. Russ
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <ymir5zcbbof.fsf@blackcat.isi.edu>
Alessio Stalla <·············@gmail.com> writes:
> I don't have means to test it on OSX right now. However, on Linux and
> Java 1.6 it works fine; your error appears right where Swank prints it
> has succeeded loading on my machine. A segmentation fault looks very
> suspicious, since ABCL is in "pure Java" such things should not
> happen. Are you using Sun's JVM?
There is no direct Sun JVM for the Mac. Only Apple's version derived
from Sun's.
--
Thomas A. Russ, USC/Information Sciences Institute
From: André Thieme
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <gt815v$t26$1@news.eternal-september.org>
Alessio Stalla schrieb:
> In my experience with ABCL and Eclipse, Java IDEs don't really play
> well with Lisp. You're stuck with the IDE's "console" which sucks bad
> as a REPL.
I have not experience with that, but I can imagine that it is not nice
to work that way. However, have you tried Enclojure?
This integrates Lisp pretty nicely into NetBeans.
> You should also give ABCL a try. Its interface to Java is pretty low-
> level but it's not hard to build abstractions on it (I have some
> useful code if you want, or there's an invoke.lisp floating on the
> net). It allows you to implement Java interfaces in Lisp which is nice
> - you can easily write Swing event listeners in Lisp! (Though I
> suspect Clojure also gives you something similar).
Yes, one can write event listeners for swing guis in Clojure.
> Also I'm working on a Swing-DSL
Would be nice if you could remove some of the warts of swing, such as
not having a center() method for JFrames.
And for example one can't directly add entries to a table. One first
needs to catch the table model and add to that.
Also working with rich texts could be much easier. It is way to complex
to change the color and font of some chars or words in a given text.
If you feel like it, you could make that easier. Maybe something like
(change-color editor-pane color 10 15)
where 10 and 15 are the cursor positions in the text for which we want
the new color.
Btw, as you are working with ABCL: you can basically use all the code
that was written for Clojure. You can have in your CL app today the
mature STM with MVCC that comes with Clojure, concurrency ready data
structures and also all those nice Clojure libs.
Maybe you like the duck-streams?
(use 'clojure.contrib.duck-streams)
(read-lines "/home/as/something.txt")
(read-lines "http://www.google.de/")
(read-lines "ftp://your.ftp.server/file.txt")
Returns a vector of strings (representing the lines of the read file).
Just have a look at what is available in contrib:
http://code.google.com/p/clojure-contrib/source/browse/#svn/trunk/src/clojure/contrib
Lots and lots of nice libs, all available in CL.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On Apr 29, 12:49 am, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Alessio Stalla schrieb:
>
> > In my experience with ABCL and Eclipse, Java IDEs don't really play
> > well with Lisp. You're stuck with the IDE's "console" which sucks bad
> > as a REPL.
>
> I have not experience with that, but I can imagine that it is not nice
> to work that way. However, have you tried Enclojure?
> This integrates Lisp pretty nicely into NetBeans.
Never tried it, I'll check it out. Thanks.
> > You should also give ABCL a try. Its interface to Java is pretty low-
> > level but it's not hard to build abstractions on it (I have some
> > useful code if you want, or there's an invoke.lisp floating on the
> > net). It allows you to implement Java interfaces in Lisp which is nice
> > - you can easily write Swing event listeners in Lisp! (Though I
> > suspect Clojure also gives you something similar).
>
> Yes, one can write event listeners for swing guis in Clojure.
>
> > Also I'm working on a Swing-DSL
>
> Would be nice if you could remove some of the warts of swing, such as
> not having a center() method for JFrames.
> And for example one can't directly add entries to a table. One first
> needs to catch the table model and add to that.
> Also working with rich texts could be much easier. It is way to complex
> to change the color and font of some chars or words in a given text.
> If you feel like it, you could make that easier. Maybe something like
> (change-color editor-pane color 10 15)
> where 10 and 15 are the cursor positions in the text for which we want
> the new color.
Heh, for now I have much more basic needs :) I have already
implemented little things like generating a list or tree model from a
Lisp list, but to actually "fix" Swing deficiencies will require a lot
more work. But yours are nice ideas.
> Btw, as you are working with ABCL: you can basically use all the code
> that was written for Clojure. You can have in your CL app today the
> mature STM with MVCC that comes with Clojure, concurrency ready data
> structures and also all those nice Clojure libs.
> Maybe you like the duck-streams?
>
> (use 'clojure.contrib.duck-streams)
> (read-lines "/home/as/something.txt")
> (read-lines "http://www.google.de/")
> (read-lines "ftp://your.ftp.server/file.txt")
> Returns a vector of strings (representing the lines of the read file).
I didn't know Clojure had "duck-streams", but I had in mind to do
something similar on ABCL sooner or later...
> Just have a look at what is available in contrib:http://code.google.com/p/clojure-contrib/source/browse/#svn/trunk/src...
> Lots and lots of nice libs, all available in CL.
...and generally the idea to "steal" some code from Clojure and port/
use it on ABCL has crossed my mind many times. Unfortunately I work on
ABCL in my spare time and I haven't got much of it...
Ale
It seems Google Groups has dropped my previous post... if it's not the
case, sorry for double posting.
On Apr 29, 12:49 am, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Alessio Stalla schrieb:
>
> > In my experience with ABCL and Eclipse, Java IDEs don't really play
> > well with Lisp. You're stuck with the IDE's "console" which sucks bad
> > as a REPL.
>
> I have not experience with that, but I can imagine that it is not nice
> to work that way. However, have you triedEnclojure?
> This integrates Lisp pretty nicely into NetBeans.
No, I have not tried it. Another thing on the to-do list :)
> > You should also give ABCL a try. Its interface to Java is pretty low-
> > level but it's not hard to build abstractions on it (I have some
> > useful code if you want, or there's an invoke.lisp floating on the
> > net). It allows you to implement Java interfaces in Lisp which is nice
> > - you can easily write Swing event listeners in Lisp! (Though I
> > suspect Clojure also gives you something similar).
>
> Yes, one can write event listeners for swing guis in Clojure.
>
> > Also I'm working on a Swing-DSL
>
> Would be nice if you could remove some of the warts of swing, such as
> not having a center() method for JFrames.
> And for example one can't directly add entries to a table. One first
> needs to catch the table model and add to that.
> Also working with rich texts could be much easier. It is way to complex
> to change the color and font of some chars or words in a given text.
> If you feel like it, you could make that easier. Maybe something like
> (change-color editor-pane color 10 15)
> where 10 and 15 are the cursor positions in the text for which we want
> the new color.
Nice ideas! But it will take some work before getting to them, I still
have much more basic needs to implement. I've been surprised at how
easy it has been to write a Lisp list -> listmodel/treemodel
translator, so the actual work needed might be less than I fear.
> Btw, as you are working with ABCL: you can basically use all the code
> that was written for Clojure. You can have in your CL app today the
> mature STM with MVCC that comes with Clojure, concurrency ready data
> structures and also all those nice Clojure libs.
> Maybe you like the duck-streams?
>
> (use 'clojure.contrib.duck-streams)
> (read-lines "/home/as/something.txt")
> (read-lines "http://www.google.de/")
> (read-lines "ftp://your.ftp.server/file.txt")
> Returns a vector of strings (representing the lines of the read file).
This is something I wanted to implement on ABCL, sooner or later. I
didn't know Clojure had it, nice!
> Just have a look at what is available in contrib:http://code.google.com/p/clojure-contrib/source/browse/#svn/trunk/src...
> Lots and lots of nice libs, all available in CL.
...and, yes, I had in mind to "steal" code from Clojure and port/use
it on ABCL. Not enough free time to to everything... :(
Ale
[it seems Google Groups has lost my previous posts; sorry in case of
unwanted multiple postings]
On Apr 29, 12:49 am, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Alessio Stalla schrieb:
>
> > In my experience with ABCL and Eclipse, Java IDEs don't really play
> > well with Lisp. You're stuck with the IDE's "console" which sucks bad
> > as a REPL.
>
> I have not experience with that, but I can imagine that it is not nice
> to work that way. However, have you tried Enclojure?
> This integrates Lisp pretty nicely into NetBeans.
Never tried it. It'll go in the to-do list, too, even if I prefer
Eclipse over NetBeans.
> > You should also give ABCL a try. Its interface to Java is pretty low-
> > level but it's not hard to build abstractions on it (I have some
> > useful code if you want, or there's an invoke.lisp floating on the
> > net). It allows you to implement Java interfaces in Lisp which is nice
> > - you can easily write Swing event listeners in Lisp! (Though I
> > suspect Clojure also gives you something similar).
>
> Yes, one can write event listeners for swing guis in Clojure.
>
> > Also I'm working on a Swing-DSL
>
> Would be nice if you could remove some of the warts of swing, such as
> not having a center() method for JFrames.
> And for example one can't directly add entries to a table. One first
> needs to catch the table model and add to that.
> Also working with rich texts could be much easier. It is way to complex
> to change the color and font of some chars or words in a given text.
> If you feel like it, you could make that easier. Maybe something like
> (change-color editor-pane color 10 15)
> where 10 and 15 are the cursor positions in the text for which we want
> the new color.
These are all nice ideas. But for now I'm stuck with much more basic
needs...
> Btw, as you are working with ABCL: you can basically use all the code
> that was written for Clojure. You can have in your CL app today the
> mature STM with MVCC that comes with Clojure, concurrency ready data
> structures and also all those nice Clojure libs.
> Maybe you like the duck-streams?
>
> (use 'clojure.contrib.duck-streams)
> (read-lines "/home/as/something.txt")
> (read-lines "http://www.google.de/")
> (read-lines "ftp://your.ftp.server/file.txt")
> Returns a vector of strings (representing the lines of the read file).
This is an idea I wanted to implement on ABCL sooner or later, nice to
see Clojure has it!
> Just have a look at what is available in contrib:http://code.google.com/p/clojure-contrib/source/browse/#svn/trunk/src...
> Lots and lots of nice libs, all available in CL.
Well, the idea of "stealing" code from Clojure and port/use it in ABCL
has crossed my mind many times. Unfortunately my spare time is
scarce...
Ale
From: André Thieme
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <gt806p$mdg$1@news.eternal-september.org>
Dimiter "malkia" Stanev schrieb:
> Thanks Andre for taking time and helping me out!
>
> I've already have my stuff in a folder called ~/p - and I have there all
> projects from anywhere like - ~/p/clojure, ~/p/clojure-contrib, etc.
Good.
> It's just for my things I have not bothered creating "src" folder,
> build.xml, etc. - for now I'm just running slime with clojure, loading
> the file and C-c C-k it.
You don't need to make a build.xml file. You can have one, and only some
days ago I tried this and found out that it really is easier than I
first thought. But it is not necessary at all.
When you want to compile a clojure namespace you just do
(binding [*compile-path* "/users/dimi/p/build"]
(compile 'your.namespace))
The folder /users/dimi/p/build/ can be an empty folder that you put into
your classpath. After that compile you will find .class files in there.
You can directly deliver this directory to friends, or give it away to
other developers.
Just put that dir into your classpath and you can (use ..) or
(require ..) your functions in there.
> I'm going to give NetBeans a go.
NetBeans is very nice for designing the basic GUI.
You will have all your buttons, sliders and other widgets, but they
won't do anything without writing event handlers.
If those are trivial things you may consider to write them in Java,
directly in NetBeans. I did this for one-liners or two-liners, such as
making some other widget visible or such.
But you can write all handlers completely in Clojure.
Interesting things that you can do with NetBeans is to connect
components with some beans. You could for example connect a slider with
an edit box which shows a number. When you then draw the slider the
number changes, and when you edit the number, the slider moves. More
advanced and interesting things are also possible - just watch this six
minute video for a little demonstration:
http://www.netbeans.org/kb/60/java/swing-app-beans-binding-screencast.html
(watching it fullscreen really makes sense)
You won't find that functionality in the CL world right now.
One thing you should also try is Enclojure: http://www.enclojure.org/
It is a plugin for NetBeans that provides NB with tools for Clojure
programming. It is not yet there where Emacs+Slime is, but it is
catching up. I personally still prefer the Emacs+Slime combo, but I am
not so certain that this will be forever. Already today Enclojure can
do several things that are not available in Emacs+Slime.
> I really like how easy is to plug a .jar file and use it :) I'm still
> deciding for myself, what exactly I need for GUI.
Yes, it's very easy indeed.
Btw, you can also have the same with a directory, as I suggested above,
with this build dir. In principle a .jar file is not much more than such
a directory, packed into a zipped file given the ending �.jar�.
> I'm using both CL (LW, ACL and ClozureCL mainly) & Clojure now - I might
> even try JFli or Allego JLink to see what else could be done.
Great, this will give you a nice overview.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On Apr 29, 12:32 am, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Dimiter "malkia" Stanev schrieb:
>
> > Thanks Andre for taking time and helping me out!
>
> > I've already have my stuff in a folder called ~/p - and I have there all
> > projects from anywhere like - ~/p/clojure, ~/p/clojure-contrib, etc.
>
> Good.
>
> > It's just for my things I have not bothered creating "src" folder,
> > build.xml, etc. - for now I'm just running slime with clojure, loading
> > the file and C-c C-k it.
>
> You don't need to make a build.xml file. You can have one, and only some
> days ago I tried this and found out that it really is easier than I
> first thought. But it is not necessary at all.
> When you want to compile a clojure namespace you just do
> (binding [*compile-path* "/users/dimi/p/build"]
> (compile 'your.namespace))
>
> The folder /users/dimi/p/build/ can be an empty folder that you put into
> your classpath. After that compile you will find .class files in there.
> You can directly deliver this directory to friends, or give it away to
> other developers.
> Just put that dir into your classpath and you can (use ..) or
> (require ..) your functions in there.
>
> > I'm going to give NetBeans a go.
>
> NetBeans is very nice for designing the basic GUI.
> You will have all your buttons, sliders and other widgets, but they
> won't do anything without writing event handlers.
> If those are trivial things you may consider to write them in Java,
> directly in NetBeans. I did this for one-liners or two-liners, such as
> making some other widget visible or such.
> But you can write all handlers completely in Clojure.
> Interesting things that you can do with NetBeans is to connect
> components with some beans. You could for example connect a slider with
> an edit box which shows a number. When you then draw the slider the
> number changes, and when you edit the number, the slider moves. More
> advanced and interesting things are also possible - just watch this six
> minute video for a little demonstration:http://www.netbeans.org/kb/60/java/swing-app-beans-binding-screencast...
> (watching it fullscreen really makes sense)
>
> You won't find that functionality in the CL world right now.
Here I have to contradict you ;) in CL we have Cells by His Kennyness
(http://common-lisp.net/project/cells/) which is far more advanced
than all the Java "databinding"/data flow libraries I have seen. When
you generate code with NetBeans it all seems easy, but when you have
to fire PropertyChangeEvents manually it doesn't look very pretty.
Probably by using AOP you can automatize most of it, but CLOS method
combinations are just nicer and simpler imho.
Ale
On Apr 25, 2:58 am, "Dimiter \"malkia\" Stanev" <······@mac.com>
wrote:
> Raffael Cavallaro wrote:
> > On Apr 24, 4:14 pm, Paul Donnelly <·············@sbcglobal.net> wrote:
>
> >> What's another example of a way in which Clojure's design is tied to the
> >> JVM?
>
> > All clojure objects are java objects. These clojure objects can be
> > coerced to java primitive types. In fact they need to be so coerced if
> > you want certain things to run quickly. Seems to me that this - the
> > java object/primitive type distinction makes clojure as much a java
> > with lisp syntax as an independent lisp language design.
Unfortunately every thing that runs on the JVM will retain this object/
primitive distinction, AFAIK. ABCL is a CL, but its fixnums are Java
objects.
> > Using clojure libraries requires wrestling with the brokenness that is
> > java's classpath workings. This will seem quite natural if you come
> > from java land and want first and foremost for your code to be a good
> > java citizen, but painfully pointless otherwise.
>
> > If you haven't already done so, work with clojure a bit. I think
> > you'll see java leaking through a fair amount. The overall impression
> > is of a language that was molded to the jvm, not an independent design
> > - like scheme for example - that just happens to be hosted on the jvm.
>
> I'm also struggling with namespaces/classpaths in clojure. I'm never
> sure for any given namespace where should I place my .clj file and in
> which directory. In fact I think there is some relation between the name
> of the package and the .clj filename (I'm not sure).
Hmm, this really sounds like a bad feature gratuitously inherited from
Java. In Java, packages (namespaces) are closely tied to filesystem
structure. Although this simplifies certain things, I find myself more
at ease with what most languages do, i.e. giving you complete freedom
on where to put your source files.
> Another stumbling block is the . and .. syntax for calling java. I
> understand that it could be taken as any of the LispAssembler (LAP
> syntaxes) found in common lisps, but I can't really use well the macro
> system in combination with the java stuff.
>
> But the problem is, as soon you start replacing some of the stuff in the
> (. (.. with macro stuff for shorter code (SWING is too-verbose), you are
> finding yourself at a problem with Runtime messages such as: "No
> matching method found"
>
> Here is such case:http://paste.lisp.org/display/79061
>
> Try coming up with language to replace this clojure "LAP" (ahem java) code:
>
> (doto layout
> (.setHorizontalGroup
> (.. layout (createParallelGroup GroupLayout$Alignment/LEADING)
> (addGroup
> (.. layout (createSequentialGroup)
> (addContainerGap)
> (addGroup
> (.. layout (createParallelGroup GroupLayout$Alignment/LEADING)
> (addGroup
> (.. layout (createSequentialGroup)
> (addComponent temp-text-field
> GroupLayout/PREFERRED_SIZE
> GroupLayout/DEFAULT_SIZE
> GroupLayout/PREFERRED_SIZE)
> (addPreferredGap LayoutStyle$ComponentPlacement/RELATED)
> (addComponent celsius-label)))
> (addGroup
> (.. layout (createSequentialGroup)
> (addComponent convert-button)
> (addPreferredGap LayoutStyle$ComponentPlacement/RELATED)
> (addComponent fahrenheit-label)))))
> (addContainerGap 27 Short/MAX_VALUE)))))
>
> with something less verbose.
This is very verbose and quite un-lispy. However, I must say I suspect
it's hardly Clojure's fault. In ABCL, if you use the basic API for
calling Java, you might end up with something like that, if not
something more verbose. Of course this being Lisp you can define your
own abstractions over Swing (in fact, I'm doing precisely that on
ABCL). Also I like to use MIG layout for Swing (http://
www.miglayout.com/), which is a layout manager that allows to specify
component layout declaratively, using a css-like language. This plays
nicely with Lisp's declarative side, imho.
> FYI: The Original Java version for refference:
>
> http://java.sun.com/docs/books/tutorial/uiswing/examples/learn/Celsiu...
>
> I guess it could be done, if you do it at once, but if you start
> iteratively - e.g. experiment various ideas then you can't. You can't do
> it bottom up. You do have to start with a concrete plan.
>
> For example try replacing (createParallelGroup
> GroupLayout$Alignment/LEADING) with something like (pg :leading)
>
> Either macro or function. In macro case I was not able to get it
> compiled, in function one - it was giving runtime exception.
>
> Here is my attempt:
>
> (def group-alignment-conversion
> {:leading GroupLayout$Alignment/LEADING,
> :baseline GroupLayout$Alignment/BASELINE})
>
> (defn pg [alignment]
> {:tag GroupLayout$ParallelGroup}
> (group-alignment-conversion alignment))
I can't really comment on this, I don't fully understand it - I don't
know Clojure. The only thing I note is that in pg you're not calling
createParallelGroup, while the code you're replacing does. Maybe this
is the problem?
> You would also need this changed from the paste above:
>
> (import '(javax.swing JComponent JFrame JLabel JTextField JButton
> GroupLayout GroupLayout$Alignment SwingConstants LayoutStyle
> LayoutStyle$ComponentPlacement GroupLayout$ParallelGroup)
> '(java.awt.event ActionListener)
> '(java.awt Component))
>
> So with Clojure/SWING I would miss my dear LispWorks's CAPI :)
Heh, I don't know CAPI, in fact I know very little GUI-related besides
Swing. Do you think writing something using CAPI could give me
enlightenment? :D
Hth,
Alessio
Raffael Cavallaro <················@gmail.com> wrote:
+---------------
| Paul Donnelly <·············@sbcglobal.net> wrote:
| > What's another example of a way in which Clojure's design is tied to the
| > JVM?
...
| If you haven't already done so, work with clojure a bit. I think
| you'll see java leaking through a fair amount. The overall impression
| is of a language that was molded to the jvm, not an independent design
| - like scheme for example - that just happens to be hosted on the jvm.
+---------------
Hmmm... So maybe that's why RH is "waiting for the JVM to have TCO"
instead of just doing TCO in the Clojure language with whatever code
generation hacks (trampoline loops, stack hacks, etc.) are necessary
to wedge TCO onto the JVM the way SISC & Kawa & JScheme & Stella,
etc., etc., did long ago [without "waiting for the JVM"]. And just
like MzScheme & ChickenScheme, etc., did without waiting for C to
get TCO.
If TCO were important to Clojure's desired target community, it *could*
be added *now*, but it might seriously complicate the internals of the
current Clojure implementation. I would suspect, on the evidence presented
in this group so far, that TCO is simply not really that important in
the Clojure world, much as it's simply not that important in the Common
Lisp world, either. Is that so bad?!?
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Apr 24, 9:10 pm, ····@rpw3.org (Rob Warnock) wrote:
> I would suspect, on the evidence presented
> in this group so far, that TCO is simply not really that important in
> the Clojure world, much as it's simply not that important in the Common
> Lisp world, either. Is that so bad?!?
It isn't bad that tco is relatively unimportant to the clojure
community. It is bad that language design is so closely tied to a
single platform - the jvm. I've given other examples of this in my
reply to Paul Donnelly.
From: André Thieme
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <gsuk56$v8l$1@news.motzarella.org>
Raffael Cavallaro schrieb:
> On Apr 24, 4:14 pm, Paul Donnelly <·············@sbcglobal.net> wrote:
>
>> What's another example of a way in which Clojure's design is tied to the
>> JVM?
>
> All clojure objects are java objects. These clojure objects can be
> coerced to java primitive types. In fact they need to be so coerced if
> you want certain things to run quickly. Seems to me that this - the
> java object/primitive type distinction makes clojure as much a java
> with lisp syntax as an independent lisp language design.
When you say that Clojure objects are Java objects under the hood this
is basically right. I think what you really mean is that they are JVM
objects.
How is the situation for Scheme implementations on the JVM.
As you put them into a special position in previous posts I would think
that it is different for them. But at the first glimpse I don't know how
those implementations could put data into anything else but the JVM data
structures.
If that is the case (Scheme implementations on the JVM also use JVM
objects under the hood) then your point is not valid or interesting,
because it would be true for all other Lisps as well. SBCL threads under
Linux for example are also just OS threads. As Linux is written in C,
what does this mean for SBCL?
> Using clojure libraries requires wrestling with the brokenness that is
> java's classpath workings. This will seem quite natural if you come
> from java land and want first and foremost for your code to be a good
> java citizen, but painfully pointless otherwise.
This is in my opinion a better point.
The classpath stuff is not what Lispers are used to, and it would be
cool if it could somehow magically work.
But I would like to use an argument here, that is often used when new
people come to CL, or pretty much any other language:
the classpath issue sucks to some extent, but it is a newbie issue.
People who seriously do programming are only a short time newbies.
As you and I mention the classpath issue as a sucky thing at the first
moment (we are coming from CL), others (coming from Java or C#) would
point out how much the parens suck. But you and I don't see them anymore
and the guys coming from Java don't even notice the classpath issue, as
they left this newbie stuff behind, long time ago.
> If you haven't already done so, work with clojure a bit. I think
> you'll see java leaking through a fair amount. The overall impression
> is of a language that was molded to the jvm, not an independent design
> - like scheme for example - that just happens to be hosted on the jvm.
I personally didn't notice this so much. In the beginning it was bad, as
I had to figure out how to get Emacs+Slime running with Clojure, and how
this classpath issue works, etc. But it took me longer to get Slime+CL
running for the first time (2004 or so?).
People can easily go around that today, simply by using Enclojure. They
install NetBeans and add the Enclojure plugin. Then they can start.
If they have some libs they want to use they simply click on a button
and add all .jar files and directories they want. In Enclojure you set
the namespace and under the hood it makes sure that everything goes into
the right directory. Those people then click the green Play-button and
have their application running. They also get a .jar file with their
program that can be distributed to friends and be doubleclicked there.
Okay, non-trivial programs won't be that easy, but it is nice to get
started, and not caring about some basic beginners issues.
http://www.enclojure.org/
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On Apr 25, 5:12 am, André Thieme <address.good.until.
···········@justmail.de> wrote:
> When you say that Clojure objects are Java objects under the hood this
> is basically right. I think what you really mean is that they are JVM
> objects.
> How is the situation for Scheme implementations on the JVM.
> As you put them into a special position in previous posts I would think
> that it is different for them. But at the first glimpse I don't know how
> those implementations could put data into anything else but the JVM data
> structures.
> If that is the case (Scheme implementations on the JVM also use JVM
> objects under the hood) then your point is not valid or interesting,
> because it would be true for all other Lisps as well. SBCL threads under
> Linux for example are also just OS threads. As Linux is written in C,
> what does this mean for SBCL?
The fact that they are jvm objects is not the issue. The fact that
they can have a dual identity as objects and primitive types, which
dual identity comes directly from this distinction in the java
language/jvm shows that clojure is as much a java with lisp syntax as
an independent language design that just happens to be hosted on the
jvm.
On Apr 24, 7:21 pm, Raffael Cavallaro <················@gmail.com>
wrote:
> On Apr 24, 4:14 pm, Paul Donnelly <·············@sbcglobal.net> wrote:
>
> > What's another example of a way in which Clojure's design is tied to the
> > JVM?
>
> All clojure objects are java objects.
And in Clojure/CLR they are all CLR objects, and in ClojureScript,
Javascript objects. That's kind of the point. Clojure is a hosted
Lisp.
> These clojure objects can be
> coerced to java primitive types. In fact they need to be so coerced if
> you want certain things to run quickly. Seems to me that this - the
> java object/primitive type distinction makes clojure as much a java
> with lisp syntax as an independent lisp language design.
Most Lisps let you talk about machine-word sized numbers at some
point. This is no different.
> If you haven't already done so, work with clojure a bit. I think
> you'll see java leaking through a fair amount. The overall impression
> is of a language that was molded to the jvm, not an independent design
> - like scheme for example - that just happens to be hosted on the jvm.
SISC already exists. People that prefer that can use it. The core of
Clojure that doesn't expose the host specifically is at least as large
as Scheme. People that want to avoid platform issues can write in it.
You can use the core data structures and libraries with no mention of
Java, and the same code will run unchanged on Clojure/CLR. If enough
people want to do that, more wrappers will be written encapsulating
more of Java/CLR to enlarge the base. If they don't, they won't. OTOH,
there are many for whom the ability to grab a Java library and use it
transparently, unencapsulated, right now, is very productive. They are
making programs that do useful things. Are they wrong? Should they
wait for some purer language to make portable versions of all of the
libraries they need? Will there be no tradeoffs for them if they do?
Clojure is an exercise in looking at these VMs as hosts, and providing
language-level facilities to access them.
Will there be differences between Clojure on different hosts? There
will. Will there be code that runs unchanged on all? Certainly. Will
there be code which is designed to leverage the specifics of the
platform which could never port? Of course. Is there value to be able
to write in a single language to target these specific platforms? Very
much yes, IMO. Clojure/Java and Clojure/CLR will be much more
compatible than Java/C#. That's a big deal for people targeting both
(e.g. consultants), where no single application will need to run on
both, but from project to project they need to move their skills and
some libraries, while being able to fully leverage client and platform
assets, with no excuses. Making a language that fully hides/unifies
the differences is a non-objective of Clojure, and a fool's errand
IMO.
Ported Schemes (on the CLR/JVM) show another approach (small standard
language + bridge libraries), but it's not significantly different.
Code written to the core is portable, code that touches the platforms
isn't. In general, my feeling is that the interop and performance is
never as good. That's one reason why people are so excited about
Clojure, in spite of the existence of Kawa/SISC/ABCL etc. But I would
never argue that in principle one approach is right and the other not.
They produce different tradeoffs - let people choose based upon what
makes sense for them. That's a fine thing. I don't consider this a
zero-sum game. I'm hoping to grow the space for Lisps in general.
Rich
On Apr 25, 2:22 pm, Rich Hickey <··········@gmail.com> wrote:
> there are many for whom the ability to grab a Java library and use it
> transparently, unencapsulated, right now, is very productive. They are
> making programs that do useful things. Are they wrong?
Absolutely not. My only point in this discussion has been the point
you yourself make:
> Clojure is an exercise in looking at these VMs as hosts, and providing
> language-level facilities to access them.
So clojure is designed to provide language-level facilities to access
the features of the jvm (what I have been calling a "java with lisp
syntax") as much as it is an independent language design that just
happens to be hosted on the jvm (as, for example scheme or common lisp
are).
On Apr 25, 3:16 pm, Raffael Cavallaro <················@gmail.com>
wrote:
> On Apr 25, 2:22 pm, Rich Hickey <··········@gmail.com> wrote:
>
> > there are many for whom the ability to grab a Java library and use it
> > transparently, unencapsulated, right now, is very productive. They are
> > making programs that do useful things. Are they wrong?
>
> Absolutely not. My only point in this discussion has been the point
> you yourself make:
>
> > Clojure is an exercise in looking at these VMs as hosts, and providing
> > language-level facilities to access them.
>
> So clojure is designed to provide language-level facilities to access
> the features of the jvm (what I have been calling a "java with lisp
> syntax") as much as it is an independent language design that just
> happens to be hosted on the jvm (as, for example scheme or common lisp
> are).
My point and your point are not the same. Clojure is not "java with
lisp syntax" just because it provides access to Java things. Few
languages are designed to run on imaginary hosts with no limitations.
We wouldn't be talking about TCO if the lack of it didn't cause
ongoing allocation of an exhaustible resource on all current hosts.
Languages and their libraries have printing facilities, streams,
threads, GUIs etc all of which are defined on top of, and bound by the
limitations of, some lower level services not in the language itself.
So, it's more a matter of encapsulation. If a language allows for
unencapsulated access to a host resource it doesn't make that language
the host.
"Java with Lisp syntax" is saying much more than that, and is quite a
slight. Java doesn't have first-class functions, closures, persistent
collections, a reader, code-as-data, macros, a large sequence-based
library, destructuring, multimethods, etc. The models for code in the
2 languages are very different. You can write non-trivial libraries
completely with Clojure's core (see e.g. clojure.contrib.datalog) that
have nothing to do with Java. For a point of comparison, contrast
Clojure with Linj.
Will Clojure on the CLR be "C# with Lisp syntax"? If it were merely
that, you would expect no possible portability between the two, as C#
and Java are incompatible. Yet clojure.contrib.datalog will run just
fine. If Common Lisps provide really great transparent C FFI's does
that make them "C with Lisp syntax"? Of course not. Clojure is not
Java with Lisp syntax, it's a Lisp with a great Java FI (note the
missing F).
Languages that completely encapsulate the hosts don't let you fully
utilize them, only the subset they've generalized. The idea behind
Clojure is: that's not very productive. So, when on a JVM host you can
do JVM things, when on the CLR, CLR things, when in the browser,
browser things, as transparently as we can make that happen.
I find these theoretical arguments quite tiresome, so here's some of
the code that puts Clojure data literals into Amazon's SimpleDB
service:
(defn put-attrs [client domain item]
(let [item-name (sdb-str (:sdb/id item))
attrs (map (fn [[k v]]
(make-replaceable-attribute (to-sdb-str k) (to-
sdb-str v) false))
(item-attrs item))]
(put-attributes client (make-put-attributes-request domain item-
name attrs))))
and a client call, putting a Clojure map with a nested set in Amazon's
cloud:
(put-attrs client "test"
{:sdb/id (uuid),
:category "Clothes",
:subcat "Pants",
:Name "Sweatpants",
:color #{"Yellow" "Pink" "Blue"},
:size "Large"})
Oops, sorry, it's actually:
(defn put-attrs [client domain item]
(let [item-name (sdb-str (:sdb/id item))
attrs (map (fn [[k v]]
(ReplaceableAttribute. (to-sdb-str k) (to-sdb-str
v) false))
(item-attrs item))]
(.putAttributes client (PutAttributesRequest. domain item-name
attrs))))
Yes, three of the function names look funky
(ReplaceableAttribute. .putAttributes PutAttributesRequest.), because,
I didn't write them. They happen to have been written, documented and
tested by Amazon folks (and have thousands of users). I'm quite
thrilled to be able to reuse them like this. Sure, I could waste my
time writing yet another implementation of Amazon's HTTP protocol and
the SimpleDB API, including the socket and security bits, and test and
document it myself, before getting around to the thing I was trying to
do, but life is too short.
This looks and feels like Lisp to me: the use of map and
destructuring, to-sdb-str is a multimethod, the resulting fn is first-
class etc. Less apparent but quite important is the ability to pass
the lazy sequence returned by map, and Clojure strings and numbers,
directly to the Java API.
Clojure lets you access Java with Lisp syntax, but Clojure is not
Java.
Rich
The extent to which clojure transparently wraps java and therby gains
much of its useful functionality from the jvm and available libraries
is the extent to which clojure's "java-nature" is what is interesting
and useful about it. The extent to which clojure is a lisp dialect
independent of the jvm is the extent to which its "lisp-nature" is
what is interesting and useful.
My point (not yours) is that this means that much (not all) of what
makes clojure interesting and useful is its "java-nature" not its
"lisp nature." This is what I (not you) mean when I say that clojure
is as much a "java with lisp syntax" as an independent lisp language
design that just happens to be hosted on the jvm.
This means that clojure is decidely less interesting if the jvm is or
becomes less interesting as a platform. From a lisp perspective, this
is more than a little disconcerting.
On 26 abr, 17:24, Raffael Cavallaro <················@gmail.com>
wrote:
> The extent to which clojure transparently wraps java and therby gains
> much of its useful functionality from the jvm and available libraries
> is the extent to which clojure's "java-nature" is what is interesting
> and useful about it. The extent to which clojure is a lisp dialect
> independent of the jvm is the extent to which its "lisp-nature" is
> what is interesting and useful.
>
> My point (not yours) is that this means that much (not all) of what
> makes clojure interesting and useful is its "java-nature" not its
> "lisp nature." This is what I (not you) mean when I say that clojure
> is as much a "java with lisp syntax" as an independent lisp language
> design that just happens to be hosted on the jvm.
>
> This means that clojure is decidely less interesting if the jvm is or
> becomes less interesting as a platform. From a lisp perspective, this
> is more than a little disconcerting.
I think that the different among Lisp, Clojure, Qi and Ruby is not so
big. What we need is a lot of libraries that allow us to
do the work quickly and easily.
The more good libraries are build the more we win. Let's make lisp
and clojure be the next java (for the enterprise)
Recently reading about the creation of science, there is the
importance of a social group to lead the improvement.
We need a strong group to succeed. That's all. We don't need to be
so purist about the language, let's be practical, construct the bridge
to go from one Lisp to another.
From: Tamas K Papp
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <75jeu6F17bt6gU1@mid.individual.net>
On Sun, 26 Apr 2009 08:39:17 -0700, camposdeviento wrote:
> I think that the different among Lisp, Clojure, Qi and Ruby is not
> so big.
How did Ruby end up in that list?
> What we need is a lot of libraries that allow us to do the work
> quickly and easily.
What _I_ need is a language which makes it very easy for me to develop
new code (you can call some of it "libraries") reliably and rapidly.
If all you do is wrapping other people's libraries in some glue code,
then I am happy for you (no, actually I am not), but our needs do not
coincide.
> We need a strong group to succeed. That's all. We don't need to be
> so purist about the language, let's be practical, construct the
> bridge to go from one Lisp to another.
What you are saying doesn't make much sense. Details matter, that's
why people argue about these things. Hackneyed phrases about bridges
aren't of much use, you need to say something specific.
Tamas
From: Pascal Costanza
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <75ocsqF19djaaU1@mid.individual.net>
camposdeviento wrote:
> On 26 abr, 17:24, Raffael Cavallaro <················@gmail.com>
> wrote:
>> The extent to which clojure transparently wraps java and therby gains
>> much of its useful functionality from the jvm and available libraries
>> is the extent to which clojure's "java-nature" is what is interesting
>> and useful about it. The extent to which clojure is a lisp dialect
>> independent of the jvm is the extent to which its "lisp-nature" is
>> what is interesting and useful.
>>
>> My point (not yours) is that this means that much (not all) of what
>> makes clojure interesting and useful is its "java-nature" not its
>> "lisp nature." This is what I (not you) mean when I say that clojure
>> is as much a "java with lisp syntax" as an independent lisp language
>> design that just happens to be hosted on the jvm.
>>
>> This means that clojure is decidely less interesting if the jvm is or
>> becomes less interesting as a platform. From a lisp perspective, this
>> is more than a little disconcerting.
>
> I think that the different among Lisp, Clojure, Qi and Ruby is not so
> big. What we need is a lot of libraries that allow us to
> do the work quickly and easily.
That's not necessarily the most important property of a language ecosystem.
> The more good libraries are build the more we win. Let's make lisp
> and clojure be the next java (for the enterprise)
The problem with Java being a mainstream language is that it is a
mainstream language. I don't want any language to be mainstream.
> Recently reading about the creation of science, there is the
> importance of a social group to lead the improvement.
If this is to the extent that the language underneath doesn't matter
anymore, I'm not in it.
> We need a strong group to succeed. That's all. We don't need to be
> so purist about the language, let's be practical, construct the bridge
> to go from one Lisp to another.
If I wouldn't care about the details of the language I'm using, I'd
stick to Java, or some other arbitrary language that allows me to get
something done. But I do care.
I prefer Common Lisp over Clojure because I think the details that _I_
care about are better designed in Common Lisp than in Clojure, as far as
I can tell.
This is not to convince anyone to drop Clojure. This is to convince you
that we shouldn't mindlessly flock around the most popular language of
the day just because of its popularity.
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: André Thieme
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <gt23lj$8ic$1@news.eternal-september.org>
Raffael Cavallaro schrieb:
> The extent to which clojure transparently wraps java and therby gains
> much of its useful functionality from the jvm and available libraries
> is the extent to which clojure's "java-nature" is what is interesting
> and useful about it. The extent to which clojure is a lisp dialect
> independent of the jvm is the extent to which its "lisp-nature" is
> what is interesting and useful.
Could you be more detailed what the java-natuare and lisp-nature is?
You put those terms into quotes, which might be an indicator that you
ask readers of your posting to use their understanding of the context.
I am not so sure however that I fully grasp what that context is.
Are there also other natures in Clojure? Such as a jvm-nature, or a
cpu-nature?
> My point (not yours) is that this means that much (not all) of what
> makes clojure interesting and useful is its "java-nature" not its
> "lisp nature." This is what I (not you) mean when I say that clojure
> is as much a "java with lisp syntax" as an independent lisp language
> design that just happens to be hosted on the jvm.
Is the point that you stated above your personal opinion?
Or is it your opinion that this is the opinion for most people?
> This means that clojure is decidely less interesting if the jvm is or
> becomes less interesting as a platform. From a lisp perspective, this
> is more than a little disconcerting.
And if the jvm is or becomes even more interesting as a platform, would
that also mean that Clojure would become more interesting? (for you?)
When Clojure gets ported to .NET, can we then add the interest in those
two plattforms? If that is the case, and if it is true what you say,
then Clojure could become one of the most interesting languages.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On Apr 26, 12:55 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Could you be more detailed what the java-natuare and lisp-nature is?
The java-nature are those aspects of the language that are the way
they are because of the nature of the platform. Things like the need
to deal with classpath, the dual identity of primitive type/object,
the absence of tco (others with more experience with clojure might
think of other things, I don't know).
The lisp-nature are those aspects of the language that have nothing to
do with the fact that clojure runs on the jvm, and everything to do
with the history of lisp. Things like macros, sequence functions, a
fairly minimal and fully parenthesized syntax.
> And if the jvm is or becomes even more interesting as a platform, would
> that also mean that Clojure would become more interesting? (for you?)
Imagine a world where the only computers in existence only ran
software on the jvm, would that make clojure more or less interesting?
> When Clojure gets ported to .NET, can we then add the interest in those
> two plattforms? If that is the case, and if it is true what you say,
> then Clojure could become one of the most interesting languages.
Only if it were the *same* exact language on both platforms. To the
extent that it were tailored to each platform and were in that way
different on each platform it would be distinctly less interesting to
me. This is the whole point of the conversation - the extent to which
clojure has been tailored to the jvm *specifically* rather than
existing as an independent language that just happens to run on the
jvm.
From: Madhu
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <m3ws974e0u.fsf@moon.robolove.meer.net>
* Rich Hickey <····································@v1g2000prd.googlegroups.com> :
Wrote on Sun, 26 Apr 2009 07:26:40 -0700 (PDT):
| "Java with Lisp syntax" is saying much more than that, and is quite a
| slight. Java doesn't have first-class functions, closures, persistent
| collections, a reader, code-as-data, macros, a large sequence-based
| library, destructuring, multimethods, etc. The models for code in the
| 2 languages are very different. You can write non-trivial libraries
| completely with Clojure's core (see e.g. clojure.contrib.datalog) that
| have nothing to do with Java. For a point of comparison, contrast
| Clojure with Linj.
Greenspunned java applications added each of those functionalities on a
as-required basis. The key point is "should run on JVM". Clojure seems
to abstract all those useful functionalities (useful in a JVM
environment), add some adhoc lisp-like syntax and pretend these are
designed from from first principles. But really, it just implements a
DSL for MP and MP constructs which are provided by the platform it runs
on (so far, the JVM).
The datastructures which implement the single model of Multiprocessing
are written in Java, AIUI also the Clojure compiler is written in Java.
Clojure can thus be viewed as the DSL which lets you access those
datastructures. The MP benefits only come from exclusive use of those
datastructures (the situation is the same as any other MP model, all
code should consistently conform to the model). But it is just a model,
and a single paradigm of programming, and even if the claim that clojure
is a lisp is admitted, I'm willing to bet true lispers will feel they
are straightjacketed by both the langauge and platforms it runs on.
Library writing game gets tiresome after seeing it in a few languages,
but you are always likely to find new labour to port existing
functionality, available in other languages and enviroments, to your new
language for the first time.
--
Madhu
From: André Thieme
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <gt22p0$113$1@news.eternal-september.org>
Madhu schrieb:
> The datastructures which implement the single model of Multiprocessing
> are written in Java, AIUI also the Clojure compiler is written in Java.
How could it be different?
It needs to be bootstrapped.
And as Duane already mentioned: a complete rewrite of Clojure in Clojure
is planned. Soon what you just said will not be valid anymore, and in 15
years people will not think about it anymore.
> Clojure can thus be viewed as the DSL which lets you access those
> datastructures.
Any Lisp is just a DSL to access and work with CPU registers and hardware.
Is using with-open-file in principle writing assembler code in a DSL?
Sure it is.
But that is not the point.
We can not objectively agree how much abstraction is needed to not see
the underlying principles anymore. When I work with Clojure I can
completely forget Java, the programming language.
Really, this whole �Java with Lisp syntax� is an imaginary problem.
> even if the claim that clojure is a lisp is admitted, I'm willing
> to bet true lispers will feel they are straightjacketed by both the
> langauge and platforms it runs on.
You probably imply an existential quantifier here, and I would agree
to that. It is just a bit too much marketing for my taste, as you make
it sound as if this was in general that way.
Being a true lisper myself I must state that I feel the opposit.
Going back coding CL (which I have to do every few days) is not so nice.
I would of course still prefer writing CL over pretty much any language,
(if the work at hand is not a perfect fit for some other language).
At least I and some other experienced lispers that I know personally
found a true productivity win with Clojure.
That does of course not mean that CL is suddenly not an extremly good
programming language anymore. It certainly is!
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
From: Pascal J. Bourguignon
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <87hc0bbbho.fsf@galatea.local>
Andr� Thieme <······························@justmail.de> writes:
> Madhu schrieb:
>
>> The datastructures which implement the single model of Multiprocessing
>> are written in Java, AIUI also the Clojure compiler is written in Java.
>
> How could it be different?
> It needs to be bootstrapped.
> And as Duane already mentioned: a complete rewrite of Clojure in Clojure
> is planned. Soon what you just said will not be valid anymore, and in 15
> years people will not think about it anymore.
>
>
>> Clojure can thus be viewed as the DSL which lets you access those
>> datastructures.
>
> Any Lisp is just a DSL to access and work with CPU registers and hardware.
> Is using with-open-file in principle writing assembler code in a DSL?
You've not understood what a Domain Specific Language is.
Perhaps Clojure is not a DSL whose domain is the Java data structures,
but you've not argued against that.
I argue that Lisp is not a DSL to access CPU registers and hardware,
because anonymous functions (lambda) are not what our hardware and its
registers deal with.
--
__Pascal Bourguignon__
From: Madhu
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <m3skjv4a5s.fsf@moon.robolove.meer.net>
* André Thieme
Wrote on Sun, 26 Apr 2009 18:39:57 +0200:
| Madhu schrieb:
|
|> The datastructures which implement the single model of
|> Multiprocessing are written in Java, AIUI also the Clojure compiler
|> is written in Java.
|
| How could it be different? It needs to be bootstrapped. And as Duane
| already mentioned: a complete rewrite of Clojure in Clojure is
| planned. Soon what you just said will not be valid anymore, and in 15
| years people will not think about it anymore.
But unlike in real lisps, metacircularity will not have any advantage
for clojure. RH admitted as much to Pascal in february. It takes some
experience with lisp to grasp this point
|> Clojure can thus be viewed as the DSL which lets you access those
|> datastructures.
|
| Any Lisp is just a DSL to access and work with CPU registers and
| hardware. Is using with-open-file in principle writing assembler code
| in a DSL? Sure it is. But that is not the point.
Logic cannot disprove this and arguments similar to this, but common
sense and experience can.
Lispers are aware of this category of argument from the static typers,
from the scheme hygienists, and from semanticists; nothing new, and
hardly worth dealing with.
|> even if the claim that clojure is a lisp is admitted, I'm willing
|> to bet true lispers will feel they are straightjacketed by both the
|> langauge and platforms it runs on.
|
| You probably imply an existential quantifier here, and I would agree
| to that. It is just a bit too much marketing for my taste, as you make
| it sound as if this was in general that way. Being a true lisper
| myself I must state that I feel the opposit.
You have no idea what I'm talking about
---
Madhu
From: Madhu
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <m3prez49wj.fsf@moon.robolove.meer.net>
* André Thieme
Wrote on Sun, 26 Apr 2009 18:39:57 +0200:
| Madhu schrieb:
|
|> The datastructures which implement the single model of
|> Multiprocessing are written in Java, AIUI also the Clojure compiler
|> is written in Java.
|
| How could it be different? It needs to be bootstrapped. And as Duane
| already mentioned: a complete rewrite of Clojure in Clojure is
| planned. Soon what you just said will not be valid anymore, and in 15
| years people will not think about it anymore.
But unlike in real lisps, metacircularity will not have any advantage
for clojure. RH admitted as much to Pascal in february. It takes some
experience with lisp to grasp this point
|> Clojure can thus be viewed as the DSL which lets you access those
|> datastructures.
|
| Any Lisp is just a DSL to access and work with CPU registers and
| hardware. Is using with-open-file in principle writing assembler code
| in a DSL? Sure it is. But that is not the point.
Logic cannot disprove this and arguments similar to this, but common
sense and experience can.
Lispers are aware of this category of argument from the static typers,
from the scheme hygienists, and from semanticists; nothing new, and
hardly worth dealing with.
|> But it is just a [single multiprocessing] model, and a single
|> paradigm of programming,
|> even if the claim that clojure is a lisp is
|> admitted, I'm willing to bet true lispers will feel they are
|> straightjacketed by both the langauge and platforms it runs on.
|
| You probably imply an existential quantifier here, and I would agree
| to that. It is just a bit too much marketing for my taste, as you make
| it sound as if this was in general that way. Being a true lisper
| myself I must state that I feel the opposit.
You have no idea what I'm talking about
---
Madhu
On Apr 24, 2:35 pm, Raffael Cavallaro <················@gmail.com>
wrote:
> On Apr 23, 8:59 pm, ·····@franz.com wrote:
>
> > of course it's tied to the JVM; that's its main platform! Does sisc
> > or kawa being implemented on JVM make them Java? Of course not!
>
> <Sigh> once again, sisc and kawa did *not* compromise the semantics of
> the scheme language in order to conform to what is available on the
> JVM.
First off, let's be careful when talking about Kawa, which definitely
compromises the semantics of Scheme to various degrees:
http://groups.google.com/group/jvm-languages/msg/be24cb7f77844ae6?hl=en
http://groups.google.com/group/jvm-languages/msg/567c58d3d4cd84fc?hl=en
Like any pragmatic language designer, Per recognizes the existence of
tradeoffs. Compare the speed or Kawa (or Clojure) to SISC to see the
tradeoff in action. There's nothing wrong with this - that's what
tradeoffs are about, deciding one thing is worth more than another in
a certain context.
> Clojure *does*. This is A Bad Thing(TM) because it completely
> changes the desired [1] semantics of the language.
>
> [1] not *my* desired semantics, but the desired semantics of the
> language designer himself, Rich Hickey.
I desire lots of things. I can't have them all. I can deal with that,
so I make choices, and deal with those. It is important to note that
this is not a Java-specific limitation. Early versions of Clojure
targeted Java and C# source code, and in neither environment could I
get TCO from the target-native calling protocol (without superimposing
my own trampolines or whatever). Even earlier prototypes of Clojure
targeted Common Lisp (and future versions may once again), and there
too I can't get Scheme-like TCO guarantees from native calls. So you
might as well blame CL for Clojure's lack of TCO. It's not a
limitation of the JVM any more than many other high-level targets.
Another way to look at it is that Scheme's TCO and continuations
require deep support in order to be efficient, and, in the absence of
such support, superimposition of additional runtime infrastructure,
i.e. they are hard features to port. That's why whenever someone gets
these features to run on another platform they get to write a paper
about it, and why there are so many 'Schemes' that don't fully
implement Scheme. I *do* wish that weren't the case, but it *is*.
There will likely in the future be versions of Clojure that have
Scheme-like TCO guarantees. The MLVM already has a TCO patch, and when
I get some free time I'll get Clojure to target it. A CLR version of
Clojure that targeted CIL could emit the tail call instruction there.
People for whom tail calls are critical will be able to make a choice,
e.g. to use Clojure/MLVM/JDK7/8+ or Clojure/CLR/CIL, the tradeoff
being lack of JDK 6- or C#-source compatibility. They'll get good
performance *and* TCO. But I can't promise that everywhere, so had to
choose, and chose performance, interoperability and greater platform
reach. There is SISC et al for those who prefer the other choice.
People who choose TCO Clojure and rely upon TCO in their code will
have to accept reduced reach and portability as tradeoffs. That's
fine. Sounds like the real world to me - tradeoffs and choices abound.
Pure designs that sit in the corner by themselves have dramatically
less utility for people trying to get things done.
Rich
From: Madhu
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <m3iqkvn17f.fsf@moon.robolove.meer.net>
* ·····@franz.com
Wrote on Thu, 23 Apr 2009 00:50:09 -0700 (PDT):
|
|> | 1. Clojure is definitely a Lisp. Clojure has all the feel of a Lisp,
|> | though it definitely has more syntax than CL or Scheme.
|>
|> It is a lisp implemented in Java, rather than being a lisp which is
|> implemented in itself or another lisp. Once you start going deeper,
|> beyond the syntax, you'll see it lacks lisp nature, and instead you'll
|> see java backtraces.
|
| By that logic, Allegro CL isn't really a CL, because when you get down
| to the disassembler, you see x86-64 instructions (or x86, or sparc, or
| ...) - if you run our lisp under gdb, dbx, or windbg, you get what
| looks very little like lisp and a lot like the underlying architecture
| of the machine. And we even try to conform to binary runtime
| specifications where possible; it is always a good goal to have a
| compiler's targeted object code be interoperable with other languages.
Only if you take the logic too far. Pascal Costanza explained this
concern better in the first round of this in Feb. RH's answers did not
hold water then, and I'm surprised if an implementer could buy them now.
| Again, I'm going by what was told to me, and RH presents a very
| consistent story; his goal as he states it is to use the features of
| whatever underlying virtual machine he is compiling to, whether it be
| JVM, CLR, or any other such VM. Things he uses from the underlying VM
| are object systems and garbage-collectors, but he provides the
| compiler. I asked him about Clojure-written-in-Clojure, and he did
| say that they weren't there yet, but that that was indeed a goal of
| his and he had some people working on self-hosting the compiler.
|
|> I see more social engineering in this language's design than any
|> technical merit. Again this reeks more of java's design decisions than
|> the design in any lisp i've seen.
|
| I guess we're two blind Indians examining the same elephant and coming
| to different conclusions [1]. You see a lot of Java design
| decisions. I see a lot of CL influence.
Well look at the history of Common Lisp --- it was an effort at unifying
a whole bunch of lisps, so people could interoperate. Compare that with
clojure, which explicitly disclaims and renders impossible any
interoperability with common lisp. The design decisions to enforce this
are especially conspicuous, and are not accidental, it has to be
sufficiently different as a market decision, a lisp produced for the HR
market, basically catering to the ecosystem that is currently java.
In that regard it ought to be clear that the success of common lisp in
the niche it tries to fill would spell the end of clojure. [ I dont
especially care about that niche]
|> For someone who is not a blank-slate fresh adopter or who did not drink
|> the kool aid at the training camps, this is not a novelty
|
| Well, we'll see how it turns out, won't we?
If you're saying let the market decide, I'm not entering into any bets
on the intelligence of the target market to decide what is good for
them. I can only bet on the intelligence of the investors who can
exploit the target market for profit.
|> | 5. (this actually relates more to #1, above): Rich Hickey is now a
|> | member of the ALU (Association of Lisp Users) board and is active in
|> | promoting Lisp.
|>
|> Rich Hickey is obviously a very smart and clever guy. I wouldn't be
|> surprised if he got the lisp vendors into selling clj in the future :)
|
| CLJ? You mean JIL? (http://www.franz.com/support/documentation/
| current/doc/jil.htm)
| Or do you mean jlinker? (http://www.franz.com/support/documentation/
| current/doc/jlinker.htm)
That was tongue in cheek (more tongue in cheek to follow...), surely the
implication was clear that RH is an evil person who was clever enough to
make his way to the ALU board, hoodwinking otherwise knowledgable
lispers, so now he will define what is and is not "LISP" and be the
ultimate authority on all things LISP.
So the next step in ruling the world would be to get the lisp vendors to
replace their CL offerings with a better JVM based lisp. i.e. after
Oracle follows the logical next step of relicensing the JVM and deciding
the royalties. :-)
Sitting here I could help but wonder if the support and marketing that
otherwise rational cll folk do on RH's behalf is the result of some
misguided notion of Enlightened Self Interest. i.e. reasoning along the
lines of this is new, let us support it, it will help us. As an
observer of some other campaigns, I've seen some enthusiasts getting
buried instead.
| Perhaps I know what you really mean, based on your perspective, and
| no, it's not likely for us. We already have connectivity to Java and
| to the JVM, and of course I'm just speculating, but if we do anything
| with Clojure, it would likely be to provide or encourage a Clojure
| client for our Agraph triple-store (the server is written in CL, and
| we have CL, Java, Python, and C# clients), so a Clojure client isn't
| far-fetched, though I don't think there are any plans right now. But
| since Clojure is so Java oriented, perhaps it would Just Work (tm) as
| a Java client, or so CLR-oriented it would Just Work (tm) as a C#
| client.
|
|
| [1] As the parable goes, five blind Indians encountered an elephant
| and tried to describe it to each other. They ended up fighting over
| what the elephant looked like, because the one who felt its tail
| thought it was very much like a rope; the one who felt its leg thought
| it was like a tree trunk; the one who felt its ear thought it was like
| a canvas, the one who felt its trunk thought it was like a huge snake,
| and the one who felt it side thought it was like a wall. But in
| reality, they were all wrong, because it was the same elephant and had
| all of the characteristics described.
For your edification, Here is the concluding part of the parable from
fortunes-off/black-humour
The elephant, tiring of all this abuse, suddenly reared up and
attacked the men. He continued to trample them until they were
nothing but bloody lumps of flesh. Then, strolling away, the elephant
remarked, "It just goes to show that you can't depend on first
impressions. When I first saw them I didn't think they they'd be any
fun at all."
--
Madhu :)
On Apr 23, 2:55 am, Madhu <·······@meer.net> wrote:
> * ·····@franz.com
> Wrote on Thu, 23 Apr 2009 00:50:09 -0700 (PDT):
>
> |
> |> | 1. Clojure is definitely a Lisp. Clojure has all the feel of a Lisp,
> |> | though it definitely has more syntax than CL or Scheme.
> |>
> |> It is a lisp implemented in Java, rather than being a lisp which is
> |> implemented in itself or another lisp. Once you start going deeper,
> |> beyond the syntax, you'll see it lacks lisp nature, and instead you'll
> |> see java backtraces.
> |
> | By that logic, Allegro CL isn't really a CL, because when you get down
> | to the disassembler, you see x86-64 instructions (or x86, or sparc, or
> | ...) - if you run our lisp under gdb, dbx, or windbg, you get what
> | looks very little like lisp and a lot like the underlying architecture
> | of the machine. And we even try to conform to binary runtime
> | specifications where possible; it is always a good goal to have a
> | compiler's targeted object code be interoperable with other languages.
>
> Only if you take the logic too far. Pascal Costanza explained this
> concern better in the first round of this in Feb. RH's answers did not
> hold water then, and I'm surprised if an implementer could buy them now.
That whole thread was pretty long and tedious; can you point me to a
particular article where he gave these explanations?
> | Again, I'm going by what was told to me, and RH presents a very
> | consistent story; his goal as he states it is to use the features of
> | whatever underlying virtual machine he is compiling to, whether it be
> | JVM, CLR, or any other such VM. Things he uses from the underlying VM
> | are object systems and garbage-collectors, but he provides the
> | compiler. I asked him about Clojure-written-in-Clojure, and he did
> | say that they weren't there yet, but that that was indeed a goal of
> | his and he had some people working on self-hosting the compiler.
> |
> |> I see more social engineering in this language's design than any
> |> technical merit. Again this reeks more of java's design decisions than
> |> the design in any lisp i've seen.
> |
> | I guess we're two blind Indians examining the same elephant and coming
> | to different conclusions [1]. You see a lot of Java design
> | decisions. I see a lot of CL influence.
>
> Well look at the history of Common Lisp --- it was an effort at unifying
> a whole bunch of lisps, so people could interoperate. Compare that with
> clojure, which explicitly disclaims and renders impossible any
> interoperability with common lisp. The design decisions to enforce this
> are especially conspicuous, and are not accidental, it has to be
> sufficiently different as a market decision, a lisp produced for the HR
> market, basically catering to the ecosystem that is currently java.
Yes. We took a similar approach in JiL. The result was a language
that was very lisp-like (indeed, it uses Allegro CL as its compiler)
it had the parens, macros a la Common Lisp, and it compiles to JVM
byte codes, which allows interoperability with Java tools. The
problem is that it isn't compatible with Common Lisp, and so there is
an issue with finding an audience for it.
The approach we eventually took was a more traditional connection
approach, in jlinker. It doesn't pretend to operate on the JVM, and
instead just communicates with it. So then CL programmers who must
also commnicate with Java programs can do their programming in CL.
> In that regard it ought to be clear that the success of common lisp in
> the niche it tries to fill would spell the end of clojure. [ I dont
> especially care about that niche]
I don't view these as niches, any more than I view C/C++ programming
as a "niche". Common Lisp is a lisp-like, general purpose programming
language, whose popularity is always understated because of the
neuroticism of its user base. Clojure seems to be a lisp-like,
general purpose programming language, whose specific targets are
virtual machines.
> |> For someone who is not a blank-slate fresh adopter or who did not drink
> |> the kool aid at the training camps, this is not a novelty
> |
> | Well, we'll see how it turns out, won't we?
>
> If you're saying let the market decide, I'm not entering into any bets
> on the intelligence of the target market to decide what is good for
> them. I can only bet on the intelligence of the investors who can
> exploit the target market for profit.
Yes. You're referring to a sort of "mob psychology". But then, it
was similar mob psychology that elevated linux to where it was today,
and made it worthwhile for investors to figure out how to make money
from it. Whether RH can get the numbers he needs to get to some
critical mass like that ... well, we'll see.
> |> | 5. (this actually relates more to #1, above): Rich Hickey is now a
> |> | member of the ALU (Association of Lisp Users) board and is active in
> |> | promoting Lisp.
> |>
> |> Rich Hickey is obviously a very smart and clever guy. I wouldn't be
> |> surprised if he got the lisp vendors into selling clj in the future :)
> |
>
> | CLJ? You mean JIL? (http://www.franz.com/support/documentation/
> | current/doc/jil.htm)
> | Or do you mean jlinker? (http://www.franz.com/support/documentation/
> | current/doc/jlinker.htm)
>
> That was tongue in cheek (more tongue in cheek to follow...), surely the
> implication was clear that RH is an evil person who was clever enough to
> make his way to the ALU board, hoodwinking otherwise knowledgable
> lispers, so now he will define what is and is not "LISP" and be the
> ultimate authority on all things LISP.
>
> So the next step in ruling the world would be to get the lisp vendors to
> replace their CL offerings with a better JVM based lisp. i.e. after
> Oracle follows the logical next step of relicensing the JVM and deciding
> the royalties. :-)
Well, of course, if I were out to rule the world, I would certainly
try to gain the souls of the Lisp Vendors, because that's where all
the power lies.
:-)
> Sitting here I could help but wonder if the support and marketing that
> otherwise rational cll folk do on RH's behalf is the result of some
> misguided notion of Enlightened Self Interest. i.e. reasoning along the
> lines of this is new, let us support it, it will help us. As an
> observer of some other campaigns, I've seen some enthusiasts getting
> buried instead.
I see no smiley here, so I'm wondering if this was also tongue-in-
cheek. Either way, I'm flabbergasted that you can take what I'm
saying (even tongue-in-cheek) as marketing on RH's behalf. I'm just
having a conversation with you, just as Andre Thieme was, and my
reason for stepping into the conversation was to call to question your
extreme reaction to Mr Thieme. If you're going to start taking that
same position with me, as in any words in favor of Clojure
automatically being taken as marketing, then this conversation will
have been over.
Duane
From: Madhu
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <m3eivjm2n7.fsf@moon.robolove.meer.net>
* ·····@franz.com Wrote on Thu, 23 Apr 2009 09:40:44 -0700 (PDT):
|>
|> That was tongue in cheek (more tongue in cheek to follow...),
Too bad theres no envanal for usenet, but this was dynamic extent,
extending till the end of the article, and across any threads that are
called in the body
[snip]
|> Sitting here I could help but wonder if the support and marketing that
|> otherwise rational cll folk do on RH's behalf is the result of some
|> misguided notion of Enlightened Self Interest. i.e. reasoning along the
|> lines of this is new, let us support it, it will help us. As an
|> observer of some other campaigns, I've seen some enthusiasts getting
|> buried instead.
| I see no smiley here, so I'm wondering if this was also tongue-in-
| cheek. Either way, I'm flabbergasted that you can take what I'm
| saying (even tongue-in-cheek) as marketing on RH's behalf. I'm just
| having a conversation with you, just as Andre Thieme was, and my
| reason for stepping into the conversation was to call to question your
| extreme reaction to Mr Thieme. If you're going to start taking that
| same position with me, as in any words in favor of Clojure
| automatically being taken as marketing, then this conversation will
| have been over.
The first sentence was a general observation from discussions on CLL, it
is speculation and was not offered as absolute truth, The second
sentence makes no reference to this topic or any referenced issue.
Neither was directed specifically at you, each was offered as as a part
of the conversation for you to consider. OTOH, now that the purpose of
bringing to my attention the over-reaction is served, I'd rather the
conversation be over (from my side at least :)
--
Madhu
On Apr 23, 3:22 pm, Madhu <·······@meer.net> wrote:
> |> Sitting here I could help but wonder if the support and marketing that
> |> otherwise rational cll folk do on RH's behalf is the result of some
> |> misguided notion of Enlightened Self Interest. i.e. reasoning along the
> |> lines of this is new, let us support it, it will help us. As an
> |> observer of some other campaigns, I've seen some enthusiasts getting
> |> buried instead.
>
> | I see no smiley here, so I'm wondering if this was also tongue-in-
> | cheek. Either way, I'm flabbergasted that you can take what I'm
> | saying (even tongue-in-cheek) as marketing on RH's behalf. I'm just
> | having a conversation with you, just as Andre Thieme was, and my
> | reason for stepping into the conversation was to call to question your
> | extreme reaction to Mr Thieme. If you're going to start taking that
> | same position with me, as in any words in favor of Clojure
> | automatically being taken as marketing, then this conversation will
> | have been over.
>
> The first sentence was a general observation from discussions on CLL, it
> is speculation and was not offered as absolute truth, The second
> sentence makes no reference to this topic or any referenced issue.
> Neither was directed specifically at you, each was offered as as a part
> of the conversation for you to consider. OTOH, now that the purpose of
> bringing to my attention the over-reaction is served, I'd rather the
> conversation be over (from my side at least :)
Done!
Duane
From: namekuseijin
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <gsqhto$1jk2$1@adenine.netfront.net>
Madhu escreveu:
> Well look at the history of Common Lisp --- it was an effort at unifying
> a whole bunch of lisps, so people could interoperate. Compare that with
> clojure, which explicitly disclaims and renders impossible any
> interoperability with common lisp.
It's another Lisp dialect, like Scheme. Not Common Lisp sure. I think
they are allowed to go on their own way. I don't see people crying over
a lack of interoperability between Scheme and CL.
> The design decisions to enforce this
> are especially conspicuous, and are not accidental, it has to be
> sufficiently different as a market decision, a lisp produced for the HR
> market, basically catering to the ecosystem that is currently java.
Many languages today are targetting mature VMs like the JVM or
Microsoft's CLR as they both get portability to many platforms and very
good performance in the long run from the JIT compilers. Why should
Lisp be left out and all the while trying new things, like toning down
the parentheses a bit?
--
a game sig: http://tinyurl.com/d3rxz9
On Apr 23, 10:09 pm, namekuseijin <············@gmail.com> wrote:
> Madhu escreveu:
>
> > Well look at the history of Common Lisp --- it was an effort at unifying
> > a whole bunch of lisps, so people could interoperate. Compare that with
> > clojure, which explicitly disclaims and renders impossible any
> > interoperability with common lisp.
>
> It's another Lisp dialect, like Scheme. Not Common Lisp sure. I think
> they are allowed to go on their own way. I don't see people crying over
> a lack of interoperability between Scheme and CL.
>
> > The design decisions to enforce this
> > are especially conspicuous, and are not accidental, it has to be
> > sufficiently different as a market decision, a lisp produced for the HR
> > market, basically catering to the ecosystem that is currently java.
>
> Many languages today are targetting mature VMs like the JVM or
> Microsoft's CLR as they both get portability to many platforms and very
> good performance in the long run from the JIT compilers. Why should
> Lisp be left out and all the while trying new things, like toning down
> the parentheses a bit?
I think you should tone up your parenthesis a bit instead. They serve
as containment of several things... :)
Cheers
--
Marco
Marco Antoniotti escreveu:
> On Apr 23, 10:09 pm, namekuseijin <············@gmail.com> wrote:
>> Lisp be left out and all the while trying new things, like toning down
>> the parentheses a bit?
>
> I think you should tone up your parenthesis a bit instead. They serve
> as containment of several things... :)
I like them. They are an incredible aid in a proper editing
environment. Most people don't know such editing environments and
thus, dislike way too much parenthesis.
--
a game sig: http://tinyurl.com/d3rxz9
From: =?UTF-8?B?QW5kcsOpIFRoaWVtZQ==?=
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <gsn8mf$h3i$1@news.motzarella.org>
Madhu schrieb:
> * André Thieme <············@news.motzarella.org> :
> Wrote on Wed, 22 Apr 2009 14:36:09 +0200:
>
> |> This is unsolicited and false advertising. Just because you claim it
> |> doesnt make it so.
> |
> | You are wrong. I have experienced it myself, so I can do my statements
> | with pure conscience. After doing CL for six years and Clojure for
> | about half a year I have enough experience to come to my conclusions.
> | I am still not convinced that you wrote anything mentionable in
> | Clojure. So obviously I can not take your provoking and trollish
> | comments serious in any way.
>
Ah, another troll posting of you, like always.
It's very difficult to find anything else of you in this forum.
> I'll take your bait just this once because I'm sick and tired of your
> java posts on this lisp news group and I suspect others are weary too.
Then please add me to your ignore list.
> I suspect you know that I never wrote anything mentionable in Common Lisp.
Yes, I know it. You don't seem to have programmed in any language at all.
> You come across as a java programmer who had never understood what
> common lisp was about, or had the skills to use its capabilities. In all
> likelihood you programmed JAVA in Common Lisp for 6 years. From that
> point of view I can understand your enthuiasm for Clojure, because it is
> closer to your wavelength.
I have learned Java for about 3 months in 1999. In the past ten years I
have written maybe 200 LOC in Java.
How many LOC have you written in Clojure?
Obviously nothing.
You compare Lisp with Java, which is ridiculous. Clojure is a full
featured Lisp. It runs on a “operating system” that happens to support
other languages as well, such as Java. But you should go and read a bit
about it, and you can find out that Clojure is just a modern and clean
Lisp.
> If you are looking for a language designed for concurrency there is
> Erlang, and concurrent estrel etc. which are arguably better tools than
> clojure.
Depends on the situation. For some concurrency tasks Erlang is better
suited, when compared with the current version of Clojure.
Clojure+Terracotta changes the game again to some extent.
> However it is indeed likely that for less than average
> programmers clojure is indeed the best bet for concurrent programming
> because its creator is obviously a very clever guy, etc.
If that is true then it must be a perfect fit for you.
> Myself, I'm glad I stopped having to deal with java some than 5-6 years
> ago, for good.
Same with me. It was okay doing it for some weeks, ten years ago.
Since end of 2002 I am doing nearly exclusively Lisp.
Please stop implying that Clojure is similar to Java programming.
> This means avoiding the JVM technology as well as
> avoiding the JAVA ECOSYSTEM.
This makes no sense at all. Why should one explicitly avoid mature
technologies? Do you also ignore Unix or Windows?
> All Clojure wants is part of that ecosystem, I have no intention
> of jumping back by downloading a JVM to run Clojure.
Feel free to never do it. But then you should also understand that
people can not take your posts seriously that mention Clojure.
Having some competency about what you are talking would help.
> So while I can relate to your enthusiasm for clojure I cannot understand
> your constant efforts at marketing it on this newsgroup.
It is no marketing. That is just your interpretation.
I am suggesting people to solve problems with a system that is well
suited for that. These are on-topic posts in a Lisp forum.
Why don't you write lengthy replies to everyone here suggesting to use
CL? Isn't that marketing too? This is not a CL-only newsgroup, I hope
you are aware of that.
> Do you get
> paid per new convert fresh adopter (like the HR dweebs in the last java
> job I had would get 1K USD per every new java drone they recruited)
Maybe you have an unhealthy connection with CL that you feel personally
attacked whenever someone mentions a technology that has its roots in CL?
Why are you so scared about Clojure? CL does not get worse only because
there is Clojure. I even guess that Clojures existance will motivate the
vendors and OS devs to copy some of its features.
Hu, please don't always be so mad okay? Peace.
André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/
From: Madhu
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <m3vdown2pr.fsf@moon.robolove.meer.net>
* André Thieme <············@news.motzarella.org> :
Wrote on Wed, 22 Apr 2009 16:13:32 +0200:
[more dishonest marketing crap]
This was a risk I knew I had to take --- that you would take every
opportunity to pimp the language more, which is what I wanted to avoid
and defeats my purpose and intent, --- and I fell for it --- this one
time.
I'm afraid the only way to win with marketing people like you is to not
deal with you at all.
--
Madhu
From: Pascal Costanza
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <75obmjF191qheU1@mid.individual.net>
Andr� Thieme wrote:
> AJ Rossini schrieb:
>> Dear all -
>>
>> Is there any package that provides (or plans to provide) a general
>> interface to threaded or similar parallel-execution technologies (user
>> space message passing or user-space shared-mem) with the generality
>> being across the "free" lisps (I'd include things like the personal
>> editions from commercial vendors, since I'd like to be able to check
>> these as needed)?
>>
>> My current guess is that bordeaux-threads would be the best starting
>> point, but is anyone aware of a currently maintained package which
>> might be relevant in particular for multicore architectures? (it
>> looks like it's been dormant for a bit).
>>
>> Any pointers welcome!
>
> You mention bordeaux-threads, so mabye you are specifically interested
> in CL.
> If a different Lisp dialect would be okay then have a look at Clojure.
> Currently it's your best bet for writing concurrent applications.
Suggestion for improvement for future postings: "Best bet" implies that
other bets are worse. But they aren't. So: Try to avoid judgmental
statements, and you can avoid useless fights such as this one.
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: André Thieme
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <gt83ls$fhi$1@news.eternal-september.org>
Pascal Costanza schrieb:
> Suggestion for improvement for future postings: "Best bet" implies that
> other bets are worse. But they aren't. So: Try to avoid judgmental
> statements, and you can avoid useless fights such as this one.
When I consequently think along those lines it offers some surprising
conclusions. I was making my original statement with respect to the Lisp
languages (excluding Erlang or Haskell, which are also good candidates
to write concurrent apps in).
If it is true that Clojure is not better suited for writing concurrent
apps, then it must be worse or exactly as good as at least one other
Lisp. And that sounds very surprising, even when I don't consider my
personal experience, where I have seen myself that Clojure is indeed
better suited. So, not regarding that I find it surprising that although
Rich Hickey put a lot of work and very much focus on concurrency into
Clojure, he ended up with a Lisp dialect that is not better suited in
its core competency than any of the existant ones, which were not
designed explicitly with concurrency in mind.
Your suggestion about judgmental statements confuses me, as only a few
minutes after you wrote that suggestion you told us things in a
different posting that implies judgements, such as that mainstream
languages have problems, or that Clojures design might not be as good
as CLs.
In general I find it funny what crazy people are hanging around in
usenet. Some of you are nearly as crazy as I am ;-)
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
From: Dimiter "malkia" Stanev
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <gt8a5e$vmi$1@malkia.motzarella.org>
Andr� Thieme wrote:
> Pascal Costanza schrieb:
>
>> Suggestion for improvement for future postings: "Best bet" implies
>> that other bets are worse. But they aren't. So: Try to avoid
>> judgmental statements, and you can avoid useless fights such as this one.
>
> When I consequently think along those lines it offers some surprising
> conclusions. I was making my original statement with respect to the Lisp
> languages (excluding Erlang or Haskell, which are also good candidates
> to write concurrent apps in).
> If it is true that Clojure is not better suited for writing concurrent
> apps, then it must be worse or exactly as good as at least one other
> Lisp. And that sounds very surprising, even when I don't consider my
> personal experience, where I have seen myself that Clojure is indeed
> better suited. So, not regarding that I find it surprising that although
> Rich Hickey put a lot of work and very much focus on concurrency into
> Clojure, he ended up with a Lisp dialect that is not better suited in
> its core competency than any of the existant ones, which were not
> designed explicitly with concurrency in mind.
>
> Your suggestion about judgmental statements confuses me, as only a few
> minutes after you wrote that suggestion you told us things in a
> different posting that implies judgements, such as that mainstream
> languages have problems, or that Clojures design might not be as good
> as CLs.
>
> In general I find it funny what crazy people are hanging around in
> usenet. Some of you are nearly as crazy as I am ;-)
>
>
> Andr�
I'm still thorn whether multi-threading/processing should involve
sharing the data or not.
For example, had it been that fork() worked everywhere (Windows that
means YOU), then if you bite the bullet and decide that no-sharing is
better, then you don't really need your Common Lisp implementation to
support real threads (ok, green threads just for couroutines are fine,
but they are almost orthogonal to the real ones). And off course
something portable to talk each other (pipes, network, even files).
As for lisps - there have been some great ones, that you can find only
in books and simulations - for example StarLisp (*Lisp) on the
Connection Machine, and there's been lots of different schemes/lispoids
that have been targeting various ways of handling multi-threading, etc.
I even have a book full of publications from Japanese universities
exactly on that topic (additionally it includes various GC schemes that
work for multi-threading), etc.
On Apr 28, 4:32 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Pascal Costanza schrieb:
>
> > Suggestion for improvement for future postings: "Best bet" implies that
> > other bets are worse. But they aren't. So: Try to avoid judgmental
> > statements, and you can avoid useless fights such as this one.
>
> When I consequently think along those lines it offers some surprising
> conclusions. I was making my original statement with respect to the Lisp
> languages (excluding Erlang or Haskell, which are also good candidates
> to write concurrent apps in).
> If it is true that Clojure is not better suited for writing concurrent
> apps, then it must be worse or exactly as good as at least one other
> Lisp. And that sounds very surprising, even when I don't consider my
> personal experience, where I have seen myself that Clojure is indeed
> better suited. So, not regarding that I find it surprising that although
> Rich Hickey put a lot of work and very much focus on concurrency into
> Clojure, he ended up with a Lisp dialect that is not better suited in
> its core competency than any of the existant ones, which were not
> designed explicitly with concurrency in mind.
Clojure is indeed designed with concurrency in mind, but it is further
designed with the constraints that pure functional programming allows,
such as immutable data. Some view that constraint as a positive, and
some as a negative.
> Your suggestion about judgmental statements confuses me, as only a few
> minutes after you wrote that suggestion you told us things in a
> different posting that implies judgements, such as that mainstream
> languages have problems, or that Clojures design might not be as good
> as CLs.
Maybe judgement calls can be made without being judgmental; Clojure
and CL are designed with different views of the programmers that will
use them. CL is, I believe, more open, because it supports many
different styles besides functional programming. And although it is
clearly harder to make truly concurrent a CL than a functional
language, we in the CL world believe that it is a worthwhile endeavor.
> In general I find it funny what crazy people are hanging around in
> usenet. Some of you are nearly as crazy as I am ;-)
Maybe crazy like a fox...
Duane
From: André Thieme
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <gta7g7$7ad$1@news.eternal-september.org>
·····@franz.com schrieb:
> On Apr 28, 4:32 pm, Andr� Thieme <address.good.until.
> ···········@justmail.de> wrote:
>> Pascal Costanza schrieb:
>>
>>> Suggestion for improvement for future postings: "Best bet" implies that
>>> other bets are worse. But they aren't. So: Try to avoid judgmental
>>> statements, and you can avoid useless fights such as this one.
>> When I consequently think along those lines it offers some surprising
>> conclusions. I was making my original statement with respect to the Lisp
>> languages (excluding Erlang or Haskell, which are also good candidates
>> to write concurrent apps in).
>> If it is true that Clojure is not better suited for writing concurrent
>> apps, then it must be worse or exactly as good as at least one other
>> Lisp. And that sounds very surprising, even when I don't consider my
>> personal experience, where I have seen myself that Clojure is indeed
>> better suited. So, not regarding that I find it surprising that although
>> Rich Hickey put a lot of work and very much focus on concurrency into
>> Clojure, he ended up with a Lisp dialect that is not better suited in
>> its core competency than any of the existant ones, which were not
>> designed explicitly with concurrency in mind.
>
> Clojure is indeed designed with concurrency in mind, but it is further
> designed with the constraints that pure functional programming allows,
> such as immutable data. Some view that constraint as a positive, and
> some as a negative.
In principle there are not really big constraints.
Like OCaml, F# and Erlang Clojure is considered an imperative language
with some nice features for functional programming, from the point of
a Haskell programmer.
All data can easily be mutated in Clojure. I agree that this requires
a few more key strokes. For example compare:
(defvar *counter* 0)
...
(infc *counter*)
...
(setf *counter* 0)
vs
(def *counter* (atom 0))
...
(swap! *counter* inc)
...
(reset! *counter* 0)
However, this will not have consequences for the productivity or the
readability of the code.
The disadvantage in the Clojure version is that it runs slower.
The advantage is: it works correctly, even when suddenly many threads
modify the counter, and although the programmer did not think about this
when she first came up with *counter*.
As soon a CL implements a STM that uses Multi Version Concurrency
Control with adaptive history queues for snapshot isolation it will
have the same performance hits, as well as the correctness.
I personally say it is okay to have a minor performance hit, but in
exchange code that is oriented on correctness on todays mainstream
computers.
So, from that perspective I don't see constraints that come from the
fact that Clojure supports functional programming (by having one name-
space, 1st class function objects and lots of core functions that don't
mutate their arguments and provide support for lazy sequences).
>> Your suggestion about judgmental statements confuses me, as only a few
>> minutes after you wrote that suggestion you told us things in a
>> different posting that implies judgements, such as that mainstream
>> languages have problems, or that Clojures design might not be as good
>> as CLs.
>
> Maybe judgement calls can be made without being judgmental; Clojure
> and CL are designed with different views of the programmers that will
> use them. CL is, I believe, more open, because it supports many
> different styles besides functional programming.
Yes. I agree, but would still like to differentiate.
Mature CL implementations are more open because they directly ship with
CLOS. As Raffael said, there is CLOS like implementation for Clojure.
But that is neither standard nor mature.
Besides that, both, CL and CLJ support imperative programming, the
functional paradigm and declerative programming styles.
So, the core difference that I see is, that CL implementations allow
their users immediately to do OOP. There are also excellent support
tools, for example for aspect oriented programming.
Allegro for example ships with AllegroCache which just needs a simple
(require :acache), and suddenly we have a sweet new metaclass.
But if we leave CLOS aside, I don't see many hurdles to do very
flexible programming in Clojure. Some people may even think that the
multimethods of Clojure with their user provided dispatch function offer
some more flexibility.
Another nice feature CL offers is the Condition System.
Other things, such as symbol-macrolet are planned. CL already has that
toda�.
> And although it is
> clearly harder to make truly concurrent a CL than a functional
> language, we in the CL world believe that it is a worthwhile endeavor.
Yes, it would be great to see strong support for that.
I don't doubt a second that soon enough a mature STM will show up.
Maybe even shipping with Allegro. It is just the same argument from
above: CLJ already has that today, for CL it still is in the (near?)
future.
Maybe I should not say CL, but instead �some CL implementations�.
If Franz offers a STM then users can be pretty sure that it will be
a mature and performant system. That would bring at least Allegro
pretty much on par with Clojure in that regard.
It will take more time until open source CLs will follow.
Looking at the plans of AMD and Intel it seems obvious to me that
most major languages will �soon� offer their own STM.
The only disadvantage I personally see with that is that they may
continue to offer the same direct mutable access to memory as they
did in the past until today.
I am aware that this is also a speed advantage, such as the JVM
Hashtables in Clojure (which currently outperform most if not all
CLs) and other mutable data structures that are not concurrency
ready.
But if it is simpler to just use directly mutable datastructures,
and if all programmers are used to do that and still have that in
mind when thinking about their specific language, and having all
books containing only that material, then it means that still for
a long time software will run slowly on one core, or have a fair
chance of containing some mean concurrency bugs, as they do today.
So, even when a CL or Python comes with a STM, people will continue
not using it at all places where it is appropriate.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
From: Pascal Costanza
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <75qfp3F1a0kcaU1@mid.individual.net>
Andr� Thieme wrote:
> Pascal Costanza schrieb:
>
>> Suggestion for improvement for future postings: "Best bet" implies
>> that other bets are worse. But they aren't. So: Try to avoid
>> judgmental statements, and you can avoid useless fights such as this one.
>
> When I consequently think along those lines it offers some surprising
> conclusions. I was making my original statement with respect to the Lisp
> languages (excluding Erlang or Haskell, which are also good candidates
> to write concurrent apps in).
> If it is true that Clojure is not better suited for writing concurrent
> apps, then it must be worse or exactly as good as at least one other
> Lisp.
Or the different Lisps make different trade offs, so it depends on
several other factors under which circumstances one is better than the
other. But none of the Lisps are better for concurrency than others
under _all_ circumstances. That is what your statement seems to suggest,
and that is what I'm objecting to.
> Your suggestion about judgmental statements confuses me, as only a few
> minutes after you wrote that suggestion you told us things in a
> different posting that implies judgements, such as that mainstream
> languages have problems, or that Clojures design might not be as good
> as CLs.
The problem with mainstream languages is exactly that it is assumed that
these mainstream languages are good for all tasks under all
circumstances. That creates a lot of problems, IMHO.
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/
In some ways, I wish I never started this thread, but it did confirm
bordeaux-threads and suggested 2 other approaches to follow up with...
On Apr 29, 10:00 am, Pascal Costanza <····@p-cos.net> wrote:
> André Thieme wrote:
> > Your suggestion about judgmental statements confuses me, as only a few
> > minutes after you wrote that suggestion you told us things in a
> > different posting that implies judgements, such as that mainstream
> > languages have problems, or that Clojures design might not be as good
> > as CLs.
>
> The problem with mainstream languages is exactly that it is assumed that
> these mainstream languages are good for all tasks under all
> circumstances. That creates a lot of problems, IMHO.
I'm with Pascal on this one -- in some sense, all languages revert
down to machine code, so you ought to be able to do the same thing in
any (theoretically -- I know this is false from a practical/pragmatic
perspective).
But just as there are a range of tools to use, the problems to attack
with parallelism are also varied, to the extent that it is very
difficult to globally optimize the selection of tool which works for a
reasonable range of problems. (data size, bandwidth, memory,
computation unit load, levels of communication between computational
units, etc...).
In my prior work with interactive parallel language constructs (R's
SNOW, which provided the first general use, low-end tool for writing
fairly portable cluster code), we had a wonderful example of naive
implementation of a parallel algorithm driving a 40-fold slow-down
over the serial version. (and the parallelization wasn't obviously
wrong at first, second, or third glance; but required a mildly
sophisticated data-flow analysis).
There is a tool selection stage, but it always needs to be placed into
the constrained context of the problems to be solved.
From: André Thieme
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <gtenck$bmn$1@news.motzarella.org>
Pascal Costanza schrieb:
> Andr� Thieme wrote:
>> Pascal Costanza schrieb:
>>
>>> Suggestion for improvement for future postings: "Best bet" implies
>>> that other bets are worse. But they aren't. So: Try to avoid
>>> judgmental statements, and you can avoid useless fights such as this
>>> one.
>>
>> When I consequently think along those lines it offers some surprising
>> conclusions. I was making my original statement with respect to the Lisp
>> languages (excluding Erlang or Haskell, which are also good candidates
>> to write concurrent apps in).
>> If it is true that Clojure is not better suited for writing concurrent
>> apps, then it must be worse or exactly as good as at least one other
>> Lisp.
>
> Or the different Lisps make different trade offs, so it depends on
> several other factors under which circumstances one is better than the
> other. But none of the Lisps are better for concurrency than others
> under _all_ circumstances. That is what your statement seems to suggest,
> and that is what I'm objecting to.
I agree with you Pascal, and I can't oversee if Clojure is better suited
for concurrency under all circumstances. That I can not think about
cases where it is the other way around it does not mean that those cases
don't exist. So I admit that it is very possible that a CL implementation
could be better suited for concurrency in some cases.
My guess is that sooner or later many language implementations, including
CLs, will provide a STM or some other advanced mechanism for concurrency.
(I don't see why F#, Python or Groovy should not also get such a
mechanism in the near future (next coming years))
With such a system my statement would not be longer true. Then I would
say that they would be roughly the same in most cases.
It is just that I see right now that most CLs offer locks and mutexes
for concurrency. Those are also available in the JVM, as well as managed
Threadpools and futures and such. This is, to my knowledge, not typical
for CL implementations. Also there is a concurrent GC working on Suns
JVM, and the G1 is already available with beta status and looks very
promising. On top of that Clojure (well, the JVM) also offers its STM
with MVCC, refs, atoms and agents.
So, in principle I see that the mechanisms available for Clojure
programming with specific respect for concurrency seem to be a superset
of what CLs offer today. That game would change in the future. And well,
for ABCL that future is potentiall just one or two weeks of coding away.
It is just that *rigt now* I see that Clojure would beat CLs in
concurrency in basically all aspects. I don't say that it will stay that
way. I even say that Clojures existance might even speed up the process
in which CLs will also offer those tools.
That would be very good news for the Lisp world in my opinion.
>> Your suggestion about judgmental statements confuses me, as only a few
>> minutes after you wrote that suggestion you told us things in a
>> different posting that implies judgements, such as that mainstream
>> languages have problems, or that Clojures design might not be as good
>> as CLs.
>
> The problem with mainstream languages is exactly that it is assumed that
> these mainstream languages are good for all tasks under all
> circumstances. That creates a lot of problems, IMHO.
Okay, some (many?) people may even think about it that way.
I have also been confronted with quasi religious programmers who thought
that Lisp is "the best programming language for everything".
But besides that those mainstream languages also offer their own
advantageous and seem to be very attractive for many companies.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
From: Pascal Costanza
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <760vgkF1arolgU1@mid.individual.net>
Andr� Thieme wrote:
> Pascal Costanza schrieb:
>> Andr� Thieme wrote:
>>> Pascal Costanza schrieb:
>>>
>>>> Suggestion for improvement for future postings: "Best bet" implies
>>>> that other bets are worse. But they aren't. So: Try to avoid
>>>> judgmental statements, and you can avoid useless fights such as this
>>>> one.
>>>
>>> When I consequently think along those lines it offers some surprising
>>> conclusions. I was making my original statement with respect to the Lisp
>>> languages (excluding Erlang or Haskell, which are also good candidates
>>> to write concurrent apps in).
>>> If it is true that Clojure is not better suited for writing concurrent
>>> apps, then it must be worse or exactly as good as at least one other
>>> Lisp.
>>
>> Or the different Lisps make different trade offs, so it depends on
>> several other factors under which circumstances one is better than the
>> other. But none of the Lisps are better for concurrency than others
>> under _all_ circumstances. That is what your statement seems to
>> suggest, and that is what I'm objecting to.
>
> I agree with you Pascal, and I can't oversee if Clojure is better suited
> for concurrency under all circumstances. That I can not think about
> cases where it is the other way around it does not mean that those cases
> don't exist. So I admit that it is very possible that a CL implementation
> could be better suited for concurrency in some cases.
OK, good. Something to consider the next time around. ;)
> My guess is that sooner or later many language implementations, including
> CLs, will provide a STM or some other advanced mechanism for concurrency.
By now, I'm skeptical about STM. STM is at least not the final word
about support for concurrency. I find that data-parallel language
constructs are far more promising.
Of course, there are differences in use cases. But if the goal is to
take advantage of the speed of multicore processors, I doubt that STM
will be the right solution.
If you want to use STM to organizes task parallelism in such a way that
you don't have to use locks anymore, then that's quite unrelated to
whether there is a multicore processor underneath or not. And then,
there is of course the actor model, where you also don't need locks, but
also no STM.
So I don't think it's nearly as clear-cut as you seem to think it is.
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: André Thieme
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <gtfv7h$prg$1@news.motzarella.org>
Pascal Costanza schrieb:
> Andr� Thieme wrote:
>> My guess is that sooner or later many language implementations,
>> including CLs, will provide a STM or some other advanced mechanism
>> for concurrency.
>
> By now, I'm skeptical about STM. STM is at least not the final word
> about support for concurrency. I find that data-parallel language
> constructs are far more promising.
Those language constructs can be built in the presence of a STM.
> Of course, there are differences in use cases. But if the goal is to
> take advantage of the speed of multicore processors, I doubt that
> STM will be the right solution.
The STM reduces hard to find bugs and makes the programmer more productive.
The presence of a STM alone does not make program run in parallel. It is
still the programmer in Clojure who needs to use Agents and Futures (and
other mechanisms) as well as functions that run concurrently.
It's just very easy - I found myself not caring very much about how to
get things right, and where to put locks, etc.
> If you want to use STM to organizes task parallelism in such a way
> that you don't have to use locks anymore, then that's quite unrelated
> to whether there is a multicore processor underneath or not. And
> then, there is of course the actor model, where you also don't need
> locks, but also no STM.
Right.
Although Rich Hickey wrote already long time ago that he may decide to
add the actor model to Clojure as well. The actor model also has the
disadvantages of being more complex. For example Hickey writes:
�It is a much more complex programming model, requiring 2-message
conversations for the simplest data reads, and forcing the use of
blocking message receives, which introduce the potential for deadlock.
Programming for the failure modes of distribution means utilizing
timeouts etc. It causes a bifurcation of the program protocols, some of
which are represented by functions and others by the values of messages.�
http://clojure.org/state
> So I don't think it's nearly as clear-cut as you seem to think it is.
As I said in my previous post, I was comparing Clojure with CL
implementations.
In those I won't typically find a STM, data parallelism or Actors.
In Clojure however I find what CL offers (locks, mutexes) and
additionally a STM and some data parallel functions.
Also let's not forget Terracotta. I can scale my Clojure application
as I wish. Adding two or ten computers is not difficult. A load
balancer (or some other mechanism) can forward work to some machine,
and that has access to all the memory that all other machines have.
All boxes in the Cluster share the same data. There is no such thing
currently in the CL world.
(Only ABCL is a potential candidate that could be made ready for TC).
TC also comes with other advantages, but that is a different topic.
I can't think of examples where I would benefit of using CL to solve
a concurrency problem vs. using Clojure for that. But yes, I see that
it is possible that such cases exist.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
From: Madhu
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <m31vr81e8x.fsf@moon.robolove.meer.net>
* André Thieme <············@news.motzarella.org> :
Wrote on Sat, 02 May 2009 01:05:13 +0200:
[dishonest clojure marketing material snipped]
--
Madhu
From: =?UTF-8?B?QW5kcsOpIFRoaWVtZQ==?=
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <gtha9g$ked$1@news.motzarella.org>
On May 2, 7:20 am, André Thieme <address.good.until.
···········@justmail.de> wrote:
> ___________________________
> /| /| | |
> ||__|| | Please don't |
> / O O\__ feed |
> / \ the troll Madhu |
> / \ \ |
> / _ \ \ ----------------------
> / |\____\ \ ||
> / | | | |\____/ ||
> / \|_|_|/ | __||
> / / \ |____| ||
> / | | /| | --|
> | | |// |____ --|
> * _ | |_|_|_| | \-/
> *-- _--\ _ \ // |
> / _ \\ _ // | /
> * / \_ /- | - | |
> * ___ c_c_c_C/ \C_c_c_c____________
>
> André
> --
> Lisp is not dead. It’s just the URL that has changed:http://clojure.org/
I don't think you have a good sense of how much you, Andre, appear to
be a marketing troll for clojure. You may think that you're doing Rich
Hickey a favor, but I doubt he would agree.
--
Lisp is not dead. It's just Andre Thieme's sig that's misleading:
common lisp implementations:
<http://common-lisp.net/project/armedbear/> abcl
<http://clisp.cons.org/> clisp
<http://trac.clozure.com/openmcl/> clozure
<http://www.franz.com/downloads/> franz
<http://www.lispworks.com/> lispworks
<http://www.sbcl.org/> sbcl
<http://www.scieneer.com/scl/> scieneer
scheme implementations:
(too numerous to list individually; there are 52 listed here:)
<http://community.schemewiki.org/?scheme-faq-
standards#implementations>
other lisps:
<http://clojure.org/>
<http://www.newlisp.org/>
<http://www.thinlisp.org/>
From: André Thieme
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <gthind$bbq$1@news.motzarella.org>
Raffael Cavallaro schrieb:
> On May 2, 7:20 am, Andr� Thieme <address.good.until.
> ···········@justmail.de> wrote:
>> ___________________________
>> /| /| | |
>> ||__|| | Please don't |
>> / O O\__ feed |
>> / \ the troll Madhu |
>> / \ \ |
>> / _ \ \ ----------------------
>> / |\____\ \ ||
>> / | | | |\____/ ||
>> / \|_|_|/ | __||
>> / / \ |____| ||
>> / | | /| | --|
>> | | |// |____ --|
>> * _ | |_|_|_| | \-/
>> *-- _--\ _ \ // |
>> / _ \\ _ // | /
>> * / \_ /- | - | |
>> * ___ c_c_c_C/ \C_c_c_c____________
>>
>> Andr�
>> --
>> Lisp is not dead. It�s just the URL that has changed:http://clojure.org/
>
> I don't think you have a good sense of how much you, Andre, appear to
> be a marketing troll for clojure. You may think that you're doing Rich
> Hickey a favor, but I doubt he would agree.
I am certain he would not agree.
But neither am I doing marketing nor do I try to impress anyone or do
him/her a favour. I express my personal opinion. And I expect that
trolls like Hu jump in.
I don't want to provoke people, but it seems that some are so religiously
and emotionally attached to their *tool*, that they need to give me
personal advice, instead of keeping that out of the discussion.
There are about 5 people or so who are just not able to keep the word
"you" out of their postings, and try to educate people in public.
Not only me, but others as well.
It's especially the emotionally attached people who see my postings
as marketing. The problem lies in their brains, not in my texts.
How ever we put it, there will always be small groups of people who
will react like that. Some more intense, others less intense.
Obviously I am confronted mostly with people who percieve this as
an intense emotional situation.
I am aware that those people are (in some cases) highly intelligent
and experienced programmers. And I also see value in their
postings, even if they are sometimes a bit off.
For me I see no reasons why I should give up my opinion and let
those people decide how I have to write my postings.
Programming languages are tools and as such they evolve. Clojure
is a next step after CL, but it will not be the last one.
Point me to the next tool that evolved even more, and I will
happily study it. And post my opinions about it, whatever you, Hu
or even Rich Hickey may say and think about it.
Not allowing you to influence my percieved right to write the way
I like does not mean that I don't respect your opinions (I do
respect them, yours and Hickeys and even Hus), or that I also want to
take your right away to write in your style.
Peace.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On May 2, 9:44 am, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Not allowing you to influence my percieved right to write the way
> I like does not mean that I don't respect your opinions (I do
> respect them, yours and Hickeys and even Hus), or that I also want to
> take your right away to write in your style.
> Peace.
I don't wish to challenge anyone's right to post whatever they wish. I
just think that you should consider the distinct possibility that your
constant cheerleading for clojure actually makes clojure look lamer
than it would otherwise (fanboys have a way of doing that, doncha
know) and inflames a largely unnecessary antagonism between common
lisp users and clojure users.
regards,
Ralph
---
Lisp is not dead. It's just Andre Thieme's sig that's misleading:
common lisp implementations:
<http://common-lisp.net/project/armedbear/> abcl
<http://clisp.cons.org/> clisp
<http://trac.clozure.com/openmcl/> clozure
<http://www.franz.com/downloads/> franz
<http://www.lispworks.com/> lispworks
<http://www.sbcl.org/> sbcl
<http://www.scieneer.com/scl/> scieneer
scheme implementations:
(too numerous to list individually; there are 52 listed here:)
<http://community.schemewiki.org/?scheme-faq-
standards#implementations>
other lisps:
<http://clojure.org/>
<http://www.newlisp.org/>
<http://www.thinlisp.org/>
From: André Thieme
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <gtht7t$kk8$1@news.motzarella.org>
Raffael Cavallaro schrieb:
> On May 2, 9:44 am, Andr� Thieme <address.good.until.
> ···········@justmail.de> wrote:
>> Not allowing you to influence my percieved right to write the way
>> I like does not mean that I don't respect your opinions (I do
>> respect them, yours and Hickeys and even Hus), or that I also want to
>> take your right away to write in your style.
>> Peace.
>
> I don't wish to challenge anyone's right to post whatever they wish. I
> just think that you should consider the distinct possibility that your
> constant cheerleading for clojure actually makes clojure look lamer
> than it would otherwise (fanboys have a way of doing that, doncha
> know) and inflames a largely unnecessary antagonism between common
> lisp users and clojure users.
c.l.l has a huge history of cheerleading CL. Did this make CL look
worse than it is? When someones mentions the advantages of CL over
some language XYZ, do you then also go and hunt them down, trying to
make them stop expressing their opinion and talk about their personal
experience?
It's just a small group of people who drift away from a technical
discussion and become personal. I don't see those speaking for the
many thousand readers of this newsgroup.
People made false claims about Clojure. I prefer to address them.
Some for example thought the issue about missing TCO in the JVM
is worse than it actually is. Some tried to explain that Clojure
is basically Java with a lisp syntax.
And there were other false claims.
I got positive private emails about my postings, so there are not
only people who feel that this is marketing.
After all, this is not a forum exclusively for Common Lisp.
Only because the majority of people here are Common Lispers
(including me) there is no need to discriminate the minority of people
who talk about the advantages that Clojure has over CL, may those
advantages be real or personally percieved that way.
That's unfair :(
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On May 2, 9:43 am, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Raffael Cavallaro schrieb:
>
> > On May 2, 9:44 am, André Thieme <address.good.until.
> > ···········@justmail.de> wrote:
> >> Not allowing you to influence my percieved right to write the way
> >> I like does not mean that I don't respect your opinions (I do
> >> respect them, yours and Hickeys and even Hus), or that I also want to
> >> take your right away to write in your style.
> >> Peace.
>
> > I don't wish to challenge anyone's right to post whatever they wish. I
> > just think that you should consider the distinct possibility that your
> > constant cheerleading for clojure actually makes clojure look lamer
> > than it would otherwise (fanboys have a way of doing that, doncha
> > know) and inflames a largely unnecessary antagonism between common
> > lisp users and clojure users.
>
> c.l.l has a huge history of cheerleading CL.
There may be some CL cheerleading in c.l.l, but mostly it is not;
instead it is responses to critiques of CL. If there seems to be a
lot of that here, it's because there are a lot of critiques of CL, and
Lisp in general.
Did this make CL look
> worse than it is? When someones mentions the advantages of CL over
> some language XYZ, do you then also go and hunt them down, trying to
> make them stop expressing their opinion and talk about their personal
> experience?
Yes, in general, people who market their favorite version without it
being a response to critiques of the same, are generally criticized
for their marketing hype.
> It's just a small group of people who drift away from a technical
> discussion and become personal. I don't see those speaking for the
> many thousand readers of this newsgroup.
So here is some advice: don't be part of that group. Speak
technically, and only respond to criticisms of Clojure when they come
up. It will result in the dogs being called off...
> People made false claims about Clojure. I prefer to address them.
So you've addressed them. That is not what people are complaining
about. What they are complaining about is your tendency to turn every
conversation into one about Clojure, even when the subject wasn't
about Clojure at all. That tendency may hurt Clojure's reputation
here, but mostly it only hurts yours.
> After all, this is not a forum exclusively for Common Lisp.
No, but it is a technical forum, and you are moving quickly into
nontechnical areas. Some have said you already have been there, and
before the ILC conference, I believed them. But it was never your
arguments that convinced me; it was only the tutorial that convinced
me that what you were saying wasn't _all_ marketing hype, and I stood
up for your right to say the things you said. However, your technique
is ineffective, and I suggest you stop now, because you are only going
to cause yourself to be not listened to.
> Only because the majority of people here are Common Lispers
> (including me) there is no need to discriminate the minority of people
> who talk about the advantages that Clojure has over CL, may those
> advantages be real or personally percieved that way.
> That's unfair :(
What's unfair is to have to watch an increasing number of posts come
across this newsgroup that are based on arguments with you, who are
not at all an effective proponent of Clojure. I'd rather not have to
see it.
Duane
From: Pascal Costanza
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <763d6jF1atd0uU1@mid.individual.net>
Andr� Thieme wrote:
> Raffael Cavallaro schrieb:
>> On May 2, 9:44 am, Andr� Thieme <address.good.until.
>> ···········@justmail.de> wrote:
>>> Not allowing you to influence my percieved right to write the way
>>> I like does not mean that I don't respect your opinions (I do
>>> respect them, yours and Hickeys and even Hus), or that I also want to
>>> take your right away to write in your style.
>>> Peace.
>>
>> I don't wish to challenge anyone's right to post whatever they wish. I
>> just think that you should consider the distinct possibility that your
>> constant cheerleading for clojure actually makes clojure look lamer
>> than it would otherwise (fanboys have a way of doing that, doncha
>> know) and inflames a largely unnecessary antagonism between common
>> lisp users and clojure users.
>
> c.l.l has a huge history of cheerleading CL.
I heavily disagree. One of the key points that attracted me to the Lisp
(and Scheme) community is that they are typically very honest about
strengths and weaknesses of the respective dialects, and Lisp in
general. The various dialects are based on a long history of careful
thought about the different trade offs, and on a lot of practical
experience with actual usage. When you look at the various papers and
documents about the dialects, you typically find good discussions about
what is and isn't possible, what the reasons for certain design
decisions, what the limitations are one has to keep in mind, etc., etc.
This is also the case for most discussions in c.l.l. and c.l.s., with -
fortunately only few - exceptions.
My impression of Clojure is no different in that regard. Rich Hickey
seems very careful about discussing pros and cons, and acknowledges that
other dialects may be more appropriate in different circumstances.
What we don't need are the cheerleaders and hooray-sayers you typically
find more often in other language communities, especially of hyped
languages. This may increase short-term popularity, but can as well have
negative effect in the long run - exactly when the next best hyped
language waits around the corner to replace the current one.
I believe the fundamental principles behind the various Lisp dialects
make them in general the better languages. But apart from that, the fact
remains that different languages have their respective strengths and
weaknesses and that none is better suited than others under all
circumstances.
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: Benjamin Tovar
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <87r5z7fx46.fsf@the.google.mail.thing>
André Thieme <······························@justmail.de> writes:
> ___________________________
> /| /| | |
> ||__|| | Please don't |
> / O O\__ feed |
> André
*plonk*
--
Benjamin Tovar
From: Kaz Kylheku
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <20090513054145.374@gmail.com>
On 2009-05-02, Benjamin Tovar <······················@the.google.mail.thing> wrote:
> André Thieme <······························@justmail.de> writes:
>
>> ___________________________
>> /| /| | |
>> ||__|| | Please don't |
>> / O O\__ feed |
>> André
>
> *plonk*
Two months ahead of you:
%Score created by slrn on Mon Mar 2 00:35:40 2009
[*]
Score: =-9999
%Expires:
% Subject: Re: Road to Clojure Survey
From: André Thieme <···································@justmail\.de>
% References: <··············@news\.motzarella\.org>
% Xref: news\.motzarella\.org comp\.lang\.lisp:30204507
% Newsgroup: comp\.lang\.lisp
%EOS
From: Petter Gustad
Subject: Re: threading and multicore on the "free" lisps -- any unified interface similar to CFFI for FFI?
Date:
Message-ID: <87tz4732sj.fsf@pangea.home.gustad.com>
AJ Rossini <··········@gmail.com> writes:
> Any pointers welcome!
Does anybody know what happened to NetCLOS and how usable it is?
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?