This is attempt #2 at generating code from bubble-sort in Qi to
Python. I think the output is looking quite Pythonesque (or maybe
less Lisp-flavoured) :). What do you think? (This is a sort of 'Does
my bum look big in this?' question. I'm sure Pythonistas would say
'yes').
The Qi source
(define bubble_sort
X -> (bubble_again_perhaps (bubble X) X))
(define bubble
[] -> []
[X] -> [X]
[X Y | Z] -> [Y | (bubble [X | Z])] where (> Y X)
[X Y | Z] -> [X | (bubble [Y | Z])])
(define bubble_again_perhaps
X X -> X
X _ -> (bubble_sort X))
# Python generated from Qi II via Quip; 19:49:30 25/4/2009
def bubble_sort(V966):
return bubble_again_perhaps(bubble(V966),V966)
def bubble(V967):
if V967 == []:
return []
else:
if iscons(V967) and V967[1:] == []:
return V967
else:
if iscons(V967) and iscons(V967[1:]) and V967[1] > V967[0]:
return cons(V967[1],bubble(cons(V967[0],V967[2:])))
else:
if iscons(V967) and iscons(V967[1:]):
return cons(V967[0],bubble(V967[1:]))
else:
return err("bubble")
def bubble_again_perhaps(V972,V973):
if V973 == V972:
return V973
else:
return bubble_sort(V972)
The system functions
def cons (x,y):
return [x] + y
def iscons (x):
return not(x == []) and type(x) == type([])
def err (x):
raise Exception("partial function: " + x)
iscons is my Python version of CONSP. I don't know if Python has some
faster test than this.
Mark
Mark Tarver <··········@ukonline.co.uk> writes:
> This is attempt #2 at generating code from bubble-sort in Qi to
> Python. I think the output is looking quite Pythonesque (or maybe
> less Lisp-flavoured)
Python people talk about `pythonic'.
> def bubble(V967):
> if V967 == []:
> return []
> else:
> if iscons(V967) and V967[1:] == []:
Using `elif' would certainly be prettier here. Should be a simple
transformation, I'd have thought, but it's a fairly trivial point.
> def iscons (x):
> return not(x == []) and type(x) == type([])
Ugh!
def iscons(x):
return type(x) is list and x
This is also likely to be more efficient. Remember that most operators
can be overloaded in Python, so your first `==' can do something
arbitrary here -- it might even raise an exception, which doesn't seem
right here! It also takes advantage of the fact that empty lists (and
only those) are false. The `is' operator is Python's EQ; `type([])' is
simply `list'.
I initially thought of using `isinstance', i.e., `return isinstance(x,
list) and x', but this also matches subclasses. This is more like
(typep x 'cons)
where the above is more like
(eq (class-of x) '#.(find-class 'cons))
The difference is more noticeable in Python because users are explicitly
allowed to define subclasses of builtin types like `list'.
-- [mdw]
On 25 Apr, 23:49, Mark Wooding <····@distorted.org.uk> wrote:
> Mark Tarver <··········@ukonline.co.uk> writes:
> > This is attempt #2 at generating code from bubble-sort in Qi to
> > Python. I think the output is looking quite Pythonesque (or maybe
> > less Lisp-flavoured)
>
> Python people talk about `pythonic'.
>
> > def bubble(V967):
> > if V967 == []:
> > return []
> > else:
> > if iscons(V967) and V967[1:] == []:
>
> Using `elif' would certainly be prettier here. Should be a simple
> transformation, I'd have thought, but it's a fairly trivial point.
>
> > def iscons (x):
> > return not(x == []) and type(x) == type([])
>
> Ugh!
>
> def iscons(x):
> return type(x) is list and x
>
> This is also likely to be more efficient. Remember that most operators
> can be overloaded in Python, so your first `==' can do something
> arbitrary here -- it might even raise an exception, which doesn't seem
> right here! It also takes advantage of the fact that empty lists (and
> only those) are false. The `is' operator is Python's EQ; `type([])' is
> simply `list'.
>
> I initially thought of using `isinstance', i.e., `return isinstance(x,
> list) and x', but this also matches subclasses. This is more like
>
> (typep x 'cons)
>
> where the above is more like
>
> (eq (class-of x) '#.(find-class 'cons))
>
> The difference is more noticeable in Python because users are explicitly
> allowed to define subclasses of builtin types like `list'.
>
> -- [mdw]
Right; I'll use your def. I'm learning Python on the fly off the
internet through code fragments. I'll post to them on some of these
issues and some others I'd like answered.
Mark
Mark,
I've been looking at Qi on and off for a few years now. Viewed your
Common Lisp for the 21st Century post and video, and after flirting
with Haskell for awhile have begun to dabble with Qi.
I have to say, I like Qi a lot. I cannot wait to use it on a real
project, and I intend to do so at the first opportunity. Qi deserves a
lot more attention that it gets.
Chris Perkins
www.medialab.com
On Apr 28, 5:53 pm, ···············@gmail.com wrote:
> Mark,
>
> I've been looking at Qi on and off for a few years now. Viewed your
> Common Lisp for the 21st Century post and video, and after flirting
> with Haskell for awhile have begun to dabble with Qi.
>
> I have to say, I like Qi a lot. I cannot wait to use it on a real
> project, and I intend to do so at the first opportunity. Qi deserves a
> lot more attention that it gets.
>
> Chris Perkinswww.medialab.com
I agree.
···············@gmail.com wrote:
> Mark,
>
> I've been looking at Qi on and off for a few years now. Viewed your
> Common Lisp for the 21st Century post and video, and after flirting
> with Haskell for awhile have begun to dabble with Qi.
>
> I have to say, I like Qi a lot. I cannot wait to use it on a real
> project, and I intend to do so at the first opportunity. Qi deserves a
> lot more attention that it gets.
>
> Chris Perkins
> www.medialab.com
We need a Challenger's Cup showdown between Clojure, Qi, and NewLisp
before CL crushes them in the final.
kxo
On Apr 29, 8:22 am, Kenneth Tilton <·········@gmail.com> wrote:
> ···············@gmail.com wrote:
> > Mark,
>
> > I've been looking at Qi on and off for a few years now. Viewed your
> > Common Lisp for the 21st Century post and video, and after flirting
> > with Haskell for awhile have begun to dabble with Qi.
>
> > I have to say, I like Qi a lot. I cannot wait to use it on a real
> > project, and I intend to do so at the first opportunity. Qi deserves a
> > lot more attention that it gets.
>
> > Chris Perkins
> >www.medialab.com
>
> We need a Challenger's Cup showdown between Clojure, Qi, and NewLisp
> before CL crushes them in the final.
>
> kxo
Are you really suggesting that CL is The Ultimate Programming
Language? That it is perfect and nothing better can come along? Or are
you just saying that Clojure, Qi and NewLisp are worse than CL?
MishoM wrote:
> On Apr 29, 8:22 am, Kenneth Tilton <·········@gmail.com> wrote:
>> ···············@gmail.com wrote:
>>> Mark,
>>> I've been looking at Qi on and off for a few years now. Viewed your
>>> Common Lisp for the 21st Century post and video, and after flirting
>>> with Haskell for awhile have begun to dabble with Qi.
>>> I have to say, I like Qi a lot. I cannot wait to use it on a real
>>> project, and I intend to do so at the first opportunity. Qi deserves a
>>> lot more attention that it gets.
>>> Chris Perkins
>>> www.medialab.com
>> We need a Challenger's Cup showdown between Clojure, Qi, and NewLisp
>> before CL crushes them in the final.
>>
>> kxo
>
> Are you really suggesting that CL is The Ultimate Programming
> Language?
Yes.
> That it is perfect...
No. But the issues are negligible.
>... and nothing better can come along?
Yes. Anything better will still have to be Common Lisp.
> Or are
> you just saying that Clojure, Qi and NewLisp are worse than CL?
I would not put it in terms of quality. Scheme* is perfect and useless,
for example. Common Lisp will simply trounce anything else in the long
run, with all successful ideas popularized by challengers absorbed into
The Ball.
kt
* Well, they are really still working on Scheme based on the last
standard so who knows what it will look like when it grows up. k
Qi _is_ Common Lisp. (or maybe is on top of, or is in) Think of it as
a big :around clause wrapping CL :-)
The Qi+Common Lisp love-in is one the primary reasons I like it.
Haskell is a great language. Their "write less, write better" approach
works for me. But as cool as it is would I ever use it for a real
project, instead of Common Lisp which I use professionally every
single day? No. As much as I like functional programming and think it
is a smart approach, I know it isn't the only approach and I worry
about being cornered.
But with Qi, running it right in my LispWorks enviro, I'm not trapped
at all. I've invited all the things I liked about Haskell into my Lisp
home. Cool.
Chris
On Apr 29, 8:37 am, ···············@gmail.com wrote:
> Qi _is_ Common Lisp. (or maybe is on top of, or is in) Think of it as
> a big :around clause wrapping CL :-)
>
> The Qi+Common Lisp love-in is one the primary reasons I like it.
Hmm. I haven't actually tried Qi, but I've read the docs, and I don't
understand your claim. Although Qi is implemented in CL and can call
out to it easily, it has its own syntax; it's not just a library that
adds optional typechecking along with backtracking, unification, and
other relevant functionality to CL. I can't take an existing CL
program and decorate it with type annotations and have Qi type-check
it. Can I? That's what I would require before considering Qi to be
an extension to CL rather than another language.
Just to put this into context, I used for years a language called
Refine which was implemented in CL. The ability to call out to CL and
to use the CL environment (e.g. the debugger) were very handy, but
there was no question that Refine was a distinct language, with its
own syntax and semantics (e.g. it was a single-namespace language, as
I believe Qi is).
Just asking for clarification here. If I have misunderstood the
relationship between Qi and CL, I would like to know.
-- Scott
On Apr 29, 5:42 pm, Scott Burson <········@gmail.com> wrote:
> Just asking for clarification here. If I have misunderstood the
> relationship between Qi and CL, I would like to know.
>
You understand it correctly. Qi is its own single-namespace language
with its own semantics, requirements, etc. It outputs Lisp. It seems
well integrated. I'm looking forward to starting my next new project
in it (whenever that is).
Chris
On Apr 29, 7:27 pm, ···············@gmail.com wrote:
> On Apr 29, 5:42 pm, Scott Burson <········@gmail.com> wrote:
>
> > Just asking for clarification here. If I have misunderstood the
> > relationship between Qi and CL, I would like to know.
>
> You understand it correctly. Qi is its own single-namespace language
> with its own semantics, requirements, etc. It outputs Lisp. It seems
> well integrated. I'm looking forward to starting my next new project
> in it (whenever that is).
Cool. Please fill us in on your experience.
-- Scott
On 30 Apr, 01:42, Scott Burson <········@gmail.com> wrote:
> On Apr 29, 8:37 am, ···············@gmail.com wrote:
>
> > Qi _is_ Common Lisp. (or maybe is on top of, or is in) Think of it as
> > a big :around clause wrapping CL :-)
>
> > The Qi+Common Lisp love-in is one the primary reasons I like it.
>
> Hmm. I haven't actually tried Qi, but I've read the docs, and I don't
> understand your claim. Although Qi is implemented in CL and can call
> out to it easily, it has its own syntax; it's not just a library that
> adds optional typechecking along with backtracking, unification, and
> other relevant functionality to CL. I can't take an existing CL
> program and decorate it with type annotations and have Qi type-check
> it. Can I? That's what I would require before considering Qi to be
> an extension to CL rather than another language.
>
> Just to put this into context, I used for years a language called
> Refine which was implemented in CL. The ability to call out to CL and
> to use the CL environment (e.g. the debugger) were very handy, but
> there was no question that Refine was a distinct language, with its
> own syntax and semantics (e.g. it was a single-namespace language, as
> I believe Qi is).
>
> Just asking for clarification here. If I have misunderstood the
> relationship between Qi and CL, I would like to know.
>
> -- Scott
I think that's about right. To summarise .....
Re: is Qi CL?
No. Qi is a seperate language from CL that happens (for good reason)
to be implemented in CL and draws a lot of philosophy from CL. But
that does not make it CL any more than writing New Jersey ML in C
makes ML = C. Qi evolved from the collective gene pool that is Lisp
(as did Edinburgh ML), but is a seperate species. The comment on the
bottom of
http://arclanguage.org/item?id=2323
is a good statement
Re: Is Qi a Lisp?
I would say it is not a Lisp in the sense that Clojure and NewLisp are
Lisps. However what is a Lisp? I'd say that there are two ideas -
shallow and deep. I can look at Clojure and NewLisp code and say 'Yep,
that's Lisp.' so the shallow concept of Lisp is - a Lisp is something
that a Lisp programmer can glance at on a page and say - 'Yes, that's
Lisp'. In the shallow sense, Qi is not a Lisp. It doesn't look
Lispy.
However there is a deep concept of a Lisp as being any language that
supports the following.
programs as data
recursion
garbage collection
arbitrary lists (in some form) as the primary construction
and Qi supports all those features. This distinction between shallow
and deep definitions of a Lisp is analogous to the distinction between
phenotype and genotype in biology. The phenotype of Qi is not in the
Lisp family. But the genotype, the DNA of the language if you like,
is in the Lisp family.
Re: Is CL the last word?
No. I think it would be unwise to underestimate the developments in
functional programming languages that became popular after CL was
standardised. IMO, inbuilt pattern matching (PM) is a boon and I
would really not consider writing a compiler (or most anything else)
without it. Paul Graham discussing this issue wrt Arc, argues that
pattern matching is dispensable because you only use it for
boilerplate functions (see link above). I find from experience that
this is false.
One obstacle to the general adoption of this feature has been that PM
is often tied to static typing of the ML kind. People who dislike the
constraints of static typing (ST) tend to associate PM with this
feature. However though, broadly, ST implies PM, PM does not imply
ST. Qi splits the two apart which is good.
Re: Python
Python does not have much to teach CL as a language; but it does have
a lot to teach the CL community as a success story. Guido made some
right moves and CL people did not. It is worth reflecting on what he
did that made Python such a success.
Mark
On Apr 30, 10:38 am, Mark Tarver <··········@ukonline.co.uk> wrote:
> Re: Python
>
> Python does not have much to teach CL as a language; but it does have
> a lot to teach the CL community as a success story. Guido made some
> right moves and CL people did not. It is worth reflecting on what he
> did that made Python such a success.
Aimed low?
On 30 Apr, 15:42, Raffael Cavallaro <················@gmail.com>
wrote:
> On Apr 30, 10:38 am, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > Re: Python
>
> > Python does not have much to teach CL as a language; but it does have
> > a lot to teach the CL community as a success story. Guido made some
> > right moves and CL people did not. It is worth reflecting on what he
> > did that made Python such a success.
>
> Aimed low?
LOL. There's something in that. However if you look at Guido's
original grant proposal he wanted to develop a language which appealed
to people; so literally you are right.
"CNRI proposes to undertake a research effort called Computer
Programming for Everybody (CP4E). This effort intends to improve the
state of the art of computer use, not by introducing new hardware, nor
even (primarily) through new software, but simply by empowering all
users to be computer programmers."
http://www.python.org/doc/essays/cp4e.html
This DARPA grant helped launch him.
Mark
Mark Tarver <··········@ukonline.co.uk> writes:
> On 30 Apr, 15:42, Raffael Cavallaro <················@gmail.com>
> wrote:
>> On Apr 30, 10:38�am, Mark Tarver <··········@ukonline.co.uk> wrote:
>>
>> > Re: Python
>>
>> > Python does not have much to teach CL as a language; but it does have
>> > a lot to teach the CL community as a success story. �Guido made some
>> > right moves and CL people did not. �It is worth reflecting on what he
>> > did that made Python such a success.
>>
>> Aimed low?
>
> LOL. There's something in that. However if you look at Guido's
> original grant proposal he wanted to develop a language which appealed
> to people; so literally you are right.
>
> "CNRI proposes to undertake a research effort called Computer
> Programming for Everybody (CP4E). This effort intends to improve the
> state of the art of computer use, not by introducing new hardware, nor
> even (primarily) through new software, but simply by empowering all
> users to be computer programmers."
>
> http://www.python.org/doc/essays/cp4e.html
>
> This DARPA grant helped launch him.
That's funny, because for the little I know of Python, it doesn't
strike me as an easy programming language for the masses. I'd imagine
a language totally different to let non programmers write programs.
But that said, if the result can be considered a success with respect
to this original purpose, that means that this is the last language to
be used by a programmer. This is exactly The programming language
that should NOT be taught in CS cursus. It might be taught to
chemists or secretaries, to _users_. But programmers must learn Lisp,
Prolog and Haskell, not Python.
Thanks for the quote, I know now that I will NEVER try to learn Python.
--
__Pascal Bourguignon__
On 30 Apr, 17:15, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Mark Tarver <··········@ukonline.co.uk> writes:
> > On 30 Apr, 15:42, Raffael Cavallaro <················@gmail.com>
> > wrote:
> >> On Apr 30, 10:38 am, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> >> > Re: Python
>
> >> > Python does not have much to teach CL as a language; but it does have
> >> > a lot to teach the CL community as a success story. Guido made some
> >> > right moves and CL people did not. It is worth reflecting on what he
> >> > did that made Python such a success.
>
> >> Aimed low?
>
> > LOL. There's something in that. However if you look at Guido's
> > original grant proposal he wanted to develop a language which appealed
> > to people; so literally you are right.
>
> > "CNRI proposes to undertake a research effort called Computer
> > Programming for Everybody (CP4E). This effort intends to improve the
> > state of the art of computer use, not by introducing new hardware, nor
> > even (primarily) through new software, but simply by empowering all
> > users to be computer programmers."
>
> >http://www.python.org/doc/essays/cp4e.html
>
> > This DARPA grant helped launch him.
>
> That's funny, because for the little I know of Python, it doesn't
> strike me as an easy programming language for the masses. I'd imagine
> a language totally different to let non programmers write programs.
>
> But that said, if the result can be considered a success with respect
> to this original purpose, that means that this is the last language to
> be used by a programmer. This is exactly The programming language
> that should NOT be taught in CS cursus. It might be taught to
> chemists or secretaries, to _users_. But programmers must learn Lisp,
> Prolog and Haskell, not Python.
>
> Thanks for the quote, I know now that I will NEVER try to learn Python.
>
> --
> __Pascal Bourguignon__- Hide quoted text -
>
> - Show quoted text -
Well, you might be against the flow there because Python seems
becoming fast the language of choice for teaching students. I mean
SICP has gone Python, OLPC went Python from go, and even my old dept.
has gone Python. Python newsgroup has overtaken CL some time back.
And actually, if I'm typical, its not hard to learn either.
http://www.cs.ubc.ca/wccce/Program03/papers/Toby.html gives some
insights on this.
Guido obviously got something right.
Mark
On 30 abr, 18:15, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Mark Tarver <··········@ukonline.co.uk> writes:
> > On 30 Apr, 15:42, Raffael Cavallaro <················@gmail.com>
> > wrote:
> >> On Apr 30, 10:38 am, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> >> > Re: Python
>
> >> > Python does not have much to teach CL as a language; but it does have
> >> > a lot to teach the CL community as a success story. Guido made some
> >> > right moves and CL people did not. It is worth reflecting on what he
> >> > did that made Python such a success.
>
> >> Aimed low?
>
> > LOL. There's something in that. However if you look at Guido's
> > original grant proposal he wanted to develop a language which appealed
> > to people; so literally you are right.
>
> > "CNRI proposes to undertake a research effort called Computer
> > Programming for Everybody (CP4E). This effort intends to improve the
> > state of the art of computer use, not by introducing new hardware, nor
> > even (primarily) through new software, but simply by empowering all
> > users to be computer programmers."
>
> >http://www.python.org/doc/essays/cp4e.html
>
> > This DARPA grant helped launch him.
>
> That's funny, because for the little I know of Python, it doesn't
> strike me as an easy programming language for the masses. I'd imagine
> a language totally different to let non programmers write programs.
>
> But that said, if the result can be considered a success with respect
> to this original purpose, that means that this is the last language to
> be used by a programmer. This is exactly The programming language
> that should NOT be taught in CS cursus. It might be taught to
> chemists or secretaries, to _users_. But programmers must learn Lisp,
> Prolog and Haskell, not Python.
>
> Thanks for the quote, I know now that I will NEVER try to learn Python.
>
> --
> __Pascal Bourguignon__
You would be surprised as how clever can be a chemist or a secretary
if you give them the correct tool for the problem.
I agree with you that if programming becames trivial them
you are going to be bad paid from programming, so I can
understand you prefer this not to be so.
Welcome to chemist and secretaries in the programming world.
I remind you that some Einstein can be a chemist or a secretary
and he could bring new ideas that Lispers don't dare to think
about.
camposdeviento <·············@gmail.com> writes:
> On 30 abr, 18:15, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> Mark Tarver <··········@ukonline.co.uk> writes:
>> > On 30 Apr, 15:42, Raffael Cavallaro <················@gmail.com>
>> > wrote:
>> > "CNRI proposes to undertake a research effort called Computer
>> > Programming for Everybody (CP4E). This effort intends to improve the
>> But that said, if the result can be considered a success with respect
>> to this original purpose, that means that this is the last language to
>> be used by a programmer. �This is exactly The programming language
>> that should NOT be taught in CS cursus. �It might be taught to
>> chemists or secretaries, to _users_. �But programmers must learn Lisp,
>> Prolog and Haskell, not Python.
>>
>> Thanks for the quote, I know now that I will NEVER try to learn Python.
>
> You would be surprised as how clever can be a chemist or a secretary
> if you give them the correct tool for the problem.
>
> I agree with you that if programming becames trivial them
> you are going to be bad paid from programming, so I can
> understand you prefer this not to be so.
>
> Welcome to chemist and secretaries in the programming world.
>
> I remind you that some Einstein can be a chemist or a secretary
> and he could bring new ideas that Lispers don't dare to think
> about.
Oh I don't worry the less if users start programming. The experience
so far has been that they just make more work for us real programmers.
Dr. House wouldn't have half the work he has if patients didn't try to
self "medicate" themselve.
--
__Pascal Bourguignon__
On May 1, 6:14 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> camposdeviento <·············@gmail.com> writes:
[...]
> > Welcome to chemist and secretaries in the programming world.
> > I remind you that some Einstein can be a chemist or a secretary
> > and he could bring new ideas that Lispers don't dare to think
> > about.
> Oh I don't worry the less if users start programming. The experience
> so far has been that they just make more work for us real programmers.
They'll make a lot less work for real programmers if they use
languages that are amenable to meta-programming. I'm in the process of
making the scientist->programmer transition, and a lot of what I've
done has been exactly the sort of work you describe. Treating user-
generated code as data and being able to create reasonably robust
syntactic abstractions for the users to use in the future has made me
*vastly* more efficient and helpful than I would be otherwise.
I also think that Common Lisp, with the right set of batteries
included in terms of libaries and with pleasant, newbie-friendly
editing environments[1], would be a perfectly reasonable language for
non-programmers. ISTR Stallman saying that secretaries who had to use
Emacs rapidly took to writing Emacs Lisp programs, and Emacs Lisp
doesn't differ from Common Lisp in ways that I think would be that
relevant to newbies.
Cheers,
Pillsy
[1] I like SLIME a great deal, and grow fonder of the LispWorks IDE
every time I use it, but neither is pitched at the programming
neophyte. It would be especially likely to work if non-programming
people were exposed to Common Lisp subsets used for scripting major
applications that they have to use anyway.
On May 1, 5:12 pm, Pillsy <·········@gmail.com> wrote:
> [1] I like SLIME a great deal, and grow fonder of the LispWorks IDE
> every time I use it, but neither is pitched at the programming
> neophyte. It would be especially likely to work if non-programming
> people were exposed to Common Lisp subsets used for scripting major
> applications that they have to use anyway.
take a look at ABLE
On Fri, 01 May 2009 12:14:08 +0200, Pascal J. Bourguignon wrote:
> camposdeviento <·············@gmail.com> writes:
>
>> On 30 abr, 18:15, ····@informatimago.com (Pascal J. Bourguignon) wrote:
>>> Mark Tarver <··········@ukonline.co.uk> writes:
>>> > On 30 Apr, 15:42, Raffael Cavallaro <················@gmail.com>
>>> > wrote:
>>> > "CNRI proposes to undertake a research effort called Computer
>>> > Programming for Everybody (CP4E). This effort intends to improve the
>>> But that said, if the result can be considered a success with respect
>>> to this original purpose, that means that this is the last language to
>>> be used by a programmer. This is exactly The programming language
>>> that should NOT be taught in CS cursus. It might be taught to
>>> chemists or secretaries, to _users_. But programmers must learn Lisp,
>>> Prolog and Haskell, not Python.
>>>
>>> Thanks for the quote, I know now that I will NEVER try to learn
>>> Python.
>>
>> You would be surprised as how clever can be a chemist or a secretary if
>> you give them the correct tool for the problem.
>>
>> I agree with you that if programming becames trivial them you are going
>> to be bad paid from programming, so I can understand you prefer this
>> not to be so.
>>
>> Welcome to chemist and secretaries in the programming world.
>>
>> I remind you that some Einstein can be a chemist or a secretary and he
>> could bring new ideas that Lispers don't dare to think about.
>
> Oh I don't worry the less if users start programming. The experience so
> far has been that they just make more work for us real programmers.
>
> Dr. House wouldn't have half the work he has if patients didn't try to
> self "medicate" themselve.
:-)
Scientist who don't have any formal training in programming routinely
program. There is no way out of it, some hire research assistants but
most of the time the overhead of communicating your needs to the RA,
let alone quality control issues, are just not worth it.
I thought about doing some CS courses, but I don't really see the
benefit, I think programming is best learned by doing and learning
from your mistakes (and I make a lot :-P). I actually asked around if
there are practical courses in CL, but I could find none in the
vicinity. And the CS people I asked thought I was crazy to learn CL
as a scientist, and recommended Fortran, C++ and (shudder) Java.
So I don't think it is similar to patients self-medicating themselves.
I would compare it to people who are going to distant lands where
there are no doctors trying to pick up a bit of medical knowledge so
they can get by.
Tamas
> Welcome to chemist and secretaries in the programming world.
>
> I remind you that some Einstein can be a chemist or a secretary
> and he could bring new ideas that Lispers don't dare to think
> about.
I might be wrong, but I vaguely remember that the median-cut algorithm
was sped up by a biologist, not a computer scientist, or software engineer.
So you never know :)
On Fri, 01 May 2009 17:10:19 -0700, "Dimiter \"malkia\" Stanev"
<······@mac.com> wrote:
>> Welcome to chemist and secretaries in the programming world.
>>
>> I remind you that some Einstein can be a chemist or a secretary
>> and he could bring new ideas that Lispers don't dare to think
>> about.
>
>I might be wrong, but I vaguely remember that the median-cut algorithm
>was sped up by a biologist, not a computer scientist, or software engineer.
>
>So you never know :)
There are always outstanding counter-examples - one of the best
algorithm designers I ever met was a EE. He was, however, not a
superb programmer.
The fact remains that most programmers are not terribly good at
algorithm design - or even at evaluating existing algorithms to decide
which to use. And the average is falling as more and more people
become programmers without the benefit of a CS education.
Not that CS makes up for a lack of math, but a decent CS program does
teach basic algorithm analysis and acquaints the student with a
variety of existing algorithms in several vital subject areas. This
at least forms a basis for going forward.
George
>>>>> "Mark" == Mark Tarver <··········@ukonline.co.uk> writes:
Mark> ... if you look at Guido's original grant proposal he wanted to
Mark> develop a language which appealed to people; so literally you are
Mark> right.
With the possible exception of TeX (and definite exception of intercal),
I do not think anybody ever set out to make something that was horrible
to use.
I do not think that Python succeeded because it was a design goal of
Guido, but rather than it was the right mix of scripting and programming
being in the right place at the right time. I haven't followed Python so
much, but peeking out from my hole, I believe its popularity grew out
of the Linux community which is comprised of scores of really smart and
hardworking geeks, fully able to embrace whatever quirks a newcomer such
as Python had.
Python happened to present itself (through luck or coincidence or
whatever) at a time where there was need for something stronger than
Perl and more convenient than C++. At least that was how it looked to
the casual observer of the Debian distro.
In that, Python merely has followed in the tracks of other languages
such as Perl, Java or Ruby which I also think has succeeded to a great
degree by being at the right place at the right time. Perl exploded in
the Unix community when sophisticated scripting was needed and people
was growing out of SH, Java appeared on the scene (in a visible way)
just when people had grown out of the static grey handcrafted html pages
and needed to make their websites more interactive and I think Ruby came
along to the web people much like Perl and Python had come to the
Unix/Linux toolers to fill the gap between pure scripting and heavy duty
programming.
------------------------+-----------------------------------------------------
Christian Lynbech | christian ··@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
On Apr 30, 11:42 am, Raffael Cavallaro <················@gmail.com>
wrote:
> On Apr 30, 10:38 am, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > Re: Python
>
> > Python does not have much to teach CL as a language; but it does have
> > a lot to teach the CL community as a success story. Guido made some
> > right moves and CL people did not. It is worth reflecting on what he
> > did that made Python such a success.
>
> Aimed low?
http://www.dreamsongs.com/WorseIsBetter.html
known for a long time...
On Apr 30, 7:38 am, Mark Tarver <··········@ukonline.co.uk> wrote:
> IMO, inbuilt pattern matching (PM) is a boon and I
> would really not consider writing a compiler (or most anything else)
> without it. Paul Graham discussing this issue wrt Arc, argues that
> pattern matching is dispensable because you only use it for
> boilerplate functions (see link above). I find from experience that
> this is false.
The other language I mentioned that was built on CL, Refine, had
pattern matching. I wrote a lot of Refine code back in the day and
would agree that pattern matching is a very handy feature, one I do
miss in CL, unquestionably. Nonetheless I would stop just short of
calling it essential. The correspondence between a pattern-matching
expression and the ordinary conditional it compiles into is just not
that complex.
-- Scott
On 30 Apr, 18:03, Scott Burson <········@gmail.com> wrote:
> On Apr 30, 7:38 am, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > IMO, inbuilt pattern matching (PM) is a boon and I
> > would really not consider writing a compiler (or most anything else)
> > without it. Paul Graham discussing this issue wrt Arc, argues that
> > pattern matching is dispensable because you only use it for
> > boilerplate functions (see link above). I find from experience that
> > this is false.
>
> The other language I mentioned that was built on CL, Refine, had
> pattern matching. I wrote a lot of Refine code back in the day and
> would agree that pattern matching is a very handy feature, one I do
> miss in CL, unquestionably. Nonetheless I would stop just short of
> calling it essential. The correspondence between a pattern-matching
> expression and the ordinary conditional it compiles into is just not
> that complex.
>
> -- Scott
Agreed. Actually the bit that is false in Paul's assessment is the
'only use it for boilerplate' - not the dispensable. Yes; you can
work without it but it makes programming so much harder. I mean take
a look at this which does a lot of the heavy lifting in Quip. The N
argument is an integer that controls the indenting.
(define lisp->python
[if P Q Else] N
-> (@c ["if " (lisp->python P N) ":" (nl (+ N 1)) (lisp->python Q
(+ N 1))
(nl N) "else:" (nl (+ N 1)) (lisp->python Else (+ N 1))])
[return X] N -> (@c ["return " (lisp->python X N)])
[Let [[X Y]] Z] N
-> (@c [(id X) " = " (lisp->python Y N) (nl N) (lisp->python Z N)])
where (= Let LET)
[Op X Y] N
-> (@c [(lisp->python X N) (infix Op) (lisp->python Y N)]) where
(infix? Op)
[Boolop W X Y | Z] N -> (lisp->python [Boolop W [Boolop X Y | Z]]
N)
where (element? Boolop [AND OR])
[qi::wrapper X] N -> (lisp->python X N)
[python-assign X Value] N
-> (@c ["global " (id X) (nl N) (id X) " = " (lisp->python Value
N)])
[do X] N -> (lisp->python X N)
[do X | Y] N -> (@c [(lisp->python X N) (nl N) (lisp->python [do |
Y] N)])
[value X] N -> (lisp->python X N)
[qi::f_error [_ X]] N -> (lisp->python [f_error (make-string "~A"
X)] N)
[qi::lazyderef X] N -> (lisp->python [lazyderef X] N)
[qi::+infs] N -> (lisp->python [infs_plus] N)
[apply F X] N -> (lisp->python [F X] N)
[Quote X] N -> (lisp->python (quote X) N) where (= Quote QUOTE)
[output X | Y] N -> (lisp->python [print [fstring X Y]])
[F] N -> (@c [(id F) "(" ")"])
[Car X] N -> (remove-car-cdr-chain 0 X N) where (element? Car [CAR
head])
[Cdr X] N -> (remove-cdr-chain 1 X N) where (element? Cdr [CDR
tail])
[Null X] N -> (@c [(lisp->python X N) " == []"]) where (or (= NULL
Null) (= empty? Null))
[F | X] N -> (@c [(id F) "(" (python-exprs X N) ")"])
[] _ -> "[]"
true _ -> True
false _ -> False
X _ -> (embed-string X) where (string? X)
X _ -> (embed-string (make-string "~C" X)) where (character? X)
X _ -> (id X))
Mark
On Apr 30, 10:14 am, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> Yes; you can
> work without it but it makes programming so much harder. I mean take
> a look at this which does a lot of the heavy lifting in Quip.
Yes, good example.
-- Scott
On Thu, 30 Apr 2009 10:03:14 -0700, Scott Burson wrote:
> On Apr 30, 7:38 am, Mark Tarver <··········@ukonline.co.uk> wrote:
>> IMO, inbuilt pattern matching (PM) is a boon and I would really not
>> consider writing a compiler (or most anything else) without it. Paul
>> Graham discussing this issue wrt Arc, argues that pattern matching is
>> dispensable because you only use it for boilerplate functions (see link
>> above). I find from experience that this is false.
>
> The other language I mentioned that was built on CL, Refine, had pattern
> matching. I wrote a lot of Refine code back in the day and would agree
> that pattern matching is a very handy feature, one I do miss in CL,
> unquestionably. Nonetheless I would stop just short of calling it
> essential. The correspondence between a pattern-matching expression and
> the ordinary conditional it compiles into is just not that complex.
And you can also use pattern matching libraries already available in
CL -- there is no need to change languages for that.
I find Haskell-like pattern matching handy for some problems, but most
of the time the amazing bind library is more than enough for me.
Tamas
On Apr 30, 10:15 am, Tamas K Papp <······@gmail.com> wrote:
> And you can also use pattern matching libraries already available in
> CL -- there is no need to change languages for that.
Yes, I have a copy of Faré-matcher, but haven't gotten around to
actually trying it. The kind of code I've been writing lately
wouldn't have much use for it. I'm sure that will change at some
point.
-- Scott
On Apr 30, 8:21 pm, Scott Burson <········@gmail.com> wrote:
> On Apr 30, 10:15 am, Tamas K Papp <······@gmail.com> wrote:
>
> > And you can also use pattern matching libraries already available in
> > CL -- there is no need to change languages for that.
>
> Yes, I have a copy of Faré-matcher, but haven't gotten around to
> actually trying it. The kind of code I've been writing lately
> wouldn't have much use for it. I'm sure that will change at some
> point.
That's because you should try CL-UNIFICATION (shameless plug)
instead. Bigger is better. :)
Just for fun (actually untested)
(defun cl->python (expr n)
(unify:match-case (expr)
((if ?test ?then ?else)
(compile2python "if" (cl->python ?test N) ":" (nl (1+ n))
(cl->python ?then (+ n 1))
(nl n)
"else:" (nl (1+ n))
(cl->python ?else (+ n 1))))
...
))
Cheers
--
Marco
On Apr 30, 1:13 pm, Marco Antoniotti <·······@gmail.com> wrote:
> On Apr 30, 8:21 pm, Scott Burson <········@gmail.com> wrote:
>
> > On Apr 30, 10:15 am, Tamas K Papp <······@gmail.com> wrote:
>
> > > And you can also use pattern matching libraries already available in
> > > CL -- there is no need to change languages for that.
>
> > Yes, I have a copy of Faré-matcher, but haven't gotten around to
> > actually trying it. The kind of code I've been writing lately
> > wouldn't have much use for it. I'm sure that will change at some
> > point.
>
> That's because you should try CL-UNIFICATION (shameless plug)
> instead. Bigger is better. :)
Okay, I'll take a look at some point. Does it do iterative
(nondeterministic) matching?
-- Scott
On Apr 30, 10:59 pm, Scott Burson <········@gmail.com> wrote:
> On Apr 30, 1:13 pm, Marco Antoniotti <·······@gmail.com> wrote:
>
> > On Apr 30, 8:21 pm, Scott Burson <········@gmail.com> wrote:
>
> > > On Apr 30, 10:15 am, Tamas K Papp <······@gmail.com> wrote:
>
> > > > And you can also use pattern matching libraries already available in
> > > > CL -- there is no need to change languages for that.
>
> > > Yes, I have a copy of Faré-matcher, but haven't gotten around to
> > > actually trying it. The kind of code I've been writing lately
> > > wouldn't have much use for it. I'm sure that will change at some
> > > point.
>
> > That's because you should try CL-UNIFICATION (shameless plug)
> > instead. Bigger is better. :)
>
> Okay, I'll take a look at some point. Does it do iterative
> (nondeterministic) matching?
You should explain. Either you do unification-style, i.e. structural
matching, or you do language matching using automata etc. CL-
UNIFICATION is a full blown CL structural matcher that sticks to CL
look'n'feel. It is not a language-based matcher. You can do
CL-USER 2 > (unify:unify #T(vector 42 &rest ?x) #(?qd 2 3 4))
#<UNIFY ENVIRONMENT: 1 frame 21BAD7AF>
CL-USER 3 > (unify:v? '?x *)
#(2 3 4)
T
CL-USER 4 > (unify:v? '?qd **)
42
T
It also works on structures and instances. You can also do
(unify:unify #T(unify:regex "a(b*)") "abbbbbb")
but this is a trick made possible by Edi Weitz.
As per your request, you should define what you want. I still bet
that CL-UNIFICATION is good foundation upon which to build it.
Cheers
--
Marco
On May 1, 1:42 am, Marco Antoniotti <·······@gmail.com> wrote:
>
> As per your request, you should define what you want.
Fair enough. I haven't thought about it that hard. I was hoping you
had :)
-- Scott
On May 1, 9:32 pm, Scott Burson <········@gmail.com> wrote:
> On May 1, 1:42 am, Marco Antoniotti <·······@gmail.com> wrote:
>
>
>
> > As per your request, you should define what you want.
>
> Fair enough. I haven't thought about it that hard. I was hoping you
> had :)
Hey! I have a limited number of neurons (< 42). I can't think of the
question you have in mind :)
Cheers
--
Marco
On 30 Apr, 18:15, Tamas K Papp <······@gmail.com> wrote:
> On Thu, 30 Apr 2009 10:03:14 -0700, Scott Burson wrote:
> > On Apr 30, 7:38 am, Mark Tarver <··········@ukonline.co.uk> wrote:
> >> IMO, inbuilt pattern matching (PM) is a boon and I would really not
> >> consider writing a compiler (or most anything else) without it. Paul
> >> Graham discussing this issue wrt Arc, argues that pattern matching is
> >> dispensable because you only use it for boilerplate functions (see link
> >> above). I find from experience that this is false.
>
> > The other language I mentioned that was built on CL, Refine, had pattern
> > matching. I wrote a lot of Refine code back in the day and would agree
> > that pattern matching is a very handy feature, one I do miss in CL,
> > unquestionably. Nonetheless I would stop just short of calling it
> > essential. The correspondence between a pattern-matching expression and
> > the ordinary conditional it compiles into is just not that complex.
>
> And you can also use pattern matching libraries already available in
> CL -- there is no need to change languages for that.
>
> I find Haskell-like pattern matching handy for some problems, but most
> of the time the amazing bind library is more than enough for me.
>
> Tamas
Well this is probably my last post on this issue.
There's a lot more to Qi than just a fast clean PM. But nobody with
sense writing an FPL in C21 would put, say, NCONC into the language
standard and PM into a library. That reflects an historical problem
of CL.
The idea of Qi is to have a bootstrapped language with the genotype of
a Lisp with a small clean declarative specification that can migrate
to different platforms - not just CL. Qi will, likely, migrate to
different (genotype) Lisps of which Python and Clojure are examples.
Binding Qi conceptually to CL is not a good idea.
Mark
On 1 mayo, 08:53, Mark Tarver <··········@ukonline.co.uk> wrote:
> On 30 Apr, 18:15, Tamas K Papp <······@gmail.com> wrote:
>
>
>
> > On Thu, 30 Apr 2009 10:03:14 -0700, Scott Burson wrote:
> > > On Apr 30, 7:38 am, Mark Tarver <··········@ukonline.co.uk> wrote:
> > >> IMO, inbuilt pattern matching (PM) is a boon and I would really not
> > >> consider writing a compiler (or most anything else) without it. Paul
> > >> Graham discussing this issue wrt Arc, argues that pattern matching is
> > >> dispensable because you only use it for boilerplate functions (see link
> > >> above). I find from experience that this is false.
>
> > > The other language I mentioned that was built on CL, Refine, had pattern
> > > matching. I wrote a lot of Refine code back in the day and would agree
> > > that pattern matching is a very handy feature, one I do miss in CL,
> > > unquestionably. Nonetheless I would stop just short of calling it
> > > essential. The correspondence between a pattern-matching expression and
> > > the ordinary conditional it compiles into is just not that complex.
>
> > And you can also use pattern matching libraries already available in
> > CL -- there is no need to change languages for that.
>
> > I find Haskell-like pattern matching handy for some problems, but most
> > of the time the amazing bind library is more than enough for me.
>
> > Tamas
>
> Well this is probably my last post on this issue.
>
> There's a lot more to Qi than just a fast clean PM. But nobody with
> sense writing an FPL in C21 would put, say, NCONC into the language
> standard and PM into a library. That reflects an historical problem
> of CL.
>
> The idea of Qi is to have a bootstrapped language with the genotype of
> a Lisp with a small clean declarative specification that can migrate
> to different platforms - not just CL. Qi will, likely, migrate to
> different (genotype) Lisps of which Python and Clojure are examples.
> Binding Qi conceptually to CL is not a good idea.
>
> Mark
Hello Mark. I think Qi is a great idea. I think Lisp is a
Language in sexy (or sweet) parenthesis (more on this later).
I agree about the genotype idea (here macros and prefix notation
can be some chromosomes) for the phenotype we can choose among
Clojure, Qi, ...
I think the idea of sweet parenthesis is making libraries so that a
Lisper can manipulate this program in any language.
For example, a Library that convert your program in a html page
that allow you to test, explore visually, communicate with
servers, add any plugin ...
We should make the genotype expand, a virus is a good example,
let's make that sweet parenthesis dance with javascript, python
and other to allow us to enjoy parenthesis.
If you think going from the symbols '(' and ')' to the idea of
parenthesis is too abstract then call your language
(L).
I think we can think of parenthesis as a link, you go from one
idea to another. A big parenthesis is wikipedia, or a good
book. What we are doing is communicating ideas, so make your
parenthesis for communicating ideas.
Take it in a funny way for expanding Lisp.
Mark Tarver <··········@ukonline.co.uk> wrote:
> The idea of Qi is to have a bootstrapped language with the genotype of
> a Lisp with a small clean declarative specification that can migrate
> to different platforms - not just CL. Qi will, likely, migrate to
> different (genotype) Lisps of which Python and Clojure are examples.
This sounds interesting. Are you planning a Scheme port of Qi?
--
Nils M Holm <n m h @ t 3 x . o r g> -- http://t3x.org/nmh/
On 1 May, 12:16, Nils M Holm <········@t3x.org> wrote:
> Mark Tarver <··········@ukonline.co.uk> wrote:
> > The idea of Qi is to have a bootstrapped language with the genotype of
> > a Lisp with a small clean declarative specification that can migrate
> > to different platforms - not just CL. Qi will, likely, migrate to
> > different (genotype) Lisps of which Python and Clojure are examples.
>
> This sounds interesting. Are you planning a Scheme port of Qi?
>
> --
> Nils M Holm <n m h @ t 3 x . o r g> --http://t3x.org/nmh/
Its not scheduled. Nothing to stop someone doing it of course.
More useful is a port to ABCL which involves less work and puts Qi on
top of the JVM. We at Qilang tried and failed to get ABCL running
Qi. The ABCL people claim to have a stronger platform than their
October 2008 version so I tried installing again and it did get
further but ABCL still didn't run. David Leoni managed to install his
ABCL under Linux but could not get Qi so far to install. We're
working on this right now.
I expect that we will crack this eventually and Qi will run under
ABCL.
FYI and for anybody who can figure this out; here is a script of my
attempt to install ABCL under CLisp/XP.
i i i i i i i ooooo o ooooooo ooooo ooooo
I I I I I I I 8 8 8 8 8 o 8 8
I \ `+' / I 8 8 8 8 8 8
\ `-+-' / 8 8 8 ooooo 8oooo
`-__|__-' 8 8 8 8 8
| 8 o 8 8 o 8 8
------+------ ooooo 8oooooo ooo8ooo ooooo 8
Welcome to GNU CLISP 2.45 (2008-05-15) <http://clisp.cons.org/>
Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2008
Type :h and hit Enter for context help.
[1]> (load "build-abcl.lisp")
;; Loading file build-abcl.lisp ...
;; Loaded file build-abcl.lisp
T
[2]> (build-abcl:build-abcl :clean t :full t)
;; Loading file C:\Documents and Settings\User\My Documents\Computer
Science\Lan
guages\abcl-src-0.14.1\abcl-src-0.14.1\customizations.lisp ...
;; Loaded file C:\Documents and Settings\User\My Documents\Computer
Science\Lang
uages\abcl-src-0.14.1\abcl-src-0.14.1\customizations.lisp
Platform: Windows
JDK: C:\Program Files\Java\jdk1.6.0_11\
Java compiler: C:\Program Files\Java\jdk1.6.0_11\bin\javac.exe
Compiler options: -g
javac: invalid flag: Files\Java\jdk1.6.0_11\jre\lib\rt.jar -g -d C:
\Documents a
nd Settings\User\My Documents\Computer Science\Languages\abcl-
src-0.14.1\abcl-sr
c-0.14.1\build\classes\ zip.java ZeroRankArray.java
WrongNumberOfArgumentsExcept
ion.java Warning.java Version.java Utilities.java UpcaseStream.java
UndefinedFun
ction.java unbound_slot_instance.java UnboundVariable.java
UnboundSlot.java Type
Error.java TwoWayStream.java truncate.java Time.java Throw.java
ThreadLock.java
ThreadDestroyed.java SynonymStream.java SymbolMacro.java
SymbolHashTable.java Sy
mbol.java StyleWarning.java StructureObject.java StructureClass.java
StringOutpu
tStream.java StringInputStream.java StringFunctions.java
stream_external_format.
java stream_element_type.java StreamError.java Stream.java
StorageCondition.java
StandardReaderMethodClass.java StandardReaderMethod.java
StandardObjectFunction
s.java StandardObject.java StandardMethodClass.java
StandardMethod.java Standard
GenericFunctionClass.java StandardGenericFunction.java
StandardClass.java Specia
lOperators.java SpecialOperator.java SpecialBinding.java
software_version.java s
oftware_type.java socket_stream.java socket_close.java
socket_accept.java Socket
Stream.java SlotDefinitionClass.java SlotDefinition.java
SlotClass.java SlimeOut
putStream.java SlimeInputStream.java SiteName.java Site.java
SingleFloat.java si
mple_list_remove_duplicates.java SimpleWarning.java SimpleVector.java
SimpleType
Error.java SimpleString.java SimpleError.java SimpleCondition.java
SimpleBitVect
or.java SimpleArray_UnsignedByte8.java SimpleArray_UnsignedByte32.java
SimpleArr
ay_UnsignedByte16.java SimpleArray_T.java ShellCommand.java
server_socket_close.
java SeriousCondition.java RuntimeClass.java room.java Return.java
rem.java Read
table.java ReaderMacroFunction.java ReaderError.java Ratio.java
RandomState.java
ProgramError.java Profiler.java probe_file.java PrintNotReadable.java
Primitive
s.java Primitive2R.java Primitive1R.java Primitive0R.java
Primitive.java peek_ch
ar.java Pathname.java ParseError.java package_error_package.java
Packages.java P
ackageFunctions.java PackageError.java Package.java
output_stream_p.java Operato
r.java open_stream_p.java NilVector.java Nil.java Mutex.java mod.java
MathFuncti
ons.java make_socket.java make_server_socket.java make_condition.java
make_array
.java Main.java Mailbox.java MacroObject.java machine_version.java
machine_type.
java logxor.java logtest.java logorc2.java logorc1.java lognot.java
lognor.java
lognand.java logior.java LogicalPathname.java logeqv.java
logcount.java logbitp.
java logandc2.java logandc1.java logand.java Load.java listen.java
lisp_implemen
tation_version.java lisp_implementation_type.java LispThread.java
LispReader.jav
a LispObject.java LispInteger.java LispError.java LispClass.java
LispCharacter.j
ava Lisp.java Layout.java last.java Keyword.java JProxy.java
jmethod_return_type
.java JHandler.java jclass_of.java jclass_name.java JavaObject.java
JavaExceptio
n.java JavaClassLoader.java JavaClass.java Java.java Interpreter.java
interactiv
e_stream_p.java input_stream_p.java HashTableFunctions.java
HashTable.java Go.ja
va get_properties.java GenericFunction.java gc.java function_info.java
FunctionB
inding.java Function.java ftruncate.java ForwardReferencedClass.java
floor.java
float_sign.java FloatingPointUnderflow.java FloatingPointOverflow.java
FloatingP
ointInvalidOperation.java FloatingPointInexact.java
FloatFunctions.java Fixnum.j
ava FillPointerOutputStream.java file_write_date.java
file_string_length.java fi
le_length.java file_error_pathname.java file_author.java
FileStream.java FileErr
or.java FastStringBuffer.java FaslReadtable.java FaslReader.java
Extensions.java
EqualpHashTable.java EqualHashTable.java EqlHashTable.java
EqHashTable.java Env
ironment.java EndOfFile.java EchoStream.java DowncaseStream.java
DoubleFloat.jav
a dotimes.java dolist.java Do.java DivisionByZero.java
DispatchMacroFunction.jav
a disassemble_class_bytes.java delete_file.java Debug.java cxr.java
create_new_f
ile.java copy_list.java ControlError.java Cons.java
ConditionThrowable.java Cond
ition.java ConcatenatedStream.java ComplexVector_UnsignedByte8.java
ComplexVecto
r_UnsignedByte32.java ComplexVector.java ComplexString.java
ComplexBitVector.jav
a ComplexArray_UnsignedByte8.java ComplexArray_UnsignedByte32.java
ComplexArray.
java Complex.java CompilerUnsupportedFeatureError.java
CompilerError.java Compil
edFunction.java CompiledClosure.java ClosureTemplateFunction.java
Closure.java C
haracterFunctions.java cell_error_name.java CellError.java
ceiling.java CaseFrob
Stream.java CapitalizeStream.java CapitalizeFirstStream.java
ByteArrayOutputStre
am.java BuiltInClass.java BroadcastStream.java Binding.java
Bignum.java BasicVec
tor_UnsignedByte8.java BasicVector_UnsignedByte32.java
BasicVector_UnsignedByte1
6.java AutoloadMacro.java Autoload.java assql.java assq.java ash.java
Arithmetic
Error.java arglist.java adjust_array.java AbstractVector.java
AbstractString.jav
a AbstractBitVector.java AbstractArray.java C:\Documents and Settings
\User\My Do
cuments\Computer Science\Languages\abcl-src-0.14.1\abcl-src-0.14.1\src
\org\armed
bear\lisp\util\RandomAccessCharacterFile.java
Usage: javac <options> <source files>
use -help for a list of possible options
Exception in thread "main" java.lang.NoClassDefFoundError: org/
armedbear/lisp/Ma
in
Caused by: java.lang.ClassNotFoundException: org.armedbear.lisp.Main
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:
301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:
320)
Could not find the main class: org.armedbear.lisp.Main. Program will
exit.
C:\Documents and Settings\User\My Documents\Computer Science\Languages
\abcl-src-
0.14.1\abcl-src-0.14.1>"C:\Program Files\Java\jdk1.6.0_11\bin\jar.exe"
cfm dist\
abcl.jar src\manifest-abcl -C src org\armedbear\lisp\LICENSE -C src
org
\armedbea
r\lisp\boot.lisp
C:\Documents and Settings\User\My Documents\Computer Science\Languages
\abcl-src-
0.14.1\abcl-src-0.14.1>"C:\Program Files\Java\jdk1.6.0_11\bin\jar.exe"
uf dist\a
bcl.jar -C build\classes .
Build completed successfully in 16.9375 seconds.
T
[3]>
The resulting installation will not execute.
Mark
Hi Mark,
I'm building ABCL using the Java ANT build system, and I might be wrong,
but it does not rely on a ready lisp anywhere - e.g. it could be build
without bootstrapping.
All you need to do is to go to the ~/abcl folder, and type:
"abcl abcl.wrapper"
This would create a shell script, or batch file (Windows) that would
call java with the abcl.jar, for example on Windows:
D:\p\abcl\abcl.bat
"D:\p\java\jdk\jre/bin/java" -server -cp "D:\p\abcl\dist\abcl.jar"
org.armedbear.lisp.Main %1 %2 %3 %4 %5 %6 %7 %8 %9
The "-server" is something I've added after the batch file was generated
- using java server JITS much better than the normal HotSpot (though a
bit slower).
Mark Tarver wrote:
> On 1 May, 12:16, Nils M Holm <········@t3x.org> wrote:
>> Mark Tarver <··········@ukonline.co.uk> wrote:
>>> The idea of Qi is to have a bootstrapped language with the genotype of
>>> a Lisp with a small clean declarative specification that can migrate
>>> to different platforms - not just CL. Qi will, likely, migrate to
>>> different (genotype) Lisps of which Python and Clojure are examples.
>> This sounds interesting. Are you planning a Scheme port of Qi?
>>
>> --
>> Nils M Holm <n m h @ t 3 x . o r g> --http://t3x.org/nmh/
>
> Its not scheduled. Nothing to stop someone doing it of course.
>
> More useful is a port to ABCL which involves less work and puts Qi on
> top of the JVM. We at Qilang tried and failed to get ABCL running
> Qi. The ABCL people claim to have a stronger platform than their
> October 2008 version so I tried installing again and it did get
> further but ABCL still didn't run. David Leoni managed to install his
> ABCL under Linux but could not get Qi so far to install. We're
> working on this right now.
>
> I expect that we will crack this eventually and Qi will run under
> ABCL.
>
> FYI and for anybody who can figure this out; here is a script of my
> attempt to install ABCL under CLisp/XP.
>
> i i i i i i i ooooo o ooooooo ooooo ooooo
> I I I I I I I 8 8 8 8 8 o 8 8
> I \ `+' / I 8 8 8 8 8 8
> \ `-+-' / 8 8 8 ooooo 8oooo
> `-__|__-' 8 8 8 8 8
> | 8 o 8 8 o 8 8
> ------+------ ooooo 8oooooo ooo8ooo ooooo 8
>
> Welcome to GNU CLISP 2.45 (2008-05-15) <http://clisp.cons.org/>
>
> Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
> Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
> Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
> Copyright (c) Bruno Haible, Sam Steingold 1999-2000
> Copyright (c) Sam Steingold, Bruno Haible 2001-2008
>
> Type :h and hit Enter for context help.
>
> [1]> (load "build-abcl.lisp")
> ;; Loading file build-abcl.lisp ...
> ;; Loaded file build-abcl.lisp
> T
> [2]> (build-abcl:build-abcl :clean t :full t)
> ;; Loading file C:\Documents and Settings\User\My Documents\Computer
> Science\Lan
> guages\abcl-src-0.14.1\abcl-src-0.14.1\customizations.lisp ...
> ;; Loaded file C:\Documents and Settings\User\My Documents\Computer
> Science\Lang
> uages\abcl-src-0.14.1\abcl-src-0.14.1\customizations.lisp
> Platform: Windows
> JDK: C:\Program Files\Java\jdk1.6.0_11\
> Java compiler: C:\Program Files\Java\jdk1.6.0_11\bin\javac.exe
> Compiler options: -g
>
> javac: invalid flag: Files\Java\jdk1.6.0_11\jre\lib\rt.jar -g -d C:
> \Documents a
> nd Settings\User\My Documents\Computer Science\Languages\abcl-
> src-0.14.1\abcl-sr
> c-0.14.1\build\classes\ zip.java ZeroRankArray.java
> WrongNumberOfArgumentsExcept
> ion.java Warning.java Version.java Utilities.java UpcaseStream.java
> UndefinedFun
> ction.java unbound_slot_instance.java UnboundVariable.java
> UnboundSlot.java Type
> Error.java TwoWayStream.java truncate.java Time.java Throw.java
> ThreadLock.java
> ThreadDestroyed.java SynonymStream.java SymbolMacro.java
> SymbolHashTable.java Sy
> mbol.java StyleWarning.java StructureObject.java StructureClass.java
> StringOutpu
> tStream.java StringInputStream.java StringFunctions.java
> stream_external_format.
> java stream_element_type.java StreamError.java Stream.java
> StorageCondition.java
> StandardReaderMethodClass.java StandardReaderMethod.java
> StandardObjectFunction
> s.java StandardObject.java StandardMethodClass.java
> StandardMethod.java Standard
> GenericFunctionClass.java StandardGenericFunction.java
> StandardClass.java Specia
> lOperators.java SpecialOperator.java SpecialBinding.java
> software_version.java s
> oftware_type.java socket_stream.java socket_close.java
> socket_accept.java Socket
> Stream.java SlotDefinitionClass.java SlotDefinition.java
> SlotClass.java SlimeOut
> putStream.java SlimeInputStream.java SiteName.java Site.java
> SingleFloat.java si
> mple_list_remove_duplicates.java SimpleWarning.java SimpleVector.java
> SimpleType
> Error.java SimpleString.java SimpleError.java SimpleCondition.java
> SimpleBitVect
> or.java SimpleArray_UnsignedByte8.java SimpleArray_UnsignedByte32.java
> SimpleArr
> ay_UnsignedByte16.java SimpleArray_T.java ShellCommand.java
> server_socket_close.
> java SeriousCondition.java RuntimeClass.java room.java Return.java
> rem.java Read
> table.java ReaderMacroFunction.java ReaderError.java Ratio.java
> RandomState.java
> ProgramError.java Profiler.java probe_file.java PrintNotReadable.java
> Primitive
> s.java Primitive2R.java Primitive1R.java Primitive0R.java
> Primitive.java peek_ch
> ar.java Pathname.java ParseError.java package_error_package.java
> Packages.java P
> ackageFunctions.java PackageError.java Package.java
> output_stream_p.java Operato
> r.java open_stream_p.java NilVector.java Nil.java Mutex.java mod.java
> MathFuncti
> ons.java make_socket.java make_server_socket.java make_condition.java
> make_array
> ..java Main.java Mailbox.java MacroObject.java machine_version.java
> machine_type.
> java logxor.java logtest.java logorc2.java logorc1.java lognot.java
> lognor.java
> lognand.java logior.java LogicalPathname.java logeqv.java
> logcount.java logbitp.
> java logandc2.java logandc1.java logand.java Load.java listen.java
> lisp_implemen
> tation_version.java lisp_implementation_type.java LispThread.java
> LispReader.jav
> a LispObject.java LispInteger.java LispError.java LispClass.java
> LispCharacter.j
> ava Lisp.java Layout.java last.java Keyword.java JProxy.java
> jmethod_return_type
> ..java JHandler.java jclass_of.java jclass_name.java JavaObject.java
> JavaExceptio
> n.java JavaClassLoader.java JavaClass.java Java.java Interpreter.java
> interactiv
> e_stream_p.java input_stream_p.java HashTableFunctions.java
> HashTable.java Go.ja
> va get_properties.java GenericFunction.java gc.java function_info.java
> FunctionB
> inding.java Function.java ftruncate.java ForwardReferencedClass.java
> floor.java
> float_sign.java FloatingPointUnderflow.java FloatingPointOverflow.java
> FloatingP
> ointInvalidOperation.java FloatingPointInexact.java
> FloatFunctions.java Fixnum.j
> ava FillPointerOutputStream.java file_write_date.java
> file_string_length.java fi
> le_length.java file_error_pathname.java file_author.java
> FileStream.java FileErr
> or.java FastStringBuffer.java FaslReadtable.java FaslReader.java
> Extensions.java
> EqualpHashTable.java EqualHashTable.java EqlHashTable.java
> EqHashTable.java Env
> ironment.java EndOfFile.java EchoStream.java DowncaseStream.java
> DoubleFloat.jav
> a dotimes.java dolist.java Do.java DivisionByZero.java
> DispatchMacroFunction.jav
> a disassemble_class_bytes.java delete_file.java Debug.java cxr.java
> create_new_f
> ile.java copy_list.java ControlError.java Cons.java
> ConditionThrowable.java Cond
> ition.java ConcatenatedStream.java ComplexVector_UnsignedByte8.java
> ComplexVecto
> r_UnsignedByte32.java ComplexVector.java ComplexString.java
> ComplexBitVector.jav
> a ComplexArray_UnsignedByte8.java ComplexArray_UnsignedByte32.java
> ComplexArray.
> java Complex.java CompilerUnsupportedFeatureError.java
> CompilerError.java Compil
> edFunction.java CompiledClosure.java ClosureTemplateFunction.java
> Closure.java C
> haracterFunctions.java cell_error_name.java CellError.java
> ceiling.java CaseFrob
> Stream.java CapitalizeStream.java CapitalizeFirstStream.java
> ByteArrayOutputStre
> am.java BuiltInClass.java BroadcastStream.java Binding.java
> Bignum.java BasicVec
> tor_UnsignedByte8.java BasicVector_UnsignedByte32.java
> BasicVector_UnsignedByte1
> 6.java AutoloadMacro.java Autoload.java assql.java assq.java ash.java
> Arithmetic
> Error.java arglist.java adjust_array.java AbstractVector.java
> AbstractString.jav
> a AbstractBitVector.java AbstractArray.java C:\Documents and Settings
> \User\My Do
> cuments\Computer Science\Languages\abcl-src-0.14.1\abcl-src-0.14.1\src
> \org\armed
> bear\lisp\util\RandomAccessCharacterFile.java
> Usage: javac <options> <source files>
> use -help for a list of possible options
>
> Exception in thread "main" java.lang.NoClassDefFoundError: org/
> armedbear/lisp/Ma
> in
> Caused by: java.lang.ClassNotFoundException: org.armedbear.lisp.Main
> at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:
> 301)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:
> 320)
> Could not find the main class: org.armedbear.lisp.Main. Program will
> exit.
>
> C:\Documents and Settings\User\My Documents\Computer Science\Languages
> \abcl-src-
> 0.14.1\abcl-src-0.14.1>"C:\Program Files\Java\jdk1.6.0_11\bin\jar.exe"
> cfm dist\
> abcl.jar src\manifest-abcl -C src org\armedbear\lisp\LICENSE -C src
> org
> \armedbea
> r\lisp\boot.lisp
>
> C:\Documents and Settings\User\My Documents\Computer Science\Languages
> \abcl-src-
> 0.14.1\abcl-src-0.14.1>"C:\Program Files\Java\jdk1.6.0_11\bin\jar.exe"
> uf dist\a
> bcl.jar -C build\classes .
> Build completed successfully in 16.9375 seconds.
> T
> [3]>
>
> The resulting installation will not execute.
>
> Mark
On 2 May, 01:28, "Dimiter \"malkia\" Stanev" <······@mac.com> wrote:
> Hi Mark,
>
> I'm building ABCL using the Java ANT build system, and I might be wrong,
> but it does not rely on a ready lisp anywhere - e.g. it could be build
> without bootstrapping.
>
> All you need to do is to go to the ~/abcl folder, and type:
>
> "abcl abcl.wrapper"
>
> This would create a shell script, or batch file (Windows) that would
> call java with the abcl.jar, for example on Windows:
>
> D:\p\abcl\abcl.bat
>
> "D:\p\java\jdk\jre/bin/java" -server -cp "D:\p\abcl\dist\abcl.jar"
> org.armedbear.lisp.Main %1 %2 %3 %4 %5 %6 %7 %8 %9
>
> The "-server" is something I've added after the batch file was generated
> - using java server JITS much better than the normal HotSpot (though a
> bit slower).
I get
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\User>cd "C:\Documents and Settings\User\My
Documents\Computer Science\Languages\abcl-src-0.14.1\abcl-src-0.14.1"
C:\Documents and Settings\User\My Documents\Computer Science\Languages
\abcl-src-0.14.1\abcl-src-0.14.1>abcl abcl.wrapper
Then this blurb ......
C:\Documents and Settings\User\My Documents\Computer Science\Languages
\abcl-src-0.14.1\abcl-src-0.14.1>"C:\Program Files\Java\jdk1.6.0_11\bin
\java.exe" -Xss4M -Xmx256M -cp "C:\Documents and Settings\User\My
Documents\Computer Science\Languages\abcl-src-0.14.1\abcl-
src-0.14.1\dist\abcl.jar" org.armedbear.lisp.Main abcl.
wrapper
Exception in thread "main" java.lang.NoClassDefFoundError: org/
armedbear/lisp/Main
Caused by: java.lang.ClassNotFoundException: org.armedbear.lisp.Main
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:
301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:
320)
Could not find the main class: org.armedbear.lisp.Main. Program will
exit.
C:\Documents and Settings\User\My Documents\Computer Science\Languages
\abcl-src-
0.14.1\abcl-src-0.14.1>
Mark
Sorry, I've actually typed the wrong thing.
You need to do: "ant abcl.wrapper" and make sure that you have ANT
installed. Not as I've said "abcl abcl.wrapper" - this does not make
sense at all.
Ant would read build.xml and do the "abcl.wrapper" target, that would
compile ABCL, it's .java, .lisp files, and create the abcl.bat file.
On May 2, 12:48 am, Mark Tarver <··········@ukonline.co.uk> wrote:
> On 2 May, 01:28, "Dimiter \"malkia\" Stanev" <······@mac.com> wrote:
>
>
>
>
>
> > Hi Mark,
>
> > I'm building ABCL using the Java ANT build system, and I might be wrong,
> > but it does not rely on a ready lisp anywhere - e.g. it could be build
> > without bootstrapping.
>
> > All you need to do is to go to the ~/abcl folder, and type:
>
> > "abcl abcl.wrapper"
>
> > This would create a shell script, or batch file (Windows) that would
> > call java with the abcl.jar, for example on Windows:
>
> > D:\p\abcl\abcl.bat
>
> > "D:\p\java\jdk\jre/bin/java" -server -cp "D:\p\abcl\dist\abcl.jar"
> > org.armedbear.lisp.Main %1 %2 %3 %4 %5 %6 %7 %8 %9
>
> > The "-server" is something I've added after the batch file was generated
> > - using java server JITS much better than the normal HotSpot (though a
> > bit slower).
>
> I get
>
> Microsoft Windows XP [Version 5.1.2600]
> (C) Copyright 1985-2001 Microsoft Corp.
>
> C:\Documents and Settings\User>cd "C:\Documents and Settings\User\My
> Documents\Computer Science\Languages\abcl-src-0.14.1\abcl-src-0.14.1"
>
> C:\Documents and Settings\User\My Documents\Computer Science\Languages
> \abcl-src-0.14.1\abcl-src-0.14.1>abcl abcl.wrapper
>
> Then this blurb ......
>
> C:\Documents and Settings\User\My Documents\Computer Science\Languages
> \abcl-src-0.14.1\abcl-src-0.14.1>"C:\Program Files\Java\jdk1.6.0_11\bin
> \java.exe" -Xss4M -Xmx256M -cp "C:\Documents and Settings\User\My
> Documents\Computer Science\Languages\abcl-src-0.14.1\abcl-
> src-0.14.1\dist\abcl.jar" org.armedbear.lisp.Main abcl.
> wrapper
> Exception in thread "main" java.lang.NoClassDefFoundError: org/
> armedbear/lisp/Main
> Caused by: java.lang.ClassNotFoundException: org.armedbear.lisp.Main
> at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:
> 301)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:
> 320)
> Could not find the main class: org.armedbear.lisp.Main. Program will
> exit.
>
> C:\Documents and Settings\User\My Documents\Computer Science\Languages
> \abcl-src-
> 0.14.1\abcl-src-0.14.1>
>
> Mark
Dimiter "malkia" Stanev schrieb:
> Hi Mark,
>
> I'm building ABCL using the Java ANT build system, and I might be wrong,
> but it does not rely on a ready lisp anywhere - e.g. it could be build
> without bootstrapping.
>
> All you need to do is to go to the ~/abcl folder, and type:
>
> "abcl abcl.wrapper"
>
> This would create a shell script, or batch file (Windows) that would
> call java with the abcl.jar, for example on Windows:
>
> D:\p\abcl\abcl.bat
>
> "D:\p\java\jdk\jre/bin/java" -server -cp "D:\p\abcl\dist\abcl.jar"
> org.armedbear.lisp.Main %1 %2 %3 %4 %5 %6 %7 %8 %9
>
> The "-server" is something I've added after the batch file was generated
> - using java server JITS much better than the normal HotSpot (though a
> bit slower).
I think what you mean is that the Server VM needs 1-2 seconds more
to start up, but then typically performs much better.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
···············@gmail.com schrieb:
> Qi _is_ Common Lisp.
You got that point wrong.
Qi is a unique Lisp. It just happens to be implemented on some VM that
also host CL, and which were originally written with CL in mind.
You can compare that with Clojure on the JVM.
As such a system inside the VM it can easily call and reuse code of its
host. But it is not another language.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On Fri, 01 May 2009 01:16:04 +0200, André Thieme wrote:
> ···············@gmail.com schrieb:
>> Qi _is_ Common Lisp.
>
> You got that point wrong.
> Qi is a unique Lisp. It just happens to be implemented on some VM that
> also host CL, and which were originally written with CL in mind. You can
> compare that with Clojure on the JVM. As such a system inside the VM it
> can easily call and reuse code of its host. But it is not another
> language.
Where does the VM come in? I thought Qi was compiled under, say, SBCL.
Tamas
Tamas K Papp schrieb:
> On Fri, 01 May 2009 01:16:04 +0200, André Thieme wrote:
>
>> ···············@gmail.com schrieb:
>>> Qi _is_ Common Lisp.
>> You got that point wrong.
>> Qi is a unique Lisp. It just happens to be implemented on some VM that
>> also host CL, and which were originally written with CL in mind. You can
>> compare that with Clojure on the JVM. As such a system inside the VM it
>> can easily call and reuse code of its host. But it is not another
>> language.
>
> Where does the VM come in? I thought Qi was compiled under, say, SBCL.
I am not sure that I understand your question. SBCL is the VM.
When Qi is compiled under SBCL it can in principle use all the code that
runs on that plattform (SBCL).
André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/
On Fri, 01 May 2009 02:22:24 +0200, André Thieme wrote:
> Tamas K Papp schrieb:
>> On Fri, 01 May 2009 01:16:04 +0200, André Thieme wrote:
>>
>>> ···············@gmail.com schrieb:
>>>> Qi _is_ Common Lisp.
>>> You got that point wrong.
>>> Qi is a unique Lisp. It just happens to be implemented on some VM that
>>> also host CL, and which were originally written with CL in mind. You
>>> can compare that with Clojure on the JVM. As such a system inside the
>>> VM it can easily call and reuse code of its host. But it is not
>>> another language.
>>
>> Where does the VM come in? I thought Qi was compiled under, say, SBCL.
>
> I am not sure that I understand your question. SBCL is the VM. When Qi
> is compiled under SBCL it can in principle use all the code that runs on
> that plattform (SBCL).
Sorry, maybe I am not using the terminology correctly, please be
patient with me as am not an expert in these matters.
I thought that a VM was something that ran bytecode. Does Qi use
anything similar?
I have to admit that I haven't looked into the internals of Qi very
deeply (especially not Qi II), but my impression was that first it
compiles to CL, and then the CL code is compiled. You may call the
context the compiled code runs in a VM, but then you would have to say
that the code I compile & run in using SBCL runs under a VM - so this
is not something that would differentiate Qi from CL (as opposed to
Clojure).
Tamas
Tamas K Papp <······@gmail.com> writes:
> On Fri, 01 May 2009 02:22:24 +0200, Andr� Thieme wrote:
>
>> Tamas K Papp schrieb:
>>> On Fri, 01 May 2009 01:16:04 +0200, Andr� Thieme wrote:
>>>
>>>> ···············@gmail.com schrieb:
>>>>> Qi _is_ Common Lisp.
>>>> You got that point wrong.
>>>> Qi is a unique Lisp. It just happens to be implemented on some VM that
>>>> also host CL, and which were originally written with CL in mind. You
>>>> can compare that with Clojure on the JVM. As such a system inside the
>>>> VM it can easily call and reuse code of its host. But it is not
>>>> another language.
>>>
>>> Where does the VM come in? I thought Qi was compiled under, say, SBCL.
>>
>> I am not sure that I understand your question. SBCL is the VM. When Qi
>> is compiled under SBCL it can in principle use all the code that runs on
>> that plattform (SBCL).
>
> Sorry, maybe I am not using the terminology correctly, please be
> patient with me as am not an expert in these matters.
>
> I thought that a VM was something that ran bytecode.
Not necessarily. It's a Virtual Machine, that is, a machine that is
implemented in software rather than physically, in hardware.
It can be any kind of machine. For example, we could implement the
MONIAC Computer as a virtual machine. There would be no byte code
here...
> Does Qi use anything similar?
>
> I have to admit that I haven't looked into the internals of Qi very
> deeply (especially not Qi II), but my impression was that first it
> compiles to CL, and then the CL code is compiled. You may call the
> context the compiled code runs in a VM, but then you would have to say
> that the code I compile & run in using SBCL runs under a VM - so this
> is not something that would differentiate Qi from CL (as opposed to
> Clojure).
We just ignore how SBCL does to run the code. Notice that some
hardware processors also include a compilation step (translation of
the code into microcode).
--
__Pascal Bourguignon__
camposdeviento <·············@gmail.com> writes:
> Is a computer language a virtual machine?
An implementation of a computer language is a virtual machine, as long
as it's not hardwired in physical phenomenon (in which case it would
be a physical machine).
> A concrete implementation is not a virtual machine.
Yes it is.
> Is Lisp a virtual machine?
No, Lisp is a language. It is the specification for machines.
> a dog is an animal, i could say a computer language is a virtual
> machine but it is more concrete and informative to say that it is
> a computer language.
> Is this ok?
This last sentence is somewhat OK, I just don't see the relationship
with dogs.
--
__Pascal Bourguignon__
On 1 mayo, 12:21, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> camposdeviento <·············@gmail.com> writes:
> > Is a computer language a virtual machine?
>
> An implementation of a computer language is a virtual machine, as long
> as it's not hardwired in physical phenomenon (in which case it would
> be a physical machine).
>
> > A concrete implementation is not a virtual machine.
>
> Yes it is.
>
> > Is Lisp a virtual machine?
>
> No, Lisp is a language. It is the specification for machines.
>
> > a dog is an animal, i could say a computer language is a virtual
> > machine but it is more concrete and informative to say that it is
> > a computer language.
> > Is this ok?
>
> This last sentence is somewhat OK, I just don't see the relationship
> with dogs.
>
> --
> __Pascal Bourguignon__
Hello Pascal.
Programmer -> Language specification -> Compiler or Interpreter
-> Virtual Machine -> Machine Code -> Hardware.
Question: What is clisp?
a) A computer Language.
b) An implementation of Common Lisp with some extensions.
c) A virtual machine for Common Lisp
d) A Compiler
e) An Interpreter
f) There is more than one possible correct answer.
Spain <---> Spain seems to be fast today. Worker's day.
camposdeviento <·············@gmail.com> writes:
> On 1 mayo, 12:21, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> camposdeviento <·············@gmail.com> writes:
>> > Is a computer language a virtual machine?
>>
>> An implementation of a computer language is a virtual machine, as long
>> as it's not hardwired in physical phenomenon (in which case it would
>> be a physical machine).
>>
>> > A concrete implementation is not a virtual machine.
>>
>> Yes it is.
>>
>> > Is Lisp a virtual machine?
>>
>> No, Lisp is a language. �It is the specification for machines.
>>
>> > a dog is an animal, i could say a computer language is a virtual
>> > machine but it is more concrete and informative to say that it is
>> > a computer language.
>> > Is this ok?
>>
>> This last sentence is somewhat OK, I just don't see the relationship
>> with dogs.
>>
>> --
>> __Pascal Bourguignon__
>
> Hello Pascal.
>
> Programmer -> Language specification -> Compiler or Interpreter
> -> Virtual Machine -> Machine Code -> Hardware.
>
> Question: What is clisp?
>
> a) A computer Language.
No.
> b) An implementation of Common Lisp with some extensions.
Yes.
> c) A virtual machine for Common Lisp
Yes.
Your formulation here is somewhat ambiguous.
clisp is both a VM implementing Common Lisp, and uses internally an
underlying byte code VM to be able to have a simplier compiler. That
underlying byte code VM itself is implemented over unix and MS-Windows
VMs. (Yes, unix is also a virtual machine, the syscalls are not
implemented by hardware, but by software).
> d) A Compiler
Yes.
> e) An Interpreter
Yes.
> f) There is more than one possible correct answer.
Yes.
> Spain <---> Spain seems to be fast today. Worker's day.
Exactly ;-)
--
__Pascal Bourguignon__
camposdeviento schrieb:
> Question: What is clisp?
>
> a) A computer Language.
> b) An implementation of Common Lisp with some extensions.
> c) A virtual machine for Common Lisp
> d) A Compiler
> e) An Interpreter
> f) There is more than one possible correct answer.
b), c) and f) are right.
When clisp is not an uncommon abbreviation for the programming language
�Common Lisp�, but instead the name of the famous CL implementation,
then clisp is not a), such as the GCC is not a language.
It also is not d) and e), but it *has* d) and e).
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
* André Thieme <············@news.motzarella.org> :
Wrote on Fri, 01 May 2009 01:16:04 +0200:
| ···············@gmail.com schrieb:
|> Qi _is_ Common Lisp.
|
| You got that point wrong.
| Qi is a unique Lisp. It just happens to be implemented on some VM that
| also host CL, and which were originally written with CL in mind.
| You can compare that with Clojure on the JVM.
| As such a system inside the VM it can easily call and reuse code of its
| host. But it is not another language.
You are wrong again. Mark Tarver has addressed your point elsewhere in
this thread.
Common Lisp defines execution semantics and is a "Virtual Machine" in
its own right.
Please stop using any and every CL thread to as an opportunity to
provoke discussion to mention and eventually market clojure.
--
Madhu
Madhu schrieb:
> * André Thieme <············@news.motzarella.org> :
> Wrote on Fri, 01 May 2009 01:16:04 +0200:
>
> | ···············@gmail.com schrieb:
> |> Qi _is_ Common Lisp.
> |
> | You got that point wrong.
> | Qi is a unique Lisp. It just happens to be implemented on some VM that
> | also host CL, and which were originally written with CL in mind.
> | You can compare that with Clojure on the JVM.
> | As such a system inside the VM it can easily call and reuse code of its
> | host. But it is not another language.
>
> You are wrong again. Mark Tarver has addressed your point elsewhere in
> this thread.
>
> Common Lisp defines execution semantics and is a "Virtual Machine" in
> its own right.
>
> Please stop using any and every CL thread to as an opportunity to
> provoke discussion to mention and eventually market clojure.
Hu, why are you so mad? I thought you wanted to prove that you are more
clever than I by not answering me anymore.
No wait, maybe you just need some attention?
You seem to personally suffer from the fact that there are other Lisps
out there, that are more interesting and better for some people than CL.
Enjoy to continue to pray to your CL religion. ;-)
Btw, Mark Tarver agrees with me that Qi is not CL. It just happens to
be implemented in CL, where it also got its inspiration from.
André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/
* André Thieme <············@news.motzarella.org> :
Wrote on Fri, 01 May 2009 13:14:55 +0200:
|> Please stop using any and every CL thread to as an opportunity to
|> provoke discussion to mention and eventually market clojure.
|
| Hu, why are you so mad? I thought you wanted to prove that you are more
| clever than I by not answering me anymore.
| No wait, maybe you just need some attention?
The only attention I want to draw is the fact that when people respond
to in a discussion you they are responding to a marketing machine, a
human advertising / spam bot.
There is a differece between offering a personal judgement and making
dishonest claims for the purpose of marketing a product. The other
participants believe the discussion centers around issus, but the only
issue you are concerned with is getting more customers, (in the tradition
that java is marketed).
Your claims contradict the experience of several people in this
newsgroup. Why don't you back up your advertising with some concrete
application which demonstrates actual speedup benefits, which is not
dependent on the platform, you tout, and someone show you how it can be
better.
--
Madhu
Madhu schrieb:
> * André Thieme <············@news.motzarella.org> :
> Wrote on Fri, 01 May 2009 13:14:55 +0200:
> |> Please stop using any and every CL thread to as an opportunity to
> |> provoke discussion to mention and eventually market clojure.
> |
> | Hu, why are you so mad? I thought you wanted to prove that you are more
> | clever than I by not answering me anymore.
> | No wait, maybe you just need some attention?
>
> The only attention I want to draw is the fact that when people respond
> to in a discussion you they are responding to a marketing machine, a
> human advertising / spam bot.
Again you prove that you are a troll.
I am still looking forward to see the first useful posting of you in
this newsgroup. Heck, even William James began to post Lisp code.
> There is a differece between offering a personal judgement and making
> dishonest claims for the purpose of marketing a product. The other
> participants believe the discussion centers around issus, but the only
> issue you are concerned with is getting more customers, (in the tradition
> that java is marketed).
You don't bring up something substantial. You are only talking about me
and constantly try to carry it to a personal level. I enjoy however to
jump in, as your postings (and my answers to them) amuse me :)
> Your claims contradict the experience of several people in this
> newsgroup.
What claims are you specifically talking about?
Who are those Clojure users, who used and use Clojure on a daily basis
to have the experience to speak up?
Until now I read mostly of people who never wrote one line of Clojure
code, like you.
I however have several years of CL background, also professionally, and
know Clojure and made personally the experience that Clojure is nicer
for me. I am in contact with experienced Lispers for who that is also
true.
> Why don't you back up your advertising with some concrete
> application which demonstrates actual speedup benefits, which is not
> dependent on the platform, you tout, and someone show you how it can be
> better.
What you ask for is not specified very well.
Do you want me to compare a single threaded CL program on a Quad-Core
CPU vs. a Clojure program running with multiple threads on it?
That sounds unfair. And what would two concurrent apps (one in CL, one
in CLJ) show?
There were already some examples in the past where I showed that Clojure
runs faster than CL when both run in a single Thread.
There were also examples that showed that CLs ran code faster than
Clojure.
In comp.lang.functional there was a thread some weeks ago showing the
speed gains for number crunching in a Clojure app, by making use of
multiple threads.
See, Clojures model helps you to make it (much) easier to write
concurrent programs. So your competition should focus on that. Obviously
a concurrent Clojure program will not necessarily run much faster than
a concurrent Common Lisp program.
Maybe you should begin to read some Clojure material and actually learn
and try it yourself. When you then come back in some months as an actual
Clojure user and tell me that you found Clojure to make it harder to
write concurrent code (compared to CL), then I will listen to what you
have to say.
Feel free to begin by translating the ants simulation to CL.
You can find it in the Clojure Google Group.
André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/
On Sat, 02 May 2009 03:16:31 +0200, André Thieme wrote:
> Madhu schrieb:
>> [something]
>
> Again you prove that you are a troll. I am still looking forward to see
> the first useful posting of you in this newsgroup. Heck, even William
> James began to post Lisp code.
I don't want to get involved in the rest of this debate, but your
opinion above is unwarranted. Madhu has answered many of my questions
in this newsgroup, and has helped me a lot.
Tamas
Tamas K Papp schrieb:
> On Sat, 02 May 2009 03:16:31 +0200, André Thieme wrote:
>
>> Madhu schrieb:
>>> [something]
>> Again you prove that you are a troll. I am still looking forward to see
>> the first useful posting of you in this newsgroup. Heck, even William
>> James began to post Lisp code.
>
> I don't want to get involved in the rest of this debate, but your
> opinion above is unwarranted. Madhu has answered many of my questions
> in this newsgroup, and has helped me a lot.
Hi Tamas. Okay, thanks for letting me know.
I was not aware of any such posting.
I just noticed that Hu is on a personal crusade against Clojure.
He is fixed on one Lisp dialect, namely CL, the most widespread one,
and sees the immediate success of Clojure as dangerous.
The unfair comparisons he makes don't amuse me. In this newsgroup we
patiently asked people who came here to complain about Lisp to first
please *learn* it, and then come back and tell us what is wrong with
it. But for Clojure now it is okay to know how to spell it to legitimate
ranting about it.
People who follow this newsgroup know that I deeply like CL, code it
every few days professionally and hope that more good work is done for
it. But unlike Hu I see Clojure as a positive influence for the Lisp
world. Only because I prefer it over CL for basically everything that
interests me (and its STM is only one of the many reasons for that), it
does *not* mean that CL is suddenly bad. It was an extremly good pro-
gramming language the day before I found Clojure, and it still is.
In the past there were multiple new Lisps that wanted to show how to
do it better, and in my opinion they all were cheap immitates, and could
not compete with CL. Of course, I thought, Clojure must be the same.
The trained behaviour I learned over the past years (new Lisps suck bad)
was not appropriate. Now it is for some cases directly or indirectly
thanks to me that some of the prejudices against it in this newsgroup
have stopped.
Some people understood the idea of fairniss, for example Raffael.
Some months ago he posted about Clojure without knowing it really.
(I think that point was mostly about the lack of TCO, and I said that
noone in the Clojure forum complains about regular crashes and other
problems with it...)
Anyway, then he sat down and learned that language. Now I am interested
in what he has to say. Maybe he does not like Clojure, and I would find
that okay. He can now have a justifiable opinion about it.
I wished that other complainers, like Hu, would take a serious look at
it for some months and *then* say what they don't like in Clojure, and
how it reduces their productivity for them.
I would really like to read in detail how a programming expert (though
maybe a Clojure newbie for 1-2 months) describes how the STM and MVCC
stand in the way while writing concurrent apps, and why the lock based
mechanism + mutable datastructures is the more productive way.
Hu however only complains, and even when Lisp vetarans step in it doesn't
stop him from continueing trolling. This motivates me to come here more
often, to read and reply.
André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/
On May 2, 4:11 am, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Hu however only complains, and even when Lisp vetarans step in it doesn't
> stop him from continueing trolling. This motivates me to come here more
> often, to read and reply.
I don't know what "step in" means. I don't consider myself a Lisp
veteran (I still am in the thick of it), but if you mean me, I did no
such thing. I came against a personal attack Madhu made against you,
and he seemed to get the message for a while. But now it is you that
are slinging personal attacks, and that is not good for you. I have
no advice to give you, because you can take or leave whatever anyone
says on this newsgroup. But if you take the apparent pass you
received in your argument against Madhu as license to spew spam
(including repetition of previously stated ideas over and over) then I
do give you a warning: more and more people will stop listening to
what you have to say altogether, and you will effectively lose your
voice on this newsgroup.
Duane
·····@franz.com schrieb:
> On May 2, 4:11 am, Andr� Thieme <address.good.until.
> ···········@justmail.de> wrote:
>
>> Hu however only complains, and even when Lisp vetarans step in it doesn't
>> stop him from continueing trolling. This motivates me to come here more
>> often, to read and reply.
>
> I don't know what "step in" means. I don't consider myself a Lisp
> veteran (I still am in the thick of it), but if you mean me, I did no
> such thing. I came against a personal attack Madhu made against you,
> and he seemed to get the message for a while. But now it is you that
> are slinging personal attacks, and that is not good for you. I have
> no advice to give you, because you can take or leave whatever anyone
> says on this newsgroup. But if you take the apparent pass you
> received in your argument against Madhu as license to spew spam
> (including repetition of previously stated ideas over and over) then I
> do give you a warning: more and more people will stop listening to
> what you have to say altogether, and you will effectively lose your
> voice on this newsgroup.
As always, well put, thanks.
I hope everyone can go continue to talk on a technical level, and remove
the word "you" out of posts as much as possible.
Repetition however is hard to avoid. When I look around in this and
other newsgroups I basically see that there is a lot of repetition.
Hundreds of times the same books were recommended, discussions about
static typing vs. dynamic typing were made, and so on.
I think it is difficult to always come up with information and expressed
opinions that are unique and were not made that way before.
Often when people are looking for a mature Lisp with good technical
support then Allegro CL is mentioned.
I understand that a majority of the people in this group are mostly
using CL and this group has a long CL history. It would just be nice,
I think, if even users of NewLisp or Bigloo or Clojure may also post
and suggest their implementation whenever someone asks for a Lisp,
without being seen as spammers. In a pure CL group this would be
different of course.
c.l.l is a nice place to talk about different Lisps and to compare them.
It is maybe better at being a place for that as more Lisp dialects arise,
I don't know.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
* Andre Thieme <············@news.motzarella.org> :
Wrote on Sat, 02 May 2009 13:11:04 +0200:
| Hu however only complains, and even when Lisp vetarans step in it
| doesn't stop him from continueing trolling. This motivates me to come
| here more often, to read and reply.
If you observe my posting history I react very rarely, and only reacted
on clojure threads when misinformation/disinformation was being wantonly
spread. In all cases I notice this source of misinformation is you,
Andre Thieme. It is you who are playing the role of a troll in this
newsgroup and you repeat, with the characterestics of a parrot, the
marketing material which Hickey has published.
Coming from India, I have been in close contact with populations that
are big markets for snake oil. People need snake oil, there is a real
requirement of snake oil, and there is no shortage of intelligent people
willing to provide the snake oil, and in many cases the authorities
collude with the sellers, especially when the snake oil seller has
unquestionable and mesmerising charisma!
The concurrency niche which Clojure tries to fill falls in this
category. From this history of concurrency, people are not going to be
satisfied. However there is money going to be made by people trying, by
downloading JVMs trying, by using google groups etc. All you are doing
is filling that role by providing the marketing material like a spambot.
There is no doubt Rich Hickey has thought deeply on his arguments so
they appear irrefutable to most of the people most of the time. These
can be only be addressed in a bigger framework, but conceptually this
looks like something that are not equipped to handle.
--
Madhu
On May 2, 4:51 am, Madhu <·······@meer.net> wrote:
>
> Coming from India, I have been in close contact with populations that
> are big markets for snake oil. People need snake oil, there is a real
> requirement of snake oil, and there is no shortage of intelligent people
> willing to provide the snake oil, and in many cases the authorities
> collude with the sellers, especially when the snake oil seller has
> unquestionable and mesmerising charisma!
>
> The concurrency niche which Clojure tries to fill falls in this
> category.
I have to object to this, and I'm not even a Clojure user. Clojure is
not snake oil; it is an experiment, that may or may not work out, but
even if it fails (which it doesn't seem to be doing) it is IMO an
excellent experiment. Transactional memory was written up in CACM a
few months ago; it is an active area of CS research.
You are welcome to your own opinion about the technical merits of the
Clojure design, but accusing Rick Hickey of peddling snake oil -- by
definition a dishonest activity -- is unjustified and offensive.
Please retract it.
-- Scott
* Scott Burson
Wrote on Sat, 2 May 2009 11:15:45 -0700 (PDT):
| On May 2, 4:51 am, Madhu <·······@meer.net> wrote:
|>
|> Coming from India, I have been in close contact with populations that
|> are big markets for snake oil. People need snake oil, there is a real
|> requirement of snake oil, and there is no shortage of intelligent people
|> willing to provide the snake oil, and in many cases the authorities
|> collude with the sellers, especially when the snake oil seller has
|> unquestionable and mesmerising charisma!
|>
|> The concurrency niche which Clojure tries to fill falls in this
|> category.
|
| I have to object to this, and I'm not even a Clojure user. Clojure is
| not snake oil; it is an experiment, that may or may not work out, but
| even if it fails (which it doesn't seem to be doing) it is IMO an
| excellent experiment. Transactional memory was written up in CACM a
| few months ago; it is an active area of CS research.
I have not reviewed the articles but I do not agree to the principles on
which you are basing your argument. The principle does not disprove my
point.
There are several areas of CS research where oodles of peer reviewed
material is published, however the results and publications are more
beneficial to the authors an publishers than to any advancement in
Computer Science. I offer SAT as an area as an example, where an NP
complete problem is of vital importance to the industry.
| You are welcome to your own opinion about the technical merits of the
| Clojure design, but accusing Rick Hickey of peddling snake oil -- by
| definition a dishonest activity -- is unjustified and offensive.
| Please retract it.
It is a possibility I think you should consider and I have alluded to
it, without explicitly making the claim, primarily from reading his
posts on CLL.
I've been following distribution/concurrency research since 1995, and it
seemed likely there will be not be a sweet spot solution which would
solve the problems under consideration. This is much like programming
languages where one can hardly expect a language where everyone will be
satisfied. Instead these research areas turn into geese that lay golden
eggs, especially where the landscape (hardware, software, and people
landscape) in which the problem exists is also being simultaneously
manipulated. I see these all these elements combining in the design and
marketing of Clojure.
At this point in time, I'm afraid I do not have enough knowledge to
retract a claim I have not formally made.
--
Madhu
On May 2, 4:30 pm, Madhu <·······@meer.net> wrote:
> * Scott Burson
> Wrote on Sat, 2 May 2009 11:15:45 -0700 (PDT):
>
> | On May 2, 4:51 am, Madhu <·······@meer.net> wrote:
> |>
> |> Coming from India, I have been in close contact with populations that
> |> are big markets for snake oil. People need snake oil, there is a real
> |> requirement of snake oil, and there is no shortage of intelligent people
> |> willing to provide the snake oil, and in many cases the authorities
> |> collude with the sellers, especially when the snake oil seller has
> |> unquestionable and mesmerising charisma!
> |>
> |> The concurrency niche which Clojure tries to fill falls in this
> |> category.
> |
> | I have to object to this, and I'm not even a Clojure user. Clojure is
> | not snake oil; it is an experiment, that may or may not work out, but
> | even if it fails (which it doesn't seem to be doing) it is IMO an
> | excellent experiment. Transactional memory was written up in CACM a
> | few months ago; it is an active area of CS research.
>
> I have not reviewed the articles but I do not agree to the principles on
> which you are basing your argument. The principle does not disprove my
> point.
>
> There are several areas of CS research where oodles of peer reviewed
> material is published, however the results and publications are more
> beneficial to the authors an publishers than to any advancement in
> Computer Science. I offer SAT as an area as an example, where an NP
> complete problem is of vital importance to the industry.
I am not sure what you are saying here. SAT solvers have progressed
remarkably in recent years and are now in production use in commercial
products today, such as the Coverity static analysis system (just one
I happen to know about). Do you think those are snake oil too??
> | You are welcome to your own opinion about the technical merits of the
> | Clojure design, but accusing Rick Hickey of peddling snake oil -- by
> | definition a dishonest activity -- is unjustified and offensive.
> | Please retract it.
>
> It is a possibility I think you should consider and I have alluded to
> it, without explicitly making the claim, primarily from reading his
> posts on CLL.
You seem not to have understood me. I already said I was aware of the
possibility that Clojure might not work out technically (though that
possibility seems more remote by the month, as the language gathers
momentum). The other possibility you seem to be suggesting, that Rich
is peddling a solution he knows will not work, is one I have no
intention of considering.
> I've been following distribution/concurrency research since 1995, and it
> seemed likely there will be not be a sweet spot solution which would
> solve the problems under consideration. This is much like programming
> languages where one can hardly expect a language where everyone will be
> satisfied. Instead these research areas turn into geese that lay golden
> eggs, especially where the landscape (hardware, software, and people
> landscape) in which the problem exists is also being simultaneously
> manipulated. I see these all these elements combining in the design and
> marketing of Clojure.
This seems a rather curmudgeonly viewpoint. The only way we get a
sense of how some of these things work in real life is for a lot of
people to work on them and try them out. You leave me with the
impression that your objection is mostly driven by envy of others'
success.
-- Scott
* Scott Burson
Wrote on Sat, 2 May 2009 21:19:39 -0700 (PDT):
|> | I have to object to this, and I'm not even a Clojure user. Clojure is
|> | not snake oil; it is an experiment, that may or may not work out, but
|> | even if it fails (which it doesn't seem to be doing) it is IMO an
|> | excellent experiment. Transactional memory was written up in CACM a
|> | few months ago; it is an active area of CS research.
|>
|> I have not reviewed the articles but I do not agree to the principles on
|> which you are basing your argument. The principle does not disprove my
|> point.
|>
|> There are several areas of CS research where oodles of peer reviewed
|> material is published, however the results and publications are more
|> beneficial to the authors an publishers than to any advancement in
|> Computer Science. I offer SAT as an area as an example, where an NP
|> complete problem is of vital importance to the industry.
|
| I am not sure what you are saying here. SAT solvers have progressed
| remarkably in recent years and are now in production use in commercial
| products today, such as the Coverity static analysis system (just one
| I happen to know about). Do you think those are snake oil too??
No that is not the point. I said they are of vital importance to the
--- I run a satsolver everytime opensuse wants to compute an rpm upgrade
point.
The scope of the problem results in a playing field such that any claim
can be justified by suitably choosing the problem and data. Any number
of papers can be published after running a few simulations and plotting
points. The peers can collude with perfect knowledge that no real
advace has been made but its all in Enlightened self interest as there
is a source of money for further work. The scope for dishonesty is in
this system.
Not sure how clear I've been in articulating the point. The important
thing (for me) is that you should be able to recognize it as such on
seeing it.
|> I've been following distribution/concurrency research since 1995, and
|> it seemed likely there will be not be a sweet spot solution which
|> would solve the problems under consideration. This is much like
|> programming languages where one can hardly expect a language where
|> everyone will be satisfied. Instead these research areas turn into
|> geese that lay golden eggs, especially where the landscape (hardware,
|> software, and people landscape) in which the problem exists is also
|> being simultaneously manipulated. I see these all these elements
|> combining in the design and marketing of Clojure.
|
| This seems a rather curmudgeonly viewpoint. The only way we get a
| sense of how some of these things work in real life is for a lot of
| people to work on them and try them out. You leave me with the
| impression that your objection is mostly driven by envy of others'
| success.
This argument is reminiscent of arguments I've noticed where clojure is
marketed--- both sides make the same point, but with totally different
spins.
I'm not sure as what you define by success in this context. Revenue
from pageads on clojure google groups? Or do you think fooling most of
the people most of the time is success, then no, I am not envious of
that. In any case if you want to stick to the "success" spin, perhaps
you can see my objection as being one that your notion of "success",
comes at a cost that is invisible to you.
--
Madhu
Madhu schrieb:
> * Andre Thieme <············@news.motzarella.org> :
> Wrote on Sat, 02 May 2009 13:11:04 +0200:
>
> | Hu however only complains, and even when Lisp vetarans step in it
> | doesn't stop him from continueing trolling. This motivates me to come
> | here more often, to read and reply.
>
> If you observe my posting history I react very rarely, and only reacted
> on clojure threads when misinformation/disinformation was being wantonly
> spread. In all cases I notice this source of misinformation is you,
> Andre Thieme. It is you who are playing the role of a troll in this
> newsgroup and you repeat, with the characterestics of a parrot, the
> marketing material which Hickey has published.
Hu, I said several times that I have some years of CL experience and now
some months of Clojure experience.
There are several ways to prove things and come to believe them. One of
those ways is to personally experience it.
This happened to me. I notice on a nearly daily basis how writing my
code in Clojure helps me. The years before I noticed that the same thing
was true when doing CL programming, instead of (for example) PHP.
This becomes most obvious not when programming in Clojure, but in CL.
Before I had this when I did CL in my free time and then did PHP in the
office, several years ago.
With that background I then post in this newsgroup, and get replies by
people who never wrote a line of Clojure code, who try to explain how it
really works. Why is Jon Harrop told to first learn CL and then write
about it, while at the same time a CLer does not need to learn Clojure
before explaining its advantages and disadvantages?
Until now the people without Clojure experience failed to show me what
the points in Clojure are that make it less adequate for me than CL.
I see nearly every day that I get small productivity gains.
And (also with characteristics of a parrot) repetitions of CL fans in
this newsgroup who try to explain those away don't change the facts.
> The concurrency niche which Clojure tries to fill falls in this
> category. From this history of concurrency, people are not going to be
> satisfied. However there is money going to be made by people trying, by
> downloading JVMs trying, by using google groups etc. All you are doing
> is filling that role by providing the marketing material like a spambot.
Clojure does not just try to fill the concurrency niche.
Btw, this niche will soon become so gaping big that the real niche will
be to be outside that niche.
Clojure is absolutely able to write several kinds of applications in.
In principle you could use it for nearly all apps that you use CL for,
or say, Java or C#. That can be desktop applications, big servers or
programs that run on Android or on the Google AppEngine.
If you would have been using Clojure for some months and actively
developing in it, you would know that it is a general purpose
programming language.
Maybe this year or maybe next year I think and hope that at least one
commercial CL will also offer similar concurrency mechanisms as Clojure
does. Then the concurrency advantage that Clojure has over CL would be
greatly reduced. I am also looking forward to see all the sceptics then
ranting about it, and tell that vendor how useless this is, like they
now tell me :)
This aspect btw amuses me to some extent. I notice that in all kinds of
areas. Some device, OS, DB system or programming language gets feature
XY. People from the competing camp jump into discussions, telling the
world how much XY sucks. A year later their favorite thing also gets XY.
Duh!
Now the same people are at the foremost front, trying to explain that
they always were the ones who understood the advantages of XY ;)
That is because many people fail to see that they and their tools are
part of an evolutionary system.
It does not always make sense to get emotionally too attached with a
specific component in that system.
Clojure offers most of the important components that CL offers.
The biggest single difference is that Clojure does not have something
like CLOS. Although Raffael mentioned that there already is a similar
system. There are some other advantages that CL has, for example the
condition system, which is not available to that extent in CLJ, although
most parts are covered.
Besides that I see no big components that CL offers that could influence
the productivity gains.
On the other hand, Clojure offers several components that are not
available per se for CL. Of course, one could evolve CL more into the
direction of Clojure (and that is going to happen I guess (maybe I will
be wrong)), and then get the same benefits.
I see however one advantage for Clojure here, and that is that it
currently only has one implementation, and that sits on the JVM.
Rich does not need to care about writing a GC. Sun recently made their
new GC available, which brings lots of improvements. Programmers can
have more control over the concurrently working GC. Devs of CL
implementations don't have the resources to do that.
Tons of lib are ready and waiting to be used. As Clojure has just one
implementations it means that all work on it goes into improving it.
If someone writes a STM for CL she will have to port it to at least
five implementations to consider a STM being available for CL. Also
it will hopefully work under the three major OSes.
Clustering solutions like Terracotta are years ahead of what is
available in the CL world today.
There are so many man hours of work put into Clojure and into the JVM,
that it is extremly hard for CLs to compete with that. Clojure just
evolves faster right now.
Duane put it right when he explained that issue some days ago. If
Clojure misses some components today they may already be available in
a few days. But even with what it has *right now* it makes me and my
company more productive.
That is a fact, and we are a group of experienced CL devs.
Also I talk with people in the #Clojure channel in IRC. I hear similar
reports.
We can't just go over this, as if this was all a big lie for marketing.
> There is no doubt Rich Hickey has thought deeply on his arguments so
> they appear irrefutable to most of the people most of the time. These
> can be only be addressed in a bigger framework, but conceptually this
> looks like something that are not equipped to handle.
Maybe at least some of his arguments are valid, and not all just
marketing tricks, made to deceive some thousand people who fell for
the lies, with the exception of some CL experts who uncovered that
dirty game.
Clojure is and will most likely not be the ultimate answer to end
the problems in this world. However, it works for me and thousand
others very well right now. Those are not just delusioned people,
but they too are good programmers and say truthful things.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
Andr� Thieme wrote:
> Clojure is and will most likely not be the ultimate answer to end
> the problems in this world.
I think you meant "Clojure is not and most likely never will be the
ultimate answer to all the world's problems." My mental zipper parsed
the orignial as "is and will not be" which is more about the
inevitability of death (sorry, Pascal) which is not I think how you feel
about Clojure. And answers cannot end other things, nor can problems be
ended, and it's problems of this world and I think you meant "and all
problems", not "the problems" though "the" indeed has a universal
connotation to it--English is a mess, sorry. Then ultimate seems flaccid
and is there some liability lawyer demanding you hedge the "most
likely"? How about "Clojure is not and never will be the answer to all
the world's problems."
> However, it works for me and thousand
> others very well right now. Those are not just delusioned people,
> but they too are good programmers and say truthful things.
So what do you care what anybody thinks? Go write Clojure. Too easy?
kt
Kenneth Tilton schrieb:
> Andr� Thieme wrote:
>> Clojure is and will most likely not be the ultimate answer to end
>> the problems in this world.
>
> I think you meant "Clojure is not and most likely never will be the
> ultimate answer to all the world's problems." My mental zipper parsed
> the orignial as "is and will not be" which is more about the
> inevitability of death (sorry, Pascal) which is not I think how you feel
> about Clojure. And answers cannot end other things, nor can problems be
> ended, and it's problems of this world and I think you meant "and all
> problems", not "the problems" though "the" indeed has a universal
> connotation to it--English is a mess, sorry. Then ultimate seems flaccid
> and is there some liability lawyer demanding you hedge the "most
> likely"? How about "Clojure is not and never will be the answer to all
> the world's problems."
Fair enough.
>> However, it works for me and thousand
>> others very well right now. Those are not just delusioned people,
>> but they too are good programmers and say truthful things.
>
> So what do you care what anybody thinks? Go write Clojure. Too easy?
But I am writing it :)
Every day at work, and on my free days for hobby projects. There is also
a CL project planned.
It is just not my only interest. I also like to spend my free time with
something else. This weekend I am in the mood to read and write in/to
c.l.l.
Hey, btw, I will hopefull take a look at Cells for Clojure :)
Andr�
--
http://farm4.static.flickr.com/3230/2506759353_ea0685bdf7.jpg?v=0
Andr� Thieme <······························@justmail.de> writes:
> [...]
> Until now the people without Clojure experience failed to show me what
> the points in Clojure are that make it less adequate for me than CL.
It is not so necessary, since you apparently know some of its shortcomings
yourself:
> [...]
> The biggest single difference is that Clojure does not have something
> like CLOS. Although Raffael mentioned that there already is a similar
> system. There are some other advantages that CL has, for example the
> condition system, which is not available to that extent in CLJ, although
> most parts are covered.
> [...]
Nicolas
--
Lisp is not dead. It�s only Andre Thieme who has lost his good taste.
Nicolas Neuss schrieb:
> Andr� Thieme <······························@justmail.de> writes:
>
>> [...]
>> Until now the people without Clojure experience failed to show me what
>> the points in Clojure are that make it less adequate for me than CL.
>
> It is not so necessary, since you apparently know some of its shortcomings
> yourself:
>
>> [...]
>> The biggest single difference is that Clojure does not have something
>> like CLOS. Although Raffael mentioned that there already is a similar
>> system. There are some other advantages that CL has, for example the
>> condition system, which is not available to that extent in CLJ, although
>> most parts are covered.
>> [...]
True. And there are other things that CL has and CLJ not. For example
symbol-macrolet. But I see that this is a minor issue compared to not
having CLOS, for most people.
OOP experts and rigid users of CLOS, such as Pascal C. would most likely
miss CLOS. I am not fully certain about the state of this issue, as
Raffael mentioned that something like CLOS already exists. In that case
this shortcoming of Clojure would be mostly eliminated.
Anyway, I personally see it as a plus of not having a OOP system.
The idea of keeping the data in hashmaps and have abritary dispatch
functions in generic methods appeals more to me.
I am with Paul Graham here who says that functional programming plus
macros trancend OOP (in his book �ANSI Common Lisp�).
But what I would really like to see is an optional static type system
for Clojure. Something like Gradual Typing, see
http://video.google.com/videoplay?docid=21835070615692553
On May 2, 6:28 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Nicolas Neuss schrieb:
>
>
>
> > André Thieme <······························@justmail.de> writes:
>
> >> [...]
> >> Until now the people without Clojure experience failed to show me what
> >> the points in Clojure are that make it less adequate for me than CL.
>
> > It is not so necessary, since you apparently know some of its shortcomings
> > yourself:
>
> >> [...]
> >> The biggest single difference is that Clojure does not have something
> >> like CLOS. Although Raffael mentioned that there already is a similar
> >> system. There are some other advantages that CL has, for example the
> >> condition system, which is not available to that extent in CLJ, although
> >> most parts are covered.
> >> [...]
>
> True. And there are other things that CL has and CLJ not. For example
> symbol-macrolet. But I see that this is a minor issue compared to not
> having CLOS, for most people.
> OOP experts and rigid users of CLOS, such as Pascal C. would most likely
> miss CLOS. I am not fully certain about the state of this issue, as
> Raffael mentioned that something like CLOS already exists. In that case
> this shortcoming of Clojure would be mostly eliminated.
> Anyway, I personally see it as a plus of not having a OOP system.
> The idea of keeping the data in hashmaps and have abritary dispatch
> functions in generic methods appeals more to me.
I don't see how you can say this. With STM, doing the "OOP thing" and
letting the objects be accessed and manipulated from multiple threads
at the same time in various "nested ways" is safe and sane again.
> I am with Paul Graham here who says that functional programming plus
> macros trancend OOP (in his book “ANSI Common Lisp”).
Riight.
> But what I would really like to see is an optional static type system
> for Clojure. Something like Gradual Typing, seehttp://video.google.com/videoplay?docid=21835070615692553
Lars Rune N�stdal schrieb:
> On May 2, 6:28 pm, Andr� Thieme <address.good.until.
> ···········@justmail.de> wrote:
>> Nicolas Neuss schrieb:
>>
>>
>>
>>> Andr� Thieme <······························@justmail.de> writes:
>>>> [...]
>>>> Until now the people without Clojure experience failed to show me what
>>>> the points in Clojure are that make it less adequate for me than CL.
>>> It is not so necessary, since you apparently know some of its shortcomings
>>> yourself:
>>>> [...]
>>>> The biggest single difference is that Clojure does not have something
>>>> like CLOS. Although Raffael mentioned that there already is a similar
>>>> system. There are some other advantages that CL has, for example the
>>>> condition system, which is not available to that extent in CLJ, although
>>>> most parts are covered.
>>>> [...]
>> True. And there are other things that CL has and CLJ not. For example
>> symbol-macrolet. But I see that this is a minor issue compared to not
>> having CLOS, for most people.
>> OOP experts and rigid users of CLOS, such as Pascal C. would most likely
>> miss CLOS. I am not fully certain about the state of this issue, as
>> Raffael mentioned that something like CLOS already exists. In that case
>> this shortcoming of Clojure would be mostly eliminated.
>> Anyway, I personally see it as a plus of not having a OOP system.
>> The idea of keeping the data in hashmaps and have abritary dispatch
>> functions in generic methods appeals more to me.
>
> I don't see how you can say this.
Say what?
> With STM, doing the "OOP thing" and
> letting the objects be accessed and manipulated from multiple threads
> at the same time in various "nested ways" is safe and sane again.
Uhm yeah, but why do you mention that?
I was not talking about this.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On May 2, 7:11 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Lars Rune Nøstdal schrieb:
>
>
>
> > On May 2, 6:28 pm, André Thieme <address.good.until.
> > ···········@justmail.de> wrote:
> >> Nicolas Neuss schrieb:
>
> >>> André Thieme <······························@justmail.de> writes:
> >>>> [...]
> >>>> Until now the people without Clojure experience failed to show me what
> >>>> the points in Clojure are that make it less adequate for me than CL.
> >>> It is not so necessary, since you apparently know some of its shortcomings
> >>> yourself:
> >>>> [...]
> >>>> The biggest single difference is that Clojure does not have something
> >>>> like CLOS. Although Raffael mentioned that there already is a similar
> >>>> system. There are some other advantages that CL has, for example the
> >>>> condition system, which is not available to that extent in CLJ, although
> >>>> most parts are covered.
> >>>> [...]
> >> True. And there are other things that CL has and CLJ not. For example
> >> symbol-macrolet. But I see that this is a minor issue compared to not
> >> having CLOS, for most people.
> >> OOP experts and rigid users of CLOS, such as Pascal C. would most likely
> >> miss CLOS. I am not fully certain about the state of this issue, as
> >> Raffael mentioned that something like CLOS already exists. In that case
> >> this shortcoming of Clojure would be mostly eliminated.
> >> Anyway, I personally see it as a plus of not having a OOP system.
> >> The idea of keeping the data in hashmaps and have abritary dispatch
> >> functions in generic methods appeals more to me.
>
> > I don't see how you can say this.
>
> Say what?
That not having an OOP system is a plus.
> > With STM, doing the "OOP thing" and
> > letting the objects be accessed and manipulated from multiple threads
> > at the same time in various "nested ways" is safe and sane again.
>
> Uhm yeah, but why do you mention that?
> I was not talking about this.
Ok, I haven't been paying attention then.
Lars Rune N�stdal schrieb:
>>>> Anyway, I personally see it as a plus of not having a OOP system.
>>>> The idea of keeping the data in hashmaps and have abritary dispatch
>>>> functions in generic methods appeals more to me.
>>> I don't see how you can say this.
>> Say what?
>
> That not having an OOP system is a plus.
This is only my personal opinion (and wrote that). I can not say in
general that it is a plus. Vivid users of CLOS like Pascal C. (hopefully
this time I got the right word *g*) would not prefer that.
It's a difficult issue. When something ships by default with a language
implementation it will be what most people use. That is good for more
compatibility. At the same time it is a bit against the idea of Lisp
being a building material. I can imagine that during standardization it
was at least considered to not put CLOS into the standard.
With the reader macros for hashmaps and some convenient abstractions I
see Clojure well positioned for writing complex applications. In one or
two years we will see more. It is possible that my intuition is wrong
and that it is too early to say my experiences of the past month will
continue to scale that good.. maybe Clojure will fail. But perhaps it
opens an alternative approach to some problems. I think so, right now.
I am always open to be proved wrong.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On May 2, 9:07 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Lars Rune Nøstdal schrieb:
>
> >>>> Anyway, I personally see it as a plus of not having a OOP system.
> >>>> The idea of keeping the data in hashmaps and have abritary dispatch
> >>>> functions in generic methods appeals more to me.
> >>> I don't see how you can say this.
> >> Say what?
>
> > That not having an OOP system is a plus.
>
> This is only my personal opinion (and wrote that). I can not say in
> general that it is a plus. Vivid users of CLOS like Pascal C. (hopefully
> this time I got the right word *g*) would not prefer that.
> It's a difficult issue. When something ships by default with a language
> implementation it will be what most people use. That is good for more
> compatibility. At the same time it is a bit against the idea of Lisp
> being a building material. I can imagine that during standardization it
> was at least considered to not put CLOS into the standard.
Yeah, well that holds true for, say, a default thread or concurrency
API and STM-support too, don't it?
This seems a bit pointless to discuss really.
Lars Rune N�stdal schrieb:
> On May 2, 9:07 pm, Andr� Thieme <address.good.until.
> ···········@justmail.de> wrote:
>> Lars Rune N�stdal schrieb:
>>
>>>>>> Anyway, I personally see it as a plus of not having a OOP system.
>>>>>> The idea of keeping the data in hashmaps and have abritary dispatch
>>>>>> functions in generic methods appeals more to me.
>>>>> I don't see how you can say this.
>>>> Say what?
>>> That not having an OOP system is a plus.
>> This is only my personal opinion (and wrote that). I can not say in
>> general that it is a plus. Vivid users of CLOS like Pascal C. (hopefully
>> this time I got the right word *g*) would not prefer that.
>> It's a difficult issue. When something ships by default with a language
>> implementation it will be what most people use. That is good for more
>> compatibility. At the same time it is a bit against the idea of Lisp
>> being a building material. I can imagine that during standardization it
>> was at least considered to not put CLOS into the standard.
>
> Yeah, well that holds true for, say, a default thread or concurrency
> API and STM-support too, don't it?
That's not very different between many Lisps. For most threading support
or the GC is not a lib that one needs to load, or the compiler that
ships with the implementations.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On May 2, 10:08 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Lars Rune Nøstdal schrieb:
>
>
>
> > On May 2, 9:07 pm, André Thieme <address.good.until.
> > ···········@justmail.de> wrote:
> >> Lars Rune Nøstdal schrieb:
>
> >>>>>> Anyway, I personally see it as a plus of not having a OOP system.
> >>>>>> The idea of keeping the data in hashmaps and have abritary dispatch
> >>>>>> functions in generic methods appeals more to me.
> >>>>> I don't see how you can say this.
> >>>> Say what?
> >>> That not having an OOP system is a plus.
> >> This is only my personal opinion (and wrote that). I can not say in
> >> general that it is a plus. Vivid users of CLOS like Pascal C. (hopefully
> >> this time I got the right word *g*) would not prefer that.
> >> It's a difficult issue. When something ships by default with a language
> >> implementation it will be what most people use. That is good for more
> >> compatibility. At the same time it is a bit against the idea of Lisp
> >> being a building material. I can imagine that during standardization it
> >> was at least considered to not put CLOS into the standard.
>
> > Yeah, well that holds true for, say, a default thread or concurrency
> > API and STM-support too, don't it?
>
> That's not very different between many Lisps. For most threading support
> or the GC is not a lib that one needs to load, or the compiler that
> ships with the implementations.
Ok, you missed the point. Forget it.
Lars Rune N�stdal schrieb:
> Ok, you missed the point. Forget it.
There is the "you" word again. In the previous posting I thought:
"Hey is it possible? On this newsgroup there are people who actually can
discuss and leave the personal level out. Cool!"
Anyway, maybe you can explain what the point was.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On May 2, 10:25 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Lars Rune Nøstdal schrieb:
>
> > Ok, you missed the point. Forget it.
>
> There is the "you" word again. In the previous posting I thought:
> "Hey is it possible? On this newsgroup there are people who actually can
> discuss and leave the personal level out. Cool!"
A.T.: "This is only MY personal opinion .."
> Anyway, maybe you can explain what the point was.
Nah.
Lars Rune N�stdal schrieb:
> On May 2, 10:25 pm, Andr� Thieme <address.good.until.
> ···········@justmail.de> wrote:
>> Lars Rune N�stdal schrieb:
>>
>>> Ok, you missed the point. Forget it.
>> There is the "you" word again. In the previous posting I thought:
>> "Hey is it possible? On this newsgroup there are people who actually can
>> discuss and leave the personal level out. Cool!"
>
> A.T.: "This is only MY personal opinion .."
That quote is out of context.
Originally I said:
"Anyway, I personally see it as a plus of not having a OOP system."
This is not a statement addressed specifically to another reader, and
it says not explicitly something about him or her.
The meaning of "It is a plus of not having an OOP system" is different.
>> Anyway, maybe you can explain what the point was.
>
> Nah.
Strange.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
Andr� Thieme wrote:
> Nicolas Neuss schrieb:
>> Andr� Thieme <······························@justmail.de> writes:
>>
>>> [...]
>>> Until now the people without Clojure experience failed to show me what
>>> the points in Clojure are that make it less adequate for me than CL.
>>
>> It is not so necessary, since you apparently know some of its
>> shortcomings
>> yourself:
>>
>>> [...]
>>> The biggest single difference is that Clojure does not have something
>>> like CLOS. Although Raffael mentioned that there already is a similar
>>> system. There are some other advantages that CL has, for example the
>>> condition system, which is not available to that extent in CLJ, although
>>> most parts are covered.
>>> [...]
>
> True. And there are other things that CL has and CLJ not. For example
> symbol-macrolet. But I see that this is a minor issue compared to not
> having CLOS, for most people.
> OOP experts and rigid users of CLOS, such as Pascal C. would most likely
> miss CLOS.
What makes you think my use of CLOS is 'rigid?'
> I am not fully certain about the state of this issue, as
> Raffael mentioned that something like CLOS already exists. In that case
> this shortcoming of Clojure would be mostly eliminated.
The major advantage of CLOS is that it has a number of very efficient
implementation, with very little compromises in the flexibility
department. This is based on a lot of careful design and implementation
work that cannot be easily reproduced in a few weeks or months.
> Anyway, I personally see it as a plus of not having a OOP system.
> The idea of keeping the data in hashmaps and have abritary dispatch
> functions in generic methods appeals more to me.
The idea of 'arbitrary dispatch functions' doesn't generalize. Clojure
defines a hook where two methods can be compared based on user code in
case Clojure cannot automatically detect which method is more specific
than the other. This is basically admitting that it doesn't generalize.
This is one of the parts of Clojure that make me somewhat skeptical. I
guess these 'arbitrary dispatch functions' probably work well for some
simple examples, but I find it hard to imagine that they scale well.
(This is issue is, by the way, known in the literature.)
> I am with Paul Graham here who says that functional programming plus
> macros trancend OOP (in his book �ANSI Common Lisp�).
LOL
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/
Pascal Costanza schrieb:
> Andr� Thieme wrote:
>> Nicolas Neuss schrieb:
>>> Andr� Thieme <······························@justmail.de> writes:
>>>
>>>
>>>> [...] Until now the people without Clojure experience failed to
>>>> show me what the points in Clojure are that make it less
>>>> adequate for me than CL.
>>>
>>> It is not so necessary, since you apparently know some of its
>>> shortcomings yourself:
>>>
>>>> [...] The biggest single difference is that Clojure does not
>>>> have something like CLOS. Although Raffael mentioned that there
>>>> already is a similar system. There are some other advantages
>>>> that CL has, for example the condition system, which is not
>>>> available to that extent in CLJ, although most parts are
>>>> covered. [...]
>>
>> True. And there are other things that CL has and CLJ not. For
>> example symbol-macrolet. But I see that this is a minor issue
>> compared to not having CLOS, for most people. OOP experts and rigid
>> users of CLOS, such as Pascal C. would most likely miss CLOS.
>
> What makes you think my use of CLOS is 'rigid?'
Oh sorry, that was the wrong word!
I just wanted to express that I have the impression that you use CLOS
often and with a deep background and knowledge, plus addons such as
AspectL.
>> I am not fully certain about the state of this issue, as Raffael
>> mentioned that something like CLOS already exists. In that case
>> this shortcoming of Clojure would be mostly eliminated.
>
> The major advantage of CLOS is that it has a number of very efficient
> implementation, with very little compromises in the flexibility
> department. This is based on a lot of careful design and
> implementation work that cannot be easily reproduced in a few weeks
> or months.
Yes, I agree.
It is unlikely that a CLOS-like implementation for Clojure that is just
a few weeks old and has only a few users is as performant and mature as
CLOS in, say, Allegro CL.
>> Anyway, I personally see it as a plus of not having a OOP system.
>> The idea of keeping the data in hashmaps and have abritary dispatch
>> functions in generic methods appeals more to me.
>
> The idea of 'arbitrary dispatch functions' doesn't generalize.
> Clojure defines a hook where two methods can be compared based on
> user code in case Clojure cannot automatically detect which method is
> more specific than the other. This is basically admitting that it
> doesn't generalize.
Could you please say a bit more about this? Maybe you have a good and
important point here, and I don't want to misunderstand it.
What I had in mind was something like:
user> (defmulti foo count)
#'user/foo
user> (defmethod foo 3 [x] (println "Three elements in" x))
#<MultiFn ····················@1feaf06>
user> (defmethod foo 10 [x] (- (Integer/parseInt (str (first x))) 100))
#<MultiFn ····················@1feaf06>
user> (foo [10 20 30])
Three elements in [10 20 30] <-- printed output
nil
user> (foo "1234567890")
-99
or
user> (defmulti bar (fn [a b] (if (even? a) (+ a b) (* 2 b))))
#'user/bar
user> (defmethod bar 8 [a b] (println "[a b] =" [a b]))
#<MultiFn ····················@16321e6>
user> (bar 6 2)
[a b] = [6 2] <-- printed output
nil
user> (bar 1 4)
[a b] = [1 4] <-- printed output
nil
>> I am with Paul Graham here who says that functional programming
>> plus macros trancend OOP (in his book �ANSI Common Lisp�).
>
> LOL
:-)
He wrote it in chapter 1:
�With macros, closures, and run-time typing, Lisp transcends
object-oriented programming. If you understood the preceding
sentence, you probably should not be reading this book. You would
have to know Lisp pretty well to see why it's true. But it is not
just words. It is an important point, and the proof of it is made
quite explicit, in code, in Chapter 17.�
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
* André Thieme <············@news.motzarella.org> :
Wrote on Sat, 02 May 2009 16:51:48 +0200:
[more dishonest clojure marketing snipped]
Apparently you have found some means to make money from clojure, I'm not
sure how, or who is investing in it. If the folks giving you contracts
have any real requirements they need to solve other than selling the
platform you are working on, and they arent just investing in a labour
market to profit from arbitrage of programmer wages on dud projects,
they are welcome to contact me for better CL solutions.
--
Madhu
On May 2, 6:35 pm, Madhu <·······@meer.net> wrote:
> * André Thieme <············@news.motzarella.org> :
> Wrote on Sat, 02 May 2009 16:51:48 +0200:
>
> [more dishonest clojure marketing snipped]
>
> Apparently you have found some means to make money from clojure, I'm not
> sure how, or who is investing in it.
My guess would be Monsanto, probably.
Madhu schrieb:
> * André Thieme <············@news.motzarella.org> :
> Wrote on Sat, 02 May 2009 16:51:48 +0200:
>
> [honest posting snipped by the mad Hu]
>
> Apparently you have found some means to make money from clojure, I'm not
> sure how, or who is investing in it. If the folks giving you contracts
> have any real requirements they need to solve other than selling the
> platform you are working on, and they arent just investing in a labour
> market to profit from arbitrage of programmer wages on dud projects,
> they are welcome to contact me for better CL solutions.
Hu, why are you so mad?
There just has to be some other source where you can get attention...
Again lies and trolling of you. That seems to be the only thing you can
do: personal attacks, instead of explaining why CL allows people to do
work in a more productive way.
You have no Clojure experience at all, your mind is full of
misconceptions about it, and even CL veterans like Duane can not bring
you back to sanity. You seem to be on a personal crusade.
It will be funny when we meet at a Lisp conference :)
André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/
* André Thieme <············@news.motzarella.org> :
Wrote on Sat, 02 May 2009 19:09:36 +0200:
| Madhu schrieb:
|> * André Thieme <············@news.motzarella.org> :
|> Wrote on Sat, 02 May 2009 16:51:48 +0200:
|> Apparently you have found some means to make money from clojure, I'm not
|> sure how, or who is investing in it. If the folks giving you contracts
|> have any real requirements they need to solve other than selling the
|> platform you are working on, and they arent just investing in a labour
|> market to profit from arbitrage of programmer wages on dud projects,
|> they are welcome to contact me for better CL solutions.
|
[more personal attack snipped and dishonesty snipped]
Everywhere you are accusing me of lying and trolling I see you lying and
trolling. Surely there is a lesson in this.
above, I offered a way of settling the isssue in a productive way, and I
stick with the offer.
--
Madhu
Madhu schrieb:
> * André Thieme <············@news.motzarella.org> :
> Wrote on Sat, 02 May 2009 19:09:36 +0200:
> [more personal attack snipped and dishonesty snipped]
>
> Everywhere you are accusing me of lying and trolling I see you lying and
> trolling. Surely there is a lesson in this.
>
> above, I offered a way of settling the isssue in a productive way, and I
> stick with the offer.
We should try to focus more on technical discussion, as Duane suggests.
A little analysis could be interesting. We look at simple problems and
see if there is a trend. To some extent we can slowly make the examples
more complex.
Maybe a counter in a concurrent environment?
Example code:
(defn make-counter [n] (atom n))
(defn inc-counter [counter n]
(dotimes [i n]
(swap! counter inc)))
(def *counter* (make-counter 0))
(dotimes [i 10] (future (inc-counter *counter* 100000)))
*counter* ==> 1000000
You can provide the CL code and explain why it is okay to use the STM
for this, or why it would have been better to take the classical
approach with locks.
André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/
On May 3, 1:46 am, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Madhu schrieb:
>
> > * André Thieme <············@news.motzarella.org> :
> > Wrote on Sat, 02 May 2009 19:09:36 +0200:
> > [more personal attack snipped and dishonesty snipped]
>
> > Everywhere you are accusing me of lying and trolling I see you lying and
> > trolling. Surely there is a lesson in this.
>
> > above, I offered a way of settling the isssue in a productive way, and I
> > stick with the offer.
>
> We should try to focus more on technical discussion, as Duane suggests.
> A little analysis could be interesting. We look at simple problems and
> see if there is a trend. To some extent we can slowly make the examples
> more complex.
> Maybe a counter in a concurrent environment?
> Example code:
>
> (defn make-counter [n] (atom n))
>
> (defn inc-counter [counter n]
> (dotimes [i n]
> (swap! counter inc)))
>
> (def *counter* (make-counter 0))
>
> (dotimes [i 10] (future (inc-counter *counter* 100000)))
>
> *counter* ==> 1000000
>
Using CAS with some utility functions/macros in SBCL:
(defun mk-counter (n)
(mk-atom n))
(defun incf-counter (counter n)
(dotimes (i n)
(swap-atom-fn counter
#'1+)))
(defparameter *counter* (mk-counter 0))
(defun test ()
(dotimes (i 10)
(with-thread (nil)
(incf-counter *counter* 100000))))
> (test)
1000000
> You can provide the CL code and explain why it is okay to use the STM
> for this, or why it would have been better to take the classical
> approach with locks.
>
> André
> --
> Lisp is not dead. It’s just the URL that has changed:http://clojure.org/
On May 3, 2:44 am, Lars Rune Nøstdal <···········@gmail.com> wrote:
> On May 3, 1:46 am, André Thieme <address.good.until.
>
>
>
> ···········@justmail.de> wrote:
> > Madhu schrieb:
>
> > > * André Thieme <············@news.motzarella.org> :
> > > Wrote on Sat, 02 May 2009 19:09:36 +0200:
> > > [more personal attack snipped and dishonesty snipped]
>
> > > Everywhere you are accusing me of lying and trolling I see you lying and
> > > trolling. Surely there is a lesson in this.
>
> > > above, I offered a way of settling the isssue in a productive way, and I
> > > stick with the offer.
>
> > We should try to focus more on technical discussion, as Duane suggests.
> > A little analysis could be interesting. We look at simple problems and
> > see if there is a trend. To some extent we can slowly make the examples
> > more complex.
> > Maybe a counter in a concurrent environment?
> > Example code:
>
> > (defn make-counter [n] (atom n))
>
> > (defn inc-counter [counter n]
> > (dotimes [i n]
> > (swap! counter inc)))
>
> > (def *counter* (make-counter 0))
>
> > (dotimes [i 10] (future (inc-counter *counter* 100000)))
>
> > *counter* ==> 1000000
>
> Using CAS with some utility functions/macros in SBCL:
I meant CAS from SBCL
.. and, gah .. it is impossible to post without messing things up. The
test function got cut off at the end:
(defun test ()
(dotimes (i 10)
(with-thread (nil)
(incf-counter *counter* 100000)))
*counter*)
On May 3, 2:50 am, Lars Rune Nøstdal <···········@gmail.com> wrote:
> On May 3, 2:44 am, Lars Rune Nøstdal <···········@gmail.com> wrote:
>
>
>
> > On May 3, 1:46 am, André Thieme <address.good.until.
>
> > ···········@justmail.de> wrote:
> > > Madhu schrieb:
>
> > > > * André Thieme <············@news.motzarella.org> :
> > > > Wrote on Sat, 02 May 2009 19:09:36 +0200:
> > > > [more personal attack snipped and dishonesty snipped]
>
> > > > Everywhere you are accusing me of lying and trolling I see you lying and
> > > > trolling. Surely there is a lesson in this.
>
> > > > above, I offered a way of settling the isssue in a productive way, and I
> > > > stick with the offer.
>
> > > We should try to focus more on technical discussion, as Duane suggests.
> > > A little analysis could be interesting. We look at simple problems and
> > > see if there is a trend. To some extent we can slowly make the examples
> > > more complex.
> > > Maybe a counter in a concurrent environment?
> > > Example code:
>
> > > (defn make-counter [n] (atom n))
>
> > > (defn inc-counter [counter n]
> > > (dotimes [i n]
> > > (swap! counter inc)))
>
> > > (def *counter* (make-counter 0))
>
> > > (dotimes [i 10] (future (inc-counter *counter* 100000)))
>
> > > *counter* ==> 1000000
>
> > Using CAS with some utility functions/macros in SBCL:
>
> I meant CAS from SBCL
>
> .. and, gah .. it is impossible to post without messing things up. The
> test function got cut off at the end:
>
> (defun test ()
> (dotimes (i 10)
> (with-thread (nil)
> (incf-counter *counter* 100000)))
> *counter*)
PS: Inspecting *counter* without joining the threads first is not a
good idea.
PPS: Hm, it's 03:45 in the morning here.
Lars Rune N�stdal schrieb:
> PPS: Hm, it's 03:45 in the morning here.
Yes, here too. We crazy guys should go to bed *lol*
That's exactly where I'm heading now, n8 n8 Lars.
Lars Rune N�stdal schrieb:
> On May 3, 1:46 am, Andr� Thieme <address.good.until.
> ···········@justmail.de> wrote:
>> A little analysis could be interesting. We look at simple problems and
>> see if there is a trend. To some extent we can slowly make the examples
>> more complex.
>> Maybe a counter in a concurrent environment?
>> Example code:
>>
>> (defn make-counter [n] (atom n))
>>
>> (defn inc-counter [counter n]
>> (dotimes [i n]
>> (swap! counter inc)))
>>
>> (def *counter* (make-counter 0))
>>
>> (dotimes [i 10] (future (inc-counter *counter* 100000)))
>>
>> *counter* ==> 1000000
>>
>
> Using CAS with some utility functions/macros in SBCL:
>
>
> (defun mk-counter (n)
> (mk-atom n))
>
>
> (defun incf-counter (counter n)
> (dotimes (i n)
> (swap-atom-fn counter
> #'1+)))
>
>
> (defparameter *counter* (mk-counter 0))
>
>
> (defun test ()
> (dotimes (i 10)
> (with-thread (nil)
> (incf-counter *counter* 100000))))
>
Thanks for the code.
I must admit that I am not sure what CAS is.
Could you please also post the code that I can paste into sbcl
to run it?
We can try next to increase the complexity a little bit, with another
example (all this taking place in the repl):
(def *nums* (atom []))
(defn add-num [n]
(dotimes [i n]
(swap! *nums* conj i)
(Thread/sleep 1)))
The sleep of one msec will give us some time to type something in the
repl while that function is running.
Now a print function:
(defn print-count [coll]
(println (count coll))
(Thread/sleep 500)
(println (count coll))
(Thread/sleep 500)
(println (count coll)))
The idea of this is that we have code that accesses our collection
several times, but needs to be aware of the state it had at the
moment we looked at it.
So now (still in the repl):
(dotimes [i 10] (future (add-num 10000)))
This calls add-num ten times in parallel.
Directly after fireing this off I type:
user> (print-count @*nums*)
68792
68792
68792
Now waiting a few seconds and then:
user> (println (count @*nums*))
100000
This example demonstrates how we work with a snapshot of our collection
while ten threads in parallel keep modifying it. A different thread that
would call print-count would get its own print out of the three counts,
but most likely with a different number.
Good night and thanks.
On May 3, 3:38 am, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Lars Rune Nøstdal schrieb:
>
>
>
> > On May 3, 1:46 am, André Thieme <address.good.until.
> > ···········@justmail.de> wrote:
> >> A little analysis could be interesting. We look at simple problems and
> >> see if there is a trend. To some extent we can slowly make the examples
> >> more complex.
> >> Maybe a counter in a concurrent environment?
> >> Example code:
>
> >> (defn make-counter [n] (atom n))
>
> >> (defn inc-counter [counter n]
> >> (dotimes [i n]
> >> (swap! counter inc)))
>
> >> (def *counter* (make-counter 0))
>
> >> (dotimes [i 10] (future (inc-counter *counter* 100000)))
>
> >> *counter* ==> 1000000
>
> > Using CAS with some utility functions/macros in SBCL:
>
> > (defun mk-counter (n)
> > (mk-atom n))
>
> > (defun incf-counter (counter n)
> > (dotimes (i n)
> > (swap-atom-fn counter
> > #'1+)))
>
> > (defparameter *counter* (mk-counter 0))
>
> > (defun test ()
> > (dotimes (i 10)
> > (with-thread (nil)
> > (incf-counter *counter* 100000))))
>
> Thanks for the code.
> I must admit that I am not sure what CAS is.
> Could you please also post the code that I can paste into sbcl
> to run it?
>
> We can try next to increase the complexity a little bit, with another
> example (all this taking place in the repl):
> (def *nums* (atom []))
>
> (defn add-num [n]
> (dotimes [i n]
> (swap! *nums* conj i)
> (Thread/sleep 1)))
>
> The sleep of one msec will give us some time to type something in the
> repl while that function is running.
>
> Now a print function:
> (defn print-count [coll]
> (println (count coll))
> (Thread/sleep 500)
> (println (count coll))
> (Thread/sleep 500)
> (println (count coll)))
>
> The idea of this is that we have code that accesses our collection
> several times, but needs to be aware of the state it had at the
> moment we looked at it.
> So now (still in the repl):
> (dotimes [i 10] (future (add-num 10000)))
>
> This calls add-num ten times in parallel.
> Directly after fireing this off I type:
> user> (print-count @*nums*)
> 68792
> 68792
> 68792
>
> Now waiting a few seconds and then:
> user> (println (count @*nums*))
> 100000
>
> This example demonstrates how we work with a snapshot of our collection
> while ten threads in parallel keep modifying it. A different thread that
> would call print-count would get its own print out of the three counts,
> but most likely with a different number.
>
> Good night and thanks.
Hum, I don't see how or where Clojure determines what is or should
"be" a transaction or not (and "when"), but anyway ..
.. one more before I sleep .. heh:
(defparameter *nums*
(mk-ref (list)))
(defun add-num (n)
(dotimes (i n)
(with-sync ()
(push i (ref-value *nums*)))
(sleep 0.001)))
(defun print-count (nums)
(with-sync ((nums))
(when-commit () (format t "~A~%" (length nums)))
(sleep 0.5)
(when-commit () (format t "~A~%" (length nums)))
(sleep 0.5)
(when-commit () (format t "~A~%" (length nums))))
nil)
SW-MVC> (dotimes (i 10) (with-thread (nil) (add-num 10000)))
NIL
SW-MVC> (print-count *nums*)
22960
22960
22960
NIL
SW-MVC> (print-count *nums*)
47243
47243
47243
NIL
SW-MVC> (print-count *nums*)
85133
85133
85133
NIL
SW-MVC> (print-count *nums*)
100000
100000
100000
NIL
WITH-SYNC accepts symbols which means one do not have to access
variables via REF-VALUE. I'm still working on this stuff so a lot of
details and things may change.
On May 3, 4:22 am, Lars Rune Nøstdal <···········@gmail.com> wrote:
> On May 3, 3:38 am, André Thieme <address.good.until.
>
>
>
> ···········@justmail.de> wrote:
> > Lars Rune Nøstdal schrieb:
>
> > > On May 3, 1:46 am, André Thieme <address.good.until.
> > > ···········@justmail.de> wrote:
> > >> A little analysis could be interesting. We look at simple problems and
> > >> see if there is a trend. To some extent we can slowly make the examples
> > >> more complex.
> > >> Maybe a counter in a concurrent environment?
> > >> Example code:
>
> > >> (defn make-counter [n] (atom n))
>
> > >> (defn inc-counter [counter n]
> > >> (dotimes [i n]
> > >> (swap! counter inc)))
>
> > >> (def *counter* (make-counter 0))
>
> > >> (dotimes [i 10] (future (inc-counter *counter* 100000)))
>
> > >> *counter* ==> 1000000
>
> > > Using CAS with some utility functions/macros in SBCL:
>
> > > (defun mk-counter (n)
> > > (mk-atom n))
>
> > > (defun incf-counter (counter n)
> > > (dotimes (i n)
> > > (swap-atom-fn counter
> > > #'1+)))
>
> > > (defparameter *counter* (mk-counter 0))
>
> > > (defun test ()
> > > (dotimes (i 10)
> > > (with-thread (nil)
> > > (incf-counter *counter* 100000))))
>
> > Thanks for the code.
> > I must admit that I am not sure what CAS is.
> > Could you please also post the code that I can paste into sbcl
> > to run it?
>
> > We can try next to increase the complexity a little bit, with another
> > example (all this taking place in the repl):
> > (def *nums* (atom []))
>
> > (defn add-num [n]
> > (dotimes [i n]
> > (swap! *nums* conj i)
> > (Thread/sleep 1)))
>
> > The sleep of one msec will give us some time to type something in the
> > repl while that function is running.
>
> > Now a print function:
> > (defn print-count [coll]
> > (println (count coll))
> > (Thread/sleep 500)
> > (println (count coll))
> > (Thread/sleep 500)
> > (println (count coll)))
>
> > The idea of this is that we have code that accesses our collection
> > several times, but needs to be aware of the state it had at the
> > moment we looked at it.
> > So now (still in the repl):
> > (dotimes [i 10] (future (add-num 10000)))
>
> > This calls add-num ten times in parallel.
> > Directly after fireing this off I type:
> > user> (print-count @*nums*)
> > 68792
> > 68792
> > 68792
>
> > Now waiting a few seconds and then:
> > user> (println (count @*nums*))
> > 100000
>
> > This example demonstrates how we work with a snapshot of our collection
> > while ten threads in parallel keep modifying it. A different thread that
> > would call print-count would get its own print out of the three counts,
> > but most likely with a different number.
>
> > Good night and thanks.
>
> Hum, I don't see how or where Clojure determines what is or should
> "be" a transaction or not (and "when"), but anyway ..
Is perhaps every function body an implicit transaction?
Lars Rune N�stdal schrieb:
> Is perhaps every function body an implicit transaction?
Nope, and I didn't explain it yesterday, which was not good of me.
It is because I forwarded a snapshot to print-count.
Oh, and the reason I do the WHEN-COMMIT thing is mentioned in point #7
here: http://clojure.org/refs
..so I used STM, ref and with-sync, which is similar to dosync, I
think, here but I see now that you used atomic stuff instead(?) - so
maybe I misunderstood something.
Lars Rune N�stdal schrieb:
> On May 3, 3:38 am, Andr� Thieme <address.good.until.
> ···········@justmail.de> wrote:
>> Lars Rune N�stdal schrieb:
>>
>>
>>
>>> On May 3, 1:46 am, Andr� Thieme <address.good.until.
>>> ···········@justmail.de> wrote:
>>>> A little analysis could be interesting. We look at simple problems and
>>>> see if there is a trend. To some extent we can slowly make the examples
>>>> more complex.
>>>> Maybe a counter in a concurrent environment?
>>>> Example code:
>>>> (defn make-counter [n] (atom n))
>>>> (defn inc-counter [counter n]
>>>> (dotimes [i n]
>>>> (swap! counter inc)))
>>>> (def *counter* (make-counter 0))
>>>> (dotimes [i 10] (future (inc-counter *counter* 100000)))
>>>> *counter* ==> 1000000
>>> Using CAS with some utility functions/macros in SBCL:
>>> (defun mk-counter (n)
>>> (mk-atom n))
>>> (defun incf-counter (counter n)
>>> (dotimes (i n)
>>> (swap-atom-fn counter
>>> #'1+)))
>>> (defparameter *counter* (mk-counter 0))
>>> (defun test ()
>>> (dotimes (i 10)
>>> (with-thread (nil)
>>> (incf-counter *counter* 100000))))
>> Thanks for the code.
>> I must admit that I am not sure what CAS is.
>> Could you please also post the code that I can paste into sbcl
>> to run it?
>>
>> We can try next to increase the complexity a little bit, with another
>> example (all this taking place in the repl):
>> (def *nums* (atom []))
>>
>> (defn add-num [n]
>> (dotimes [i n]
>> (swap! *nums* conj i)
>> (Thread/sleep 1)))
>>
>> The sleep of one msec will give us some time to type something in the
>> repl while that function is running.
>>
>> Now a print function:
>> (defn print-count [coll]
>> (println (count coll))
>> (Thread/sleep 500)
>> (println (count coll))
>> (Thread/sleep 500)
>> (println (count coll)))
>>
>> The idea of this is that we have code that accesses our collection
>> several times, but needs to be aware of the state it had at the
>> moment we looked at it.
>> So now (still in the repl):
>> (dotimes [i 10] (future (add-num 10000)))
>>
>> This calls add-num ten times in parallel.
>> Directly after fireing this off I type:
>> user> (print-count @*nums*)
>> 68792
>> 68792
>> 68792
>>
>> Now waiting a few seconds and then:
>> user> (println (count @*nums*))
>> 100000
>>
>> This example demonstrates how we work with a snapshot of our collection
>> while ten threads in parallel keep modifying it. A different thread that
>> would call print-count would get its own print out of the three counts,
>> but most likely with a different number.
>>
>> Good night and thanks.
>
> Hum, I don't see how or where Clojure determines what is or should
> "be" a transaction or not (and "when"), but anyway ..
I should have written some more words, I just was tired and forgot
about that.
> .. one more before I sleep .. heh:
>
>
>
> (defparameter *nums*
> (mk-ref (list)))
>
>
> (defun add-num (n)
> (dotimes (i n)
> (with-sync ()
> (push i (ref-value *nums*)))
> (sleep 0.001)))
I suppose the with-sync is similar to Clojures dosync.
> (defun print-count (nums)
> (with-sync ((nums))
> (when-commit () (format t "~A~%" (length nums)))
> (sleep 0.5)
> (when-commit () (format t "~A~%" (length nums)))
> (sleep 0.5)
> (when-commit () (format t "~A~%" (length nums))))
> nil)
Ah, I see. when-commit is probably Clojures io! equivalent,
and you print inside a transaction. I have not looked at it
in detail, but maybe this puts a lock around its body?
I think in Clojure it throws an exception.
Btw, I did not explain my print-count.
I did not use a ref but an atom instead. An atom supports:
1) changing its current value dependence of that
Examples:
(def my-atom (atom -20))
(def my-atom2 (atom []))
(swap! my-atom inc) ; increases the counter
(swap! my-atom2 conj 5) ; conjes the 5 to the collection
2) setting (hard) a new value
(reset! my-atom "Hallo Lars")
And those operations are atomic. Under the hood the current value
of the atom is read, the change is made on a temp var, then inside
a transaction it is checked if the value is still the same and with
a lock the new value is set to temp.
Now to the @ that I used:
user> (def x (ref 0))
#'user/x
user> x
#<···@4b35ef: 0>
user> @x
0
user> (deref x)
0
x is a ref. I could have said (atom 0) or (agent 0) as well and the
snippet from the repl would stay the same.
To read the actual object to which x refers I need to dereference x.
This is done via deref or with the reader macro @ which expands to
(deref x).
@x does not only give me the current value of what x references, but it
also uses MVCC to give me a snapshot of it. In my call I did that:
(print-count @*nums*)
That forwarded a snapshot of the collection that *nums* references to
print-count. Instead of counting the number of its elements I could as
well have used it in some function chains, which "add" / "modify"
elements of it. Those would not have been real modifications, such as
(+ 5 6) does not change the value of 5, or such that
(cons 0 '(1 2)) does not modify (1 2), but instead return a new object
which shares structure with the one before.
All those operations can take place outside of transactions, as the
dereferenced value was an immutable one again.
> SW-MVC> (dotimes (i 10) (with-thread (nil) (add-num 10000)))
> NIL
> SW-MVC> (print-count *nums*)
> 22960
> 22960
> 22960
> NIL
> SW-MVC> (print-count *nums*)
> 47243
> 47243
> 47243
> NIL
> SW-MVC> (print-count *nums*)
> 85133
> 85133
> 85133
> NIL
> SW-MVC> (print-count *nums*)
> 100000
> 100000
> 100000
> NIL
>
>
>
> WITH-SYNC accepts symbols which means one do not have to access
> variables via REF-VALUE. I'm still working on this stuff so a lot of
> details and things may change.
Ah okay, that's the reason why you can't paste the code.
But I believe you if you say that those pastings really come from your
repl and are not just made up for this newsgroup.
So, it seems you are implementing your own STM, which I find to be
very positive news. I wish you much success. Don't let some people from
this newsgroup stop you. Some don't believe in the usefullness of a STM
and even believe it is better to go without one.
I personally believe that it is great support for programmers who want
to write concurrent code. It may not be always the best solution, and a
STM has its unique set of problems (live locks can be one). But compared
to the traditional toolset of mutexes and locks I see it as an improvement.
Plus: when you implemented the STM those older mechanisms won't go away.
Programmers could still use them.
Would be great to see a STM becoming available for SBCL and the commercial
Lisps in 2009 or 2010. I can imagine that in the not too far future Ruby
and Python, F# and maybe also D could get one. Perhaps.
What I find especially interesting is that you came up with a solution
that allows you to use CLs mutable data structures, such as lists.
Right now I need to think more about it, and if one could cheat the
mechanism, by using setf outside of a transaction.
Anyway, it is good work. And we won't need to continue with comparisons.
When you use a STM, then obviously our code would look very similar, and
we could still not learn why we both are so wrong with our attempt of
using the STM.
Thank you Lars *thumbs up*
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On May 3, 1:58 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Lars Rune Nøstdal schrieb:
> >
> > (defparameter *nums*
> > (mk-ref (list)))
> >
> > (defun add-num (n)
> > (dotimes (i n)
> > (with-sync ()
> > (push i (ref-value *nums*)))
> > (sleep 0.001)))
>
> I suppose the with-sync is similar to Clojures dosync.
Hi,
Yes. No locking. Safe nesting (no deadlocks etc.), and "snapshot view"
of stuff.
> > (defun print-count (nums)
> > (with-sync ((nums))
> > (when-commit () (format t "~A~%" (length nums)))
> > (sleep 0.5)
> > (when-commit () (format t "~A~%" (length nums)))
> > (sleep 0.5)
> > (when-commit () (format t "~A~%" (length nums))))
> > nil)
>
> Ah, I see. when-commit is probably Clojures io! equivalent,
Yes.
> and you print inside a transaction. I have not looked at it
> in detail, but maybe this puts a lock around its body?
I don't know how Clojure does it, but I defer the execution of the
WHEN-COMMIT bodies until "commit time".
> I think in Clojure it throws an exception.
> Btw, I did not explain my print-count.
> I did not use a ref but an atom instead.
Yeah, I eventually realized that. :P
> An atom supports:
> 1) changing its current value dependence of that
> Examples:
> (def my-atom (atom -20))
> (def my-atom2 (atom []))
> (swap! my-atom inc) ; increases the counter
> (swap! my-atom2 conj 5) ; conjes the 5 to the collection
> 2) setting (hard) a new value
> (reset! my-atom "Hallo Lars")
>
> And those operations are atomic. Under the hood the current value
> of the atom is read, the change is made on a temp var, then inside
> a transaction it is checked if the value is still the same and with
> a lock the new value is set to temp.
Hum, I don't think these things actually use any locking at all(?);
guessing by their names I think they use CAS also:
http://en.wikipedia.org/wiki/Compare-and-swap
In SBCL, this construct is available via sb-ext:compare-and-swap, and
one can build a lot of cool stuff (lock free data structures etc.)
using it.
> Now to the @ that I used:
> user> (def x (ref 0))
> #'user/x
> user> x
> #<···@4b35ef: 0>
> user> @x
> 0
> user> (deref x)
> 0
>
> x is a ref. I could have said (atom 0) or (agent 0) as well and the
> snippet from the repl would stay the same.
> To read the actual object to which x refers I need to dereference x.
> This is done via deref or with the reader macro @ which expands to
> (deref x).
Ah, ok. This had me confused. I don't have a reader macro for that;
just a longish name for now.
> @x does not only give me the current value of what x references, but it
> also uses MVCC to give me a snapshot of it. In my call I did that:
> (print-count @*nums*)
> That forwarded a snapshot of the collection that *nums* references to
> print-count. Instead of counting the number of its elements I could as
> well have used it in some function chains, which "add" / "modify"
> elements of it. Those would not have been real modifications, such as
> (+ 5 6) does not change the value of 5, or such that
> (cons 0 '(1 2)) does not modify (1 2), but instead return a new object
> which shares structure with the one before.
> All those operations can take place outside of transactions, as the
> dereferenced value was an immutable one again.
Ok, so this isn't STM but atomic operations + functional programming
as I kinda realized after posting yesterday then. I see. :) CL already
have some functional data structures and/or operations, so I can do
this, then:
(defparameter *nums*
(mk-atom (list)))
(defun add-num (n)
(dotimes (i n)
(swap-atom-fn *nums* (lambda (old) (cons n old)))
(sleep 0.001)))
(defun print-count (nums)
(format t "~A~%" (length nums))
(sleep 0.5)
(format t "~A~%" (length nums))
(sleep 0.5)
(format t "~A~%" (length nums)))
..instead of using STM too. It results in the same:
SW-MVC> (print-count (atomt-value *nums*))
26170
26170
26170
NIL
SW-MVC> (print-count (atomt-value *nums*))
40705
40705
40705
NIL
SW-MVC> (print-count (atomt-value *nums*))
100000
100000
100000
SW-MVC>
..ATOMT-VALUE is guts hanging out; I'd like to have a nicer shorter
name for that, I think, ref. your talk about reader macro above.
There is also http://common-lisp.net/project/fset/ and I'm working on
some structures also.
> So, it seems you are implementing your own STM, which I find to be
> very positive news. I wish you much success. Don't let some people from
> this newsgroup stop you. Some don't believe in the usefullness of a STM
> and even believe it is better to go without one.
Yeah, while the Clojure and CL examples above are done just fine
without STM (if I haven't misunderstood something!), and instead just
use atomic primitives and functional data structures, there are other
examples where it is very cumbersome not to use STM. I'm collecting
some pastes, tests and examples here: http://common-lisp.net/~lnostdal/
which trigger deadlocks and other nasty problems. About CLOS; I've
also implemented a metaclass that makes it possible to access and
manipulate CLOS slots in a transactional fashion and one of the paste
has an example of this.
> I personally believe that it is great support for programmers who want
> to write concurrent code. It may not be always the best solution, and a
> STM has its unique set of problems (live locks can be one). But compared
> to the traditional toolset of mutexes and locks I see it as an improvement.
> Plus: when you implemented the STM those older mechanisms won't go away.
> Programmers could still use them.
Yes, this is what I meant with "why be glad there is no CLOS?" by the
way. I mean; one can just chose not to use the already included
components and build one's own stuff from the bottom up using low-
level or core constructs.
> Would be great to see a STM becoming available for SBCL and the commercial
> Lisps in 2009 or 2010. I can imagine that in the not too far future Ruby
> and Python, F# and maybe also D could get one. Perhaps.
> What I find especially interesting is that you came up with a solution
> that allows you to use CLs mutable data structures, such as lists.
> Right now I need to think more about it, and if one could cheat the
> mechanism, by using setf outside of a transaction.
Yes, in this example we do not mutate the list content anyway; we are
just atomically setting a new reference at the top level; the tail is
never touched or mutated.
However, I have support for STM at the "cons level" which means I can
really do mutation on conses, directly, also in a transactional
fashion;
(defun test-stm-on-cons ()
(let ((cons (cons nil nil)))
(with-thread (:thread-a)
(with-sync ()
(sleep 0.25)
(setf (tcar cons) :thread-a-was-here)
(sleep 1)
(format t "thread-a: ~A~%" (tcar cons))))
(with-thread (:thread-b)
(with-sync ()
(sleep 0.5)
(setf (tcar cons) :thread-b-was-here)
(sleep 1)
(format t "thread-b: ~A~%" (tcar cons)))))
nil)
> (test-stm-on-cons)
thread-a: THREAD-A-WAS-HERE
thread-b: THREAD-B-WAS-HERE
>
..TCAR and (SETF TCAR) are defined like this btw:
(defun (setf tcar) (new-value cons)
(set-memory cons new-value
(lambda () (setf (car cons) new-value))
:eq))
(defun tcar (cons)
(get-memory cons
(lambda () (car cons))
:eq))
..closures are nice. :) The metaclass is implemented in an equally
simple fashion.
..but I do not think it is a good idea to _build_ on something like
that (wrt. conses as direct data type). It's probably a better idea to
build custom data structures that guarantee STM support from the
bottom up on a "type basis" instead. Something like (written in a
hurry just now .. :P):
(defstruct (pair (:constructor %mk-pair (left right)))
(left)
(right))
(defun mk-pair (left right)
(%mk-pair (mk-ref left)
(mk-ref right)))
..and we have our own type safe cons. Next up is list, tree, etc. and
this is just built on this low-level construct.
> Anyway, it is good work. And we won't need to continue with comparisons.
> When you use a STM, then obviously our code would look very similar, and
> we could still not learn why we both are so wrong with our attempt of
> using the STM.
> Thank you Lars *thumbs up*
:)
> André
> --
> Lisp is not dead. It’s just the URL that has changed:http://clojure.org/
On May 3, 4:38 am, André Thieme <address.good.until.
···········@justmail.de> wrote:
Hi André!
> We can try next to increase the complexity a little bit, with another
> example (all this taking place in the repl):
In this "contest" do you want others to create the code, semantically
matching your Clojure variants? Or solving the same problems?
If the latter, I think, it would be better to first specify the
problem. This especially applies to the following snippet:
> (defn print-count [coll]
> (println (count coll))
> (Thread/sleep 500)
> (println (count coll))
> (Thread/sleep 500)
> (println (count coll)))
At a first glance I thought, that you wanted to get the state of the
collection at the times of calling (println (count coll)), while it
turned out, that you expected it at the time of call of print-count.
Why then don't just make it more explicit, like this:
(defun print-count (coll)
(let ((tmp (bt:with-lock-held (*lock*)
(copy-seq coll))))
(print (length tmp))
(sleep 0.5)
(print (length tmp))
(sleep 0.5)
(print (length tmp))))
or rather:
(defun print-count (coll)
(let ((size (bt:with-lock-held (*lock*)
(length coll))))
(print size)
(sleep 0.5)
(print size)
(sleep 0.5)
(print size)))
:)
Concerning the other parts:
> (def *nums* (atom []))
(defvar *nums* (make-array 0 :adjustable t :fill-pointer t))
> (defn add-num [n]
> (dotimes [i n]
> (swap! *nums* conj i)
> (Thread/sleep 1)))
(defun add-num (n)
(dotimes (i n)
(bt:with-lock-held (*lock*)
(vector-push-extend 1 *nums*))
(sleep 0.001)))
> So now (still in the repl):
> (dotimes [i 10] (future (add-num 10000))) ; correction: should be 100, not 10 thousands
> This calls add-num ten times in parallel.
Here it would also be better to specify the desired semantics not in
Clojure, but in natural language. I understand, that you just want to
asynchronously add 100000 elements to collection? And how do you know,
that 10 parallel threads will operate?
Overall, I think, this example doesn't show any benefits of using
Clojure model, as the analogous lock-based code is quite simple and
clean. But it is nonetheless interesting in that it shows, how a lot
of synchronization semantics in Clojure becomes implicit. IMO, it is
neither good, nor bad as is (although, Pythonistas will say it's bad
-- see PEP 20: "Explicit is better than implicit"). But it definitely
should be something, that *all* users understand thoroughly.
Best regards,
Vsevolod
On May 3, 10:50 am, Vsevolod <········@gmail.com> wrote:
> > So now (still in the repl):
> > (dotimes [i 10] (future (add-num 10000))) ; correction: should be 100, not 10 thousands
> > This calls add-num ten times in parallel.
>
> Here it would also be better to specify the desired semantics not in
> Clojure, but in natural language. I understand, that you just want to
> asynchronously add 100000 elements to collection? And how do you know,
> that 10 parallel threads will operate?
Sorry, I misunderstood the example. Now I see, that 10 * 10000 =
100000 :)
The CL equiv can be:
(dotimes (i 1)
(pcall:pexec (add-num 10000))
Vsevolod
Vsevolod schrieb:
> On May 3, 10:50 am, Vsevolod <········@gmail.com> wrote:
>>> So now (still in the repl):
>>> (dotimes [i 10] (future (add-num 10000))) ; correction: should be 100, not 10 thousands
>>> This calls add-num ten times in parallel.
>> Here it would also be better to specify the desired semantics not in
>> Clojure, but in natural language. I understand, that you just want to
>> asynchronously add 100000 elements to collection? And how do you know,
>> that 10 parallel threads will operate?
>
> Sorry, I misunderstood the example. Now I see, that 10 * 10000 =
> 100000 :)
> The CL equiv can be:
> (dotimes (i 1)
> (pcall:pexec (add-num 10000))
Yes, in this example this is perfectly fine. I "misused" futures here in
that example. Typically futures are used to calculate constants. And
they can automatically block on read access.
I am currently not aware if and which CL implementation ships with
direct support for futures.
The pcall:pexec is closer being an equivalent to Clojures send-off.
For our example here pexec is exactly the right function.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
Vsevolod schrieb:
> On May 3, 4:38 am, Andr� Thieme <address.good.until.
> ···········@justmail.de> wrote:
>
> Hi Andr�!
>
>> We can try next to increase the complexity a little bit, with another
>> example (all this taking place in the repl):
>
> In this "contest" do you want others to create the code, semantically
> matching your Clojure variants? Or solving the same problems?
> If the latter, I think, it would be better to first specify the
> problem.
Hello Vsevolod, you are right. I admit that I did not wrote enough
explanations yesterday. Please excuse this, I felt too tired and did
not think too much about it.
> This especially applies to the following snippet:
>> (defn print-count [coll]
>> (println (count coll))
>> (Thread/sleep 500)
>> (println (count coll))
>> (Thread/sleep 500)
>> (println (count coll)))
> At a first glance I thought, that you wanted to get the state of the
> collection at the times of calling (println (count coll)),
This is exactly what happens. You understood it correctly.
Instead of count I could have used conj to add an element to coll.
I could have read elements out of the middle of it and such.
> while it turned out, that you expected it at the time of call of print-count.
> Why then don't just make it more explicit, like this:
> (defun print-count (coll)
> (let ((tmp (bt:with-lock-held (*lock*)
> (copy-seq coll))))
> (print (length tmp))
> (sleep 0.5)
> (print (length tmp))
> (sleep 0.5)
> (print (length tmp))))
I made it explicit... for the Clojure compiler :-)
But I should have mentioned it for human readers as well.
See also my other posting, made a bit earlier than this one,
also in this thread.
When I said (print-count @*nums*) then my argument to
print-count was a snapshot of an immutable vector, which *nums*
references.
It would be better IMO to put no locks and copying into
print-count itself. In this toy example it does not matter of course.
But this print-count is just a place holder for some function that is
doing real work.
In principle each call to print-count should be wrapped into the let
that you gave above.
(let ((temp (bt:with-lock-held (*lock*)
(copy-seq *nums*))))
(print-count temp))
But here I think we already have a potential problem. More about it
later.
> or rather:
> (defun print-count (coll)
> (let ((size (bt:with-lock-held (*lock*)
> (length coll))))
> (print size)
> (sleep 0.5)
> (print size)
> (sleep 0.5)
> (print size)))
> :)
Hehe yes, for this example this would be a great solution. Why should
we measure the length of coll each time when we know it can't change
anyway.
(btw, in Clojure (count coll) returns in constant time)
But in general we should make a full copy, on which we could operate
with append, reverse and the other list/sequence functions.
I just wanted to demonstrate that I was operating on a snapshot and
that its number of elements does not change.
> Concerning the other parts:
>
>> (def *nums* (atom []))
> (defvar *nums* (make-array 0 :adjustable t :fill-pointer t))
A list would also have been okay.
An adjustable array is okay for this example, but in general if we
would care about performance it could be a bottleneck to copy the
full contents of that array several times.
>> (defn add-num [n]
>> (dotimes [i n]
>> (swap! *nums* conj i)
>> (Thread/sleep 1)))
> (defun add-num (n)
> (dotimes (i n)
> (bt:with-lock-held (*lock*)
> (vector-push-extend 1 *nums*))
> (sleep 0.001)))
>
>> So now (still in the repl):
>> (dotimes [i 10] (future (add-num 10000))) ; correction: should be 100, not 10 thousands
>> This calls add-num ten times in parallel.
> Here it would also be better to specify the desired semantics not in
> Clojure, but in natural language.
Yes Vsevolod, I agree I should have done this. Sorry about that.
> I understand, that you just want to
> asynchronously add 100000 elements to collection? And how do you know,
> that 10 parallel threads will operate?
The function future returns a future object. The function returns
immediately. It represents the result of an operation that will
finish in the future (I mean the time now, not the object), and it
would block on dereferenciation. This operation takes place in a
new thread. So when I say
(future
(x (y (z 100))))
then this runs in its own thread. If enough cores are available it is
likely that this would run on its own core.
So, the dotimes returns immediately, and I have control in the repl
again. But at the same time in the background ten threads/cores are
busy running add-num.
> Overall, I think, this example doesn't show any benefits of using
> Clojure model, as the analogous lock-based code is quite simple and
> clean.
I don't agree with that, and here is why:
When you use locks, then exactly one thread is operating on the object
at the same time. Intels upcoming server CPU (in 1-2 years) with 80
cores would use 1/80th of its capacity, that is 1,25%. Your approach
is back in single-core land. Plus: when you want to make a snapshot you
have to copy the whole collection. That is the problem, I was referring
to (above). The STM mechanism does not need to make copies.
When I say @*nums* then no lock is required, this is an atomic operation.
Now 19 other cores can continue to happily write to that collection
while I work with the snapshot of that moment.
I only used atoms so far for these little examples. In a meaningful
program more work would be done with refs, which can operate in sync
in a transaction.
The idea is that we need to put more concentration on letting things
really happen concurrently. AMD and Intel can't increase the speed of
their processors anymore as they did in the past 40 years or so (I think
they are both 40 now?). They just give us more cores.
And customers will more and more ask us to speed up the applications
for their business needs (or scientific needs).
Also another disadvantage: you must not forget to put the locks around
your object. When I use atoms in Clojure it is impossible to forget that.
When I use refs and try to modify them outside of a dosync block I will
get an error message. I can't forget that.
Each time you make a read access to a collection that is modified in
multiple threads you need to lock each of those. Reading needs locks.
In the first example with the counter it is okay, as you read a number,
which is atomic. But in a more complex program than "Hello World" we
have collections everywhere, or in the case of CL also class instances.
All 724 reads of collections in a "real world program" would require
locks, shutting down all concurrent operation.
We could also mention the danger of dead locks or just locks that one
programmer in the team forgot to set. The code will happily pass the
unit tests and run without problems, for days. But then it explodes.
Btw, if you want, there is a nice video here:
http://rubyconf2008.confreaks.com/what-all-rubyist-should-know-about-threads.html
Yeah, it is from a ruby conference, but what Jim explains in there is in
principle true for most programming languages, including CL.
> But it is nonetheless interesting in that it shows, how a lot
> of synchronization semantics in Clojure becomes implicit. IMO, it is
> neither good, nor bad as is (although, Pythonistas will say it's bad
> -- see PEP 20: "Explicit is better than implicit"). But it definitely
> should be something, that *all* users understand thoroughly.
Well, the synchronization was explicit, I just did not explain it, and
if you have not studied Clojure before you could of course not know
that. In the code we had (atom ..) and @*nums* and (swap! ...).
Thank you for providing the code Vsevolod!
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
On May 3, 3:43 pm, André Thieme <address.good.until.
···········@justmail.de> wrote:
> This is exactly what happens. You understood it correctly.
> Instead of count I could have used conj to add an element to coll.
> I could have read elements out of the middle of it and such.
Yes, I understand that, but using conj will not change the var,
because you pass it by value, so it's not very relevant: all the
interesting things will be done before calling this function in any
implementation.
> When I said (print-count @*nums*) then my argument to
> print-count was a snapshot of an immutable vector, which *nums*
> references.
[...]
> It would be better IMO to put no locks and copying into
> print-count itself. In this toy example it does not matter of course.
> But this print-count is just a place holder for some function that is
> doing real work.
> In principle each call to print-count should be wrapped into the let
> that you gave above.
> (let ((temp (bt:with-lock-held (*lock*)
> (copy-seq *nums*))))
> (print-count temp))
I agree. This would, basically, yield the same semantics as yours.
It's clear, that the operation is atomic. But, AFAIK, there are two
variants how this atomicity could be implemented on the low level:
either with locks or copy-on-write. Using explicit locks was the most
simple and straightforward solution. But you could as well have
implemented any other thing (like copy-on-write). If you look at
Clojure java sources, you'll see, that dereferencing is also
implemented using locks.
> But in general we should make a full copy, on which we could operate
> with append, reverse and the other list/sequence functions.
Depending on the data-structures you use. For FSet I belive it won't
be needed.
> > Overall, I think, this example doesn't show any benefits of using
> > Clojure model, as the analogous lock-based code is quite simple and
> > clean.
>
> I don't agree with that, and here is why:
> When you use locks, then exactly one thread is operating on the object
> at the same time.
But when you deref an agent in Clojure, locks are also used (under the
hood).
> Plus: when you want to make a snapshot you have to copy the whole collection.
Yes, sometimes right data structures are important. But that's
orthogonal to STM: Clojure also needs to make a copy for the snapshot.
Maybe, not a full copy. But once again: that is implicit. Does any
user of the language know the complexity characteristics of Clojure's
copying for it's data structures? In the previous discussion there was
a mention, that Clojure's vectors (implemented as tries) have some
uncommon characteristics. I think, those issues should be addressed
more pedantically in the documentation.
> When I say @*nums* then no lock is required, this is an atomic operation.
I may be mistaken, but from a quick glance at Clojure Java code I'd
say, that locks are used in this case.
> Now 19 other cores can continue to happily write to that collection
> while I work with the snapshot of that moment.
Only after you've made a copy. (Implicitly)
> I only used atoms so far for these little examples. In a meaningful
> program more work would be done with refs, which can operate in sync
> in a transaction.
> The idea is that we need to put more concentration on letting things
> really happen concurrently.
I don't object.
> Also another disadvantage: you must not forget to put the locks around
> your object. When I use atoms in Clojure it is impossible to forget that.
> When I use refs and try to modify them outside of a dosync block I will
> get an error message. I can't forget that.
But still there are 5 or more different concurrency constructs
available in Clojure: atoms, agents, refs, vars, futures (and locks).
Anything else? Each has it's distinct semantics users should
understand very good not to mess things up and use one, where the
other would be appropriate. Basically most of them are just
programming patterns, that can be developed from a set of low-level
primitives: lock, semaphore, atomic operations (like test-set-lock,
compare-and-swap, or load-link/store-conditional). It's very good,
that Clojure has them. But still users should know, what's happening
underneath and what are the characteristics of all those operations.
> We could also mention the danger of dead locks or just locks that one
> programmer in the team forgot to set. The code will happily pass the
> unit tests and run without problems, for days. But then it explodes.
Yes, I know: there are deadlocks, livelocks, polling, starvation and
other synchronization problems... :)
> Well, the synchronization was explicit, I just did not explain it, and
> if you have not studied Clojure before you could of course not know
> that. In the code we had (atom ..) and @*nums* and (swap! ...).
I understood that. What I meant was, that inside the function print-
count the synchronization was implicit. I see know, that I
misunderstood that, because all reads of mutable variables' values in
Clojure should be made through deref, yes?
Overall, I don't object to Clojure having great features in the
concurrency area. (That doesn't mean, thought, that they can be found
right now or implemented at will in CL, perhaps, even with greater
flexibility. See Cl-STM, FSet, Pcall etc. :)
Best regards,
Vsevolod
Vsevolod schrieb:
> On May 3, 3:43 pm, Andr� Thieme <address.good.until.
> ···········@justmail.de> wrote:
>> This is exactly what happens. You understood it correctly.
>> Instead of count I could have used conj to add an element to coll.
>> I could have read elements out of the middle of it and such.
> Yes, I understand that, but using conj will not change the var,
> because you pass it by value, so it's not very relevant: all the
> interesting things will be done before calling this function in any
> implementation.
True.
I just mentioned this to make sure that we should look at the version
which copies the whole collection while it has the lock, instead of
just measuring the length.
>> When I said (print-count @*nums*) then my argument to
>> print-count was a snapshot of an immutable vector, which *nums*
>> references.
> [...]
>> It would be better IMO to put no locks and copying into
>> print-count itself. In this toy example it does not matter of course.
>> But this print-count is just a place holder for some function that is
>> doing real work.
>> In principle each call to print-count should be wrapped into the let
>> that you gave above.
>> (let ((temp (bt:with-lock-held (*lock*)
>> (copy-seq *nums*))))
>> (print-count temp))
> I agree. This would, basically, yield the same semantics as yours.
> It's clear, that the operation is atomic. But, AFAIK, there are two
> variants how this atomicity could be implemented on the low level:
> either with locks or copy-on-write. Using explicit locks was the most
> simple and straightforward solution. But you could as well have
> implemented any other thing (like copy-on-write). If you look at
> Clojure java sources, you'll see, that dereferencing is also
> implemented using locks.
Clojure uses a third method: the data structures which sit under vectors
and sets and maps. There are indeed locks in the implementation of
Clojure itself. But user code can be in almost all cases lock free.
The locks in Clojures implementation are held for making only copies of
very few data cells. Vectors, sets and maps are implemented in tries in
Clojure. Making a snapshot runs in near constant time, as nearly the
whole data object is shared.
I regard the implementation of those data structures as one of the core
jobs that Rich did, and I find that piece of work impressive. Currently
I am not aware of many other language implementations that implemented
their core data structures on top of tries, with the same performance
characteristics.
So as it currently stands, taking a snapshot in Clojure is very
efficient, while code that locks all processor cores out while it copies
a whole collection most likely isn't.
>> But in general we should make a full copy, on which we could operate
>> with append, reverse and the other list/sequence functions.
> Depending on the data-structures you use. For FSet I belive it won't
> be needed.
I don't know in detail how FSet is implemented under the hood, but it
sounds like a good candidate. Even if it is not yet fully ready, the
project already has a good code base and can maybe get tuned where
needed.
>>> Overall, I think, this example doesn't show any benefits of using
>>> Clojure model, as the analogous lock-based code is quite simple and
>>> clean.
>> I don't agree with that, and here is why:
>> When you use locks, then exactly one thread is operating on the object
>> at the same time.
> But when you deref an agent in Clojure, locks are also used (under the
> hood).
Yes true, but just for some microseconds. I just tried:
user> (def x (atom (range 5000000)))
#'user/x
user> (count @x)
5000000
user> (time (apply + (for [i (range 100)]
(do (swap! x conj i)
(count @x)))))
"Elapsed time: 3.731479 msecs"
500005050
So if we assume that adding 100 numbers costs no time, conjing 100
numbers onto the atom costs no time and really all time went into making
the snapshots, and even if we assume a runtime of 30 msecs for that in
more complex applications (we assume it to be one order of magnitude
less efficient, without any evidence), then it would still be just
300 microseconds to make a snapshot of a sequence of five million objects.
When I try for example in SBCL 1.0.18
(defparameter x (loop for i from 1 to 20 collect i))
And then
* (time (length x))
Evaluation took:
0.014 seconds of real time
0.020001 seconds of total run time (0.020001 user, 0.000000 system)
117.65% CPU
34,258,263 processor cycles
0 bytes consed
5000000
So alone measuring the length of x takes about as much time as my
100 snapshots above.
Although in practice Rich admits that it is not O(1) but instead
something like O(log32 n), for my practical matters I percieve it
as similar as constant time.
>> Plus: when you want to make a snapshot you have to copy the whole collection.
> Yes, sometimes right data structures are important. But that's
> orthogonal to STM: Clojure also needs to make a copy for the snapshot.
Rich would know this much better, but I think max 32 objects need to
be copied?!
> Maybe, not a full copy. But once again: that is implicit. Does any
> user of the language know the complexity characteristics of Clojure's
> copying for it's data structures?
I think it is about the same as in most languages:
newbies don't know it, expert programmers have a sense for it and are
aware of problems. As CL and even more so CLJ are unpopular languages
and have only a small user base, but one that tends to have more
experts, I would say that right now many Clojure users (as well as
CL users) have an idea of the complexity characteristics.
>> When I say @*nums* then no lock is required, this is an atomic operation.
> I may be mistaken, but from a quick glance at Clojure Java code I'd
> say, that locks are used in this case.
Under the hood yes, but then again that is also the place where no Lisp
exists anymore, but instead some Zeros and Ones ;-)
The idea is that Clojure abstracts a lot of that away.
In user code you will only see rarely locks.
If you happen to have some time and interest you could play with Clojure
a bit and get a feeling for that.
>> Now 19 other cores can continue to happily write to that collection
>> while I work with the snapshot of that moment.
> Only after you've made a copy. (Implicitly)
Maybe there is a little misunderstanding.
I agree that it looks as if I worked with a copy, but as you saw in my
timing above: even the newest AMD processor or whatever could not copy
the vector that fast.
That is one of the things that impresses me about Richs work on Clojure.
>> Also another disadvantage: you must not forget to put the locks around
>> your object. When I use atoms in Clojure it is impossible to forget that.
>> When I use refs and try to modify them outside of a dosync block I will
>> get an error message. I can't forget that.
> But still there are 5 or more different concurrency constructs
> available in Clojure: atoms, agents, refs, vars, futures (and locks).
> Anything else? Each has it's distinct semantics users should
> understand very good not to mess things up and use one, where the
> other would be appropriate. Basically most of them are just
> programming patterns, that can be developed from a set of low-level
> primitives: lock, semaphore, atomic operations (like test-set-lock,
> compare-and-swap, or load-link/store-conditional). It's very good,
> that Clojure has them. But still users should know, what's happening
> underneath and what are the characteristics of all those operations.
You are rigth. Concurrent programming is not easy, and Clojure also
won't write the programs for you.
It's a bit help here and there for the most common problems.
Only experience and a good amount of education will help.
>> Well, the synchronization was explicit, I just did not explain it, and
>> if you have not studied Clojure before you could of course not know
>> that. In the code we had (atom ..) and @*nums* and (swap! ...).
> I understood that. What I meant was, that inside the function print-
> count the synchronization was implicit. I see know, that I
> misunderstood that, because all reads of mutable variables' values in
> Clojure should be made through deref, yes?
In print-count there was no synchronization going on anymore.
print-count only saw an immutable object, a vector.
And yes, reads of the mutable data structures such as refs, agents and
atoms require a deref (or @).
In the repl they print also in a way that humans see what's going on:
user> (def x (agent {:a 1, :b 2}))
#'user/x
user> x
#<·····@9e0c2d: {:a 1, :b 2}>
^^^^^^^^^^^^
With deref:
user> @x
{:a 1, :b 2}
> Overall, I don't object to Clojure having great features in the
> concurrency area. (That doesn't mean, thought, that they can be found
> right now or implemented at will in CL, perhaps, even with greater
> flexibility. See Cl-STM, FSet, Pcall etc. :)
It would be fantastic news if some CLs would very soon have something
better and more flexible to offer.
I am glad when members of the Lisp family evolve.
Maybe Lars will have something up in the coming months for SBCL.
Andr�
--
Lisp is not dead. It�s just the URL that has changed:
http://clojure.org/
* André Thieme <············@news.motzarella.org> :
Wrote on Sun, 03 May 2009 01:46:07 +0200:
|> above, I offered a way of settling the isssue in a productive way,
|> and I stick with the offer.
| We should try to focus more on technical discussion, as Duane
| suggests. A little analysis could be interesting. We look at simple
| problems and see if there is a trend. To some extent we can slowly
| make the examples more complex. Maybe a counter in a concurrent
| environment? Example code:
No, I am not interested in discussing these sort of examples, and do not
consider them productive or conclusive.
You have snipped the portion that I quoted twice. Those contain the
requirements on the requirements on the project that I am willing to
undertake, which I believe would be productive.
--
Madhu
Madhu schrieb:
> * André Thieme <············@news.motzarella.org> :
> Wrote on Sun, 03 May 2009 01:46:07 +0200:
>
> |> above, I offered a way of settling the isssue in a productive way,
> |> and I stick with the offer.
>
> | We should try to focus more on technical discussion, as Duane
> | suggests. A little analysis could be interesting. We look at simple
> | problems and see if there is a trend. To some extent we can slowly
> | make the examples more complex. Maybe a counter in a concurrent
> | environment? Example code:
>
> No, I am not interested in discussing these sort of examples, and do not
> consider them productive or conclusive.
I see. I thought this could be an opportunity to become more concrete.
We could see if the use of locks and mutexes reduces the amount of bugs
in concurrent applications, or if a STM helps to increase productivity
for at least some cases, which I believe.
> You have snipped the portion that I quoted twice. Those contain the
> requirements on the requirements on the project that I am willing to
> undertake, which I believe would be productive.
It's unlikely that we can go this route. I won't go into internal
details of my work. And investors will typically see your claim with
scepticism... that although you have not learned any Clojure and don't
know any detail about the project requirements, you yet offer a
"better CL solution".
André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/
* André Thieme <············@news.motzarella.org> :
Wrote on Sun, 03 May 2009 02:08:57 +0200:
| It's unlikely that we can go this route. I won't go into internal
| details of my work. And investors will typically see your claim with
| scepticism... that although you have not learned any Clojure and don't
| know any detail about the project requirements, you yet offer a
| "better CL solution".
Or it is likely the investors do not have any requirements that fit my
specifications for a project that I see would be useful in deciding the
value of the benefits you keep repeating, and I'd like to disprove.
In any case subject to the conditions, my offer stands
--
Madhu
* Madhu <··············@moon.robolove.meer.net> :
Wrote on Sun, 03 May 2009 05:55:00 +0530:
| * André Thieme <············@news.motzarella.org> :
| Wrote on Sun, 03 May 2009 02:08:57 +0200:
|
| | It's unlikely that we can go this route. I won't go into internal
| | details of my work. And investors will typically see your claim with
| | scepticism... that although you have not learned any Clojure and don't
| | know any detail about the project requirements, you yet offer a
| | "better CL solution".
Indeed, you dont seemt to appreciate what the whole point of my
challenge is: I'm offering them a way to test your claims against my
claim that your claims do not add up.
| Or it is likely the investors do not have any requirements that fit my
| specifications for a project that I see would be useful in deciding the
| value of the benefits you keep repeating, and I'd like to disprove.
|
| In any case subject to the conditions, my offer stands
--
Madhu
Madhu schrieb:
> * Madhu <··············@moon.robolove.meer.net> :
> Wrote on Sun, 03 May 2009 05:55:00 +0530:
>
> | * André Thieme <············@news.motzarella.org> :
> | Wrote on Sun, 03 May 2009 02:08:57 +0200:
> |
> | | It's unlikely that we can go this route. I won't go into internal
> | | details of my work. And investors will typically see your claim with
> | | scepticism... that although you have not learned any Clojure and don't
> | | know any detail about the project requirements, you yet offer a
> | | "better CL solution".
>
> Indeed, you dont seemt to appreciate what the whole point of my
> challenge is: I'm offering them a way to test your claims against my
> claim that your claims do not add up.
Would be interesting to see a study of this.
To make it more realistic there should be maybe 10 programmers of
each camp. Some work alone, some in teams.
Maybe someone is interested to finance such a study.
Unfortunately it is not trivial to measure the productivity gains of
specific programming languages. When I came to Lisp some years ago I
often read that it will multiply productivity 5x to 20x. There were
claims in several flavours. Although I have never seen a proof for that,
I experienced it myself that Lisp can indeed help productivity.
While the difference between C and CL can be very big, the differences
between CL and CLJ are typically much smaller.
When looking specifically at the concurrency I fail to see how the
current strategy of locks and mutexes will make a programmer more
productive. Anyway, Clojure supports those as well. How does *not*
having a STM provide advantages?
If no scientific study will be made, then we will just have to wait
and see the results. Will some CLs eventually get a STM?
Will Clojure fail? In 1-2 years we know more. If I happen to stumble
upon some serious problems I will report back and happily admit it.
André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/
=?UTF-8?B?QW5kcsOpIFRoaWVtZQ==?=
<······························@justmail.de> wrote in
·················@news.motzarella.org:
> Would be interesting to see a study of this.
> To make it more realistic there should be maybe 10 programmers of
> each camp. Some work alone, some in teams.
How would you account for differences in programmer skill, and keep those
differences out of the results? Even for the same programmer, skill varies
at random from week to week and from hour to hour, sometimes by orders of
magnitude.
How would you account for one language being more oriented towards the kind
of problem chosen as the test? Or how would you make sure the chosen test
was equal for both languages?
eric-and-jane-smith schrieb:
> =?UTF-8?B?QW5kcsOpIFRoaWVtZQ==?=
> <······························@justmail.de> wrote in
> ·················@news.motzarella.org:
>
>> Would be interesting to see a study of this.
>> To make it more realistic there should be maybe 10 programmers of
>> each camp. Some work alone, some in teams.
>
> How would you account for differences in programmer skill, and keep those
> differences out of the results? Even for the same programmer, skill varies
> at random from week to week and from hour to hour, sometimes by orders of
> magnitude.
>
> How would you account for one language being more oriented towards the kind
> of problem chosen as the test? Or how would you make sure the chosen test
> was equal for both languages?
True. I gave the number of 10 programmers for each camp, so that Hu can
easier bring up the money for the study, or find investors for it.
More programmers for each camp, in more projects over longer times, in
different team combinations - that could help.
André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/
* André Thieme <············@news.motzarella.org> :
Wrote on Sat, 02 May 2009 13:20:14 +0200:
| ||__|| | Please don't |
| / O O\__ feed |
| / \ the troll Madhu |
I understand this has gotten too personal, which was not my ultimate
intent at the outset---I fear I made a mistake in taking a personal
stance in the beginning, though I believed it would be a fruitful
approach. The fruit or original intent was, of course, only to get you
to regulate your posts here, and consider the broader issues that your
posts involved. I'm sorry if I've caused unnecessary anger in the
process.
--
Madhu
On May 2, 3:16 am, André Thieme <address.good.until.
···········@justmail.de> wrote:
> Madhu schrieb:
>
> > * André Thieme <············@news.motzarella.org> :
> > Wrote on Fri, 01 May 2009 13:14:55 +0200:
> > |> Please stop using any and every CL thread to as an opportunity to
> > |> provoke discussion to mention and eventually market clojure.
> > |
> > | Hu, why are you so mad? I thought you wanted to prove that you are more
> > | clever than I by not answering me anymore.
> > | No wait, maybe you just need some attention?
>
> > The only attention I want to draw is the fact that when people respond
> > to in a discussion you they are responding to a marketing machine, a
> > human advertising / spam bot.
>
> Again you prove that you are a troll.
> I am still looking forward to see the first useful posting of you in
> this newsgroup. Heck, even William James began to post Lisp code.
Nope. The Ruby guy has not posted a single line of Common Lisp (or
Scheme) code. Plus, he is still delinquent about his homework.
Cheers
--
Marco
>
> > There is a differece between offering a personal judgement and making
> > dishonest claims for the purpose of marketing a product. The other
> > participants believe the discussion centers around issus, but the only
> > issue you are concerned with is getting more customers, (in the tradition
> > that java is marketed).
>
> You don't bring up something substantial. You are only talking about me
> and constantly try to carry it to a personal level. I enjoy however to
> jump in, as your postings (and my answers to them) amuse me :)
>
> > Your claims contradict the experience of several people in this
> > newsgroup.
>
> What claims are you specifically talking about?
> Who are those Clojure users, who used and use Clojure on a daily basis
> to have the experience to speak up?
> Until now I read mostly of people who never wrote one line of Clojure
> code, like you.
> I however have several years of CL background, also professionally, and
> know Clojure and made personally the experience that Clojure is nicer
> for me. I am in contact with experienced Lispers for who that is also
> true.
>
> > Why don't you back up your advertising with some concrete
> > application which demonstrates actual speedup benefits, which is not
> > dependent on the platform, you tout, and someone show you how it can be
> > better.
>
> What you ask for is not specified very well.
> Do you want me to compare a single threaded CL program on a Quad-Core
> CPU vs. a Clojure program running with multiple threads on it?
> That sounds unfair. And what would two concurrent apps (one in CL, one
> in CLJ) show?
>
> There were already some examples in the past where I showed that Clojure
> runs faster than CL when both run in a single Thread.
> There were also examples that showed that CLs ran code faster than
> Clojure.
>
> In comp.lang.functional there was a thread some weeks ago showing the
> speed gains for number crunching in a Clojure app, by making use of
> multiple threads.
>
> See, Clojures model helps you to make it (much) easier to write
> concurrent programs. So your competition should focus on that. Obviously
> a concurrent Clojure program will not necessarily run much faster than
> a concurrent Common Lisp program.
> Maybe you should begin to read some Clojure material and actually learn
> and try it yourself. When you then come back in some months as an actual
> Clojure user and tell me that you found Clojure to make it harder to
> write concurrent code (compared to CL), then I will listen to what you
> have to say.
> Feel free to begin by translating the ants simulation to CL.
> You can find it in the Clojure Google Group.
>
> André
> --
> Lisp is not dead. It’s just the URL that has changed:http://clojure.org/
Madhu schrieb:
> * André Thieme <············@news.motzarella.org> :
> Wrote on Sat, 02 May 2009 03:16:31 +0200:
>
> [more dishonest clojure marketing snipped]
I knew it. Troll!
You just wanted to jump into the discussion to spread your
nonsense.
André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/
André Thieme wrote:
> Feel free to begin by translating the ants simulation to CL.
> You can find it in the Clojure Google Group.
Do you have a more concrete link? (I can look for it myself, but maybe
you have it at hand...)
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/
Pascal Costanza schrieb:
> André Thieme wrote:
>
>> Feel free to begin by translating the ants simulation to CL.
>> You can find it in the Clojure Google Group.
>
> Do you have a more concrete link? (I can look for it myself, but maybe
> you have it at hand...)
I hope this link works when used directly:
http://clojure.googlegroups.com/web/ants.clj
Btw, although this is written by Rich Hickey himself, this code could
need some cleanups :-)
Run Clojure and then in the repl:
(load-file "/users/ath/desktop/ants.clj")
(def ants (setup))
(send-off animator animation)
(dorun (map #(send-off % behave) ants))
To turn on slow evaporation, optionally:
(send-off evaporator evaporation)
And after some time stop the program:
(def running false)
André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/
On Apr 29, 4:32 pm, Kenneth Tilton <·········@gmail.com> wrote:
> I would not put it in terms of quality. Scheme* is perfect and useless,
> for example. Common Lisp will simply trounce anything else in the long
> run, with all successful ideas popularized by challengers absorbed into
> The Ball.nd
I see your point, but having third party libraries to support the new
ideas come along doesn't mean that the language itself will grow.
Having in mind that the CL standard is rather old, and it seems very
unlikely that a new standard will come soon (or ever), and also having
in mind that there isn't a "de facto standard" set of libraries
(correct me if I'm wrong here), I think that though libraries will be
created to support new ideas as they come along, the CL language (at
least ANSI Common Lisp) itself will not adapt. So, if a new CL
standard (official or not) miraculously appears, it might be better
than what is known as CL now.
What I mean is that in my opinion a language which is based on the
ANSI Common Lisp but extends or modifies the standard does not qualify
as Common Lisp.
On Wed, 29 Apr 2009 14:49:02 -0700, MishoM wrote:
> On Apr 29, 4:32 pm, Kenneth Tilton <·········@gmail.com> wrote:
>
>> I would not put it in terms of quality. Scheme* is perfect and useless,
>> for example. Common Lisp will simply trounce anything else in the long
>> run, with all successful ideas popularized by challengers absorbed into
>> The Ball.nd
>
> I see your point, but having third party libraries to support the new
> ideas come along doesn't mean that the language itself will grow. Having
> in mind that the CL standard is rather old, and it seems very unlikely
> that a new standard will come soon (or ever), and also having in mind
> that there isn't a "de facto standard" set of libraries (correct me if
> I'm wrong here), I think that though libraries will be created to
> support new ideas as they come along, the CL language (at least ANSI
> Common Lisp) itself will not adapt. So, if a new CL standard (official
> or not) miraculously appears, it might be better than what is known as
> CL now.
There are a few implicit assumptions in your reasoning. One is that
CL needs to "adapt", and the other is that CL cannot "adapt" (whatever
that means) without changing the standard. I don't see why these
assumptions would hold.
Also, there are a libraries which have become de facto standard, such
as asdf, metabang-bind, cl-ppcre etc.
Finally, a "new" standard is not necessarily required for improvements
in the language, as it can be extended in a piecemeal fashion, eg by
CDRs.
Tamas
MishoM <···············@gmail.com> writes:
> On Apr 29, 4:32�pm, Kenneth Tilton <·········@gmail.com> wrote:
>
>> I would not put it in terms of quality. Scheme* is perfect and useless,
>> for example. Common Lisp will simply trounce anything else in the long
>> run, with all successful ideas popularized by challengers absorbed into
>> The Ball.nd
>
> I see your point, but having third party libraries to support the new
> ideas come along doesn't mean that the language itself will grow.
> Having in mind that the CL standard is rather old, and it seems very
> unlikely that a new standard will come soon (or ever), and also having
> in mind that there isn't a "de facto standard" set of libraries
> (correct me if I'm wrong here), I think that though libraries will be
> created to support new ideas as they come along, the CL language (at
> least ANSI Common Lisp) itself will not adapt. So, if a new CL
> standard (official or not) miraculously appears, it might be better
> than what is known as CL now.
>
> What I mean is that in my opinion a language which is based on the
> ANSI Common Lisp but extends or modifies the standard does not qualify
> as Common Lisp.
What you say here demonstrate a dire lack of understanding of what Lisp is.
Language-wise, Common Lisp is 17 special operators, and an evaluation
model (lambda, closures, environments). This is a very small kernel.
All the rest of the language is defined above this kernel, using macros.
Actually most of the time lisp programmers don't even use the
special operators, but favor instead the macros (eg. dolist or loop
instead of tagbody, setf instead of setq, defun or defmacro instead
of lambda, etc).
And then, some "library" functions to complete it.
The point is that everything above the 17 special operators defined in
the standard has exactly the same status as anything you, as a simple
user of the language, may define. All the libraries have the exact
same status as what is in CL. And this is a lot of stuff, and a lot
of design space to explore for extensions to a programming language.
There's no need to standardize anything there, because it's very easy
to design your libraries to be portable over any CL implementation,
and therefore be a de-facto standard by itself. Each conforming user
library is essentially a CL standard extension. Make it good to have
it used in a lot of applications, and you've got your CL-2009 standard.
There remains the kernel, that you might want to mend with other
concepts. And then either the new concept is orthogonal to the
existing, and can be integrated without difficulty (eg. threads), or
there's some fundamental incompatibility between the new concept and
the existing kernel (eg. full continuations); in this case, you have
to live with the language choices, and your only option is to use
another language, or to work at the metalinguistic level (which is
possible and easy in lisp). In the former case, "customer" pressure
quickly forces the implementations to provide the good features
(eg. threads are now provided in all the implementations, even if some
are not entirely debugged on all the OS yet). And then, even if the
various implementations don't provide a common API, we fall back to
the previous case, where users may develop portability "standard"
libraries (eg. bordeaux-threads becomes THE standard CL thread API, no
need for ANSI or ISO intervention).
Finally, there's no point in "standardizing" a set of library. Each
user may choose what language he uses, composing his language from a
base CL standard, and adding the language libraries he wants.
If you feel a need to define your own new-CL language, well, it's up
to you to specify the set of libraries you need to implement that
new-CL language. You may even write the defpackage "NEW-CL" form to
export all the symbols you want to include in your "standard", and
start to write your applications by using that "NEW-CL" package
instead of "CL". Nothing simpler: (defpackage "MY-APP" (:use "NEW-CL")
...) If your NEW-CL language is good, you might even have a following
and see it become a defacto new "language". (You may even write a CDR).
But since there's no difference in status between CL and NEW-CL (*),
you'll excuse me if I still call it Common Lisp and if I still
consider that CL is not old and dead.
--
__Pascal Bourguignon__
On Apr 30, 1:56 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> MishoM <···············@gmail.com> writes:
> > On Apr 29, 4:32 pm, Kenneth Tilton <·········@gmail.com> wrote:
>
> >> I would not put it in terms of quality. Scheme* is perfect and useless,
> >> for example. Common Lisp will simply trounce anything else in the long
> >> run, with all successful ideas popularized by challengers absorbed into
> >> The Ball.nd
>
> > I see your point, but having third party libraries to support the new
> > ideas come along doesn't mean that the language itself will grow.
> > Having in mind that the CL standard is rather old, and it seems very
> > unlikely that a new standard will come soon (or ever), and also having
> > in mind that there isn't a "de facto standard" set of libraries
> > (correct me if I'm wrong here), I think that though libraries will be
> > created to support new ideas as they come along, the CL language (at
> > least ANSI Common Lisp) itself will not adapt. So, if a new CL
> > standard (official or not) miraculously appears, it might be better
> > than what is known as CL now.
>
> > What I mean is that in my opinion a language which is based on the
> > ANSI Common Lisp but extends or modifies the standard does not qualify
> > as Common Lisp.
>
> What you say here demonstrate a dire lack of understanding of what Lisp is.
>
> Language-wise, Common Lisp is 17 special operators, and an evaluation
> model (lambda, closures, environments). This is a very small kernel.
>
> All the rest of the language is defined above this kernel, using macros.
>
> Actually most of the time lisp programmers don't even use the
> special operators, but favor instead the macros (eg. dolist or loop
> instead of tagbody, setf instead of setq, defun or defmacro instead
> of lambda, etc).
>
> And then, some "library" functions to complete it.
>
> The point is that everything above the 17 special operators defined in
> the standard has exactly the same status as anything you, as a simple
> user of the language, may define. All the libraries have the exact
> same status as what is in CL. And this is a lot of stuff, and a lot
> of design space to explore for extensions to a programming language.
> There's no need to standardize anything there, because it's very easy
> to design your libraries to be portable over any CL implementation,
> and therefore be a de-facto standard by itself. Each conforming user
> library is essentially a CL standard extension. Make it good to have
> it used in a lot of applications, and you've got your CL-2009 standard.
>
> There remains the kernel, that you might want to mend with other
> concepts. And then either the new concept is orthogonal to the
> existing, and can be integrated without difficulty (eg. threads), or
> there's some fundamental incompatibility between the new concept and
> the existing kernel (eg. full continuations); in this case, you have
> to live with the language choices, and your only option is to use
> another language, or to work at the metalinguistic level (which is
> possible and easy in lisp). In the former case, "customer" pressure
> quickly forces the implementations to provide the good features
> (eg. threads are now provided in all the implementations, even if some
> are not entirely debugged on all the OS yet). And then, even if the
> various implementations don't provide a common API, we fall back to
> the previous case, where users may develop portability "standard"
> libraries (eg. bordeaux-threads becomes THE standard CL thread API, no
> need for ANSI or ISO intervention).
>
> Finally, there's no point in "standardizing" a set of library. Each
> user may choose what language he uses, composing his language from a
> base CL standard, and adding the language libraries he wants.
>
> If you feel a need to define your own new-CL language, well, it's up
> to you to specify the set of libraries you need to implement that
> new-CL language. You may even write the defpackage "NEW-CL" form to
> export all the symbols you want to include in your "standard", and
> start to write your applications by using that "NEW-CL" package
> instead of "CL". Nothing simpler: (defpackage "MY-APP" (:use "NEW-CL")
> ...) If your NEW-CL language is good, you might even have a following
> and see it become a defacto new "language". (You may even write a CDR).
>
> But since there's no difference in status between CL and NEW-CL (*),
> you'll excuse me if I still call it Common Lisp and if I still
> consider that CL is not old and dead.
>
> --
> __Pascal Bourguignon__
Well, it seems to me that this is to some extent a question of
personal view. But please, don't assume that I don't understand what
Lisp is. I do understand, and the difference between your position and
mine is in what we include in a language.
You seem to include either only the kernel (as long as the kernel is
the same, the language is the same), or the kernel plus all portable
libraries written by anybody, anywhere, at any time (every portable
reusable piece of code ever written in the language automatically
becomes a part of it).
In my view, there needs to be a way to draw some boundary between
things which are a part of the language and things which are
implemented in it. That boundary is drawn by specifying the things
which are guaranteed to be present in any implementation of the
language - it is there to tell you what you can rely on - hence the
need for an official or de facto standard.
I think I made my view clear enough and I don't intend to argue any
more, because I'm starting to feel bad about participating in the
hijacking of his thread which started from something completely
unrelated.
På Thu, 30 Apr 2009 00:56:04 +0200, skrev Pascal J. Bourguignon
<···@informatimago.com>:
> MishoM <···············@gmail.com> writes:
>
>> On Apr 29, 4:32 pm, Kenneth Tilton <·········@gmail.com> wrote:
>>
>>> I would not put it in terms of quality. Scheme* is perfect and useless,
>>> for example. Common Lisp will simply trounce anything else in the long
>>> run, with all successful ideas popularized by challengers absorbed into
>>> The Ball.nd
>>
>> I see your point, but having third party libraries to support the new
>> ideas come along doesn't mean that the language itself will grow.
>> Having in mind that the CL standard is rather old, and it seems very
>> unlikely that a new standard will come soon (or ever), and also having
>> in mind that there isn't a "de facto standard" set of libraries
>> (correct me if I'm wrong here), I think that though libraries will be
>> created to support new ideas as they come along, the CL language (at
>> least ANSI Common Lisp) itself will not adapt. So, if a new CL
>> standard (official or not) miraculously appears, it might be better
>> than what is known as CL now.
>>
>> What I mean is that in my opinion a language which is based on the
>> ANSI Common Lisp but extends or modifies the standard does not qualify
>> as Common Lisp.
>
> What you say here demonstrate a dire lack of understanding of what Lisp
> is.
>
>
> Language-wise, Common Lisp is 17 special operators, and an evaluation
> model (lambda, closures, environments). This is a very small kernel.
>
actually 26.. see PCL. Now Scheeme has only 6
---------------------
John Thingstad
John Thingstad <·······@online.no> wrote:
+---------------
| skrev Pascal J. Bourguignon <···@informatimago.com>:
| > Language-wise, Common Lisp is 17 special operators, and an evaluation
| > model (lambda, closures, environments). This is a very small kernel.
|
| actually 26.. see PCL. Now Scheeme has only 6
+---------------
Well, R4RS Scheme actually had *9* primitive or special forms ["essential
syntax"] if you assume that there is some sort of macro system available
[one is proposed in the appendix, though not technically part of R4RS]:
{variable reference}
quote
{procedure call}
lambda
if
set!
define
begin
define-syntax [or defmacro or define-macro (see below)]
Otherwise, without a macro system you'd have to add the dozen or so
"derived expressions", COND, CASE, AND, OR, LET, etc., as special forms.
[Note that due to the macro system not being part of the formal spec, these
were also called "essential syntax" in R4RS, but weren't really, since all
useful Schemes had *some* kind of macro system, even if just DEFMACRO!]
Aside: DEFINE has to be a primitive special form, since it must be
capable of distinguishing whether it's being used at the top level
(equivalent to a SET!) or as an "internal DEFINE" (equiv. to LETREC),
and thus cannot be specified entirely by DEFINE-SYNTAX.
Similarly, BEGIN must be capable of distinguishing whether it's
being used at the top level, in which case it must propagate
"top-level status" to any DEFINEs within it [much like PROGN does
in CL]. When not at the top level, it could be macro-expanded into
a call of a function ((LAMBDA (ignored) rest...) first-expr), but
that hack doesn't work for preserving top-level status of DEFINEs.
R5RS Scheme formalized the DEFINE-SYNTAX macro system but also added
two local syntax binding forms [think MACROLET], and so ended up with
*11* primitive or special forms:
{variable reference}
quote
{procedure call}
lambda
if
set!
define
begin
define-syntax
let-syntax
letrec-syntax
Listed another way, from R5RS "7.1.6 Programs and definitions" and
"7.1.3 Expressions":
<program> ---> <command or definition>*
<command or definition> ---> <command> | <definition>
| <syntax definition>
| (begin <command or definition>+)
<definition> ---> (define <variable> <expression>)
| (define (<variable> <def formals>) <body>)
| (begin <definition>*)
<expression> ---> <variable> | <literal> | <procedure call>
| <lambda expression> | <conditional> | <assignment>
| <derived expression> | <macro use> | <macro block>
where:
<syntax definition> ---> (define-syntax <keyword> <transformer spec>)
<literal> ---> <quotation> | <self-evaluating>
<derived expression> ---> {all the standard macros, COND, CASE, etc.}
<macro use> ---> (<keyword> <datum>*)
<macro block> ---> (let-syntax (<syntax spec>*) <body>)
| (letrec-syntax (<syntax spec>*) <body>)
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Apr 29, 10:32 am, Kenneth Tilton <·········@gmail.com> wrote:
> for example. Common Lisp will simply trounce anything else in the long
> run, with all successful ideas popularized by challengers absorbed into
> The Ball.
I don't see pattern matching on parameters absorbed yet into The Ball,
even though they've been highly useful features from functional
programming languages like ML and Haskell for more than *2 decades*
now. There's the horrible manual hackish way to do it by using the
miles-long destructuring-bind and perhaps some other macros, like
Scheme's case-lambda. But it just can't beat:
(define bubble_again_perhaps
X X -> X
X _ -> (bubble_sort X))
and similar usage.
On Sat, 02 May 2009 17:31:33 -0700, namekuseijin wrote:
> On Apr 29, 10:32 am, Kenneth Tilton <·········@gmail.com> wrote:
>> for example. Common Lisp will simply trounce anything else in the long
>> run, with all successful ideas popularized by challengers absorbed into
>> The Ball.
>
> I don't see pattern matching on parameters absorbed yet into The Ball,
> even though they've been highly useful features from functional
> programming languages like ML and Haskell for more than *2 decades* now.
> There's the horrible manual hackish way to do it by using the
> miles-long destructuring-bind and perhaps some other macros, like
> Scheme's case-lambda. But it just can't beat:
>
> (define bubble_again_perhaps
> X X -> X
> X _ -> (bubble_sort X))
>
> and similar usage.
Or you could use cl-match, cl-unification, or other similar libraries.
All have nice, unobtrusive syntax which integrates into CL just fine,
and seem to work well. I just tried cl-match a couple of days ago.
If you need something, don't complain about it not making its way into
The Ball. Just grab it and incorporate it yourself. Everyone has a
different mudball, BTW, so things can make it into yours without being
generally widespread, and vice versa. The beauty of libraries.
Tamas
On May 3, 2:31 am, namekuseijin <············@gmail.com> wrote:
> On Apr 29, 10:32 am, Kenneth Tilton <·········@gmail.com> wrote:
>
> > for example. Common Lisp will simply trounce anything else in the long
> > run, with all successful ideas popularized by challengers absorbed into
> > The Ball.
>
> I don't see pattern matching on parameters absorbed yet into The Ball,
> even though they've been highly useful features from functional
> programming languages like ML and Haskell for more than *2 decades*
> now. There's the horrible manual hackish way to do it by using the
> miles-long destructuring-bind and perhaps some other macros, like
> Scheme's case-lambda. But it just can't beat:
>
> (define bubble_again_perhaps
> X X -> X
> X _ -> (bubble_sort X))
>
> and similar usage.
On May 3, 2:31 am, namekuseijin <············@gmail.com> wrote:
> On Apr 29, 10:32 am, Kenneth Tilton <·········@gmail.com> wrote:
>
> > for example. Common Lisp will simply trounce anything else in the long
> > run, with all successful ideas popularized by challengers absorbed into
> > The Ball.
>
> I don't see pattern matching on parameters absorbed yet into The Ball,
> even though they've been highly useful features from functional
> programming languages like ML and Haskell for more than *2 decades*
> now. There's the horrible manual hackish way to do it by using the
> miles-long destructuring-bind and perhaps some other macros, like
> Scheme's case-lambda. But it just can't beat:
>
> (define bubble_again_perhaps
> X X -> X
> X _ -> (bubble_sort X))
>
> and similar usage.
What you are asking is at the same time very easy and quite tricky.
IMHO the above lacks some syntax markers, but that's OK. Using CL
unification you can easily write up a DEFINE macro.
(defmacro define (name &rest clauses)
`(defun ,name (gensymmed-symbol-here)
(unify:match-case (gensymmed-symbol-here)
,@(collect-qi-things clauses))))
(defun collect-qi-things (cs)
(labels
((collect-value-expr (c pat defs)
(collect-def (rest c) (cons (list pat (first c)) defs)))
(collect-pat (c pat defs)
(let ((fc (first c)))
(if (eq '-> fc)
(collect-value-expr (rest c) pat defs)
(collect-pat (rest c) (append pat (list fc)) defs))))
(collect-def (c defs)
(if c
(collect-pat c () defs)
defs))
)
(nreverse (collect-def cs ()))))
The above is untested and unchecked; it is just an idea about how to
do the simple thing. You are very welcome to post fixes and
enhancements to the CL-UNIFICATION mailing lists.
Now you can say
(define bubble-sort-maybe
?x ?x -> ?x
?x _ -> (bubble-sort ?x))
You can also say
(define fact
#T(number 0) -> 1
?n -> (* ?n (fact (1- ?n))))
and
(define foo
#T(list 1 2 3 42 &rest ?r) _ -> (append ?r (list 42 42))
#T(ship ship-x ?x ship-y ?y) #T(plane plane-p ?p)
-> (progn (format t "There's a ship at ~S ~S and a plane at ~S.~%" ?
x ?y ?p))
If you can get the code to add the "correct" declaration for the
hidden variable, then in a CL with a compiler that does type inference
you have gotten yourself very close to Qi itself (for a proper
defintion of "very close").
Join the fun on the CL-UNIFICATION development.....
Cheers
--
Marco
ELS 2009 www.european-lisp-symposium.org
Marco Antoniotti wrote:
> On May 3, 2:31 am, namekuseijin <············@gmail.com> wrote:
>> I don't see pattern matching on parameters absorbed yet into The Ball,
>
> What you are asking is at the same time very easy and quite tricky.
> IMHO the above lacks some syntax markers, but that's OK. Using CL
> unification you can easily write up a DEFINE macro.
>
> (defmacro define (name &rest clauses)
> `(defun ,name (gensymmed-symbol-here)
> (unify:match-case (gensymmed-symbol-here)
> ,@(collect-qi-things clauses))))
>
> (defun collect-qi-things (cs)
> (labels
> ((collect-value-expr (c pat defs)
> (collect-def (rest c) (cons (list pat (first c)) defs)))
>
> (collect-pat (c pat defs)
> (let ((fc (first c)))
> (if (eq '-> fc)
> (collect-value-expr (rest c) pat defs)
> (collect-pat (rest c) (append pat (list fc)) defs))))
>
> (collect-def (c defs)
> (if c
> (collect-pat c () defs)
> defs))
> )
> (nreverse (collect-def cs ()))))
>
> The above is untested and unchecked; it is just an idea about how to
> do the simple thing. You are very welcome to post fixes and
> enhancements to the CL-UNIFICATION mailing lists.
That's all pretty impressive no doubt. But I can't help but fear
there's a culture of complexity in CL.
For instance:
> (define fact
> #T(number 0) -> 1
> ?n -> (* ?n (fact (1- ?n))))
ideally, I'd want something less Perlish and more clean like:
(define fact
0 -> 1
n -> (* n (fact (1- n))))
This is cleaner than Scheme itself. :)
> (define foo
> #T(list 1 2 3 42 &rest ?r) _ -> (append ?r (list 42 42))
> #T(ship ship-x ?x ship-y ?y) #T(plane plane-p ?p)
> -> (progn (format t "There's a ship at ~S ~S and a plane at ~S.~%" ?
> x ?y ?p))
(define foo
(1 2 3 42 . r) _ -> (append r (list 42 42))
(ship ship-x x ship-y y) (plane plane-p p)
-> (progn (format t "There's a ship at ~S ~S and a plane at ~S.~%" x
y p))
Still impressive anyway. But since it's not in the standard, it's
simply not used that much.
On May 4, 12:37 am, namekuseijin <···················@gmail.com>
wrote:
> Marco Antoniotti wrote:
> > On May 3, 2:31 am, namekuseijin <············@gmail.com> wrote:
> >> I don't see pattern matching on parameters absorbed yet into The Ball,
>
> > What you are asking is at the same time very easy and quite tricky.
> > IMHO the above lacks some syntax markers, but that's OK. Using CL
> > unification you can easily write up a DEFINE macro.
>
> > (defmacro define (name &rest clauses)
> > `(defun ,name (gensymmed-symbol-here)
> > (unify:match-case (gensymmed-symbol-here)
> > ,@(collect-qi-things clauses))))
>
> > (defun collect-qi-things (cs)
> > (labels
> > ((collect-value-expr (c pat defs)
> > (collect-def (rest c) (cons (list pat (first c)) defs)))
>
> > (collect-pat (c pat defs)
> > (let ((fc (first c)))
> > (if (eq '-> fc)
> > (collect-value-expr (rest c) pat defs)
> > (collect-pat (rest c) (append pat (list fc)) defs))))
>
> > (collect-def (c defs)
> > (if c
> > (collect-pat c () defs)
> > defs))
> > )
> > (nreverse (collect-def cs ()))))
>
> > The above is untested and unchecked; it is just an idea about how to
> > do the simple thing. You are very welcome to post fixes and
> > enhancements to the CL-UNIFICATION mailing lists.
>
> That's all pretty impressive no doubt. But I can't help but fear
> there's a culture of complexity in CL.
>
> For instance:
>
> > (define fact
> > #T(number 0) -> 1
> > ?n -> (* ?n (fact (1- ?n))))
>
> ideally, I'd want something less Perlish and more clean like:
> (define fact
> 0 -> 1
> n -> (* n (fact (1- n))))
I apologize beforehand for sounding paternalistic. :)
If you had just tried it a little more seriously you would have seen
that the above (modulo *your* bug fixes and improvements *does work*
with CL-UNIFICATION.
(define fact
0 -> 1
?n -> (* n (fact (1- n)))
It would seem that with a little bit of extra work you can also get
rid of the question mark, but I would advise against it for reasons
that will become clear later on and that should be clear to anybody
who has seen real unification at work in Prolog (vs. pattern matching
in FPs). Apart from that, Qi does type inference for you, but it
also gives you syntax to tag variables with types.
>
> This is cleaner than Scheme itself. :)
>
> > (define foo
> > #T(list 1 2 3 42 &rest ?r) _ -> (append ?r (list 42 42))
> > #T(ship ship-x ?x ship-y ?y) #T(plane plane-p ?p)
> > -> (progn (format t "There's a ship at ~S ~S and a plane at ~S.~%" ?
> > x ?y ?p))
>
> (define foo
> (1 2 3 42 . r) _ -> (append r (list 42 42))
> (ship ship-x x ship-y y) (plane plane-p p)
> -> (progn (format t "There's a ship at ~S ~S and a plane at ~S.~%" x
> y p))
>
Cute. Note that the above is a almost a SMOP with CL-UNIFICATION, but
I have the following questions (with a long preamble) for you.
The second pattern is trivial to handle the way you want. You just
have to bypass the reader macro and get down to the MAKE-TEMPLATE
call; as I said it is a SMOP.
Now, let's have a look at the first template. Let's not talk about
the . vs &rest; that is just a matter of style. But, what are you
matching there? A strange object with "type" 1, or a list? What if
you want to match a dotted pair with the symbol R after the dot?
These are the kind of questions I answered when I designed CL-
UNIFICATION, whose driving goal was to "go past" S-expression matching/
unification. Hence the choices I made. I do not think they are
perfect, but they do not interfere with the underlying language.
Again, consider
(define month->ordinal
january -> 1
february -> 2
march -> 3
...)
The above is perfectly "understandable" and it works "out of the box"
with CL-UNIFICATION. But compare it with the simple FACT definition
above. What is the difference between the N and MARCH?
> Still impressive anyway. But since it's not in the standard, it's
> simply not used that much.
Most of the Scheme used nowadays is "not in the standard".
If it is not used much, why don't you start using it? You sound like
the opposite of "that bar is so crowded that nobody goes there
anymore". :)
Having said that, a few comments more. I am very very very careful to
ensure that my libraries are (1) unobtrusive and (2) with only
absolutely necessary dependencies and (3) portable.
The latest CL-UNIFICATION iteration included CL-PPCRE (praised be the
Weitz!). Now you can do
cl-prompt> (unify #T(regex "a(b*)" (?bs)) "abbbbb")
#<UNIFY ENVIRONMENT: 1 frame 21BD1D67>
cl-prompt> (unify:v? '?bs *)
"bbbbbb"
T
It is instructive to see how much work I put into what. First I went
through Edi's docs to find out what I needed. That was easy. Then I
designed a CL-UNIFICATION template; relatively easy again.
... then the hard part came ...
Getting ASDF (and MK:DEFSYSTEM) to load the CL-PCRE template extension
if and only if CL-PPCRE is available in a CL environment. This took
much more time than the above. But the result is that now you can
load CL-UNIFICATION even if you do not have CL-PPCRE installed. You
just will not have the regexp templates available.
In other words, you can load CL-UNIFICATION in a fresh CL. An that is
also thanks to the fact that CL-UNIFICATION does not depend on, e.g.,
ITERATE.
Cheers
--
Marco
On May 4, 7:17 am, Marco Antoniotti <·······@gmail.com> wrote:
> I apologize beforehand for sounding paternalistic. :)
No prob. We all enjoy our personal Lisps. ;)
> (define fact
> 0 -> 1
> ?n -> (* n (fact (1- n)))
>
> It would seem that with a little bit of extra work you can also get
> rid of the question mark, but I would advise against it for reasons
> that will become clear later on and that should be clear to anybody
> who has seen real unification at work in Prolog (vs. pattern matching
> in FPs).
> > (define foo
> > (1 2 3 42 . r) _ -> (append r (list 42 42))
> > (ship ship-x x ship-y y) (plane plane-p p)
> > -> (progn (format t "There's a ship at ~S ~S and a plane at ~S.~%" x
> > y p))
>
>
> The second pattern is trivial to handle the way you want. You just
> have to bypass the reader macro and get down to the MAKE-TEMPLATE
> call; as I said it is a SMOP.
Everything is always just a SMOP in CL. I fear that when the need for
SMOPs abound, perhaps it is time for a new revision for the language?
C++ is getting a new one just about now and it's coming with plenty of
good stuff. Including lambdas, can you imagine? o_O
> what are you
> matching there? A strange object with "type" 1, or a list? What if
> you want to match a dotted pair with the symbol R after the dot?
perhaps like:
(1 2 3 42 . (a . b))
?
> (define month->ordinal
> january -> 1
> february -> 2
> march -> 3
> ...)
>
> The above is perfectly "understandable" and it works "out of the box"
> with CL-UNIFICATION. But compare it with the simple FACT definition
> above. What is the difference between the N and MARCH?
The difference is that march is not used in the right side of the
expression. ;)
> > Still impressive anyway. But since it's not in the standard, it's
> > simply not used that much.
>
> Most of the Scheme used nowadays is "not in the standard".
Yes, but the point is that parameter pattern matching is an incredibly
useful, but since it's not part of the language standard, there will
always be some resistance to its use, unobtrusive or whatnot.
> The latest CL-UNIFICATION iteration included CL-PPCRE (praised be the
> Weitz!).
and the Wall!
> cl-prompt> (unify #T(regex "a(b*)" (?bs)) "abbbbb")
> #<UNIFY ENVIRONMENT: 1 frame 21BD1D67>
>
> cl-prompt> (unify:v? '?bs *)
> "bbbbbb"
> T
Amazing. But forgive me if my enthusiasm is low: I didn't sleep this
night, hacking away some stuff... :P
> ... then the hard part came ...
>
> Getting ASDF (and MK:DEFSYSTEM) to load the CL-PCRE template extension
> if and only if CL-PPCRE is available in a CL environment. This took
> much more time than the above.
BTW, it's amazing the number of automatic package managers that each
language got to themselves. Ruby has gems, Haskell, hackage, Perl has
some script to automatically search/download/install from CPAN.
*Each* Scheme has their own repository. Python has none.
I need coffee...
> Everything is always just a SMOP in CL. I fear that when the need for
> SMOPs abound, perhaps it is time for a new revision for the language?
> C++ is getting a new one just about now and it's coming with plenty of
> good stuff. Including lambdas, can you imagine? o_O
I think this is true, but I think the problem is that a lot of people
who /would/ do revisions to the language go out and end up either
reinventing the wheel (and ending up with something kind of lumpy), or
trying to solve all of the world's problems at the same time, and not
ending up with much of a spiritual successor (to Common Lisp anyway).
On Mon, 04 May 2009 09:03:24 -0700, namekuseijin wrote:
> Everything is always just a SMOP in CL. I fear that when the need for
> SMOPs abound, perhaps it is time for a new revision for the language?
> C++ is getting a new one just about now and it's coming with plenty of
> good stuff. Including lambdas, can you imagine? o_O
I don't see how a revision would benefit you more than just loading a
library, especially given the high cost of revisions.
I think a revision is warranted when the language is so constraining
that you just cannot implement things as a library. Even though CL
has some constraints, they are the most lax of all languages I know
and give you lots of freedom.
As the examples show, pattern matching is something you can do just
fine in a library, so I don't see the point of asking for a revision
to the language.
It is amazing though that this question crops up so often on c.l.l,
people argue that certain libraries/features need to be made
"standard", so they would be spared the expense of downloading &
loading the relevant library. Perhaps the reason is that ASDF, the
prevalent distribution/management system for libraries, has a lot of
flaws. But replacements are in progress.
Tamas
On May 4, 1:37 pm, Tamas K Papp <······@gmail.com> wrote:
> On Mon, 04 May 2009 09:03:24 -0700, namekuseijin wrote:
> > Everything is always just a SMOP in CL. I fear that when the need for
> > SMOPs abound, perhaps it is time for a new revision for the language?
> > C++ is getting a new one just about now and it's coming with plenty of
> > good stuff. Including lambdas, can you imagine? o_O
>
> I don't see how a revision would benefit you more than just loading a
> library, especially given the high cost of revisions.
>
> I think a revision is warranted when the language is so constraining
> that you just cannot implement things as a library. Even though CL
> has some constraints, they are the most lax of all languages I know
> and give you lots of freedom.
>
> As the examples show, pattern matching is something you can do just
> fine in a library, so I don't see the point of asking for a revision
> to the language.
CL-UNIFICATION was carefully coded in order not to use things like
ITERATE, or so Marco said. Because it's costly to depend on and
require ever more things outside the standard.
Don't revise the language, fine, CL is perfect. But at least revise
the standard libs so that pattern matching, threads, ffi and a few
more are standardized. You know, actually make it stick to The Ball.
On May 4, 12:37 pm, Tamas K Papp <······@gmail.com> wrote:
> It is amazing though that this question crops up so often on c.l.l,
> people argue that certain libraries/features need to be made
> "standard", so they would be spared the expense of downloading &
> loading the relevant library. Perhaps the reason is that ASDF, the
> prevalent distribution/management system for libraries, has a lot of
> flaws. But replacements are in progress.
I don't see why certain things can't be a 'standard library'.
If it is something that is basic and is going to be useful for a large
number of projects, it might as well come with whatever CL system you
are working with.
There are a few reasons this would be good:
1.) Eliminates the minor pain of downloading and installing said
libraries which you pretty much have to download anyway. If I'm going
to do it anyway, it should be done for me. :-)
2a.) Removes some of the 'reinventing the wheel' writing your own
'iterate' macro (for example) is a fun and educational exercise, but
actually going and using it is another thing entirely.
2b.) Helps pool resources. I mean, if your lisp system comes with a
package that is nice, but not *quite* good enough (fast enough, for
example), are you more likely to re-factor what you have, or start
anew? CL is a smallish community, and while CL is a powerful language,
anything benefits from more eyes.
3.) Bit-rot. Package A depends on B, Package B depends on C, Pacage C
depends on D.
-------------
D gets upgraded to a new version and the old version is taken down,
the new version causes C to not work. This means that A and B also
don't work. C's maintainer has gone on vacation or died or gone to
commune with nature, leaving the petty materialistic life of a
programmer. So now package A and B suffer and no one can get them to
work anymore.
------------
In an alternate reality, package D's API is standardized. It gets
improved/upgraded and doesn't break package C.
------------
Point 3 does not happen terribly often, but I am forced to think about
how many packages there are that I use which are maintained by a
single person. You end up putting a lot of eggs in one basket.
On May 4, 3:31 pm, ··················@gmail.com wrote:
> 1.) Eliminates the minor pain of downloading and installing said
> libraries which you pretty much have to download anyway. If I'm going
> to do it anyway, it should be done for me. :-)
I don't have any problem with that. The problem begins when said
library is just available for implementation X or Y, but not Z.
Being a _standard lib_ definitely means quite something. It means
you'll definitely use standard lib features with gusto, without fear
of it not working or not being available for any standard lib
compliant implementation. It should definitely change the source code
landscape, possibly for the better.
Forget the old-time idiom of
(if (null list) (foo ...)
(bar (car list) (cdr list) ...))
or the stinking destructuring-bind and just go
(() -> (foo ...)
(hd . tl) -> (bar hd tl ...))
or something like that. BTW, I don't really like -> and would very
much prefer to use an extra pair os parentheses around each pattern-
rhe...
On May 4, 3:18 pm, namekuseijin <············@gmail.com> wrote:
> On May 4, 3:31 pm, ··················@gmail.com wrote:
>
> > 1.) Eliminates the minor pain of downloading and installing said
> > libraries which you pretty much have to download anyway. If I'm going
> > to do it anyway, it should be done for me. :-)
>
> I don't have any problem with that. The problem begins when said
> library is just available for implementation X or Y, but not Z.
>
That's true.
I haven't really had too much trouble with that in Common Lisp land,
then again, I stick to SBCL on debian most of the time, which is
definitely one of the more supported implementations.
> Being a _standard lib_ definitely means quite something. It means
> you'll definitely use standard lib features with gusto, without fear
> of it not working or not being available for any standard lib
> compliant implementation. It should definitely change the source code
> landscape, possibly for the better.
>
That is true, but you kind of run into a chicken and egg sort of thing
here.
(Do you demand it as a standard library and then make all the
implementations use it, or do you get all of the implementations to
adopt it and then make in a standard library). The first version is
probably more pragmatic.
> Forget the old-time idiom of
> (if (null list) (foo ...)
> (bar (car list) (cdr list) ...))
>
> or the stinking destructuring-bind and just go
>
> (() -> (foo ...)
> (hd . tl) -> (bar hd tl ...))
>
> or something like that. BTW, I don't really like -> and would very
> much prefer to use an extra pair os parentheses around each pattern-
> rhe...
I'm not sure what you mean, but car and cdr have actually grown on me.
I also think that when you start to do more macrology, not having
stuff like '->' is a definite advantage.
On May 4, 5:55 pm, ··················@gmail.com wrote:
> > (() -> (foo ...)
> > (hd . tl) -> (bar hd tl ...))
>
> I'm not sure what you mean, but car and cdr have actually grown on me.
cons, car and cdr are Lisp's "assembly". car and cdr were indeed
assembly in the original machines some of the first Lisp's ran on.
Pattern matching just removes the need for manual assembly coding:
specify what you want rather than manually do it.
> stuff like '->' is a definite advantage.
I don't like -> either, very unLispy. I'd want something more akin to
((hd . tl) (bar hd tl ...))
namekuseijin <············@gmail.com> writes:
> I don't like -> either, very unLispy. I'd want something more akin to
> ((hd . tl) (bar hd tl ...))
For me, there are very few things that are "unlispy". Among them are
putting closing parens on extra lines, and detesting the possibility of
visual syntactic improvements like "->".
Nicolas
On May 5, 4:14 am, Nicolas Neuss <········@math.uni-karlsruhe.de>
wrote:
> namekuseijin <············@gmail.com> writes:
> > I don't like -> either, very unLispy. I'd want something more akin to
> > ((hd . tl) (bar hd tl ...))
>
> For me, there are very few things that are "unlispy". Among them are
> putting closing parens on extra lines, and detesting the possibility of
> visual syntactic improvements like "->".
>
> Nicolas
When I have a lot of close parens and I'm going to go back and edit
stuff later, I'll separate them out onto lines (based on i.e. where
the let ends). Helps me edit later.
I like to use '<-' (FP lisp code reads right to left...) to indicate a
conversion sort of function.
Do you think the right-to-left-ness of lisp hurts it?
A lot of the time I am reading bottom-to-top and right to left when I
read lisp code.
Then other times, (when I'm reading someone's C code converted to lisp
via progn), I'll find myself reading left to right and top to bottom.
Maybe part of the entry barrier to lisp is a certain level of mental/
spatial ability.
Is code that reads 'right to left' bad? It doesn't seem bad to me, but
it occurs to me that it might be an issue for some people.
··················@gmail.com escreveu:
> When I have a lot of close parens and I'm going to go back and edit
> stuff later, I'll separate them out onto lines (based on i.e. where
> the let ends). Helps me edit later.
Man, don't use notepad when there's far better tools for free out there,
specially Lisp-related tools, like Emacs or DrScheme. Parenthetical
editing is a breeze with them, not only visually showing matching
parentheses, but also actually cut-and-pasting over entire enclosements
in a single keypress. And () in another, and up and down enclosements
and so forth...
Heck, even plain vi matches parentheses!
> I like to use '<-' (FP lisp code reads right to left...) to indicate a
> conversion sort of function.
>
> Do you think the right-to-left-ness of lisp hurts it?
>
> A lot of the time I am reading bottom-to-top and right to left when I
> read lisp code.
Are you nuts? This is Lisp, not Forth.
You read the functions and then the arguments left to right. Can you
provide any exemple of otherwise?
> Is code that reads 'right to left' bad? It doesn't seem bad to me, but
> it occurs to me that it might be an issue for some people.
I certainly don't enjoy Forth or OO languages, say:
Bozo.ClownFriends.gather()
I very much prefer:
(gather (clown-friends bozo))...
:)
--
a game sig: http://tinyurl.com/d3rxz9
On May 5, 2:31 pm, namekuseijin <············@gmail.com> wrote:
> ··················@gmail.com escreveu:
>
> > When I have a lot of close parens and I'm going to go back and edit
> > stuff later, I'll separate them out onto lines (based on i.e. where
> > the let ends). Helps me edit later.
>
> Man, don't use notepad when there's far better tools for free out there,
> specially Lisp-related tools, like Emacs or DrScheme. Parenthetical
> editing is a breeze with them, not only visually showing matching
> parentheses, but also actually cut-and-pasting over entire enclosements
> in a single keypress. And () in another, and up and down enclosements
> and so forth...
>
> Heck, even plain vi matches parentheses!
>
I use Emacs.
Its not about counting/matching or indenting parenthesis,
its about having the sections of my function body delimited.
> > I like to use '<-' (FP lisp code reads right to left...) to indicate a
> > conversion sort of function.
>
> > Do you think the right-to-left-ness of lisp hurts it?
>
> > A lot of the time I am reading bottom-to-top and right to left when I
> > read lisp code.
>
> Are you nuts? This is Lisp, not Forth.
>
> You read the functions and then the arguments left to right. Can you
> provide any example of otherwise?
>
No I read the argument and then the functions from right to left,
maybe I'm brain damaged, but it makes most sense to me thinking of it
as a series of transformations.
Example would be:
(defun symbol-tree<-list-tree (symbol-tree)
(list-tree<-id-tree (id-tree<-object-tree (object-tree<-symbol-tree
symbol-tree))))
I start with a 'symbol tree' and I end up with a 'list tree'.
The program actually flows from right to left and bottom to top, so i
read it like that.
This is also good if you want to use/write destructive functions, as
you can copy at one end and not worry about the middle parts.
> > Is code that reads 'right to left' bad? It doesn't seem bad to me, but
> > it occurs to me that it might be an issue for some people.
>
> I certainly don't enjoy Forth or OO languages, say:
>
> Bozo.ClownFriends.gather()
>
> I very much prefer:
>
> (gather (clown-friends bozo))...
>
> :)
>
> --
> a game sig:http://tinyurl.com/d3rxz9
Maybe we just have different definitions of right to left.
··················@gmail.com escreveu:
> On May 5, 2:31 pm, namekuseijin <············@gmail.com> wrote:
> Its not about counting/matching or indenting parenthesis,
> its about having the sections of my function body delimited.
ah
>>> I like to use '<-' (FP lisp code reads right to left...) to indicate a
>>> conversion sort of function.
>>> Do you think the right-to-left-ness of lisp hurts it?
>>> A lot of the time I am reading bottom-to-top and right to left when I
>>> read lisp code.
>> Are you nuts? This is Lisp, not Forth.
>>
>> You read the functions and then the arguments left to right. Can you
>> provide any example of otherwise?
>
> No I read the argument and then the functions from right to left,
> maybe I'm brain damaged, but it makes most sense to me thinking of it
> as a series of transformations.
Perhaps Forth would suit you better. ;)
Only one required to read source that way is a (strict) language
compiler. It gotta eval arguments first, that is. Not necessarily
right to left.
> (defun symbol-tree<-list-tree (symbol-tree)
> (list-tree<-id-tree (id-tree<-object-tree (object-tree<-symbol-tree
> symbol-tree))))
You receive a "symbol-tree" for argument, but by the function name I
would expect it to convert *from* a list-tree *to* a symbol-tree. This
is way confusing... unless the function name is a typo, which it seems
to be since object-tree->symbol-tree receives the symbol-tree.
I have to say I never thought of conversion functions that way and
looking at it it does visually seems to make sense -- for a Forth
programmer! That is, you have to ditch Lisp's prefix syntax in favor of
a postfix one. What you're doing is first seeing the arguments and then
the operator acting on them and that is the hallmark of stack-based
languages.
Besides, I'm not that visual a guy when it comes to programming, or at
least with Lisp source: I read string->number as "string to number" so
I know it receives a string and outputs a number.
>>> Is code that reads 'right to left' bad? It doesn't seem bad to me, but
>>> it occurs to me that it might be an issue for some people.
>> I certainly don't enjoy Forth or OO languages, say:
>>
>> Bozo.ClownFriends.gather()
>>
>> I very much prefer:
>>
>> (gather (clown-friends bozo))...
>
> Maybe we just have different definitions of right to left.
are you by any chance from China or Japan? ;)
Reading "gather of the clown friends of bozo" to me is more straight
forward (active voice) than "bozo's clown friends's gather". Hmm, I
think I had this conversation here at c.l.l before...
and srsly, you should consider giving Forth or Factor a chance...
--
a game sig: http://tinyurl.com/d3rxz9
On May 5, 6:36 pm, namekuseijin <············@gmail.com> wrote:
> ··················@gmail.com escreveu:
>
> > On May 5, 2:31 pm, namekuseijin <············@gmail.com> wrote:
> > Its not about counting/matching or indenting parenthesis,
> > its about having the sections of my function body delimited.
>
> ah
>
> >>> I like to use '<-' (FP lisp code reads right to left...) to indicate a
> >>> conversion sort of function.
> >>> Do you think the right-to-left-ness of lisp hurts it?
> >>> A lot of the time I am reading bottom-to-top and right to left when I
> >>> read lisp code.
> >> Are you nuts? This is Lisp, not Forth.
>
> >> You read the functions and then the arguments left to right. Can you
> >> provide any example of otherwise?
>
> > No I read the argument and then the functions from right to left,
> > maybe I'm brain damaged, but it makes most sense to me thinking of it
> > as a series of transformations.
>
> Perhaps Forth would suit you better. ;)
>
> Only one required to read source that way is a (strict) language
> compiler. It gotta eval arguments first, that is. Not necessarily
> right to left.
>
> > (defun symbol-tree<-list-tree (symbol-tree)
> > (list-tree<-id-tree (id-tree<-object-tree (object-tree<-symbol-tree
> > symbol-tree))))
>
> You receive a "symbol-tree" for argument, but by the function name I
> would expect it to convert *from* a list-tree *to* a symbol-tree. This
> is way confusing... unless the function name is a typo, which it seems
> to be since object-tree->symbol-tree receives the symbol-tree.
>
Ah, indeed it was a typo.
Intended it to be list-tree<-symbol-tree
> I have to say I never thought of conversion functions that way and
> looking at it it does visually seems to make sense -- for a Forth
> programmer! That is, you have to ditch Lisp's prefix syntax in favor of
> a postfix one. What you're doing is first seeing the arguments and then
> the operator acting on them and that is the hallmark of stack-based
> languages.
>
Well what prefix does is it gives you the order in which things get
pushed *onto* the stack. (as opposed to popped off as in postfix).
So I guess you could think of it as
(push list-tree<-id-tree)
(push id-tree<-object-tree)
(push object-tree<-symbol-tree)
(push symbol-tree)
(apply)
(apply)
(apply)
(pop)
(or something like that)
> Besides, I'm not that visual a guy when it comes to programming, or at
> least with Lisp source: I read string->number as "string to number" so
> I know it receives a string and outputs a number.
>
> >>> Is code that reads 'right to left' bad? It doesn't seem bad to me, but
> >>> it occurs to me that it might be an issue for some people.
> >> I certainly don't enjoy Forth or OO languages, say:
>
> >> Bozo.ClownFriends.gather()
>
> >> I very much prefer:
>
> >> (gather (clown-friends bozo))...
>
> > Maybe we just have different definitions of right to left.
>
> are you by any chance from China or Japan? ;)
>
nope.. just weird.
> Reading "gather of the clown friends of bozo" to me is more straight
> forward (active voice) than "bozo's clown friends's gather". Hmm, I
> think I had this conversation here at c.l.l before...
>
"Get bozo's clown-friends and gather them."
I think is how I would put it.
> and srsly, you should consider giving Forth or Factor a chance...
I certainly will!
Can I use objects and macros in forth or factor?
··················@gmail.com wrote:
> On May 5, 6:36 pm, namekuseijin <············@gmail.com> wrote:
>> ··················@gmail.com escreveu:
>>
>>> On May 5, 2:31 pm, namekuseijin <············@gmail.com> wrote:
>>> Its not about counting/matching or indenting parenthesis,
>>> its about having the sections of my function body delimited.
>> ah
>>
>>>>> I like to use '<-' (FP lisp code reads right to left...) to indicate a
>>>>> conversion sort of function.
>>>>> Do you think the right-to-left-ness of lisp hurts it?
>>>>> A lot of the time I am reading bottom-to-top and right to left when I
>>>>> read lisp code.
>>>> Are you nuts? This is Lisp, not Forth.
>>>> You read the functions and then the arguments left to right. Can you
>>>> provide any example of otherwise?
>>> No I read the argument and then the functions from right to left,
>>> maybe I'm brain damaged, but it makes most sense to me thinking of it
>>> as a series of transformations.
>> Perhaps Forth would suit you better. ;)
>>
>> Only one required to read source that way is a (strict) language
>> compiler. It gotta eval arguments first, that is. Not necessarily
>> right to left.
>>
>>> (defun symbol-tree<-list-tree (symbol-tree)
>>> (list-tree<-id-tree (id-tree<-object-tree (object-tree<-symbol-tree
>>> symbol-tree))))
>> You receive a "symbol-tree" for argument, but by the function name I
>> would expect it to convert *from* a list-tree *to* a symbol-tree. This
>> is way confusing... unless the function name is a typo, which it seems
>> to be since object-tree->symbol-tree receives the symbol-tree.
>>
>
> Ah, indeed it was a typo.
> Intended it to be list-tree<-symbol-tree
>
>> I have to say I never thought of conversion functions that way and
>> looking at it it does visually seems to make sense -- for a Forth
>> programmer! That is, you have to ditch Lisp's prefix syntax in favor of
>> a postfix one. What you're doing is first seeing the arguments and then
>> the operator acting on them and that is the hallmark of stack-based
>> languages.
>>
>
> Well what prefix does is it gives you the order in which things get
> pushed *onto* the stack. (as opposed to popped off as in postfix).
>
> So I guess you could think of it as
>
> (push list-tree<-id-tree)
> (push id-tree<-object-tree)
> (push object-tree<-symbol-tree)
> (push symbol-tree)
> (apply)
> (apply)
> (apply)
> (pop)
>
> (or something like that)
>
>> Besides, I'm not that visual a guy when it comes to programming, or at
>> least with Lisp source: I read string->number as "string to number" so
>> I know it receives a string and outputs a number.
>>
>>>>> Is code that reads 'right to left' bad? It doesn't seem bad to me, but
>>>>> it occurs to me that it might be an issue for some people.
>>>> I certainly don't enjoy Forth or OO languages, say:
>>>> Bozo.ClownFriends.gather()
>>>> I very much prefer:
>>>> (gather (clown-friends bozo))...
>>> Maybe we just have different definitions of right to left.
>> are you by any chance from China or Japan? ;)
>>
>
> nope.. just weird.
>
>> Reading "gather of the clown friends of bozo" to me is more straight
>> forward (active voice) than "bozo's clown friends's gather". Hmm, I
>> think I had this conversation here at c.l.l before...
>>
>
> "Get bozo's clown-friends and gather them."
> I think is how I would put it.
>
>
>> and srsly, you should consider giving Forth or Factor a chance...
>
> I certainly will!
>
> Can I use objects and macros in forth or factor?
I don't have practical knowledge of either, but from what I read,
Forth's "words" are pretty much like macros and pretty much the whole of
the language is defined upon a very small "vocabulary".
Only functions, but it looks pretty much like object oriented
programming, as in Bozo ClownFriends gather. ;)
From the description of gforth in the Ubuntu repository:
"Each Forth environment provides one or more dictionaries of
pre-defined words, and programming in Forth consists of defining and
executing new words that are combinations of previously defined words.
*It has been said that learning Forth changes forever the way you think
about writing programs*."
Sounds about like Lisp, and is pretty old as well. :)
In fact, sounds like (reverse lisp)... or lisp reverse to be precise...
Factor is kinda like shizznit forth:
http://factorcode.org/
It's self-described as a concatenative programming language.
On Tue, 05 May 2009 22:09:34 -0300, namekuseijin wrote:
> From the description of gforth in the Ubuntu repository:
> "Each Forth environment provides one or more dictionaries of pre-defined
> words, and programming in Forth consists of defining and executing new
> words that are combinations of previously defined words. *It has been
> said that learning Forth changes forever the way you think about writing
> programs*."
>
> Sounds about like Lisp, and is pretty old as well. :)
>
> In fact, sounds like (reverse lisp)... or lisp reverse to be precise...
The final chapter of Let Over Lambda is about Lisp and Forth. Pretty
interesting ideas there, you should check it out if you are interested in Forth.
Tamas
On May 5, 10:22 pm, Tamas K Papp <······@gmail.com> wrote:
> The final chapter of Let Over Lambda is about Lisp and Forth. Pretty
> interesting ideas there, you should check it out if you are interested in Forth.
http://letoverlambda.com/
Cool! Cool choice of recursive acronym as well... :)
<··················@gmail.com> wrote:
+---------------
| (defun symbol-tree<-list-tree (symbol-tree)
| (list-tree<-id-tree (id-tree<-object-tree (object-tree<-symbol-tree
| symbol-tree))))
|
| I start with a 'symbol tree' and I end up with a 'list tree'.
| The program actually flows from right to left and bottom to top, so i
| read it like that.
+---------------
If that bothers you, you can do your own manual A-normalization
[equivalent to SSA, in this particular case] using LET*:
(defun symbol-tree<-list-tree (symbol-tree)
(let* ((obj-tree (object-tree<-symbol-tree symbol-tree))
(id-tree (id-tree<-object-tree obj-tree))
(list-tree (list-tree<-id-tree id-tree)))
list-tree))
Hmmm... That makes it clear the function should have been named
either LIST-TREE<-SYMBOL-TREE or SYMBOL-TREE->LIST-TREE or maybe
just SYMBOL-TREE-TO-LIST-TREE. ;-}
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On May 4, 7:37 pm, Tamas K Papp <······@gmail.com> wrote:
> On Mon, 04 May 2009 09:03:24 -0700, namekuseijin wrote:
> > Everything is always just a SMOP in CL. I fear that when the need for
> > SMOPs abound, perhaps it is time for a new revision for the language?
> > C++ is getting a new one just about now and it's coming with plenty of
> > good stuff. Including lambdas, can you imagine? o_O
>
> I don't see how a revision would benefit you more than just loading a
> library, especially given the high cost of revisions.
>
> I think a revision is warranted when the language is so constraining
> that you just cannot implement things as a library. Even though CL
> has some constraints, they are the most lax of all languages I know
> and give you lots of freedom.
>
> As the examples show, pattern matching is something you can do just
> fine in a library, so I don't see the point of asking for a revision
> to the language.
>
> It is amazing though that this question crops up so often on c.l.l,
> people argue that certain libraries/features need to be made
> "standard", so they would be spared the expense of downloading &
> loading the relevant library. Perhaps the reason is that ASDF, the
> prevalent distribution/management system for libraries, has a lot of
> flaws. But replacements are in progress.
>
> Tamas
This is really amazing. I've been disconnected for less than a week
and look how this topic got dragged all over the place. About a dozens
different arguments interlinked into each other, most of them not at
all related to the original post. Newlisp and Clojure proponents
taking every opportunity to advertise their Lisp and getting accused
of it. Common Lisp people looking down on everybody else, thinking
that CL and Lisp are synonyms and CL is the last word... And the most
amazing thing is that this is typical...
As I've said before, I'm new to Lisp, and I'm learning slowly, because
I have very little free time. But I'm not new to programming - that's
my job. Problem is, I seem to come from a different background than
most of the people who post on this group. I've been working in
different software companies for the last 10 years making products for
end users. But many of you (especially the most active ones) seems to
have a very different experience - academia, consulting, big custom
projects, web programming... All these areas are very different from
the situation when you are providing a product, instead of a solution
(*). So it seems to me that most of the time most of you don't think
at all about the end user, the one without whom almost no software
would exist...
Someone said on this thread, that he felt that Python was not made for
programmers, that it was made for secretaries and scientists (I can't
see how on earth these two groups got lumped together, but that's
another story). And a number of people said that the CL standard does
not need updating, because it permits all kinds of new features and
paradigms to be seamlessly integrated into the language. And recently,
when I posted a question about building native deliverables that don't
include things that are not used, several people explained to me that
I'm wrong to want this, because the user would benefit from having a
REPL (who, the secretary???, or am I forbidden to target mortals with
software written in Lisp???), and I would benefit from having it in
the customer's installation of my product too... All examples of this
"solution-centric" thinking...
And what is worse, these same people regard the language as a solution
instead of a product too. They find it normal that every programmer
should find the CL implementation and set of libraries most suitable
for him/her through trial and error... But what is the benefit of
every new user of CL needing to go through a painful period of feeling
lost and frustrated? And is it efficient when every programmer has his/
her own custom development environment, and then everyone else needs
to duplicate it (or parts of it) to be able to use code created by the
first programmer? I think that everybody would agree that the most
important virtue of a programming language is to make programming
EASY. That's what makes Lisp's extensibility so valuable - it makes
programming easy. And having to hunt for libraries makes it HARD... or
at least a little bit harder. Having been used to Windows (like many
younger programmers), and coming to a place where Emacs is the best
choice makes things a bit harder too. The fact that common-lisp.net
and CLiki are not very friendly adds another frustration to the pile.
And then getting accused that you "just don't get it" (or more bluntly
that you are plain wrong) when you share your frustration here can be
the last drop which drives you away from CL and Lisp in general...
I like Common Lisp, I really do. In the last couple of years I was
growing more and more frustrated with the shortcomings of C++ and I
started thinking about what would my perfect programming language look
like. Then I found CL, and it met all my requirements. But I'm afraid
that it is going down with a slow and steady pace, because it is just
very user unfriendly... It is time for the CL community to realize
that programmers are users too, and make CL a nicer place. Apparently
a lot of you have both the depth of knowledge and the programming
experience necessary. Just start a civil discussion and try to agree
on a "recommended set of libraries" out of the existing ones. Not an
expensive, years-consuming standard update, just a list of portable,
well supported libraries. Put this list where it is hard to be missed.
Write some tutorials based on these libraries... Do this, and CL will
be much more appealing to newcomers like me. And who knows, maybe even
some of you will find that this makes CL a better experience for you
too...
Now, I expect some people will ask me who am I to tell you what to do.
Well, of course, all of this is just my opinion, but if I'm not
mistaken, other people have said the same things before me. So maybe
there is at least some truth in what I've said. Think about it.
* By "solution", I mean software which solves the specific problem of
a single customer, and by "product", I mean software which is used
out of the box by many unrelated users.
On May 5, 10:23 pm, MishoM <···············@gmail.com> wrote:
Generally in a small-ish community, it's best to have a go at
something. This is the trade-off I guess. With Python or Ruby, others
may have already done much of the hard work so everyone benefits. With
CL you may need to get your hands a little dirty first. If you think
the language is worth it, and you seem to, then this can be quite
rewarding.
I agree that getting a decent set of libraries together and pointing
people at them is a good idea. I've had a rather timid attempt at this
with the most recent release of my own software. I was quite
conservative and only supplied about a dozen libraries but people have
generally found this useful and the number of downloads increased as a
result. Even if nobody uses the stupid editor, at least it's an easy
way to get a Lisp up and running with some libraries. Give it a try,
it may help you to build something of your own, perhaps with emacs. Or
feel free to do some testing of different libraries to see which are
good candidates for cross-compiler-cross-platform inclusion in the
list.
> So it seems to me that most of the time most of you don't think
> at all about the end user, the one without whom almost no software
> would exist...
I do and while I don't get to do anywhere near enough of it in Lisp, I
sneak it in where I can, usually in order to get stuff done faster
than with the mandated "day job languages". Server side "batch"
processes are a safe, albeit unglamorous, bet. I admit that I've yet
to put a commercial application on a users desktop written in Lisp but
I bet others on here have. And I know people have delivered end-user
web applications written in CL too.
> And recently, when I posted a question about building native deliverables that don't
> include things that are not used, several people explained to me that
> I'm wrong to want this
...and several of us gave you answers on how to go about doing this!
Unfortunately there was no free way to do exactly what you wanted so
you were frustrated.
As to telling you that you were wrong to want to do this: you'll find
in the Lisp world that there are a lot of smart people who might be
inquisitive about what you're trying to do and by finding out more,
might be able to offer you a better solution to your problem than you
would have come up with on your own. You may not always agree with the
ideas but it's worth a listen!
--
Phil
http://phil.nullable.eu/
On May 6, 1:56 am, Phil Armitage <···············@gmail.com> wrote:
> I agree that getting a decent set of libraries together and pointing
> people at them is a good idea. I've had a rather timid attempt at this
> with the most recent release of my own software. I was quite
> conservative and only supplied about a dozen libraries but people have
> generally found this useful and the number of downloads increased as a
> result. Even if nobody uses the stupid editor, at least it's an easy
> way to get a Lisp up and running with some libraries. Give it a try,
> it may help you to build something of your own, perhaps with emacs. Or
> feel free to do some testing of different libraries to see which are
> good candidates for cross-compiler-cross-platform inclusion in the
> list.
I gave ABLE a try and I really appreciate the effort you put into it.
I'm just too used to menus and mouse interaction and a tabbed
interface to make the transition to a more emacs style editor, so I'm
currently using LispIDE. Still, I find what you have done really
admirable. The problem is that I don't see many other people doing
what you have done (with the notable exception of the McCLIM project,
but it seems it was never meant to be OS portable, so they are having
a lot of trouble porting it now).
> > And recently, when I posted a question about building native deliverables that don't
> > include things that are not used, several people explained to me that
> > I'm wrong to want this
>
> ...and several of us gave you answers on how to go about doing this!
> Unfortunately there was no free way to do exactly what you wanted so
> you were frustrated.
That's true, and I appreciate all suggestions that I received. But
there were many answers saying that it is a stupid idea to want this
at all.
> As to telling you that you were wrong to want to do this: you'll find
> in the Lisp world that there are a lot of smart people who might be
> inquisitive about what you're trying to do and by finding out more,
> might be able to offer you a better solution to your problem than you
> would have come up with on your own. You may not always agree with the
> ideas but it's worth a listen!
That's also true. I didn't mean to say that there are no helpful,
friendly people on c.l.l. I've received a lot of useful answers to my
questions. What I mean is, there are too many of the experienced
lispers who refuse to consider the possibility that there is something
wrong going on.
I think that some joint efforts to make CL more welcoming are needed.
Just compare SBCL, CLISP, etc. with DrScheme...
>
> --
> Philhttp://phil.nullable.eu/
If your main itch is ASDF or ASDF-INSTALL, or something, there is:
* http://mudballs.com/
* http://common-lisp.net/project/xcvb/
..and maybe other efforts.
Creating executables; http://www.cliki.net/Creating%20Executables Ok,
so there is often no tree-shaking for reasons mentioned. However, I
don't care as a SBCL core compressed with bzip2 is about 10MB. If you
still care, you know what to look for.
Oh, and distributing a core dump does not mean throwing a REPL in the
face of your users ... .. . whatever.
MishoM wrote:
> my job. Problem is, I seem to come from a different background than
> most of the people who post on this group. I've been working in
> different software companies for the last 10 years making products for
> end users. But many of you (especially the most active ones) seems to
> have a very different experience - academia, consulting, big custom
> projects, web programming... All these areas are very different from
> the situation when you are providing a product, instead of a solution
> (*). So it seems to me that most of the time most of you don't think
> at all about the end user, the one without whom almost no software
> would exist...
I do think of end users all day at work, in a proprietary Microsoft SQL
Server environment. My solutions are my products.
I'm an end user of Lisp (Scheme to be exact) and I don't have that many
complaints, just a feel that it could get better.
> Someone said on this thread, that he felt that Python was not made for
> programmers, that it was made for secretaries and scientists (I can't
> see how on earth these two groups got lumped together, but that's
> another story).
As in "they are both non-programmers". It's an amusing quote anyway,
since Lisp, and Fortran at the time, were largely sold as programming
languages to mere mortals. Python and others have come to be even
simpler and more readily accessible than the original high level
languages for mere mortals though. Even more than Basic BTW.
Doing more with less typing, at the cost of performance or sheer
flexibility.
> And what is worse, these same people regard the language as a solution
> instead of a product too. They find it normal that every programmer
> should find the CL implementation and set of libraries most suitable
> for him/her through trial and error... But what is the benefit of
> every new user of CL needing to go through a painful period of feeling
> lost and frustrated? And is it efficient when every programmer has his/
> her own custom development environment, and then everyone else needs
> to duplicate it (or parts of it) to be able to use code created by the
> first programmer?
Had you just replaced CL with Java, I'd say it's spot on. Trying to
replicate a large Eclipse environment in someone else's machine from
scratch to even begin developing anything in a common repository is a
whole lot of work. Download and install this and that framework, find
out and configure a whole bunch of xml's, try to make it work etc...
I'd say the only "happy" programmers are those that go with a
whole-stack Microsoft *solution* and get a full-blown VS environment
with everything builtin to access Microsoft VSS repositories and
Microsoft SQL Server environments using Microsoft ASP.NET to generate
webpages. There, just sign the check, hit next,next,next and our
wizards will guide you by Heaven until the next upgrade cycle or if you
replace one of the solutions in the stack for an unsupported
non-Microsoft equivalent...
> I think that everybody would agree that the most
> important virtue of a programming language is to make programming
> EASY.
Sure.
> And having to hunt for libraries makes it HARD... or
Welcome to a world without solutions from a single provider. Python
suffers from that too.
> I like Common Lisp, I really do. In the last couple of years I was
> growing more and more frustrated with the shortcomings of C++ and I
> started thinking about what would my perfect programming language look
> like. Then I found CL, and it met all my requirements. But I'm afraid
> that it is going down with a slow and steady pace, because it is just
> very user unfriendly... It is time for the CL community to realize
> that programmers are users too, and make CL a nicer place. Apparently
> a lot of you have both the depth of knowledge and the programming
> experience necessary. Just start a civil discussion and try to agree
> on a "recommended set of libraries" out of the existing ones. Not an
> expensive, years-consuming standard update, just a list of portable,
> well supported libraries. Put this list where it is hard to be missed.
> Write some tutorials based on these libraries... Do this, and CL will
> be much more appealing to newcomers like me. And who knows, maybe even
> some of you will find that this makes CL a better experience for you
> too...
Have you tried Allegro? I mean, surely it's as worthy, complete,
commercially-supported and wizard-guided CL environment as your probable
Visual Studio solution from Microsoft.
That said, I think CL has plenty of libs, perhaps what you're asking for
is just a better package management system for it. And a free Lisp IDE
rather than Emacs? Ever heard of CUSP?
http://www.bitfauna.com/projects/cusp/cusp.htm
On May 6, 5:03 am, namekuseijin <···················@gmail.com> wrote:
>
> I do think of end users all day at work, in a proprietary Microsoft SQL
> Server environment. My solutions are my products.
>
> I'm an end user of Lisp (Scheme to be exact) and I don't have that many
> complaints, just a feel that it could get better.
My statements were mostly about CL. I don't know how things are with
Scheme, but from seeing PLT Scheme and having in mind that there is a
living standard that gets updated constantly, I suppose they are much
better.
> > And having to hunt for libraries makes it HARD... or
>
> Welcome to a world without solutions from a single provider. Python
> suffers from that too.
>
C++ doesn't have a single provider either, but the situation is better
there.
>
> Have you tried Allegro? I mean, surely it's as worthy, complete,
> commercially-supported and wizard-guided CL environment as your probable
> Visual Studio solution from Microsoft.
Yes it is. But it seems to me that once you decide to use the more
enhanced features, you are tied to a proprietary development
environment.
> That said, I think CL has plenty of libs, perhaps what you're asking for
> is just a better package management system for it.
No, what I think lacks is information about what libraries are
available, which ones to use, etc. Just browse through CLiki and
you'll encounter a lot of dead links and pages that haven't been
updated for years. And common-lisp.net is just an alphabetical list of
projects - not very helpful.
> And a free Lisp IDE
> rather than Emacs? Ever heard of CUSP?
>
> http://www.bitfauna.com/projects/cusp/cusp.htm
Yes, I've encountered CUSP.
On May 6, 5:49 am, MishoM <···············@gmail.com> wrote:
> On May 6, 5:03 am, namekuseijin <···················@gmail.com> wrote:
> My statements were mostly about CL. I don't know how things are with
> Scheme, but from seeing PLT Scheme and having in mind that there is a
> living standard that gets updated constantly, I suppose they are much
> better.
It's a living standard because different implementors of the many
Schemes out there quite never agree on all subjects and when they do,
they leave enough bits underspecified to ensue lots of fights over non-
portable libs so that a new figh... I mean, standardization effort is
put again into motion...
> > > And having to hunt for libraries makes it HARD... or
>
> > Welcome to a world without solutions from a single provider. Python
> > suffers from that too.
>
> C++ doesn't have a single provider either, but the situation is better
> there.
It's better because the whole IT world is built onto C/C++, including
your OS whatever it is.
> > Have you tried Allegro? I mean, surely it's as worthy, complete,
> > commercially-supported and wizard-guided CL environment as your probable
> > Visual Studio solution from Microsoft.
>
> Yes it is. But it seems to me that once you decide to use the more
> enhanced features, you are tied to a proprietary development
> environment.
Yeah, welcome to the Microsoft way of life. ;)
> > That said, I think CL has plenty of libs, perhaps what you're asking for
> > is just a better package management system for it.
>
> No, what I think lacks is information about what libraries are
> available, which ones to use, etc.
Which libs are available to C++? Which one to use? Unless, you just
use what comes with your IDE or OS, it's pretty much the same
situation, except there are much, much more C/C++ libs available than
will ever be for Lisp. How does one not get confused with that?
Perhaps what you are lacking is a common hub? For me, the easiest way
to check out whatever I can do with C/C++ is to look what headers are
available at /usr/include/* and then lookup in the web if no
functionality is there.
What would be the CL equivalent? CL too must have libs in particular
directories and it too has web hubs for looking up libs.
> Just browse through CLiki and
> you'll encounter a lot of dead links and pages that haven't been
> updated for years. And common-lisp.net is just an alphabetical list of
> projects - not very helpful.
Google is your friend.
CL the language has not been updated for years! Most surely it runs
ancient code. :)
MishoM <···············@gmail.com> writes:
> On May 6, 5:03�am, namekuseijin <···················@gmail.com> wrote:
>>
>> I do think of end users all day at work, in a proprietary Microsoft SQL
>> Server environment. �My solutions are my products.
>>
>> I'm an end user of Lisp (Scheme to be exact) and I don't have that many
>> complaints, just a feel that it could get better.
>
> My statements were mostly about CL. I don't know how things are with
> Scheme, but from seeing PLT Scheme and having in mind that there is a
> living standard that gets updated constantly, I suppose they are much
> better.
>
>> > And having to hunt for libraries makes it HARD... or
>>
>> Welcome to a world without solutions from a single provider. Python
>> suffers from that too.
>>
>
> C++ doesn't have a single provider either, but the situation is better
> there.
Worse. If there's not a lot of choice of libraries, or even worse, if
there are libraries so proeminent that customers or PHB impose them
and prevent to write your own library better adapted to the current
development. Having proeminent libraries is not a good thing, IMO.
>> Have you tried Allegro? �I mean, surely it's as worthy, complete,
>> commercially-supported and wizard-guided CL environment as your probable
>> � Visual Studio solution from Microsoft.
>
> Yes it is. But it seems to me that once you decide to use the more
> enhanced features, you are tied to a proprietary development
> environment.
>
>> That said, I think CL has plenty of libs, perhaps what you're asking for
>> is just a better package management system for it.
>
> No, what I think lacks is information about what libraries are
> available, which ones to use, etc. Just browse through CLiki and
> you'll encounter a lot of dead links and pages that haven't been
> updated for years.
Why are you complaining here? Cliki is a WIKI! It is up to *YOU* to
update the dead links.
And why do you complain about pages that have not been updated for
years: this just indicates that the corresponding library have be
_stable_ for a long time. It's a guarantee of quality.
> And common-lisp.net is just an alphabetical list of
> projects - not very helpful.
It's more than that, it's a "sourceforge" for lisp projects.
But nobody prevents you to make a hierarchical directory of
common-lisp.net projects. You may do that on cliki.net, or write your
own web site.
--
__Pascal Bourguignon__
On May 6, 12:33 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> MishoM <···············@gmail.com> writes:
> > On May 6, 5:03 am, namekuseijin <···················@gmail.com> wrote:
>
> >> I do think of end users all day at work, in a proprietary Microsoft SQL
> >> Server environment. My solutions are my products.
>
> >> I'm an end user of Lisp (Scheme to be exact) and I don't have that many
> >> complaints, just a feel that it could get better.
>
> > My statements were mostly about CL. I don't know how things are with
> > Scheme, but from seeing PLT Scheme and having in mind that there is a
> > living standard that gets updated constantly, I suppose they are much
> > better.
>
> >> > And having to hunt for libraries makes it HARD... or
>
> >> Welcome to a world without solutions from a single provider. Python
> >> suffers from that too.
>
> > C++ doesn't have a single provider either, but the situation is better
> > there.
>
> Worse. If there's not a lot of choice of libraries, or even worse, if
> there are libraries so proeminent that customers or PHB impose them
> and prevent to write your own library better adapted to the current
> development. Having proeminent libraries is not a good thing, IMO.
>
> >> Have you tried Allegro? I mean, surely it's as worthy, complete,
> >> commercially-supported and wizard-guided CL environment as your probable
> >> Visual Studio solution from Microsoft.
>
> > Yes it is. But it seems to me that once you decide to use the more
> > enhanced features, you are tied to a proprietary development
> > environment.
>
> >> That said, I think CL has plenty of libs, perhaps what you're asking for
> >> is just a better package management system for it.
>
> > No, what I think lacks is information about what libraries are
> > available, which ones to use, etc. Just browse through CLiki and
> > you'll encounter a lot of dead links and pages that haven't been
> > updated for years.
>
> Why are you complaining here? Cliki is a WIKI! It is up to *YOU* to
> update the dead links.
>
> And why do you complain about pages that have not been updated for
> years: this just indicates that the corresponding library have be
> _stable_ for a long time. It's a guarantee of quality.
>
> > And common-lisp.net is just an alphabetical list of
> > projects - not very helpful.
>
> It's more than that, it's a "sourceforge" for lisp projects.
>
> But nobody prevents you to make a hierarchical directory of
> common-lisp.net projects. You may do that on cliki.net, or write your
> own web site.
>
> --
> __Pascal Bourguignon__
Missing the point again. I'm talking about the situation of a newbie
who wants to start using CL. It's unreasonable to leave it to such
people to _provide_ the things that would make it easier for them to
get started, because they need to get started before they can provide
these things. And about CLiki being a Wiki - I know that, but I kind
of expect the project pages to be updated by the people who do the
projects, because they have the most information. And common-lisp.net
being like sourceforge - it provides hosting and collaboration
facilities, but have you looked at the interface sourceforge provides
to _users_ of the hosted projects?
Bottom line - I understand that experienced CL users are probably
perfectly happy with the situation, but try to see it from the
perspective of a newbie.
On May 6, 6:02 am, MishoM <···············@gmail.com> wrote:
[...]
> I'm talking about the situation of a newbie who wants to start
> using CL.
How much expertise and experience does it take to note on a Wiki page
that a link is deader than disco?
> It's unreasonable to leave it to such people to _provide_ the things
> that would make it easier for them to get started, because they need
> to get started before they can provide these things.
That's an extremely common set-up in the world of open source
software, though. People will usually contribute to projects for one
of two reasons:
1) It's their job.
2) They want to use the product, and need it to be better.
You, as a newbie, fall into camp 2.
File bug reports. Note dead links. Hassle maintainers on mailing
lists. Keep notes that you can turn into FAQs and documentation.
[...]
> Bottom line - I understand that experienced CL users are probably
> perfectly happy with the situation, but try to see it from the
> perspective of a newbie.
That's not that hard. I only started with Common Lisp 3 years ago. I
suppose I had/have one significant advantage over other newbies, in
that I had been using Emacs for a lot of years and thus wasn't scared
off by SLIME[1]. But I simply didn't have the sort of trouble you've
described here.
Two things really helped:
1) I started in on a project and went looking for libraries as I
needed them instead of looking for libraries and starting in on a
project.
2) When I asked people here and on IRC how to do things, and they told
me that I was solving the wrong problem, I believed them.
Anyway, you're solving the wrong problem now. You're trying to
convince people that the newbie experience sucks instead of trying to
improve the newbie experience.
Cheers,
Pillsy
[1] Though I somehow managed not to learn any Lisp beyond "setq" in
the course of a decade!
MishoM <···············@gmail.com> writes:
> And common-lisp.net
> being like sourceforge - it provides hosting and collaboration
> facilities, but have you looked at the interface sourceforge provides
> to _users_ of the hosted projects?
Well, I didn't compare both, but I'll just note that sourceforge user
interface worsened when they improved the features and stability. I
find it harder now to get the files or the documentation on
sourceforge than it was a few years ago.
> Bottom line - I understand that experienced CL users are probably
> perfectly happy with the situation, but try to see it from the
> perspective of a newbie.
Of course, the newbie cannot correct cliki while he's newbie. But
he's the best placed to note what's wrong with it, and to come back
when he's not newbie anymore to correct it.
It's the same everywhere, when you're new in an enterprise, you get to
read the internal wiki, and use it to find the information needed to
integrate. Your first job is exactly to do that, and to update the
wiki and documentations, because you're the only one with a fresh
point of view able to correct it to improve newbie experience.
--
__Pascal Bourguignon__
From: Pascal J. Bourguignon
Subject: Re: CL-UNIFICATION as a library (Re: Qi Seems Great)
Date:
Message-ID: <87ljpb42vk.fsf@galatea.local>
MishoM <···············@gmail.com> writes:
> [... the classical newbie rant ...]
You don't get it. You are plain wrong. And what's more, you're a
"salaud" in Sartre's meaning, (ie. you're a cinical bitch) because
you're asking things of Common Lisp that you don't expect of C.
C doesn't come with pre-installed libraries.
C doesn't come with userfriendly IDE.
C libraries don't come with better written documentation.
C users don't ask for a "recommended set of libraries".
(And when I write "C", I mean actually any other programming language.)
So if you are really interested in Common Lisp, and find its
implementations lacking in some aspect, you're just welcome to start
working and writing code, documentation or integrating a preconfigured
user friendly development environment.
Others have been doing that, as much as their resources allowed, so
you are not entitled to any complain here.
--
__Pascal Bourguignon__
On May 6, 1:10 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> > [... the classical newbie rant ...]
If it's classical, then maybe there is something true to it, don't you
think?
> You don't get it. You are plain wrong. And what's more, you're a
> "salaud" in Sartre's meaning, (ie. you're a cinical bitch) because
> you're asking things of Common Lisp that you don't expect of C.
Well, let's compare it with C++, with which I have most experience...
(BTW, very good use of sarcasm, it's clear that you've had a lot of
practice...)
> C++ doesn't come with pre-installed libraries.
C++ comes with the runtime library and STL, just like CL comes with
the 900 something operators defined by the standard. Many
distributions (including free ones) come with other preinstalled
libraries for GUI, graphics, etc (see below for an example).
> C++ doesn't come with userfriendly IDE.
There is a number of very good user-friendly IDEs for C++. I use
Code::Blocks, which is completely free. The Windows version includes
the gcc compiler and the gdb debuger, the MingW library for Windows, a
number of other libraries (for example wxWidgets), and a number of
wizards for fast generation of application templates. Supports syntax
highlighting, automatic indentation, etc. Works out of the box. There
are other high-quality free IDEs also.
> C++ libraries don't come with better written documentation.
The runtime library and STL are extremely well documented but so is
the ANSI CL standard. The documentation of the Boost libraries (the de-
facto replacement of both the runtime and STL) is not as good, but is
also quite helpful - the main reason it's not complete is that the
libraries are still under active development. Other popular libraries
tend to have not only good documentation, but also numerous books
written on them.
> C++ users don't ask for a "recommended set of libraries".
Because they don't have to. They often have all that they need at
their disposal. And when they need to solve a specific task, it's
usually easy to find the generally accepted library for the task. And
the Boost library is so "recommended" that it became the main reason
for the new C++ standard.
> So if you are really interested in Common Lisp, and find its
> implementations lacking in some aspect, you're just welcome to start
> working and writing code, documentation or integrating a preconfigured
> user friendly development environment.
What I find lacking is not as much a specific feature or library, as
attitude. I may be wrong, but I get the impression of an "if they need
it, they'll do/find it themselves" attitude prevailing in the
community.
> Others have been doing that, as much as their resources allowed, so
> you are not entitled to any complain here.
I admit there are some attempts, but it seems to me that they don't
get much support. Most of them are single-person efforts. They are
also usually Linux or Mac oriented, but that's another story.
And I'm not complaining. I don't expect people to do my work for me.
I'm just saying that in my opinion the efforts that exist could
benefit from a shift in target.
Though I still have very little experience with CL, I'd contribute as
much as I could, if I found anything to contribute to. And if I write
a library that I think is worth sharing, I'll definitely do so. But
there must be some joint effort in order to produce anything that
would change the state of things.
> --
> __Pascal Bourguignon__
On May 5, 8:24 pm, MishoM <···············@gmail.com> wrote:
> On May 6, 1:10 am, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>
> > > [... the classical newbie rant ...]
>
> If it's classical, then maybe there is something true to it, don't you
> think?
>
There is something true to it.
> > You don't get it. You are plain wrong. And what's more, you're a
> > "salaud" in Sartre's meaning, (i.e. you're a cynical bitch) because
> > you're asking things of Common Lisp that you don't expect of C.
>
> Well, let's compare it with C++, with which I have most experience...
> (BTW, very good use of sarcasm, it's clear that you've had a lot of
> practice...)
>
> > C++ doesn't come with pre-installed libraries.
>
> C++ comes with the runtime library and STL, just like CL comes with
> the 900 something operators defined by the standard. Many
> distributions (including free ones) come with other preinstalled
> libraries for GUI, graphics, etc (see below for an example).
>
/Distributions/
> > C++ doesn't come with userfriendly IDE.
>
> There is a number of very good user-friendly IDEs for C++. I use
> Code::Blocks, which is completely free. The Windows version includes
> the gcc compiler and the gdb debuger, the MingW library for Windows, a
> number of other libraries (for example wxWidgets), and a number of
> wizards for fast generation of application templates. Supports syntax
> highlighting, automatic indentation, etc. Works out of the box. There
> are other high-quality free IDEs also.
>
I like emacs and slime (?) I mean, you have to realize that C++ has
had a LOT more money poured into its development than CL has.
> > C++ libraries don't come with better written documentation.
>
> The runtime library and STL are extremely well documented but so is
> the ANSI CL standard. The documentation of the Boost libraries (the de-
> facto replacement of both the runtime and STL) is not as good, but is
> also quite helpful - the main reason it's not complete is that the
> libraries are still under active development. Other popular libraries
> tend to have not only good documentation, but also numerous books
> written on them.
I agree that documentation is lacking in a lot of CL libraries, but
again, we aren't comparing apples and apples here...
>
> > C++ users don't ask for a "recommended set of libraries".
>
> Because they don't have to. They often have all that they need at
> their disposal. And when they need to solve a specific task, it's
> usually easy to find the generally accepted library for the task. And
> the Boost library is so "recommended" that it became the main reason
> for the new C++ standard.
>
http://www.boost.org/community/
I'd like to see a CL library that has had more than a dozen people
working on it, let alone 'thousands'. CL is a powerful language, but
thus far, the establishment has spoken.
> > So if you are really interested in Common Lisp, and find its
> > implementations lacking in some aspect, you're just welcome to start
> > working and writing code, documentation or integrating a preconfigured
> > user friendly development environment.
>
> What I find lacking is not as much a specific feature or library, as
> attitude. I may be wrong, but I get the impression of an "if they need
> it, they'll do/find it themselves" attitude prevailing in the
> community.
>
Because that's generally how things get done in CL.
If no one has done it, you do it yourself.
> > Others have been doing that, as much as their resources allowed, so
> > you are not entitled to any complain here.
>
> I admit there are some attempts, but it seems to me that they don't
> get much support. Most of them are single-person efforts. They are
> also usually Linux or Mac oriented, but that's another story.
>
Well you can complain about it or you can do something about it ;-)
> And I'm not complaining. I don't expect people to do my work for me.
> I'm just saying that in my opinion the efforts that exist could
> benefit from a shift in target.
Sorry, it seemed like complaining, my mistake! :-P
They could also benefit from an influx of programmers and funding.
Perhaps one of us could win the lottery?
> Though I still have very little experience with CL, I'd contribute as
> much as I could, if I found anything to contribute to. And if I write
> a library that I think is worth sharing, I'll definitely do so. But
> there must be some joint effort in order to produce anything that
> would change the state of things.
That's a good sentiment.
I think the most important thing to do is RTFM on any library you
download (sometimes the manual is the code itself...), Linux+SBCL+ASDF
are a powerful and fairly easy way to install libraries (but you do
have to do some research before you download).
And hack code. Hack lots of code. Find something you'd like to help
with and just hack it.
From: Frank GOENNINGER
Subject: Re: Newbie attitudes... WAS: CL-UNIFICATION as a library (Re: Qi Seems Great)
Date:
Message-ID: <m24ovyljsa.fsf_-_@goenninger.net>
Sorry, had to change the subject. This is so non-unification...
··················@gmail.com writes:
> On May 5, 8:24�pm, MishoM <···············@gmail.com> wrote:
>> On May 6, 1:10�am, ····@informatimago.com (Pascal J. Bourguignon)
>> wrote:
>>
>> > > [... the classical newbie rant ...]
>>
>> If it's classical, then maybe there is something true to it, don't you
>> think?
>>
>
> There is something true to it.
Hehe, yes: That MishoM is a newbie. And that's about it.
Remember: We all have been newbies once. What might be different with us
old farts is that we first went to read every book available on the
subject and wrote some considerable amount of code before we started to
put out strong statements about everybody else.
> And hack code. Hack lots of code. Find something you'd like to help
> with and just hack it.
Yep, that's the one thing I support also. When you barely have time to
read c.l.l then you do the right amount of coding ...
Cheers
Frank
On Tue, 05 May 2009 17:24:27 -0700, MishoM wrote:
> On May 6, 1:10 am, ····@informatimago.com (Pascal J. Bourguignon) wrote:
>
>> > [... the classical newbie rant ...]
>
> If it's classical, then maybe there is something true to it, don't you
> think?
Non sequitur.
> What I find lacking is not as much a specific feature or library, as
> attitude. I may be wrong, but I get the impression of an "if they need
> it, they'll do/find it themselves" attitude prevailing in the community.
I am a newbie, and I got a lot of help. When people see that you are
putting in some effort, they will help you. Meta-discussions about
the attitude of CL'ers will not get you far, though.
> And I'm not complaining. I don't expect people to do my work for me. I'm
> just saying that in my opinion the efforts that exist could benefit from
> a shift in target.
Well, unless you start paying them, people are just going to work on
what interests them, so I don't see how you can make "shifts in the
target".
> Though I still have very little experience with CL, I'd contribute as
> much as I could, if I found anything to contribute to. And if I write a
> library that I think is worth sharing, I'll definitely do so. But there
> must be some joint effort in order to produce anything that would change
> the state of things.
There are plenty of libraries you can contribute to, the authors are
usually happy to accept contributions. People do cooperate, perhaps a
bit less than in other communities, but there are exceptions. Just
find something that you think could benefit from improvement, and
start coding.
Tamas
From: Pascal J. Bourguignon
Subject: Re: CL-UNIFICATION as a library (Re: Qi Seems Great)
Date:
Message-ID: <87eiv24voi.fsf@galatea.local>
MishoM <···············@gmail.com> writes:
> Well, let's compare it with C++, with which I have most experience...
> (BTW, very good use of sarcasm, it's clear that you've had a lot of
> practice...)
>
>> C++ doesn't come with pre-installed libraries.
>
> C++ comes with the runtime library and STL, just like CL comes with
> the 900 something operators defined by the standard. Many
> distributions (including free ones) come with other preinstalled
> libraries for GUI, graphics, etc (see below for an example).
Distributions are not C++.
Why do you complain about CL?
Try the LispBox and complain about it!
--
__Pascal Bourguignon__
On May 6, 9:01 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> MishoM <···············@gmail.com> writes:
> > Well, let's compare it with C++, with which I have most experience...
> > (BTW, very good use of sarcasm, it's clear that you've had a lot of
> > practice...)
>
> >> C++ doesn't come with pre-installed libraries.
>
> > C++ comes with the runtime library and STL, just like CL comes with
> > the 900 something operators defined by the standard. Many
> > distributions (including free ones) come with other preinstalled
> > libraries for GUI, graphics, etc (see below for an example).
>
> Distributions are not C++.
>
> Why do you complain about CL?
> Try the LispBox and complain about it!
>
> --
> __Pascal Bourguignon__
You are missing the point. I'm not talking about the CL standard. I'm
talking about using CL, which of course means I'm talking about
available CL distributions and CL IDEs and comparing them to C++
distributions and available C++ IDEs. I'm also talking about CL
libraries and comparing their availability and documentation to the
availability and documentation of C++ libraries. And I'm only doing
this comparison to address your claims that I'm expecting thinks from
CL, which I don't expect from another language. You couldn't be more
wrong - this are things that I've come to take for granted.
And the point is not that I'm bitching about me expecting this things
and not finding them - the point is that there are probably many
people like me, who are used to taking them for granted, but unlike me
they will give up after the first contact. They'll read some of PCL or
some other introduction, get enthusiastic, and then they'll try to use
CL to do that side project they had in mind for some time, and planned
to do in language X. And they'll feel at a loss and after some
struggling they'll get back to what they are accustomed to. Because
most people just won't make the transition to something new, if there
are too many obstacles. That's why I'm saying that CL is not friendly
to newcomers.
On Wed, 06 May 2009 02:20:49 -0700, MishoM wrote:
> And the point is not that I'm bitching about me expecting this things
> and not finding them - the point is that there are probably many people
> like me, who are used to taking them for granted, but unlike me they
> will give up after the first contact. They'll read some of PCL or some
> other introduction, get enthusiastic, and then they'll try to use CL to
> do that side project they had in mind for some time, and planned to do
> in language X. And they'll feel at a loss and after some struggling
> they'll get back to what they are accustomed to. Because most people
> just won't make the transition to something new, if there are too many
> obstacles. That's why I'm saying that CL is not friendly to newcomers.
Maybe CL is not friendly to lazy or clueless people. I can live with
that.
I started reading PCL as a newbie, and then decided to install a CL
implementation. After about 20 minutes, I was already coding in
CMUCL, using SLIME as an IDE.
The amount of time you have spent whining here could have been used to
do something productive in CL. Maybe computers are just not your
thing.
Tamas
On May 6, 7:36 am, Tamas K Papp <······@gmail.com> wrote:
[...]
> Maybe CL is not friendly to lazy or clueless people. I can live with
> that.
On the contrary, CL is exceptionally friendly to lazy and clueless
people. The REPL, the debugging capabilities and general safety of the
language, garbage collection and macros all add up to a language that
forgives cluelessness and often actively rewards laziness.
What it's not so good for is dipping into it momentarily to find a
cookbook solution that will let you glue a bunch of existing crap
together. And I'm beginning to think a lot of that is just a lack of
available cookbook solutions.
Cheers,
Pillsy
On May 6, 4:36 am, Tamas K Papp <······@gmail.com> wrote:
>
> The amount of time you have spent whining here could have been used to
> do something productive in CL. Maybe computers are just not your
> thing.
The amount of time you spent going out of your way to insult MishoM
could have been spent doing something productive to ameliorate the
problem he is encountering. Maybe humans are just not your thing.
-- Scott
From: Frank GOENNINGER
Subject: Re: CL-UNIFICATION as a library (Re: Qi Seems Great)
Date:
Message-ID: <m2fxfeva7m.fsf@goenninger.net>
Scott Burson <········@gmail.com> writes:
> On May 6, 4:36�am, Tamas K Papp <······@gmail.com> wrote:
>>
>> The amount of time you have spent whining here could have been used to
>> do something productive in CL. �Maybe computers are just not your
>> thing.
>
> The amount of time you spent going out of your way to insult MishoM
> could have been spent doing something productive to ameliorate the
> problem he is encountering. Maybe humans are just not your thing.
>
> -- Scott
The amount of time you spent going out of your way to insult TKP
could have been spent doing something productive to ameliorate the
problem he is encountering.
I did not transcribe the last sentence. It may have been too insulting.
Oh. Yeah. Wow. Now let's get back to write apps and libs that we can use
to actually, really attract people to Common Lisp the language.
Frank
Sorry. Couldn't resist.
MishoM <···············@gmail.com> writes:
> On May 6, 9:01�am, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> MishoM <···············@gmail.com> writes:
>> > Well, let's compare it with C++, with which I have most experience...
>> > (BTW, very good use of sarcasm, it's clear that you've had a lot of
>> > practice...)
>>
>> >> C++ doesn't come with pre-installed libraries.
>>
>> > C++ comes with the runtime library and STL, just like CL comes with
>> > the 900 something operators defined by the standard. Many
>> > distributions (including free ones) come with other preinstalled
>> > libraries for GUI, graphics, etc (see below for an example).
>>
>> Distributions are not C++.
>>
>> Why do you complain about CL?
>> Try the LispBox and complain about it!
>>
>> --
>> __Pascal Bourguignon__
>
> You are missing the point. I'm not talking about the CL standard. I'm
> talking about using CL, which of course means I'm talking about
> available CL distributions and CL IDEs and comparing them to C++
> distributions and available C++ IDEs.
You should name names. Apart the commercial distributions, I know of
only one CL distribution: the LispBox.
Why do you talk us about cliki? You should compare the set of
libraries provided by the LispBox with the set of libraries provided
by MS-Windows or MacOSX or ubuntu.
> I'm also talking about CL
> libraries and comparing their availability and documentation to the
> availability and documentation of C++ libraries. And I'm only doing
> this comparison to address your claims that I'm expecting thinks from
> CL, which I don't expect from another language. You couldn't be more
> wrong - this are things that I've come to take for granted.
Let's compare then.
Assuming there's no library in the LispBox to parse XML data,
googling for Lisp library XML gives about 100,000 hits, while
googling for C++ library XML gives about 3 million hits.
Where will I be able to better make a decision choosing a XML library?
Notice that http://www.boost.org/doc/libs/1_39_0 doesn't have any XML
library.
> And the point is not that I'm bitching about me expecting this things
> and not finding them - the point is that there are probably many
> people like me, who are used to taking them for granted,
But you are lying, they cannot take them for granted given that they
are not granted!
If I want to use a xml library on my gentoo distribution, I've must
choose amongst about ten libraries (having "xml" in their name, there
are even more libraries), and I must give commands to instal the one I
choose explicitely.
$ ls -d1 /usr/portage/*lib*/*xml*|grep -v metadata
/usr/portage/dev-libs/dbxml/
/usr/portage/dev-libs/dvxml/
/usr/portage/dev-libs/libwbxml/
/usr/portage/dev-libs/libxml/
/usr/portage/dev-libs/libxml2/
/usr/portage/dev-libs/ltxml/
/usr/portage/dev-libs/mini-xml/
/usr/portage/dev-libs/xmlrpc-c/
/usr/portage/dev-libs/xmlsec/
/usr/portage/dev-libs/xmlwrapp/
/usr/portage/net-libs/libnxml/
/usr/portage/x11-libs/qt-xmlpatterns/
This is exactly the same with CL, http://www.cliki.net/XML list about
the same number of libraries, and you have to give a
(asdf-install:install choosen-library) command to have it installed.
Why would you say that in C++ such a library is taken for granted and
not in Lisp, when there is exactly the same procedure to apply to
choose one and to install it before being able to use?
> but unlike me
> they will give up after the first contact. They'll read some of PCL or
> some other introduction, get enthusiastic, and then they'll try to use
> CL to do that side project they had in mind for some time, and planned
> to do in language X. And they'll feel at a loss and after some
> struggling they'll get back to what they are accustomed to. Because
> most people just won't make the transition to something new, if there
> are too many obstacles. That's why I'm saying that CL is not friendly
> to newcomers.
So you're saying that CL is not friendly to newcomers because you
imagine newcomers are idiots or lazy or both. Sorry, but I don't see
the relationship between what you believe about people and CL.
Perhaps you're extrapolating between what you think you are and these
"newcomers"?
--
__Pascal Bourguignon__
On May 6, 12:59 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> You should name names. Apart the commercial distributions, I know of
> only one CL distribution: the LispBox.
You could say that ABLE is also a CL distribution.
> Assuming there's no library in the LispBox to parse XML data,
> googling for Lisp library XML gives about 100,000 hits, while
> googling for C++ library XML gives about 3 million hits.
> Where will I be able to better make a decision choosing a XML library?
It doesn't matter if google will return 10,000 results or 10,000,000.
You'll only look at the first several pages anyway, so what really
matters is what are the results on the first two or three pages.
> Notice thathttp://www.boost.org/doc/libs/1_39_0doesn't have any XML
> library.
I'm not 100% sure, but I think it does as a subsystem in the
serialization library. Just go to the Boost homepage and search for
XML.
> But you are lying, they cannot take them for granted given that they
> are not granted!
>
> If I want to use a xml library on my gentoo distribution, I've must
> choose amongst about ten libraries (having "xml" in their name, there
> are even more libraries), and I must give commands to instal the one I
> choose explicitely.
> ....
> This is exactly the same with CL,http://www.cliki.net/XMLlist about
> the same number of libraries, and you have to give a
> (asdf-install:install choosen-library) command to have it installed.
>
> Why would you say that in C++ such a library is taken for granted and
> not in Lisp, when there is exactly the same procedure to apply to
> choose one and to install it before being able to use?
>
Under Windows, your first bet would be to search msdn and you'll find
MSXML. If you want something portable, the first three hits of your
google search will give you libxml2 (gnome, so a good bet), Expat and
Xerces. All three sites contain a lot of information. I haven't used
any of them, but I'm pretty confident that you'll be able to get going
in a matter of hours.
When searching for "lisp xml library", I get the CLiki XML page (a
collection of links with one sentence for each), CL-XML (the latest
entry on its page is from 2004 and it says that there are things which
need to be finished), some question answered on stack overflow... I
don't get the feeling of having a safe bet here.
> So you're saying that CL is not friendly to newcomers because you
> imagine newcomers are idiots or lazy or both. Sorry, but I don't see
> the relationship between what you believe about people and CL.
No. I just don't think that making something hard, when it could be
made easy, is rational. Smart people would benefit from being spared
some aggravation as much as stupid ones, or even more.
> Perhaps you're extrapolating between what you think you are and these
> "newcomers"?
Well, if you have to resort to calling me idiot and/or lazy, be my
guest.
> --
> __Pascal Bourguignon__
From: John Thingstad
Subject: Re: CL-UNIFICATION as a library (Re: Qi Seems Great)
Date:
Message-ID: <op.utic6ipgut4oq5@pandora>
På Wed, 06 May 2009 12:40:06 +0200, skrev MishoM
<···············@gmail.com>:
>
> When searching for "lisp xml library", I get the CLiki XML page (a
> collection of links with one sentence for each), CL-XML (the latest
> entry on its page is from 2004 and it says that there are things which
> need to be finished), some question answered on stack overflow... I
> don't get the feeling of having a safe bet here.
>
Actually cxml has seen heavy developement recently. I find it is quite
powerfull.
note:
rel-2008-11-30
particularly:
Add-on features
The following libraries are available as separate downloads:
cxml-rng: Relax NG validation
cxml-stp: STP, an alternative to DOM
Plexippus: XPath 1.0
Xuriella: XSLT 1.0
Closure HTML: parse HTML 4; convert between HTML and XHTML
Available at:
http://common-lisp.net/project/cxml/
Wouldn't it be easier to just ask?
---
For easier installation of the latest sources I use clbuild.
This is only for Linux users.. (maybe cygwin)
http://common-lisp.net/project/clbuild/
So can just write:
./clbuild projects
for a list of available projects
or
./clbuild install cl-ppcre
To install the best regular expression parser, say
---
As for not liking Emacs well have you actually used Emacs with a newer
version of SLIME?
It can be run mostly by point and click.
Say you run a function from the repl and it returns a class object.
If you want to inspect it, just right click on the returned value and
select inspect from the pop-up menu.
If SBCL gives a error you can click on the stack trace to see parameters
for that function.
If the error refers to a part of the standard just click on the reference
and that section opens in your browser.
There is a one page cheat sheet that contains the most useful commands,
but if you want the full story there is a 50 page manual.
I thought I should mention it because, after all SLIME has 20 developers
and over 100 contributors and thus is by far the best supported and most
powerful opensource IDE.
---------------------
John Thingstad
MishoM <···············@gmail.com> writes:
> Under Windows, your first bet would be to search msdn and you'll find
> MSXML. If you want something portable, the first three hits of your
> google search will give you libxml2 (gnome, so a good bet), Expat and
> Xerces. All three sites contain a lot of information. I haven't used
> any of them, but I'm pretty confident that you'll be able to get going
> in a matter of hours.
You keep comparing things that are not comparable, and complaining to
the wrong entity.
When you use Common Lisp, instead of searching MSDN, you'd just use
google, or go directly to a site such as cliki or the Common Lisp
Directory. You'd get the same kind of results, since you'll be
watching only the first few hits.
So if you are complaining because there is no commercial vendor with
95% of the OS/platform market with an interest in documenting and
promoting Lisp libraries, perhaps you should complain to Microsoft and
have THEY add in MSDN documentation about Lisp libraries for their
Visual Common Lisp IDE.
If just go to the website of Franz or Lispworks or some other
commercial Lisp vendor. http://franz.com/ and type XML in the search
box. Click on the second link and search for XML. Notice how there
is only ONE recommended library provided by Franz, pxml to parse XML
data.
> When searching for "lisp xml library", I get the CLiki XML page (a
> collection of links with one sentence for each), CL-XML (the latest
> entry on its page is from 2004 and it says that there are things which
> need to be finished), some question answered on stack overflow... I
> don't get the feeling of having a safe bet here.
Go to Franz, (or Lispworks, or some other commercial Lisp vendor), and
you'll get support and guarantees that their libraries work.
>> So you're saying that CL is not friendly to newcomers because you
>> imagine newcomers are idiots or lazy or both. �Sorry, but I don't see
>> the relationship between what you believe about people and CL.
>
> No. I just don't think that making something hard, when it could be
> made easy, is rational. Smart people would benefit from being spared
> some aggravation as much as stupid ones, or even more.
See, the problem here is that while I'm not specially smart (if I
were, I'd be in a totally different situation), I never had any
difficulty to find and use Lisp libraries to do whatever I had to do
in Lisp, including XML parsing (to keep with the example).
So I still wonder what's your problem?
--
__Pascal Bourguignon__
On May 6, 11:20 am, MishoM <···············@gmail.com> wrote:
> You are missing the point. I'm not talking about the CL standard. I'm
> talking about using CL, which of course means I'm talking about
> available CL distributions and CL IDEs and comparing them to C++
> distributions and available C++ IDEs. I'm also talking about CL
> libraries and comparing their availability and documentation to the
> availability and documentation of C++ libraries. And I'm only doing
> this comparison to address your claims that I'm expecting thinks from
> CL, which I don't expect from another language. You couldn't be more
> wrong - this are things that I've come to take for granted.
>
> And the point is not that I'm bitching about me expecting this things
> and not finding them - the point is that there are probably many
> people like me, who are used to taking them for granted, but unlike me
> they will give up after the first contact. They'll read some of PCL or
> some other introduction, get enthusiastic, and then they'll try to use
> CL to do that side project they had in mind for some time, and planned
> to do in language X. And they'll feel at a loss and after some
> struggling they'll get back to what they are accustomed to. Because
> most people just won't make the transition to something new, if there
> are too many obstacles. That's why I'm saying that CL is not friendly
> to newcomers.
CL is just a programming language. What you're saying that lisp
ecosystem is not friendly to windows newcomers, which is somewhat
true.
You need some work to make hack lisp on windows, the easiest way is
with Edi's starter pack which will give you plenty to start with.
The best advice if you want to use open source library is to just
install some *nix system, like linux, mac or Freebsd because the most
lispers are there or/and you can buy commercial lisp.
With todays hardware, setting up virtual machine with ubuntu, sbcl,
slime and cl-build will take only few hours. Then you only need to
type
./clbuild install weblocks cl-prevalence to have a full blown web
framework on your machine.
Whining about CL being unfriendly won't do any good. Either do some
work to setup lisp on windows(I'm ready to give you some help) and be
prepared to patch some libraries(though many work perfectly on any
ANSI lisp implementation), or try lisping on some *nix OS or finally
quit the weird language called lisp and return to your favorite run-of-
the-mill language.
It's your choice.
bobi
From: Kenneth Tilton
Subject: Re: CL-UNIFICATION as a library (Re: Qi Seems Great)
Date:
Message-ID: <4a03576d$0$5393$607ed4bc@cv.net>
Slobodan Blazeski wrote:
> On May 6, 11:20 am, MishoM <···············@gmail.com> wrote:
>> You are missing the point. I'm not talking about the CL standard. I'm
>> talking about using CL, which of course means I'm talking about
>> available CL distributions and CL IDEs and comparing them to C++
>> distributions and available C++ IDEs. I'm also talking about CL
>> libraries and comparing their availability and documentation to the
>> availability and documentation of C++ libraries. And I'm only doing
>> this comparison to address your claims that I'm expecting thinks from
>> CL, which I don't expect from another language. You couldn't be more
>> wrong - this are things that I've come to take for granted.
You are absolutely right. Lisp seems like a joke when approached from
The Real World. This assumes of course the approach does not begin with
the AllegroCL (Duane, are you happy I type that whole damn thing out?!)
on Windows where you do get a kick-ass IDE, but that is a safe
assumption given all you free as in my time has no value retard geeks
out there.
>>
>> And the point is not that I'm bitching about me expecting this things
>> and not finding them - the point is that there are probably many
>> people like me, who are used to taking them for granted, but unlike me
>> they will give up after the first contact. They'll read some of PCL or
>> some other introduction, get enthusiastic, and then they'll try to use
>> CL to do that side project they had in mind for some time, and planned
>> to do in language X. And they'll feel at a loss and after some
>> struggling they'll get back to what they are accustomed to. Because
>> most people just won't make the transition to something new, if there
>> are too many obstacles. That's why I'm saying that CL is not friendly
>> to newcomers.
That is a feature, not a bug. Java and C++ have amazingly helpful IDEs
because those languages need them. What seems like a deficit is the
natural outcome of a more powerful language. But noobs do not know that,
they just see the deficit compared with conventional languages' IDEs.
>
> CL is just a programming language.
And Anna Kournikova is just a tennis player.
> What you're saying that lisp
> ecosystem is not friendly to windows newcomers, which is somewhat
> true.
> You need some work to make hack lisp on windows, the easiest way is
... to download the AllegroCL free trial installer?
> with Edi's starter pack which will give you plenty to start with.
Oh, well.
> The best advice if you want to use open source library is to just
> install some *nix system, like linux, mac or Freebsd because the most
> lispers are there..
Yeah, but The Kenny is here.
> or/and you can buy commercial lisp.
> With todays hardware, setting up virtual machine with ubuntu, sbcl,
> slime and cl-build will take only few hours. Then you only need to
> type
> ./clbuild install weblocks cl-prevalence to have a full blown web
> framework on your machine.
>
> Whining about CL being unfriendly won't do any good. Either do some
> work to setup lisp on windows(I'm ready to give you some help) and be
> prepared to patch some libraries(though many work perfectly on any
> ANSI lisp implementation),
pwuahahahah... sounds like the install will cost as much in time as a
frickin ACL license. Oh, I forgot, time has no value.
Meanwhile, if someone reads PCL and does not develop sufficient
enthusiasm to Do Whatever It Takes(tm) to get past hello world in lisp
they might want to stick to Java because Lisp will not help them that
much if they do not get it.
kt
On May 7, 2:49 pm, Kenneth Tilton <·········@gmail.com> wrote:
> You are absolutely right. Lisp seems like a joke when approached from
> The Real World. This assumes of course the approach does not begin with
> the AllegroCL (Duane, are you happy I type that whole damn thing out?!)
Yeah; keep up the good work!
> frickin ACL license. Oh, I forgot, time has no value.
==========^^^
Oops!
:-)
From: Frank GOENNINGER
Subject: Re: CL-UNIFICATION as a library (Re: Qi Seems Great)
Date:
Message-ID: <m2k54ruyw8.fsf@goenninger.net>
MishoM <···············@gmail.com> writes:
>
> You are missing the point. I'm not talking about the CL standard. I'm
> talking about using CL, which of course means I'm talking about
> available CL distributions and CL IDEs and comparing them to C++
> distributions and available C++ IDEs.
Ok. We know it now.
> I'm also talking about CL
> libraries and comparing their availability and documentation to the
> availability and documentation of C++ libraries.
Ok. We know it now.
Now that we know it we are not missing the point anymore.
Repeat after me:
We are not missing the point.
No, no, louder:
We are not missing the point.
Yeah. Good.
> And I'm only doing
> this comparison to address your claims that I'm expecting thinks from
> CL, which I don't expect from another language. You couldn't be more
> wrong - this are things that I've come to take for granted.
Ok. Relax now. So you are saying that the CL implementations are not up
to your high standard. Because you do take things for granted.
Ok. We know it now. No, we will not be missing the point.
> And the point is not that I'm bitching about me expecting this things
> and not finding them - the point is that there are probably many
> people like me, who are used to taking them for granted, but unlike me
> they will give up after the first contact.
Now we should make note of that:
There are other people who are also taking these things for
granted. They will walk away because they do not find what they take for
granted.
> They'll read some of PCL or
> some other introduction, get enthusiastic, and then they'll try to use
> CL to do that side project they had in mind for some time, and planned
> to do in language X. And they'll feel at a loss and after some
> struggling they'll get back to what they are accustomed to. Because
> most people just won't make the transition to something new, if there
> are too many obstacles. That's why I'm saying that CL is not friendly
> to newcomers.
Ok. Now we have the facts:
1. You take things for granted.
2. Other people take these things for granted also.
3. You are not satisfied with what you find in CL land.
4. Other people (the so called newcomers) are also not satisfied with
what they find.
5. They walk away from CL.
The results are:
1. We have people in CL land who are not taking things for granted.
2. People in CL land are able to find their way to solutions that are
not easy to find.
3. People in CL land are able to stay on a subject even if it is not
easy to overcome some obstacles when being a newcomer.
That gives us:
People using CL are determined to get to a solution.
Which is not that bad, really.
So, do we want to change that whole situation?
I certainly hope that we all get away from typing what I call Industry
Lyrics (this thread is one of those examples) but do Real Coding. I do
have a problem currently with CFFI on Mac OS X running AllegroCL.
I could use some real help, actually - if you would be so kind to have a
look at a real problem ... I've sent all info on CFFI discussion list...
Thanks.
Frank
On May 5, 3:10 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> MishoM <···············@gmail.com> writes:
> > [... the classical newbie rant ...]
>
> You don't get it. You are plain wrong. And what's more, you're a
> "salaud" in Sartre's meaning, (ie. you're a cinical bitch) because
> you're asking things of Common Lisp that you don't expect of C.
This is the kind of curmudgeonly reply that scares new users away. I
really wish you would resist the temptation to write like this.
The fact is, the bar IS higher for CL. Why? Consider: most people
don't learn languages on their own; they pick up a lot of information
from co-workers already familiar with the language, or from fellow
contributors to their open-source project, or over IRC, or whatever.
Languages with thriving communities and lots of users make this easy
and common. In effect, they have "recommended" sets of libraries: the
ones that a lot of people are using.
With CL, people are much more likely to be trying to learn the
language without knowing anyone else who uses it, just because the
community is so small to begin with. That makes the kind of things
MishoM is asking for more important.
That doesn't mean any of us has time to produce it... but don't
dismiss it as a legitimate desire.
-- Scott
From: Pascal J. Bourguignon
Subject: Re: CL-UNIFICATION as a library (Re: Qi Seems Great)
Date:
Message-ID: <877i0u3you.fsf@galatea.local>
Scott Burson <········@gmail.com> writes:
> On May 5, 3:10�pm, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> MishoM <···············@gmail.com> writes:
>> > [... the classical newbie rant ...]
>>
>> You don't get it. �You are plain wrong. �And what's more, you're a
>> "salaud" in Sartre's meaning, �(ie. you're a cinical bitch) because
>> you're asking things of Common Lisp that you don't expect of C.
>
> This is the kind of curmudgeonly reply that scares new users away. I
> really wish you would resist the temptation to write like this.
>
> The fact is, the bar IS higher for CL. Why? Consider: most people
> don't learn languages on their own; they pick up a lot of information
> from co-workers already familiar with the language, or from fellow
> contributors to their open-source project, or over IRC, or whatever.
> Languages with thriving communities and lots of users make this easy
> and common. In effect, they have "recommended" sets of libraries: the
> ones that a lot of people are using.
>
> With CL, people are much more likely to be trying to learn the
> language without knowing anyone else who uses it, just because the
> community is so small to begin with. That makes the kind of things
> MishoM is asking for more important.
But what MishoM asks
1- is not more available for the other programming language,
2- is already available for Common Lisp.
That's the reason of my hostile answer to MishoM.
--
__Pascal Bourguignon__
> But what MishoM asks
> 1- is not more available for the other programming language,
> 2- is already available for Common Lisp.
>
> That's the reason of my hostile answer to MishoM.
>
> --
> __Pascal Bourguignon__
I actually find a lot of the newbie rants interesting, as someone who
learned common lisp first and then had to learn other languages for
work/school (C, Java Perl, etc.)
Honestly a lot things that they complain about in CL are remarkably
symmetric to the things that I was irritated by going from CL to other
languages.
(Syntax is confusing! I can't find a proper IDE! (Why do i have to do
everything in textpad?!?!) installation sucks! Where is my repl? Why
do i have to recompile the *ENTIRE-DAMN-PROJECT* again because I
wanted to fix a typo in *ONE* function? Why do i have to import 3
libraries for even the tiniest project? Why is everything done by
importing a ton of libraries and linking them together, doesn't anyone
write code in this language? I can't follow this indentation! What is
with this If then else if then else if then else crap? Where's cond?
Why do macros never work (correctly)? I don't get the difference
between a 'procedure' and a function, why is there a distinction? Why
do i have to make an arbitrary distinction based on the size and type
of number I'm using? They're all numbers to me! I have trouble telling
the difference between a { a ( and a [ on a small screen; what the
hell is the difference between them anyway? I can't remember order of
operations so I never know what my math code will do! Why does this
syntax look like a pile of arbitrary operators? Why do I have to spend
so much time copy/pasting code I already wrote and changing it
slightly?
I'm confused, I'm lost, why doesn't my code run! No I didn't read the
manual! You think i have /time/ to /read/ and /think/ about what I'm
doing? I have a /deadline/ damn it. Time to PANIC!
//probably an exaggeration, but I do get pretty irritated writing in
confusing non-lisp dialects...
On May 6, 10:53 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Scott Burson <········@gmail.com> writes:
> > On May 5, 3:10 pm, ····@informatimago.com (Pascal J. Bourguignon)
> > wrote:
> >> MishoM <···············@gmail.com> writes:
> >> > [... the classical newbie rant ...]
>
> >> You don't get it. You are plain wrong. And what's more, you're a
> >> "salaud" in Sartre's meaning, (ie. you're a cinical bitch) because
> >> you're asking things of Common Lisp that you don't expect of C.
>
> > This is the kind of curmudgeonly reply that scares new users away. I
> > really wish you would resist the temptation to write like this.
>
> > The fact is, the bar IS higher for CL. Why? Consider: most people
> > don't learn languages on their own; they pick up a lot of information
> > from co-workers already familiar with the language, or from fellow
> > contributors to their open-source project, or over IRC, or whatever.
> > Languages with thriving communities and lots of users make this easy
> > and common. In effect, they have "recommended" sets of libraries: the
> > ones that a lot of people are using.
>
> > With CL, people are much more likely to be trying to learn the
> > language without knowing anyone else who uses it, just because the
> > community is so small to begin with. That makes the kind of things
> > MishoM is asking for more important.
>
> But what MishoM asks
> 1- is not more available for the other programming language,
> 2- is already available for Common Lisp.
>
> That's the reason of my hostile answer to MishoM.
Even if I agreed with you, that would not justify hostility.
And I don't agree. Linux distros come with lots of libraries, many of
which are de facto standard by now. Perl has CPAN. Python has its
standard libraries.
CL has some things like those, but they're harder to locate, harder to
use, and less informative.
I'm not going to get into a long debate on this point. My own brief
forays into Perl and Python, compared with the hit-and-miss experience
of CLiki and common-lisp.net, have already persuaded me. You
disagree? Great, I'm glad the CL stuff works for you. It doesn't
work for everyone.
I realize also that it's not black-and-white (Python also has a
plethora of Web frameworks, for instance), and that there is a certain
amount of newbie disorientation that is inevitable. I also think the
situation in CL could be improved... not that I have any time to work
on it myself.
-- Scott
From: Pascal J. Bourguignon
Subject: Re: CL-UNIFICATION as a library (Re: Qi Seems Great)
Date:
Message-ID: <87my9p2z7h.fsf@galatea.local>
Scott Burson <········@gmail.com> writes:
> On May 6, 10:53�am, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> Scott Burson <········@gmail.com> writes:
>> > On May 5, 3:10�pm, ····@informatimago.com (Pascal J. Bourguignon)
>> > wrote:
>> >> MishoM <···············@gmail.com> writes:
>> >> > [... the classical newbie rant ...]
>>
>> >> You don't get it. �You are plain wrong. �And what's more, you're a
>> >> "salaud" in Sartre's meaning, �(ie. you're a cinical bitch) because
>> >> you're asking things of Common Lisp that you don't expect of C.
>>
>> > This is the kind of curmudgeonly reply that scares new users away. �I
>> > really wish you would resist the temptation to write like this.
>>
>> > The fact is, the bar IS higher for CL. �Why? �Consider: most people
>> > don't learn languages on their own; they pick up a lot of information
>> > from co-workers already familiar with the language, or from fellow
>> > contributors to their open-source project, or over IRC, or whatever.
>> > Languages with thriving communities and lots of users make this easy
>> > and common. �In effect, they have "recommended" sets of libraries: the
>> > ones that a lot of people are using.
>>
>> > With CL, people are much more likely to be trying to learn the
>> > language without knowing anyone else who uses it, just because the
>> > community is so small to begin with. �That makes the kind of things
>> > MishoM is asking for more important.
>>
>> But what MishoM asks
>> 1- is not more available for the other programming language,
>> 2- is already available for Common Lisp.
>>
>> That's the reason of my hostile answer to MishoM.
>
> Even if I agreed with you, that would not justify hostility.
>
> And I don't agree. Linux distros come with lots of libraries, many of
> which are de facto standard by now.
Well, yesterday I had a discussion with a Linux user who complained
that different applications used different frameworks, and that led to
a plethora of different libraries doing the same thing being
installed, (and worse in his point of view, of a plethora of processes
to be forked). Seems to me there's no standard library to display a
button or process a user interface event...
How can you say there are de facto libraries when for such a simple
thing as parsing XML there are more than 6787 sourceforge projects,
and googling for linux c library xml gives more than 250,000 hits...
> Perl has CPAN. Python has its
> standard libraries.
>
> CL has some things like those, but they're harder to locate, harder to
> use, and less informative.
>
> I'm not going to get into a long debate on this point. My own brief
> forays into Perl and Python, compared with the hit-and-miss experience
> of CLiki and common-lisp.net, have already persuaded me. You
> disagree? Great, I'm glad the CL stuff works for you. It doesn't
> work for everyone.
>
> I realize also that it's not black-and-white (Python also has a
> plethora of Web frameworks, for instance), and that there is a certain
> amount of newbie disorientation that is inevitable. I also think the
> situation in CL could be improved... not that I have any time to work
> on it myself.
But you keep making the error or confusing a language with implementations.
Try to s/CL/SBCL/ or s/CL/Franz Allegro Common Lisp/ or s/CL/clisp/.
--
__Pascal Bourguignon__
On May 7, 9:40 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> How can you say there are de facto libraries when for such a simple
> thing as parsing XML there are more than 6787 sourceforge projects,
> and googling for linux c library xml gives more than 250,000 hits...
You are right that there are more libraries for C/C++ than for CL and
that usually there is no single "standard" library. But you are wrong
to conclude that this makes it harder to find a suitable library. I
tried to demonstrate it to you with your own example of looking for an
XML library but you chose to conveniently ignore it and talk about me
mentioning msdn and Windows.
So again, as I said before, looking for a C/C++ XML library in google,
you need not look further than the first three or four hits, and
you'll find three very mature, widely used and actively supported
libraries. Choosing any of them will get you going in no time. And the
most important thing - each of them has a dedicated web site and just
by glancing over it you will immediately get an idea of the state of
the library - you'll see that it is being developed actively, that
there is introductory material right there on the site, etc. So unless
you have more specific needs you have an easy choice (please, don't
ask me which of the three ones - there is enough information on the
sites to get an idea of the general approach and choose one to your
liking). And if your needs are more specific, like for example small
memory usage or something else, you'll need to spend some more time
looking, but again, the odds are that most libraries you'll look at
will have a lot of information on a dedicated web site.
Compare this to the case when you are looking for a CL XML library.
You get a page on CLiki with some links that lead to minimalistic
pages with almost no information, and several other pages. Both the
pages you reach through CLiki, and the pages you reach directly from
the google results page leave the impression that they have not been
maintained for several years. The odds are, you need to try out each
of the libraries to find out what it supports. Or at least that's the
impression you get.
BTW, I've not used any of these libraries - I've needed an XML library
in only one project when it was decided to use MSXML, so I looked for
these libraries only for your example, and still I get the feeling of
a safe bet with C/C++.
You can apply the same comparison when comparing the availability of
libraries for C/C++ vs CL for any purpose. Many CL libraries have no
dedicated web site, no introductory material and no documentation. In
many cases all that is available is a link to some source repository
along with a few sentences describing the general purpose of the
package. The choice is much easier with C/C++ because, though there is
much more to choose from, there is also much more information to guide
your choice. C/C++ programmers make their libraries with usability in
mind. Even when the library is developed by a single developer, he/she
tries to provide some guidance to its users. CL libraries on the other
hand leave the impression that their authors made them for their own
use and then just shared the sources. That's why I say that it is a
matter of attitude.
> But you keep making the error or confusing a language with implementations.
> Try to s/CL/SBCL/ or s/CL/Franz Allegro Common Lisp/ or s/CL/clisp/.
And you keep ignoring the fact that it's the attitude of people who
create libraries and implementations that is being compared here.
On 7 May, 10:29, MishoM <···············@gmail.com> wrote:
> On May 7, 9:40 am, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>
> > How can you say there are de facto libraries when for such a simple
> > thing as parsing XML there are more than 6787 sourceforge projects,
> > and googling for linux c library xml gives more than 250,000 hits...
>
> You are right that there are more libraries for C/C++ than for CL and
> that usually there is no single "standard" library. But you are wrong
> to conclude that this makes it harder to find a suitable library. I
> tried to demonstrate it to you with your own example of looking for an
> XML library but you chose to conveniently ignore it and talk about me
> mentioning msdn and Windows.
>
> So again, as I said before, looking for a C/C++ XML library in google,
> you need not look further than the first three or four hits, and
> you'll find three very mature, widely used and actively supported
> libraries. Choosing any of them will get you going in no time. And the
> most important thing - each of them has a dedicated web site and just
> by glancing over it you will immediately get an idea of the state of
> the library - you'll see that it is being developed actively, that
> there is introductory material right there on the site, etc. So unless
> you have more specific needs you have an easy choice (please, don't
> ask me which of the three ones - there is enough information on the
> sites to get an idea of the general approach and choose one to your
> liking). And if your needs are more specific, like for example small
> memory usage or something else, you'll need to spend some more time
> looking, but again, the odds are that most libraries you'll look at
> will have a lot of information on a dedicated web site.
>
> Compare this to the case when you are looking for a CL XML library.
> You get a page on CLiki with some links that lead to minimalistic
> pages with almost no information, and several other pages. Both the
> pages you reach through CLiki, and the pages you reach directly from
> the google results page leave the impression that they have not been
> maintained for several years. The odds are, you need to try out each
> of the libraries to find out what it supports. Or at least that's the
> impression you get.
>
> BTW, I've not used any of these libraries - I've needed an XML library
> in only one project when it was decided to use MSXML, so I looked for
> these libraries only for your example, and still I get the feeling of
> a safe bet with C/C++.
>
> You can apply the same comparison when comparing the availability of
> libraries for C/C++ vs CL for any purpose. Many CL libraries have no
> dedicated web site, no introductory material and no documentation. In
> many cases all that is available is a link to some source repository
> along with a few sentences describing the general purpose of the
> package. The choice is much easier with C/C++ because, though there is
> much more to choose from, there is also much more information to guide
> your choice. C/C++ programmers make their libraries with usability in
> mind. Even when the library is developed by a single developer, he/she
> tries to provide some guidance to its users. CL libraries on the other
> hand leave the impression that their authors made them for their own
> use and then just shared the sources. That's why I say that it is a
> matter of attitude.
>
> > But you keep making the error or confusing a language with implementations.
> > Try to s/CL/SBCL/ or s/CL/Franz Allegro Common Lisp/ or s/CL/clisp/.
>
> And you keep ignoring the fact that it's the attitude of people who
> create libraries and implementations that is being compared here.
CL has some very good libraries, but as I said in my L21 talk, the
level of support, standardisation and documentation is not great.
Generally there is a space, as Scott has said, for someone coming
forward and taking on the task of doing just that.
Part of the L21 project at Qilang is about putting that into effect
with the added bonus of supplying type theories for all this stuff.
However one problem is that, though most people think This is A Good
Thing, there is not much financial support for it. There is a generic
problem with a lot of open source systems programming which is that
the main official source of revenue for this kind of work- university
grants - are not available for those working outside that system.
IMO the govt. funding system has not caught up with the realities of
FOSS software development and people like Stallman never developed a
proper economic model to support people's work. Putting the CL
libraries into some order therefore remains a very good example of the
difference between 'paid work' and 'useful stuff that people can do'
that I alluded to on my thread to Mr Maas about employment.
Mark
MishoM <···············@gmail.com> writes:
> On May 7, 9:40�am, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>
>> How can you say there are de facto libraries when for such a simple
>> thing as parsing XML there are more than 6787 sourceforge projects,
>> and googling for linux c library xml gives more than 250,000 hits...
>
> You are right that there are more libraries for C/C++ than for CL and
> that usually there is no single "standard" library. But you are wrong
> to conclude that this makes it harder to find a suitable library. I
> tried to demonstrate it to you with your own example of looking for an
> XML library but you chose to conveniently ignore it and talk about me
> mentioning msdn and Windows.
>
> So again, as I said before, looking for a C/C++ XML library in google,
> you need not look further than the first three or four hits, and
> you'll find three very mature, widely used and actively supported
> libraries.
But the very same is true for CL XML libraries!!!!
What are you complaining about?
> Choosing any of them will get you going in no time. And the
> most important thing - each of them has a dedicated web site and just
> by glancing over it you will immediately get an idea of the state of
> the library - you'll see that it is being developed actively, that
> there is introductory material right there on the site, etc. So unless
> you have more specific needs you have an easy choice (please, don't
> ask me which of the three ones - there is enough information on the
> sites to get an idea of the general approach and choose one to your
> liking).
And this is exactly the situation we have with CL libraries.
> And if your needs are more specific, like for example small
> memory usage or something else, you'll need to spend some more time
> looking, but again, the odds are that most libraries you'll look at
> will have a lot of information on a dedicated web site.
Idem.
> Compare this to the case when you are looking for a CL XML library.
> You get a page on CLiki with some links that lead to minimalistic
> pages with almost no information, and several other pages. Both the
> pages you reach through CLiki, and the pages you reach directly from
> the google results page leave the impression that they have not been
> maintained for several years.
Why would you want to "maintain" a library when it works perfectly???
> The odds are, you need to try out each of the libraries to find out
> what it supports. Or at least that's the impression you get.
And what would be wrong with having to try out the libraries, if you
cannot make your mind reading the documentation? You've got the
sources, you can freely check the quality of the code reading the
sources, and you can exercise it. And this is very much more possible
to do that with CL libraries than with C++ or C libraries since CL is
more concise a programming language, it will be easier to read the
library sources and understand them. That's all advantages.
> BTW, I've not used any of these libraries - I've needed an XML library
> in only one project when it was decided to use MSXML, so I looked for
> these libraries only for your example, and still I get the feeling of
> a safe bet with C/C++.
OT: Well, I assume MSXML won't work on MacOSX or Linux. Just by the
name it doesn't sound such a great choice...
> You can apply the same comparison when comparing the availability of
> libraries for C/C++ vs CL for any purpose. Many CL libraries have no
> dedicated web site, no introductory material and no documentation.
Assume we're comparing a 100,000 LoC C++ library.
It would translate into a 5,000 LoC CL library. Thanks to the
dynamicity of the language, the API itself is bound to be from half to
a tenth of the C++ API size.
Do you really think that we need a whole dedicated web site and heaps
of documentation for such a small body of code?
Now, let's assume a bigger library, implementing a more complex
algorith, such as, for example, RETE.
Google rete C++ library gives nothing concluding. There seems to have
been a rete++ commercial library but the company has been bought by
Oracle and their web site where supposedly it would have been
documented doesn't exist anymore.
Google rete CL library gives http://lisa.sourceforge.net/ with a
dedicated sourceforge web site, documentation, and all you asked for.
> In many cases all that is available is a link to some source
> repository along with a few sentences describing the general purpose
> of the package.
Why would we duplicate on cliki the dedicated web pages or the sources
of the library?
> The choice is much easier with C/C++ because, though
> there is much more to choose from, there is also much more
> information to guide your choice. C/C++ programmers make their
> libraries with usability in mind. Even when the library is developed
> by a single developer, he/she tries to provide some guidance to its
> users. CL libraries on the other hand leave the impression that
> their authors made them for their own use and then just shared the
> sources. That's why I say that it is a matter of attitude.
That's not what I observe. I see that complex CL libraries or
programs are well documented, and the other are simple enough that no
documentation is needed: get the source browse them and use them.
>> But you keep making the error or confusing a language with implementations.
>> Try to s/CL/SBCL/ or s/CL/Franz Allegro Common Lisp/ or s/CL/clisp/.
>
> And you keep ignoring the fact that it's the attitude of people who
> create libraries and implementations that is being compared here.
I'm sorry, but you are not adequately addressing this question. You
would need to do a statistically significant study about the attibute
of the people, including their contexts.
Why do you compare the contributions of amateur (ie. not paid work)
sunday programming vs. Microsoft products?
Why do you compare universitary PhD by-products (the software are
never the main object of theses, AFAIK, but by-products developed to
experiment, confirm or infirm, or just otherwise help in the thesis
production) vs. any commercial products? And don't be misled by the
user's freedom, most linux distributions are still produced by
commercial ventures and well paid professionnal programmers.
--
__Pascal Bourguignon__
On Thu, 07 May 2009 13:57:43 +0200, Pascal J. Bourguignon wrote:
> Assume we're comparing a 100,000 LoC C++ library. It would translate
> into a 5,000 LoC CL library. Thanks to the dynamicity of the language,
> the API itself is bound to be from half to a tenth of the C++ API size.
>
> Do you really think that we need a whole dedicated web site and heaps of
> documentation for such a small body of code?
While I generally agree with you, some minor amount of documentation
could really help some CL libraries. I am not thinking about
super-detailed docs, but a discussion of the basic principles and a
bit of example code, total 2-4 pages.
Tamas
Tamas K Papp <······@gmail.com> writes:
> On Thu, 07 May 2009 13:57:43 +0200, Pascal J. Bourguignon wrote:
>
>> Assume we're comparing a 100,000 LoC C++ library. It would translate
>> into a 5,000 LoC CL library. Thanks to the dynamicity of the language,
>> the API itself is bound to be from half to a tenth of the C++ API size.
>>
>> Do you really think that we need a whole dedicated web site and heaps of
>> documentation for such a small body of code?
>
> While I generally agree with you, some minor amount of documentation
> could really help some CL libraries. I am not thinking about
> super-detailed docs, but a discussion of the basic principles and a
> bit of example code, total 2-4 pages.
I usually find that in the sources, or the attached README...
The problem is probably with web-centric newbies.
--
__Pascal Bourguignon__
On May 7, 5:10 pm, Tamas K Papp <······@gmail.com> wrote:
> On Thu, 07 May 2009 13:57:43 +0200, Pascal J. Bourguignon wrote:
> > Assume we're comparing a 100,000 LoC C++ library. It would translate
> > into a 5,000 LoC CL library. Thanks to the dynamicity of the language,
> > the API itself is bound to be from half to a tenth of the C++ API size.
>
> > Do you really think that we need a whole dedicated web site and heaps of
> > documentation for such a small body of code?
>
> While I generally agree with you, some minor amount of documentation
> could really help some CL libraries. I am not thinking about
> super-detailed docs, but a discussion of the basic principles and a
> bit of example code, total 2-4 pages.
>
> Tamas
I agree with you.
Vsevolod
From: Pascal J. Bourguignon
Subject: Re: CL-UNIFICATION as a library (Re: Qi Seems Great)
Date:
Message-ID: <87fxff3n51.fsf@galatea.local>
Vsevolod Dyomkin <········@gmail.com> writes:
> On May 7, 5:10 pm, Tamas K Papp <······@gmail.com> wrote:
>> On Thu, 07 May 2009 13:57:43 +0200, Pascal J. Bourguignon wrote:
>> > Assume we're comparing a 100,000 LoC C++ library. It would translate
>> > into a 5,000 LoC CL library. Thanks to the dynamicity of the language,
>> > the API itself is bound to be from half to a tenth of the C++ API size.
>>
>> > Do you really think that we need a whole dedicated web site and heaps of
>> > documentation for such a small body of code?
>>
>> While I generally agree with you, some minor amount of documentation
>> could really help some CL libraries. I am not thinking about
>> super-detailed docs, but a discussion of the basic principles and a
>> bit of example code, total 2-4 pages.
>>
>> Tamas
>
> I agree with you.
Perhaps one way to start it would be to make a "Underdocumented
Libraries" cliki page to list the libraries in need of documentation
work? You could then add a link to the library when you find one
underdocumented.
--
__Pascal Bourguignon__
On May 8, 1:27 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Vsevolod Dyomkin <········@gmail.com> writes:
> > On May 7, 5:10 pm, Tamas K Papp <······@gmail.com> wrote:
> >> On Thu, 07 May 2009 13:57:43 +0200, Pascal J. Bourguignon wrote:
> >> > Assume we're comparing a 100,000 LoC C++ library. It would translate
> >> > into a 5,000 LoC CL library. Thanks to the dynamicity of the language,
> >> > the API itself is bound to be from half to a tenth of the C++ API size.
>
> >> > Do you really think that we need a whole dedicated web site and heaps of
> >> > documentation for such a small body of code?
>
> >> While I generally agree with you, some minor amount of documentation
> >> could really help some CL libraries. I am not thinking about
> >> super-detailed docs, but a discussion of the basic principles and a
> >> bit of example code, total 2-4 pages.
>
> >> Tamas
>
> > I agree with you.
>
> Perhaps one way to start it would be to make a "Underdocumented
> Libraries" cliki page to list the libraries in need of documentation
> work? You could then add a link to the library when you find one
> underdocumented.
>
> --
> __Pascal Bourguignon__
That's a good idea, I agree. But, besides, this page should be visible
somehow. Maybe in the footer of every cliki page there should be a
link "this lib needs more documentation" (like wikipedia's: needs
cite, clarification etc), which will automatically add the library to
the underdocumented page
Vsevolod
On May 8, 1:27 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Vsevolod Dyomkin <········@gmail.com> writes:
> > On May 7, 5:10 pm, Tamas K Papp <······@gmail.com> wrote:
> >> On Thu, 07 May 2009 13:57:43 +0200, Pascal J. Bourguignon wrote:
> >> > Assume we're comparing a 100,000 LoC C++ library. It would translate
> >> > into a 5,000 LoC CL library. Thanks to the dynamicity of the language,
> >> > the API itself is bound to be from half to a tenth of the C++ API size.
>
> >> > Do you really think that we need a whole dedicated web site and heaps of
> >> > documentation for such a small body of code?
>
> >> While I generally agree with you, some minor amount of documentation
> >> could really help some CL libraries. I am not thinking about
> >> super-detailed docs, but a discussion of the basic principles and a
> >> bit of example code, total 2-4 pages.
>
> >> Tamas
>
> > I agree with you.
>
> Perhaps one way to start it would be to make a "Underdocumented
> Libraries" cliki page to list the libraries in need of documentation
> work? You could then add a link to the library when you find one
> underdocumented.
>
> --
> __Pascal Bourguignon__
I've added a page: http://www.cliki.net/underdocumented
and here are the proposed extensions to CLiki, so that at the footer
of each page there's a link to add it to underdocumented:
http://paste.lisp.org/display/79895. (Untested code actually and not
protected from spamming, but I can develop it more, if it will be
considered helpful).
But maybe, it's overkill, I don't know. And how to send the suggestion
to CLiki maintainers? I've found bugs page (but it's not a bug) and
TODO list, that doesn't seem to be updated recently...
Best regards,
Vsevolod
From: ···············@ruag.com
Subject: Re: CL-UNIFICATION as a library (Re: Qi Seems Great)
Date:
Message-ID: <uiqkbiq47.fsf@ruag.com>
>>>>> " " == Vsevolod Dyomkin <········@gmail.com> writes:
> On May 8, 1:27 pm, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> Perhaps one way to start it would be to make a "Underdocumented
>> Libraries" cliki page to list the libraries in need of documentation
>> work? You could then add a link to the library when you find one
>> underdocumented.
>>
>> __Pascal Bourguignon__
> I've added a page: http://www.cliki.net/underdocumented
> and here are the proposed extensions to CLiki, so that at the footer
> of each page there's a link to add it to underdocumented:
> http://paste.lisp.org/display/79895. (Untested code actually and not
> protected from spamming, but I can develop it more, if it will be
> considered helpful).
> But maybe, it's overkill, I don't know. And how to send the suggestion
> to CLiki maintainers? I've found bugs page (but it's not a bug) and
> TODO list, that doesn't seem to be updated recently...
Hello,
can't you use the topic marker mechanism, i.e. add *(underdocumented)
to the CLiki page of the library?
regards
Roland
On May 8, 6:14 pm, ···············@ruag.com wrote:
> >>>>> " " == Vsevolod Dyomkin <········@gmail.com> writes:
>
> > On May 8, 1:27 pm, ····@informatimago.com (Pascal J. Bourguignon)
> > wrote:
> >> Perhaps one way to start it would be to make a "Underdocumented
> >> Libraries" cliki page to list the libraries in need of documentation
> >> work? You could then add a link to the library when you find one
> >> underdocumented.
> >>
> >> __Pascal Bourguignon__
>
> > I've added a page:http://www.cliki.net/underdocumented
> > and here are the proposed extensions to CLiki, so that at the footer
> > of each page there's a link to add it to underdocumented:
> >http://paste.lisp.org/display/79895. (Untested code actually and not
> > protected from spamming, but I can develop it more, if it will be
> > considered helpful).
> > But maybe, it's overkill, I don't know. And how to send the suggestion
> > to CLiki maintainers? I've found bugs page (but it's not a bug) and
> > TODO list, that doesn't seem to be updated recently...
>
> Hello,
> can't you use the topic marker mechanism, i.e. add *(underdocumented)
> to the CLiki page of the library?
>
> regards
> Roland
Yeah, that's a much simpler solution.
The only thing it lacks is advertisement to all users, that such an
option exists.
Maybe a brief note can be added to every page's footer. Something in
the lines of:
"Use *(underdocumented) tag, to signify, that you think this article
needs improvement"
?
Best regards,
Vsevolod
On May 7, 12:29 pm, MishoM <···············@gmail.com> wrote:
> On May 7, 9:40 am, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
> Compare this to the case when you are looking for a CL XML library.
> You get a page on CLiki with some links that lead to minimalistic
> pages with almost no information, and several other pages. Both the
> pages you reach through CLiki, and the pages you reach directly from
> the google results page leave the impression that they have not been
> maintained for several years. The odds are, you need to try out each
> of the libraries to find out what it supports. Or at least that's the
> impression you get.
I don't agree with you. If you ask google (http://www.google.com/
search?q=common+lisp+xml)
the second result you'll get is a link to CLiki pages on S-XML and
Closure XML. Those are two most widely used open-source XML libraries
for CL. And if the first (S-XML) has a rather minimalistic page, it's
instructive enough to get you started (at least for me it took less
than half-hour to adapt the library to my requirements and after that
I've used it or a long time not needing to return to soring out
anything. Although I keep in mind extension possibilities, that the
library provides). While the second (CXML) has a rather big web-page
with tutorials, examples etc. It's quite actively maintained. Surely
there are other more obscure libraries (most of them not supported
now), there's an actively supported libxml bindings library, which
you'll easily find, if you ask http://www.google.com/search?q=common+lisp+libxml,
there are libraries from commercial vendors. So (with the adjustment
to the size of CL community compared to C/C++ one), don't you find the
situation quite similar? Or did I make some magic things, not
accessible to mere mortals to find all that information?
Best regards
Vsevolod
On May 8, 9:40 am, Vsevolod Dyomkin <········@gmail.com> wrote:
> the second result you'll get is a link to CLiki pages
sorry, those where common-lisp.net pages
* Scott Burson Wrote on Wed, 6 May 2009 09:27:23 -0700 (PDT):
|> You don't get it. You are plain wrong. And what's more, you're a
|> "salaud" in Sartre's meaning, (ie. you're a cinical bitch) because
|> you're asking things of Common Lisp that you don't expect of C.
|
| This is the kind of curmudgeonly reply that scares new users away. I
| really wish you would resist the temptation to write like this.
[snip]
| With CL, people are much more likely to be trying to learn the
| language without knowing anyone else who uses it, just because the
| community is so small to begin with. That makes the kind of things
| MishoM is asking for more important.
|
| That doesn't mean any of us has time to produce it... but don't
| dismiss it as a legitimate desire.
I believe the OP said has a background in producing commercial software
products for end users. I also believe all his requirements stated in
this thread are met (as PJB also suggested) if he chooses a vendor
supported commercial lisp implementation. I am not criticizing your
criticism of PJB here, but I am pointing out PJB has provided the
requested information. It is up to the person asking to decide if he
wants to choose to be offended or follow the advice and be helped.
The community is reportedly small but it is seems to be overflowing with
both newbies and oldtimers charged with devising ways of making lisp
"more popular".
--
Madhu
On May 5, 2:23 pm, MishoM <···············@gmail.com> wrote:
> Problem is, I seem to come from a different background than
> most of the people who post on this group. I've been working in
> different software companies for the last 10 years making products for
> end users. But many of you (especially the most active ones) seems to
> have a very different experience - academia, consulting, big custom
> projects, web programming...
It's true, there are many different kinds of programming. And
packaged applications are not what CL is best at, nor does the
community, such as it is, tend to be focussed on them.
> And recently,
> when I posted a question about building native deliverables that don't
> include things that are not used, several people explained to me that
> I'm wrong to want this, because the user would benefit from having a
> REPL (who, the secretary???, or am I forbidden to target mortals with
> software written in Lisp???), and I would benefit from having it in
> the customer's installation of my product too...
Yes, I was among those who failed to see that it was a big deal, not
so much because you would benefit by having a REPL hidden in the
product -- that seems rather a stretch -- but just because the amount
of disk space required is tiny by modern standards. It's just not
worth the trouble anymore, seems to me, to trim off the bits you're
not using.
Certainly that depends somewhat on what your ambitions are for your
app. If people will be paying money for it and you expect to sell
hundreds of thousands of copies, then yeah, you probably want to take
the time to pare down the executable. But in that case, I would think
you would have the budget to use a commercial CL that supports such
paring down.
> And what is worse, these same people regard the language as a solution
> instead of a product too. They find it normal that every programmer
> should find the CL implementation and set of libraries most suitable
> for him/her through trial and error... But what is the benefit of
> every new user of CL needing to go through a painful period of feeling
> lost and frustrated?
I agree with you, we could stand to do better here. There is Peter
Siebel's Lisp in a Box, which is a good start, but far more could be
done.
But there aren't really very many of us and we don't have a lot of
time.
> The fact that common-lisp.net
> and CLiki are not very friendly adds another frustration to the pile.
I agree again -- adding more SourceForge-style features here would be
a big help. It would be nice to have projects rated by maturity
level, for instance, so one could browse only those that are
reasonably mature.
> It is time for the CL community to realize
> that programmers are users too, and make CL a nicer place. Apparently
> a lot of you have both the depth of knowledge and the programming
> experience necessary. Just start a civil discussion and try to agree
> on a "recommended set of libraries" out of the existing ones. Not an
> expensive, years-consuming standard update, just a list of portable,
> well supported libraries. Put this list where it is hard to be missed.
> Write some tutorials based on these libraries... Do this, and CL will
> be much more appealing to newcomers like me.
I have toyed with undertaking such a project, but it would consume my
hobby time for at least a couple of years, and I'm afraid I have other
projects that are more important to me.
Probably most of the rest of the c.l.l denizens are in the same
situation, which partly explains their unsympathetic replies.
But I would love to see somebody do that, and I'd be willing to help
in small ways.
-- Scott
On May 4, 6:03 pm, namekuseijin <············@gmail.com> wrote:
> On May 4, 7:17 am, Marco Antoniotti <·······@gmail.com> wrote:
>
> > I apologize beforehand for sounding paternalistic. :)
>
> No prob. We all enjoy our personal Lisps. ;)
>
>
>
> > (define fact
> > 0 -> 1
> > ?n -> (* n (fact (1- n)))
>
> > It would seem that with a little bit of extra work you can also get
> > rid of the question mark, but I would advise against it for reasons
> > that will become clear later on and that should be clear to anybody
> > who has seen real unification at work in Prolog (vs. pattern matching
> > in FPs).
> > > (define foo
> > > (1 2 3 42 . r) _ -> (append r (list 42 42))
> > > (ship ship-x x ship-y y) (plane plane-p p)
> > > -> (progn (format t "There's a ship at ~S ~S and a plane at ~S.~%" x
> > > y p))
>
> > The second pattern is trivial to handle the way you want. You just
> > have to bypass the reader macro and get down to the MAKE-TEMPLATE
> > call; as I said it is a SMOP.
>
> Everything is always just a SMOP in CL. I fear that when the need for
> SMOPs abound, perhaps it is time for a new revision for the language?
Nope. That is a non-sequitur. A SMOP means that some of the
questions you are requesting are easy. I can add them (or *you* can
add them, which would be far better) to CL-UNIFICATION. One thing is
griping, another is doing.
> C++ is getting a new one just about now and it's coming with plenty of
> good stuff. Including lambdas, can you imagine? o_O
C++ has money behind, CL doesn't.
> > what are you
> > matching there? A strange object with "type" 1, or a list? What if
> > you want to match a dotted pair with the symbol R after the dot?
>
> perhaps like:
> (1 2 3 42 . (a . b))
Nope. You did not get it. Maybe I was not clear, but you are missing
the difference between
(a 42 . r)
and
(a 42 . ?r)
> ?
>
> > (define month->ordinal
> > january -> 1
> > february -> 2
> > march -> 3
> > ...)
>
> > The above is perfectly "understandable" and it works "out of the box"
> > with CL-UNIFICATION. But compare it with the simple FACT definition
> > above. What is the difference between the N and MARCH?
>
> The difference is that march is not used in the right side of the
> expression. ;)
One extra rule to remember. This needlessly complicates things. You
basically have two choices. Either any symbol on the left side is a
variable or you distinguish variables syntactically. Full unification
(usually) usually makes the second choice. Prolog *is* an interesting
language. There aren't only FP and OO under the sun.
> > > Still impressive anyway. But since it's not in the standard, it's
> > > simply not used that much.
>
> > Most of the Scheme used nowadays is "not in the standard".
>
> Yes, but the point is that parameter pattern matching is an incredibly
> useful, but since it's not part of the language standard, there will
> always be some resistance to its use, unobtrusive or whatnot.
If you want it and need it, use it, by all means. I am not forcing
anybody to use anything. Plus, pattern matching is useful when it is
useful, which is a tautology. Sometimes it is not all that useful.
But I do agree that certain things *should* be made standard.
Cheers
--
Marco
ELS 2009 www.european-lisp-symposium.org
On Apr 29, 2:22 am, Kenneth Tilton <·········@gmail.com> wrote:
> We need a Challenger's Cup showdown between Clojure, Qi, and NewLisp
> before CL crushes them in the final.
although I don't agree, this definitely should be in the fortunes
file... ^_^