Browser scripting in Lisp, without Javascript

[Patrick May]

A recent discussion on Hacker News piqued my curiosity about how to
use Common Lisp or Scheme instead of Javascript for client side
scripting in a web browser. An hour or so of Googling didn't yield any
insights, so clearly I'm looking for the wrong terms.

There are some options for compiling Lisp to Javascript, but I'm
looking for how to completely replace it. What would be involved in
supporting a tag like this:

<script type="text/lisp" language="common-lisp" src="web-ui.lisp">

in a browser like Firefox or Chrome? Do these browsers make an API
available to all scripting engines or does support need to be built in?
Could it be done through a plugin?

Thanks,

Patrick

--
------------------------------------------------------------------------
http://www.softwarematters.org
Large scale, mission-critical, distributed systems design and
implementation. (C++, Java, Common Lisp, grid computing, SOA)

[Pascal J. Bourguignon]

Patrick May <pat...@softwarematters.org> writes:

> A recent discussion on Hacker News piqued my curiosity about how to
> use Common Lisp or Scheme instead of Javascript for client side
> scripting in a web browser. An hour or so of Googling didn't yield any
> insights, so clearly I'm looking for the wrong terms.
>
> There are some options for compiling Lisp to Javascript, but I'm
> looking for how to completely replace it. What would be involved in
> supporting a tag like this:
>
> <script type="text/lisp" language="common-lisp" src="web-ui.lisp">
>
> in a browser like Firefox or Chrome? Do these browsers make an API
> available to all scripting engines or does support need to be built in?
> Could it be done through a plugin?

AFAIK, no API or plugin. But use the source, Luke!

Now, of course, the problem would be to convince Firefox Foundation or
Google to take in a patch that would add CL as a scripting language for
their browser.

Alternatively, the problem would be to convince billions of users to
switch to your fork of a browser using CL instead of Javascript, and to
convince millions of web programmers to switch from Javascript to CL.


No, really, the most walkable path is to target asm.js and compile your
CL code to that.

--
__Pascal Bourguignon__
http://www.informatimago.com/
"Le mercure monte ? C'est le moment d'acheter !"

[Mark Tarver]

Shen is essentially an advanced FPL that compiles into a very simple Lisp KLambda which itself then compiles into a variety of languages including Javascript. You can find the JS version on

www.shenlanguage.org

Mark

[fee...@iro.umontreal.ca]

The Gambit Scheme system (https://github.com/feeley/gambit) has a few approaches to running Scheme in the browser.

1) You can use a version of Gambit-C that was compiled to JS using emscripten. You'll find a demo of that version here: http://feeley.github.io/gambit-in-the-browser . It has a REPL, an emacs compatible line-editor, and a hook to evaluate JS code.

2) If you are using Chrome you can use a version of Gambit-C compiled using NACL. The demo is at http://mzh.im/gambit-in-nacl and the code is at https://github.com/wsxiaoys/gambit-in-nacl .

3) You can use the "universal backend" to compile Scheme to JS (and also to Python, Ruby and PHP). Once Gambit is built, run the compiler with

gsc -c -target js program.scm

A description of the compilation approach used by "Gambit-JS" is in the paper "Efficient Compilation of Tail Calls and Continuations to JavaScript" (http://users-cs.au.dk/danvy/sfp12/papers/thivierge-feeley-paper-sfp12.pdf).

By the way, the HTML script tag for Lisp could be implemented in the server which would translate the Lisp code to JS (or simply send a precompiled file).

If you really want to support the Lisp script tag on the browser, then the browser has to have a Lisp compiler or interpreter. That is quite easy to do with Gambit (compiled to JS), but it will add some weight to your web app. I'm currently working on a much more compact Scheme interpreter in JS bootstrapped with Gambit-JS. It will provide a remote REPL to allow live remote debugging of web apps running in the browser.

Marc

[His Kennyness]

On Sunday, March 2, 2014 10:40:35 AM UTC-5, informatimago wrote:
> No, really, the most walkable path is to target asm.js and compile your

Cool, I did not know about asm.js.

But I dunno, its two claims to fame are speed (are we protein-folding in the client now?) and ease of retargeting a C/C++ compiler, something like asm.js that sees the world as just so many numbers.

Is that really a good target for a CL compiler?

-hk

[Madhu]

* His Kennyness <dbcffc1e-69bf-4135...@googlegroups.com> :
Wrote on Mon, 3 Mar 2014 15:33:41 -0800 (PST):

|
| Is that really a good target for a CL compiler?
|

Attend the next ILC. Read the "peer reviewed" papers. Get (re)educated ---Madhu

The investments that changed the computing landscape to where javascript
is the target started with the buying up and selling out of those "peers"

[rmal...@gmail.com]

yeah, shame that script tag text property only really accepts one single value

that said, you can at the very least run this javascript program implementing an old VM called a z-machine and run a text-adventure on it that in turn implements a fully functional Scheme interpreter:

http://iplayif.com/?story=http%3A%2F%2Fwww.ifarchive.org%2Fif-archive%2Fgames%2Fzcode%2Flists.z5

how cool is that? :)

