Has anyone done any thought on the usage of Lisp as an internet
language? I know that some work exists on the issue but I haven't
seen too much discussion on it here.
I know that one site
(http://www.ai.mit.edu/projects/iiip/doc/cl-http/server-paper.html)
refers to the usage of Lisp as a server, but has anyone heard of any
work of people intending to utilize lisp in ways similar to Java.
For example, has anyone seen anything where lisp is used as the
scripting language of webpages? It seems to me that it would be
possible to write a web browser with a lisp interpreter in it so that
sophisticated client-server lisp programming could be done.
I've started playing around with some ideas on this but I haven't
developed anything formal. However, I would like to hear from others
who have ideas and/or interests in this.
If you have any information on this, or would like to discuss this
issue, please contact me.
Sincerely yours,
Arthur Ed LeBouthillier
In article <················@news.cyberg8t.com>,
Arthur Ed LeBouthillier <········@cyberg8t.com> wrote:
>Has anyone done any thought on the usage of Lisp as an internet
>language? I know that some work exists on the issue but I haven't
>seen too much discussion on it here.
There's been some discussion about compiling Lisp into Java bytecodes.
That way, any Java-enabled browser would be able to execute these applets
(once it's compiled, the original source language is immaterial).
Getting Lisp accepted as a real scripting language would require overcoming
all the "why Lisp failed in the marketplace" hurdles once again. I
wouldn't expect the major browser vendors to rush to add it to their code
before there's significant demand. You could do it as a plug-in, and if it
becomes popular enough that might encourage them to make it a built-in
feature.
But is a second Internet scripting language (JavaScript won't go away)
really worth the bloat in the browsers that will be needed to support them?
I agree that JavaScript isn't the best scripting language in the world, but
for the kinds of things one tends to do with web page scripts it's
adequate. If you need something more complex, you should use applets.
--
Barry Margolin
BBN Corporation, Cambridge, MA
······@bbnplanet.com
(BBN customers, call (800) 632-7638 option 1 for support)
On 15 Mar 1997 11:22:36 -0500, Barry Margolin <······@bbnplanet.com>
wrote:
>There's been some discussion about compiling Lisp into Java bytecodes.
>That way, any Java-enabled browser would be able to execute these applets
>(once it's compiled, the original source language is immaterial).
That's a good idea. I've considered that one.
>Getting Lisp accepted as a real scripting language would require overcoming
>all the "why Lisp failed in the marketplace" hurdles once again. I
>wouldn't expect the major browser vendors to rush to add it to their code
>before there's significant demand. You could do it as a plug-in, and if it
>becomes popular enough that might encourage them to make it a built-in
>feature.
I'm not sure that I would care whether it is "popular." To me, it
would be a thought-experiment as well as the development of
additionally capabilities into the lisp world. For all I care, it
could remain a curiosity in the Lisp world and still be a successful
project.
What I've been playing with (although it's not finished) is using
XLISP21W server as the interpreter to a simple browser. that
way, I don't have to rewrite a complete interpreter. The shell is
Visual-Basic based but it is hardly complete.
Does LISP offer advantages over other languages in certain
applications? Most definitely yes. My idea would be to explore what
advantages might be offered by using a language like Lisp as a
scripting/page description langauge as well as whatever benefits that
might be accrued from its unique capabilities.
What might those capabilities be? Well, lisp excels in symbolic
representations so might we see better web (client/server)
applications that use those features (I don't know what they might
be). Additionally, lisp is a dialectically fragmented language with
many different dialects and this keeps it from being a unified force.
Could such a simple, easy interface make at least one dialect of lisp
more of a force in popular computing? I don't know.
>But is a second Internet scripting language (JavaScript won't go away)
>really worth the bloat in the browsers that will be needed to support them?
>I agree that JavaScript isn't the best scripting language in the world, but
>for the kinds of things one tends to do with web page scripts it's
>adequate. If you need something more complex, you should use applets.
Perhaps, but that argument might be made in general (i.e. Do we really
need any language other than Fortran?). As someone interested with
lisp, I wonder what kind of benefits might be derived in a
client/server environment.
Art LeBouthillier
On 15 Mar 1997 11:22:36 -0500, Barry Margolin <······@bbnplanet.com>
wrote:
>In article <················@news.cyberg8t.com> you write:
>>Perhaps, but that argument might be made in general (i.e. Do we really
>>need any language other than Fortran?).
>
>And indeed, even though Fortran and COBOL are two of the most successful
>languages in the computer industry, they aren't available as Internet
>languages in browsers.
Nor am I advocating that they should be. What I am suggesting is that
client/server capabilities be experimented with as an additional
feature/library/capability for Lisp programmers. I really couldn't
care less whether such capabilities do or don't exist for other
languages. That's not my point.
As I envision this, it would be a browser that would be able to
communicate with a lisp interpreter and some routines which could
facilitate demonstration/control of the browser.
In my mind, this fills a need. The need is the ability to adequately
distribute lisp programs. One of the biggest problems I've seen with
regard to using lisp to write programs is its distribution and
execution.
The interpretive environment of lisp is wonderful for development but
it sucks for distribution and execution of finished programs. Do I
tell a user who has never before even seen a lisp interpreter that he
should "just start the interpreter, load this library, and type (go)?"
That's more than most would ever want to do.
A browser capability would provide an enhanced, single interface to
execute lisp programs. In environments as exist on PCs, it would
provide the ability to put an icon which when double klicked would
load and execute a lisp program.
An additional benefit of this approach would be to provide these same
capabilities over local/wide area networks.
If you've got so much time to advocate against the development of lisp
enhancements, why don't you go to alt.politics.java and tell the rest
of the world that they should not consider any langague other than
java.
This idea has some merit, it has some benefits to lisp and the lisp
community and I couldn't care less about whether or not Netscape or
Explorer include these capabilities. The point is to provide
enhancements to benefit lisp users, and the distribution and execution
of lisp programs.
Art Ed LeBouthillier
Let me first state that it is not my intention to make this a flame
discussion as is so common on the internet. If there is someone who
has ideas on this, I'd like to hear from them.
It is not my intention to insult or antagonize Mr. Margolin
Art
Arthur Ed LeBouthillier <········@cyberg8t.com> wrote in article
> Asking about internet lisp examples.
See http://people.delphi.com/gjc/chtml.html
For an example of CGI scripting in Scheme.
> Do I
> tell a user who has never before even seen a lisp interpreter that he
> should "just start the interpreter, load this library, and type (go)?"
Fortunately you can easily hide the loading of the lisp interpreter.
Also you can hide the lisp source code too. Which is why SIOD
has a "csiod" command to do both. See how it is done in ms windows
http://people.delphi.com/gjc/winsiod.html , or unix
environment http://people.delphi.com/gjc/siod.html
Frankly I sometimes use SIOD in situations where I need quick
time-to-market in some portable module, but I don't want to
'give away' the technique or make it appear 'cheap and easy
to rip off' by writing it in Perl.
So LISP may be the ultimate consultants language.
-gjc
p.s. Of course if the lisp interpreter takes 5 seconds to 'come up'
it is difficult to hide. But SIOD starts up in a few hundred micro seconds
on some machines. A little longer on others.
On 18 Mar 1997 10:43:44 GMT, "George J. Carrette" <···@delphi.com>
wrote:
>Arthur Ed LeBouthillier <········@cyberg8t.com> wrote in article
>> Asking about internet lisp examples.
>
>See http://people.delphi.com/gjc/chtml.html
>
>For an example of CGI scripting in Scheme.
>
>> Do I
>> tell a user who has never before even seen a lisp interpreter that he
>> should "just start the interpreter, load this library, and type (go)?"
>
>Fortunately you can easily hide the loading of the lisp interpreter.
>Also you can hide the lisp source code too. Which is why SIOD
>has a "csiod" command to do both. See how it is done in ms windows
>http://people.delphi.com/gjc/winsiod.html , or unix
>environment http://people.delphi.com/gjc/siod.html
>
Thanks, I'll check it out.
Art
On 18 Mar 1997 10:43:44 GMT, "George J. Carrette" <···@delphi.com>
wrote:
>Fortunately you can easily hide the loading of the lisp interpreter.
>Also you can hide the lisp source code too. Which is why SIOD
>has a "csiod" command to do both. See how it is done in ms windows
>http://people.delphi.com/gjc/winsiod.html , or unix
>environment http://people.delphi.com/gjc/siod.html
Thanks for the SIOD reference; it is very good. I still have
to review it more but it looks very interesting.
Art
Barry Margolin <······@bbnplanet.com> wrote in article
<··········@pasilla.bbnplanet.com>...
> But is a second Internet scripting language (JavaScript won't go away)
> really worth the bloat in the browsers that will be needed to support
them?
Microsoft seems to feel that there is reason to allow an infinite
number of scripting languages. Very different from the Netscape
attitude of course.
Already the Microsoft browser ships with Visual Basic and Java,
and has hooks to add Scheme or whatever you like.
Bloat: Look at it another way. Say you are developing an application
with Microsoft Internet Explorer at the platform. If you created the
"Active-X" control that allowed for Scheme scripting it could very
well be that your application with scheme embedded in HTML
would take up less memory than an equivalent Javascript or Java
application. So the users would see a faster application.
Java is really fat on the microsoft platform compared with C++
or Visual Basic scription.
OK. So use Visual Basic.
Keep in mind that even Netscape allows for applet-interpreter plugins;
look into SafeTcl, for example. All someone would have to do is write
the equivalent interpreter with environment as a plug-in and it
becomes instantly available to anyone that wants it, assuming you
compile the plug-in for their platform.
--
Alexander Williams ········@··················@photobooks.com}
[ Alexandrvs Vrai, Prefect 8,000,000th Experimental Strike Legion ]
[ BELLATORES INQVITI --- Restless Warriors ]
====================================================================
Barry Margolin <······@bbnplanet.com> writes:
>There's been some discussion about compiling Lisp into Java bytecodes.
For Scheme (a small dialect of Lisp), it's been _done_.
>But is a second Internet scripting language (JavaScript won't go away)
>really worth the bloat in the browsers that will be needed to support them?
I've just been studying Javascript. It's amazing what people will
put up with (warnings that "if your recursion doesn't stop, netscape
will crash" for example). Scheme could certainly do what Javascript
does, and judging from siod, it'd be smaller, too. In fact, it is not
clear to me that there need be any serious bloat at all. Javascript is
a language with latent typing, and its data structures are almost a
subset of Scheme's. (Javascript objects are a cross between extensible
arrays and hash tables; if you can support that, Scheme vectors are just
a teeny tiny step away.) I don't see any reason why one couldn't have a
Scheme system _plus_ Javascript objects and a Javascript parser, with
the Javascript being turned into the same executable form, whatever that
is, as Scheme.
>I agree that JavaScript isn't the best scripting language in the world, but
>for the kinds of things one tends to do with web page scripts it's
>adequate. If you need something more complex, you should use applets.
Well, given the similarity of the models underlying Javascript and Lisp,
that's pretty much saying "Lisp-like languages are useless for serious
computing". The whole Lisp lesson, after all, is that Lisp-like
languages don't _have_ to be slow! (Anyone know how Javascript objects
are actually implemented? Do they use the slow naive implementation,
or do they hash, or what?)
--
Will maintain COBOL for money.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
··@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:
> I don't see any reason why one couldn't have a Scheme system _plus_
> Javascript objects and a Javascript parser, with the Javascript
> being turned into the same executable form, whatever that is, as
> Scheme.
Not (yet) Scheme, but one of the Lisp-based web browsers, Emacs W3,
has file w3-jscript.el, which says:
;; FIXME! Well, actually IMPLEMENTME!
(provide 'w3-jscript)
though IMHO first supporting DSSSL style sheets (Scheme expressions),
would be more at least more tasteful.
--
Apologies for any late posts appearing to ignore others because of
news system/feed problems.
In article <················@news.cyberg8t.com>,
Arthur Ed LeBouthillier <········@cyberg8t.com> wrote:
>Has anyone done any thought on the usage of Lisp as an internet
>language? I know that some work exists on the issue but I haven't
>seen too much discussion on it here.
Blackboard Technology's NetGBB product is built using a
remote evaluation facility where the server can provide a
full Common Lisp environment to the client (if desired).
Remote, just in time compilation is as easy as:
(eval-at-node :my-node '(progn (defun houdy ()
(print "HI"))
(compile 'houdy)
(houdy)))
Full access to the Common Lisp environment is provided
only when authenticated; and access to the environment
can also be restricted to a defined set of explicity
allowed operators.
Blackboard Technology's NetGBB is used to create
dynamic distributed organizations of blackboard
and agent-based systems.
On 16 Mar 1997 01:11:33 GMT, ····@cs.umass.edu (dan corkill) wrote:
>Blackboard Technology's NetGBB product is built using a
>remote evaluation facility where the server can provide a
>full Common Lisp environment to the client (if desired).
>Remote, just in time compilation is as easy as:
>
> (eval-at-node :my-node '(progn (defun houdy ()
> (print "HI"))
> (compile 'houdy)
> (houdy)))
>
>Full access to the Common Lisp environment is provided
>only when authenticated; and access to the environment
>can also be restricted to a defined set of explicity
>allowed operators.
>
>Blackboard Technology's NetGBB is used to create
>dynamic distributed organizations of blackboard
>and agent-based systems.
Thanks, I'll check it out.
Art
In article <··········@netnews.alf.dec.com>,
·······@uxtlaser.alf.dec.com (Alex Williams) writes:
>Keep in mind that even Netscape allows for applet-interpreter plugins;
>look into SafeTcl, for example. All someone would have to do is write
>the equivalent interpreter with environment as a plug-in and it
>becomes instantly available to anyone that wants it, assuming you
>compile the plug-in for their platform.
That's the approach I took with the Tube mobile code system. Plugin
forwards Scheme program onto a Tube site and tells it which window to
display in. Then reparent window to it and you get applets. The
Scheme interpreter is a separate process. When you move away from a
page in Netscape, the plugin contacts the Tube site and returns the
current state of the Scheme program's execution - so it can be restarted
if the user revisits the page.
When I've finished writing up my PhD I want to tidy up all this stuff and
release it for ftp. Oh well, back to 'vi thesis.tex'. Sigh.
Oh, Kawa (Scheme->JVM) is good - I ported my state-saving interpreter to
it in no time.
Dave
--
David Halls, ·····@cl.cam.ac.uk
3rd Year PhD student
University of Cambridge Computer Laboratory