Until today, I was unaware that the Mozilla project is using CL.
http://lxr.mozilla.org/mozilla/source/js2/semantics/
"js/semantics contains experimental code used to generate LR(1) and
LALR(1) grammars for JavaScript as well as compile and check formal
semantics for JavaScript. The semantics can be executed directly or
printed into either HTML or Microsoft Word RTF formats.
This code is written in standard Common Lisp. It's been used under
Macintosh Common Lisp 4.0, and Allegro Common Lisp 5.0.1 for Windows,
but should also work under other Common Lisp implementations.
Contact Waldemar Horwat (········@netscape.com or ········@acm.org) for
more information."
There is a lot of CL code that looks, to my eye, to be excellent quality
work. The code is all under the MPL. JS2 is a Moz. extension, I saw on
irc.mozilla.org, with perhaps some interesting new language features. I
am curious about Mr. Horwat's influence on those features, given his
approach to JS2.
Jeff Caldwell
Jeff Caldwell wrote:
> Until today, I was unaware that the Mozilla project is using CL.
>
> http://lxr.mozilla.org/mozilla/source/js2/semantics/
>
Hi --
This has nothing to do with your post, except that you mention CL +
Mozilla.
Mozilla is, nowadays, more than simply a browser. It's has taken shape
as a platform for development, as some articles that came out last year
pointed out.
Don't you think it's theoretically possible to ship a Common Lisp "VM"
(like a Java VM) to work with Mozilla? Say, CLISP (multiplatform). And
then have all the "advantages" of Java (which all boil down to having
downloaded a JVM that will interact with a browser, and then write some
code for that, IMHO).
Regs
HL
synthespian wrote:
> Don't you think it's theoretically possible to ship a Common Lisp "VM"
> (like a Java VM) to work with Mozilla? Say, CLISP (multiplatform). And
> then have all the "advantages" of Java (which all boil down to having
> downloaded a JVM that will interact with a browser, and then write some
> code for that, IMHO).
I don't see any optimism in Lisp Community here.
Indeed, look into related discussion:
http://groups.google.de/groups?dq=&hl=de&lr=&ie=UTF-8&threadm=beja6d%241160%241%40f1node01.rhrz.uni-bonn.de&prev=/groups%3Fdq%3D%26num%3D25%26hl%3Dde%26lr%3D%26ie%3DUTF-8%26group%3Dcomp.lang.lisp%26start%3D25
In this discussion Parrot was discussed as a possible starting point.
Nobody supported this idea; this post seems to be representative:
http://groups.google.de/groups?q=g:thl4181453437d&dq=&hl=de&lr=&ie=UTF-8&selm=costanza-537A06.10590709072003%40news.netcologne.de
P.S.
USA was united to be a stronger country.
USSR was united to be a stronger country.
Germany was united to be a stronger country.
Europe was united to be a stronger community.
Lisp community is still diverse in a way.
Indeed, why creators of *single* Lisp implementation should think of
VM?! Developers of this *single* implementation do not need this
basis very much. You question will be rather consideed by them like:
"Huh, do they need a compact Lisp for something like those guys who
work with embeded devices? --OK, we'll make the kernel more comapct
for them. But why do they speak about VM?.."
Something like that :-)
This bread is eaten by Java, where motivation was supported at
corporational level.
I'd be happy to be wrong.
/Valery
"Valery" <········@mail.ru> wrote
> synthespian wrote:
> > Don't you think it's theoretically possible to ship a Common Lisp "VM"
> > (like a Java VM) to work with Mozilla? Say, CLISP (multiplatform). And
> > then have all the "advantages" of Java (which all boil down to having
> > downloaded a JVM that will interact with a browser, and then write some
> > code for that, IMHO).
> This bread is eaten by Java, where motivation was supported at
> corporational level.
Nobody use applets anymore these days.
The battle is on the servers where Common Lisp has unfair technical
advantages against Java. And unfair non technical dis-advantages as well. :-(
> I'd be happy to be wrong.
Be happy! ;-)
Marc
Marc Battyani wrote:
> Nobody use applets anymore these days.
?
Could you expand this statement, please?
>> I'd be happy to be wrong.
> Be happy! ;-)
Do you have something concrete to say?
thank you.
--
Valery
In article <····························@posting.google.com>,
········@mail.ru (Valery) wrote:
> I don't see any optimism in Lisp Community here.
> Indeed, look into related discussion:
>
> http://groups.google.de/groups?dq=&hl=de&lr=&ie=UTF-8&threadm=beja6d%241160%24
> 1%40f1node01.rhrz.uni-bonn.de&prev=/groups%3Fdq%3D%26num%3D25%26hl%3Dde%26lr%3
> D%26ie%3DUTF-8%26group%3Dcomp.lang.lisp%26start%3D25
>
> In this discussion Parrot was discussed as a possible starting point.
> Nobody supported this idea; this post seems to be representative:
>
> http://groups.google.de/groups?q=g:thl4181453437d&dq=&hl=de&lr=&ie=UTF-8&selm=
> costanza-537A06.10590709072003%40news.netcologne.de
Wow - typically people regard me as being a little bit too optimistict,
and now this! ;) (And I don't think that I am representative either.)
I am sorry, but I think you are quoting me out of context and don't seem
to get the point. However, I think it is understandable why this is the
case - you are relatively new to Lisp and it takes quite a while until
one finally gets it. (This is more or less taken from a famous quote by
Eric Raymond:
"Lisp is worth learning for the profound enlightenment experience you
will have when you finally get it; that experience will make you a
better programmer for the rest of your days, even if you never actually
use Lisp itself a lot.")
There is a long history that newbies tend to see a need for a more
mainstream syntax instead of those apparently strange s-expressions.
Here is a quote from a famous paper by Richard Gabriel and Guy Steele
about the history of Lisp (see http://www.dreamsongs.com/Essays.html):
"[...] because Lisp makes it easy to play with program representations,
it is always easy for the novice to experiment with alternative
notations. Therefore we expect future generations of Lisp programmers to
continue to reinvent Algol-style syntax for Lisp, over and over and over
again, and we are equally confident that they will continue, after an
initial period of infatuation, to reject it. (Perhaps this process
should be regarded as a rite of passage for Lisp hackers.)"
Why do I quote this? Well, it seems to me that you are currently going
through a similar process - however, not wrt the syntax but rather wrt
the implementation of Lisp. [1] I am pretty sure that, if you decide to
stick to Lisp, then you will see at a certain stage that the points you
raise are not as important as you seem to think right now.
Note that I don't say that they are completely unimportant - but there
will certainly be easier ways to deal with them. The idea of Perl and
Python is to use them as embeddable scripting languages, so there will
probably be a very simple way to embed Parrot inside a Common Lisp
implementation. This allows you to interoperate with Perl/Python, and
this is probably the most important issue for practical cases. The use
of Parrot as a target platform is very likely to remain a secondary
issue, especially because the JVM and .NET won't go away either.
> Lisp community is still diverse in a way.
Diversity is beautiful. I am only half-joking. The Lisp way of thinking,
at leat as I perceive it, is that you can build your own Lisp dialect
according to the needs of the concrete you want/need to solve.
Everything beyond solving concrete problems is secondary.
If _you_ want to implement a Lisp on Parrot, then just do it. You will
certainly learn a lot in that process. But don't make assumptions about
other people's needs.
> Indeed, why creators of *single* Lisp implementation should think of
> VM?! Developers of this *single* implementation do not need this
> basis very much.
Lisp vendors are well-known for keeping focused on their customers'
needs. When they detect that your claim is true they will probably start
to work on this. If they don't start they will probably have very good
reasons for their decision.
This all boils down to the fact that you need to contribute to the
community if you want to get certain things done. Ask vendors to support
your favorite platform, participate in existing open source projects, or
roll your own project. (Or wait until someone implements a Lisp/Scheme
for Parrot - as I said before, I think this will probably happen some
time soon.)
> I'd be happy to be wrong.
Start doing something to find out whether you're wrong or not. It will
be worth it in either case.
Pascal
[1] Here is a paraphrase: We expect future generations of Lisp
programmers to continue to reimplement Lisp, over and over and over
again, and we are equally confident that they will continue, after an
initial period of infatuation, reject their reimplementations. It seems
to me that this actually happens, especially in the Scheme community. ;)
Pascal Costanza <········@web.de> writes:
> Note that I don't say that they are completely unimportant - but there
> will certainly be easier ways to deal with them. The idea of Perl and
> Python is to use them as embeddable scripting languages, so there will
> probably be a very simple way to embed Parrot inside a Common Lisp
> implementation. This allows you to interoperate with Perl/Python, and
> this is probably the most important issue for practical cases. The use
> of Parrot as a target platform is very likely to remain a secondary
> issue, especially because the JVM and .NET won't go away either.
[ ... snip ...]
> (Or wait until someone implements a Lisp/Scheme for Parrot - as I
> said before, I think this will probably happen some time soon.)
If Parrot stays relatively stable, I'd think it would be more likely
that someone would implement a Parrot VM in CL than a CL on Parrot.
Hell, a compiler from Parrot bytecode functions to Lisp wouldn't be
too hard. Then you could use the native Lisp compiler, bada-bing
bada-boom, no need for a JIT.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Centuries ago, Nostradamus foresaw when ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) would write:
> If Parrot stays relatively stable, I'd think it would be more likely
> that someone would implement a Parrot VM in CL than a CL on Parrot.
> Hell, a compiler from Parrot bytecode functions to Lisp wouldn't be
> too hard. Then you could use the native Lisp compiler, bada-bing
> bada-boom, no need for a JIT.
I'm not sure I agree.
The problem with that is that it requires that you also maintain a
"standard" way of linking CL to C libraries. An important component
of Parrot is the "loadlib" operator, which is used to draw in
libraries, and "dlfunc," which creates a Parrot subroutine out of a
DLL function.
A _lot_ of Parrot functionality is intended to be drawn in that way,
which seems likely, to me, to make it a bit harder to deal with. The
Parrot "signatures" can probably be made to correspond to something in
(say) CMU/CL, but it would be rather more challenging vis-a-vis CLISP,
where attaching in foreign functions requires compiling some C.
--
let name="aa454" and tld="freenet.carleton.ca" in String.concat ·@" [name;tld];;
http://www.ntlug.org/~cbbrowne/lisp.html
"Of course 5 years from now that will be different, but 5 years from
now everyone will be running free GNU on their 200 MIPS, 64M
SPARCstation-5." -- Andrew Tanenbaum, 1992.
Christopher Browne <········@acm.org> writes:
> Centuries ago, Nostradamus foresaw when ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) would write:
> > If Parrot stays relatively stable, I'd think it would be more likely
> > that someone would implement a Parrot VM in CL than a CL on Parrot.
> > Hell, a compiler from Parrot bytecode functions to Lisp wouldn't be
> > too hard. Then you could use the native Lisp compiler, bada-bing
> > bada-boom, no need for a JIT.
>
> I'm not sure I agree.
Well, I'm not saying it's necessarily going to happen, just that
Parrot-on-CL is a lot more likely than CL-on-Parrot. Also...
> The problem with that is that it requires that you also maintain a
> "standard" way of linking CL to C libraries. An important component
> of Parrot is the "loadlib" operator, which is used to draw in
> libraries, and "dlfunc," which creates a Parrot subroutine out of a
> DLL function.
I wasn't thinking all-ANSI CL, so much as a CMUCL-specific
implementation, or maybe CL+UFFI.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Valery A.Khamenya
Subject: Re: CL used in Mozilla
Date:
Message-ID: <3f12c1c1@shknews01>
Pascal Costanza wrote:
> I am sorry, but I think you are quoting me out of context and don't seem
> to get the point.
I did not quote anything. Context is available in link I've provided.
(and, please, let's assume I got the point)
> "Lisp is worth learning for the profound enlightenment experience you
> will have when you finally get it; that experience will make you a
> better programmer for the rest of your days, even if you never actually
> use Lisp itself a lot.")
Like with Latin, I remember a similar from P.Graham.
> Why do I quote this? Well, it seems to me that you are currently going
> through a similar process - however, not wrt the syntax but rather wrt
> the implementation of Lisp. [1] I am pretty sure that, if you decide to
> stick to Lisp, then you will see at a certain stage that the points you
> raise are not as important as you seem to think right now.
> Note that I don't say that they are completely unimportant - but there
> will certainly be easier ways to deal with them.
Some things are important beside what I think of it.
Just for example. If one has to create an application with a GUI, then a
lot of implementations are out of scope. Especially for those, who got a
chance to work in Delphi-like environments (BCB/Kylix) -- afterwards it
is very difficult to agree on something less then that. What do we have
then? only ACL? Quite expensive choice.
For those who are extremely aggressive fan of (X)Emacs-based
development: please be free to skip my last paragraph, we'll never find
a common point (nevertheless I use Emacs very often).
> The use of Parrot as a target platform is very likely to remain a
secondary
> issue, especially because the JVM and .NET won't go away either.
I could agree. What remains unclear where is the Lisp's baby in this
kindergarten designed for Lisp? why Java's VM? why .NET? why not Lisp?
Interesting, but nobody of those big lispers says simply "yeah, we've
lost this round".
>> Lisp community is still diverse in a way.
> Diversity is beautiful. I am only half-joking. The Lisp way of thinking,
> at leat as I perceive it, is that you can build your own Lisp dialect
> according to the needs of the concrete you want/need to solve.
> Everything beyond solving concrete problems is secondary.
Nevertheless I fully agree with your last sentence, I do not understand
how it explains that it is better to spread efforts of Lisp Community?
"Lisp community has to few resources" -- not my words.
> If _you_ want to implement a Lisp on Parrot, then just do it.
Are you joking? I have a lot of things to do. Making project like Parrot
is about several years of personal time investment (even with Lisp).
> You will certainly learn a lot in that process.
I agree, but I could learn from a smaller hobby application.
> But don't make assumptions about other people's needs.
sorry. I will do. It is funny to make assumptions, because of the fact
that we are human beings. I see that it is not your way of thinking, not
yours behavior.
And, I know, there is a *lot* of developers like me, who have to supply
those GUIs for users nevertheless those developers never use it
themselves. Therefore they choose Delphi-and-a-like for rapid
prototyping. The question is:
why they don�t use ACL instead of Kylix/Delphi/BCB/Java/�
Let me make assumption about people like I am.
> Lisp vendors are well-known for keeping focused on their customers'
> needs. When they detect that your claim is true they will probably start
> to work on this. If they don't start they will probably have very good
> reasons for their decision.
1. vendors are just human beings.
2. they could deny low-budget customers because of *decision*, and not
because of the fact that low-budget sales can not build their income.
3. Let's focus our attention on ACL and Delphi. It is quite clear that
they have similar intention with GUI builder feature.
Now put in Google: "Allegro CL". You'll find 43'000 pages.
then put: "Borland Delphi" -- 315'000 pages (And the same with Kylix)
You could imagine the difference in activity.
> This all boils down to the fact that you need to contribute to the
> community if you want to get certain things done.
> Ask vendors to support your favorite platform, participate in existing
> open source projects, or roll your own project.
Could I rather contribute 200-300 Euro for purchasing "Allegro CL
smaaaaall personal edition"? -- NO. And I buy Kylix.
> (Or wait until someone implements a Lisp/Scheme
> for Parrot - as I said before, I think this will probably happen some
> time soon.)
wait. Parrot and Lisp is not *that* critical for me. I do like Lisp as
much as functional approaches in programming. I just do not see any good
signs to say "well today they (i.e. lispers) are not strong enough but
tomorrow it definitely should be".
Look, even up to now you�ve never said "Huh, general-purpose-VM could be
a good idea for lispers". You just say I think this will probably happen
some time soon. ...such a needed embarrassment like Perl, Python or
Scheme, kind of misunderstanding needed for those stupid and immature
customers :)
>> I'd be happy to be wrong.
> Start doing something to find out whether you're wrong or not. It will
> be worth it in either case.
You are more then just right here.
> [1] Here is a paraphrase: We expect future generations of Lisp
> programmers to continue to reimplement Lisp, over and over and over
> again, and we are equally confident that they will continue, after an
> initial period of infatuation, reject their reimplementations. It seems
> to me that this actually happens, especially in the Scheme community. ;)
BTW, why should we speak about *implementations* in this context??
Let's be honest. Let's speak about Lisp standards, which predefine the
Lisp implementations. Is there something new? CL was the first
standardized OO language. Is there nothing to improve still? or we have
learn nothing from other languages after CL was standardized?
Let's speak about Lisp standards first, and then we shouldn't waste our
time for investing our lifespan in deadborn implementations.
I hope I am not the only one who says:
"why CL is too big and Scheme is too small." :)
With best regards from 5-years-as-Lisp-lover!
--
Valery
[hmm, it seems I hit the wrong button earlier and did not notice...].
>
> There is a long history that newbies tend to see a need for a more
> mainstream syntax instead of those apparently strange s-expressions.
> Here is a quote from a famous paper by Richard Gabriel and Guy Steele
> about the history of Lisp (see http://www.dreamsongs.com/Essays.html):
>
> "[...] because Lisp makes it easy to play with program representations,
> it is always easy for the novice to experiment with alternative
> notations. Therefore we expect future generations of Lisp programmers to
> continue to reinvent Algol-style syntax for Lisp, over and over and over
> again, and we are equally confident that they will continue, after an
> initial period of infatuation, to reject it. (Perhaps this process
> should be regarded as a rite of passage for Lisp hackers.)"
>
hmm, I remember this one. my 'lb' syntax, which I have since stopped using,
was such an example.
actually I had considered implementing another syntax (which I planned to
call 'lb2') which would be a fix of a lot of the problems found in 'lb'
(such as notable annoyances from dealing with an indentation syntax), and
would likely resemble a hybrid of s-expressions, c, and basic.
the reason for this, though, is not because I have a problem with using
s-expressions, but rather I feel that they have a possible tendancy to scare
off newbies. I might be able to capture more newbies if I have an alternate
syntax that sort-of resembles basic and c...
likely all the base stuff will continue being written in s-expressions
though, as the syntax I was imagining will not be that great for some things
(ie: intricate code).
this is just one of many things I want to do, talk is easier than doing, and
I am dragging in getting stuff done.
········@mail.ru (Valery) wrote in message news:<····························@posting.google.com>...
>
> USA was united to be a stronger country.
The USA has one official language. People can move easily among the
states. The states have a quite a lot of autonomy; for instance some
impose the death penalty and some do not.
If you want to unite people, you have to leave them a lot of autonomy.
Good fences make good neighbors and all that.
> USSR was united to be a stronger country.
Didn't work. Why? It was coerced, centrally controlled, and generaly
based on immoral socialist principles.
> Germany was united to be a stronger country.
Only less than half a century after it was originally coerced into
division! Does such a re-union even count as a union?
The Czech Republic and Slovakia, on the other hand, split.
> Europe was united to be a stronger community.
Economically only, not in language, culture, etc.
> Lisp community is still diverse in a way.
See above.
We could say:
Computers were united to form an planet-wide network.
yet we still have diverse operating systems, programming environments,
etc---notwithstanding some notable, large monocultures.
On Mon, Jul 14, 2003 at 12:31:14PM -0700, Kaz Kylheku wrote:
> The USA has one official language.
You meant to say "no official language", right?
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."