hullo from namekuseijin

[D Herring]

On 03/02/2014 10:10 AM, Patrick May wrote:
>
> A recent discussion on Hacker News piqued my curiosity about how to
> use Common Lisp or Scheme instead of Javascript for client side
> scripting in a web browser. An hour or so of Googling didn't yield any
> insights, so clearly I'm looking for the wrong terms.

I started implementing a NPAPI (Netscape Plugin API) browser plugin a
few years ago, with the goal of allowing other languages to be used
for scripting. I quickly learned why Java applets are so isolated
from web content.

Just yesterday, the following email was sent to a NPAPI developers
mailing list.

""
Date: Tue, 04 Mar 2014 13:10:32 -0500
From: Benjamin Smedberg <...>
To: "plugin-...@mozilla.org" <plugin-...@mozilla.org>
Subject: A whitelist for automatic activation of plugins in Firefox

Because it may reach people who are not on other lists, I wanted to
note a policy that Mozilla recently announced about a whitelist for
automatic plugin activation:

https://blog.mozilla.org/security/2014/02/28/update-on-plugin-activation/

The goal of this is to provide additional time for plugin vendors who
are working to move away from plugins and to open web technologies but
haven't finished the transition or where web APIs aren't available.

Please follow up with me directly if you have questions.

--BDS
""


Back when I started, there was no API for a plugin to intercept script
text, interact with the document object model, etc. I emailed a few
NPAPI folks and they were somewhat receptive to the idea but said I
needed a working prototype first. i.e. demo it in Firefox or another
browser. That never happened.

After a bit of exploration through Mozilla code bases, I moved on to
other CL projects. I had proof that the road would be hard, and a
growing feeling that it was the wrong path anyway. Why build on top
of a broken baseline? (IMO HTML, CSS, and JS have some deep flaws,
Firefox UI choices have been questionable lately, etc.) Why not
leverage WebKit to build your own browser with added features? (such
as a better security model and a custom language or rendering model)
Getting people to install a new application is not much harder than
getting them to install a plugin...

Since then, there has been a big push to eliminate all "native"
plugins. The HTML canvas, video support, webcam support, and related
features are the "open web technologies" meant to replace them. Thus
I feel increasing resistance to plugin solutions, and even Java
Applets and Flash are in peril.

- Daniel

[Steve Gonedes]

fee...@iro.umontreal.ca writes:


< If you really want to support the Lisp script tag on the browser, then the
< browser has to have a Lisp compiler or interpreter.

I think this may have been a problem some time ago. The java sandbox
rings my bell.

< That is quite easy to do
< with Gambit (compiled to JS), but it will add some weight to your web app.
< I'm currently working on a much more compact Scheme interpreter in JS
< bootstrapped with Gambit-JS. It will provide a remote REPL to allow live
< remote debugging of web apps running in the browser.

Probably irrelevant; but w3 the emacs web browser used to have some code
for parsing web sites into TeX/ etc...

< Marc

[Madhu]

* D Herring <lf87lt$rbm$1...@dont-email.me> :
Wrote on Wed, 05 Mar 2014 17:15:24 -0500:

| After a bit of exploration through Mozilla code bases, I moved on to
| other CL projects. I had proof that the road would be hard, and a
| growing feeling that it was the wrong path anyway. Why build on top
| of a broken baseline? (IMO HTML, CSS, and JS have some deep flaws,
| Firefox UI choices have been questionable lately, etc.) Why not
| leverage WebKit to build your own browser with added features? (such
| as a better security model and a custom language or rendering model)
| Getting people to install a new application is not much harder than
| getting them to install a plugin...

Why are you kidding yourself? The `security model' for "webkit" appears
to come from the same servants of the wicked one as those who you are
trying to avoid; and the goal seems to be identical: to invert and
confound the definitions of "trust" for the adopting customer as he is
lead into the fire.

Consider Issue 39616 in chromium: XML with XSL not shown under file
<URL:https://groups.google.com/a/chromium.org/d/topic/chromium-bugs/kz2QWKrDnUo>

The local principal who bought the device and is responsible for
supplying the bandwidth, is "untrusted", while the adversary, the
spammer who shoves the bandwidth down the connection, is now the point
from where the trust flows.

<URL:http://stackoverflow.com/questions/5660116/unsafe-javascript-attempt-to-access-frame-in-google-chrome>

And I expect you will be given the same runaround, when trying to get
any value, from any "web app" that isn't contract-farmed down from the
48 million-cash-reserves or from the missing trillions. Except instead
of hammering at bugzilla.mozilla, you'll be making bandwidth-love to
google's servers, as if it was different equity pwning both.


PS. I can't access anything on groups.google, using javascript off, and
while implementing the same "same origin" policies that the W3C is
subverting. and the Location redirects reliably segfault the w3m on on
say debian based 12.04 systems. ---Madhu


--
"I've filed 30+ bugs for web browsers for two years (and I regret it
now). I'm not a major contributor for the web, but maybe I'm not just a
free rider. As a developer like that, let me say that the web platform
and browser vendors are unreliable and untrustworthy." -- comment on
http://blog.mozilla.org/security/2014/02/28/update-on-plugin-activation/

[gavino_himself]

cool idea

amber smalltalk compiles to js

java used to be a forced pluin install, would auto download java plugin

no reason why similar couldnt be doe with lisp

[Taegyoon Kim]

2014년 3월 3일 월요일 오전 12시 10분 43초 UTC+9, Patrick May 님의 말:

Try ParenJS | https://bitbucket.org/ktg/parenjs

Usage (in HTML)

Using script tag support: Once you include paren.js, any script tags in your document with type="text/paren" will be evaluated.

<script src="paren.js"></script>
<script>if(typeof(paren)==='undefined')document.write('<script src="http://jsutil.sourceforge.net/paren.js"><\/script>')</script>
<script type="text/paren">
(alert "hello")
</script>


You can also evaluate paren code from JavaScript using paren.eval(str).

<script type="text/javascript">
paren.compile(str); // return Paren program compiled to JavaScript
paren.eval(str); // evaluate Paren program
</script>

[derrr_fhurer]

On Sunday, March 2, 2014 7:10:43 AM UTC-8, Patrick May wrote:

this is a great idea I have also bene thinking abuot

I mean java or flash crap are already 100M+
with that you have full lisp interpreter as a firefox plugin

then all lisps power!

node.lisp!

[derrr_fhurer]

On Sunday, March 2, 2014 7:10:43 AM UTC-8, Patrick May wrote:

I think this is a great idea like I had said.

I also think paul graham had something when he said that server side programming is some thing that is little understood even today.

When you control the server, you can update anything anytime.

[polos...@gmail.com]

BTW, did you know that Lisp can easily turn WebKit into the most insecure browser possible?

See for yourself:

http://gitorious.org/eql/eql/blobs/master/screenshots/Examples-Browser.png

[m...@mitranim.com]

There's a JS implementation of Arc (Lisp dialect) underway: http://smihica.github.io/arc-js/ Registers its script tags in browser and lets you skip JS completely. See http://arclanguage.org and https://sites.google.com/site/arclanguagewiki/getting-started/tutorial for info on the dialect.

[Taegyoon Kim]

2014년 3월 3일 월요일 오전 12시 10분 43초 UTC+9, Patrick May 님의 말:

LispScript | https://bitbucket.org/ktg/lispscript