The eponymous sister article to this one discusses whether the one
future of Lisp is in end-user programming of highly distributed,
knowledge-based, interacting devices (cell phones, media centers,
including using web services (and maybe even programming them, but
that's the "old" c.l.l. and we've moved on beyond that! :-)). Step one
toward this is to get a Lisp onto these devices (we can do the end-user
part using Eval for now!)
My (limited) understanding of these devices is that thay are current
programmed using extremely lightweight languages: Forth, Erlang, C,
assembly. I know nearly nothing about how to program these sorts of
devices so I'm throwing the idea to the wind hoping that someone who
has actually programmed some of these devices will chime in:
Questions:
For those knowledgeable about Erlang (etc.): Would having the
flexibility of Lisp macros (and whatever else you get with Lisp that
you don't already have in Erlang) be worth it if you didn't have to pay
the price for a heavy-weight implementaion? (What exactly you can v.
can't have is TDB, of course.)
For those who program phones (etc.): Do these platforms generally come
with hardware-level simulators that one could try to build a Lisp into?
What do these cost? Is there some standard middleware model that the
above folks could build to? What are their constraints (today,
envisioned for the future)? What are the best resources for finding out
about these?
For those who build Lisps: What would one lose to make an extremely
lightweight Lisp, and get it onto these platforms?
I don't think that an experiment would be out of order. It couldn't be
that hard for all the lisp monkeys on this list to get together and
embed a Lisp on a cell phone or and iPod. (I'll even back it to a
limited extent!)
From: Pascal Costanza
Subject: Re: Too Much Caffeine II -- Is Lisp the new Erlang?
Date:
Message-ID: <4m2uafF47lgsU1@individual.net>
········@gmail.com wrote:
> The eponymous sister article to this one discusses whether the one
> future of Lisp is in end-user programming of highly distributed,
> knowledge-based, interacting devices (cell phones, media centers,
> including using web services (and maybe even programming them, but
> that's the "old" c.l.l. and we've moved on beyond that! :-)). Step one
> toward this is to get a Lisp onto these devices (we can do the end-user
> part using Eval for now!)
>
> My (limited) understanding of these devices is that thay are current
> programmed using extremely lightweight languages: Forth, Erlang, C,
> assembly. I know nearly nothing about how to program these sorts of
> devices so I'm throwing the idea to the wind hoping that someone who
> has actually programmed some of these devices will chime in:
>
> Questions:
>
> For those knowledgeable about Erlang (etc.): Would having the
> flexibility of Lisp macros (and whatever else you get with Lisp that
> you don't already have in Erlang) be worth it if you didn't have to pay
> the price for a heavy-weight implementaion? (What exactly you can v.
> can't have is TDB, of course.)
>
> For those who program phones (etc.): Do these platforms generally come
> with hardware-level simulators that one could try to build a Lisp into?
> What do these cost? Is there some standard middleware model that the
> above folks could build to? What are their constraints (today,
> envisioned for the future)? What are the best resources for finding out
> about these?
>
> For those who build Lisps: What would one lose to make an extremely
> lightweight Lisp, and get it onto these platforms?
>
> I don't think that an experiment would be out of order. It couldn't be
> that hard for all the lisp monkeys on this list to get together and
> embed a Lisp on a cell phone or and iPod. (I'll even back it to a
> limited extent!)
I think implementations like OpenLisp, clisp and some Scheme
implementations (probably also others) are good candidates for getting
them to run on cell phones. (There are already implementations of Java
and Python available for cell phones, again probably also others, so the
resource constraints don't seem that pressing.)
I think finding the right programming model is more relevant than the
actual language to be used. Colleagues of mine are working on some ideas
in this regard, see http://prog.vub.ac.be/amop/ for more information.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
> I think finding the right programming model is more relevant than the
> actual language to be used. Colleagues of mine are working on some ideas
> in this regard, see http://prog.vub.ac.be/amop/ for more information.
I agree (mostly) with this. In fact, I just skimmed Jessie Dedecker's
thesis (available via your pointer); It's terrific!
Her (His?) langauge is based on Scheme:
"Pic% is an extension of the language Pico, both languages were
designed and conceived by Theo D'Hondt and in a later stage also
codesigned by Wolfgang
De Meuter. Both these languages are used in an educational and research
context. Many of the design principles of Pico were borrowed from the
language
Scheme [AS96], that is to say that simplicity of the design of the
language was a
foremost concern. Next to the design principles, Pico also borrowed a
number of
concepts found in Scheme, such as a dynamic type system, first-class
abstract
grammar, continuations, closures and an interactive interpreter.
Concerning
the implementation, a Pico system also features a tail-recursive
interpreter and
a garbage collector to automatically reclaim memory that is no longer
in use.
However, Pico also differs from Scheme in a number of profound ways:"
[Uh oh...Here come the usual mistakes:]
"· Syntax: a common criticism against Scheme is that its prefix
syntax is hard
to read. For cultural reasons most people seem to read and understand
infix expressions better, probably because mathematical expressions are
also written using infix notation. Although Pico features infix
operators,
the goal was still to make its syntax as minimal and regular as
possible.
We have experienced in our courses and by writing and reading many
programs in Pico that giving it a more conventional syntax it enhances
the readability.
· Tables: in Scheme a distinction is made between lists and vectors,
while
in Pico indexable tables are used to represent both datastructures.
Also,
in Scheme the abstract grammar is made first-class by using lists,
whereas
Pico uses tables. I.e. a Scheme program is reified as a nested list,
whereas
a Pico program is reified as a nested table structure.
· No Special Forms: in the implementation of Scheme some
special-forms
have been introduced, because some language constructs such as control
structures need argument evaluation rules that differ from the standard
eager evaluation rules. In Pico there is no need for special forms.
Instead
Pico has richer parameter passing semantics, this is explained in
section 5.3.2."
Okay, so she (he?) messed up the syntax and removed macros, once again
leaving us with a brilliant non-extensible langauge. [The tables thing
isn't a mistake. It's neither here nor there from what I can tell, and
makes some things simpler in ways I have yet to understand, but which
is explained in the dissertation.]
I actually don't mean to dis this wonderful dissertation; Although I've
skimmed the entire thing, I haven't read it carefully enough to be able
to tell if it fits my requirements for a surface programming langauge
(which, it seems to me, demands macros!). But it's a terrific review of
everything interesting about ambient programming, and the language is
certainly damned close!
From: Pascal Costanza
Subject: Re: Too Much Caffeine II -- Is Lisp the new Erlang?
Date:
Message-ID: <4m35q4F48f0pU1@individual.net>
········@gmail.com wrote:
>> I think finding the right programming model is more relevant than the
>> actual language to be used. Colleagues of mine are working on some ideas
>> in this regard, see http://prog.vub.ac.be/amop/ for more information.
>
> I agree (mostly) with this. In fact, I just skimmed Jessie Dedecker's
> thesis (available via your pointer); It's terrific!
>
> Her (His?) langauge is based on Scheme:
His language.
> [Uh oh...Here come the usual mistakes:]
Don't tell me - I have discussions with them on an almost daily basis.
;) [1]
> Okay, so she (he?) messed up the syntax and removed macros, once again
> leaving us with a brilliant non-extensible langauge. [The tables thing
> isn't a mistake. It's neither here nor there from what I can tell, and
> makes some things simpler in ways I have yet to understand, but which
> is explained in the dissertation.]
As is explained in the dissertation, the language is based on Pico and
Pic%, and some of these features are directly inherited from those
languages. You can find more details at http://pico.vub.ac.be/
Pico is indeed used for teaching programmming to non-programmers and
non-computer-scientists, and it seems to be indeed a very effective tool
for that. The really interesting thing for teaching is not the syntax,
but the neat orthogonality of language features, at least IMHO.
> I actually don't mean to dis this wonderful dissertation; Although I've
> skimmed the entire thing, I haven't read it carefully enough to be able
> to tell if it fits my requirements for a surface programming langauge
> (which, it seems to me, demands macros!). But it's a terrific review of
> everything interesting about ambient programming, and the language is
> certainly damned close!
In AmbientTalk, Jessie uses a reflective layer to implement language
extensions, and this also seems to work pretty well. However, I have
some doubts with regard to efficient implementability, and in that
regard, macros indeed have some considerable advantages.
Pascal
[1] Well, maybe I am exaggerating a little bit here. ;) But I had some
discussions on that topic...
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
In article <··············@individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> (There are already implementations of Java
> and Python available for cell phones, again probably also others, so the
> resource constraints don't seem that pressing.)
I'm no expert here, but I was thinking along the same lines - If Java
runs on a device then shouldn't one be able to use sisc or kawa on it?
(both are schemes that run atop a JVM).
Wouldn't this also allow abcl (armed bear common lisp) to run on such a
device too (or are the resource constraints too limiting?)
Raffael Cavallaro wrote:
> In article <··············@individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
> > (There are already implementations of Java
> > and Python available for cell phones, again probably also others, so the
> > resource constraints don't seem that pressing.)
>
> I'm no expert here, but I was thinking along the same lines - If Java
> runs on a device then shouldn't one be able to use sisc or kawa on it?
> (both are schemes that run atop a JVM).
>
> Wouldn't this also allow abcl (armed bear common lisp) to run on such a
> device too (or are the resource constraints too limiting?)
The java on phones is normally J2ME, Java micro edition. I don't think
it would run Kawa or sisc, but it may.
In general there are two types of handset:-
1) Most handsets have a DSP processor and a general microprocessors.
The DSP deals with difficult comms protocol tasks like voice coding and
error correction. The MPU deal with the rest of the protocol and the
GUI.
2) High end handsets have three processor, a DSP, an MPU and an
"applications processor". The DSP performs it's normal tasks, the MPU
deal with the rest of the protocol. The app processor deals with the
GUI and the rest.
In case (1) getting a lisp up and running would be difficult because
the machines tend to be quite limited. They may also have hard
realtime requirements. It wouldn't be impossible though.
In case (2) things are much better. App processors are things like
200MHz ARM processors with a few mb of RAM. These things already run
Linux, they could probably run a small Common Lisp implementation. They
could definitely run a cut down lisp, or a Scheme with ease.
jurgen_defurne wrote:
> SIOD, maybe ?
There are quite a lot of small Schemes that would work, f.e.g. SCM can
be made almost as small as SIOD I think. You could also try something
wacky like Lisp500.
········@gmail.com wrote:
> The eponymous sister article to this one discusses whether the one
> future of Lisp is in end-user programming of highly distributed,
> knowledge-based, interacting devices (cell phones, media centers,
> including using web services (and maybe even programming them, but
> that's the "old" c.l.l. and we've moved on beyond that! :-)). Step one
> toward this is to get a Lisp onto these devices (we can do the end-user
> part using Eval for now!)
>
> My (limited) understanding of these devices is that thay are current
> programmed using extremely lightweight languages: Forth, Erlang, C,
> assembly. I know nearly nothing about how to program these sorts of
> devices so I'm throwing the idea to the wind hoping that someone who
> has actually programmed some of these devices will chime in:
>
> Questions:
>
> For those knowledgeable about Erlang (etc.): Would having the
> flexibility of Lisp macros (and whatever else you get with Lisp that
> you don't already have in Erlang) be worth it if you didn't have to pay
> the price for a heavy-weight implementaion? (What exactly you can v.
> can't have is TDB, of course.)
Forth vs Lisp:
It's interesting to note that Forth already has "the flexibility
of Lisp macros", or something like them. For a low-level
language, Forth partakes of a lot of Lisp-nature, and it does so in
an incredibly tiny space - an embedded device can run not
only Forth object code, but also a usable Forth development
environment rather handily (around 10K of object code for a simple,
non-optimizing threaded code system, including REPL, interpreter,
compiler, and editor). Forth makes the full power of the compiler
available at read-time, compile-time, and run-time, so implementing
macro-like stuff is straightforward; although the details are quite
different from Lisp macros, the essence is the same.
Forth has even less syntax than Lisp -- there's some sense in
which Forth *really* has no syntax at all, not even an AST,
since lexed tokens are more-or-less immediately executed by
the evaluator. DSLs are pretty simple to implement in Forth
(some Forth-ers say that every Forth program is a DSL).
Like Lisp, Forth "looks funny" to programmers experienced
with the usual suspects (C, Java, etc). Moreover, the folks
on c.l.forth are always kvetching about the obvious superiority
of Forth to <language x, usually C>, and wondering why nobody
uses Forth anymore. I think it may be the Lispiest thing you
could get running on a device with 16K of RAM. :-)
-- JK
Joe Knapka <·········@kneuro.net> writes:
> Like Lisp, Forth "looks funny" to programmers experienced
> with the usual suspects (C, Java, etc). Moreover, the folks
> on c.l.forth are always kvetching about the obvious superiority
> of Forth to <language x, usually C>, and wondering why nobody
> uses Forth anymore. I think it may be the Lispiest thing you
> could get running on a device with 16K of RAM. :-)
Not to disparage Forth, but Lisp is the Lispiest thing you can run in
16KB of RAM. (Perhaps not Common Lisp, I'd be impressed by a full
implementation of CL in 16KB, but most Lisp until about 1986, were
smaller).
--
__Pascal Bourguignon__ http://www.informatimago.com/
I need a new toy.
Tail of black dog keeps good time.
Pounce! Good dog! Good dog!
Pascal Bourguignon wrote:
> Joe Knapka <·········@kneuro.net> writes:
> > Like Lisp, Forth "looks funny" to programmers experienced
> > with the usual suspects (C, Java, etc). Moreover, the folks
> > on c.l.forth are always kvetching about the obvious superiority
> > of Forth to <language x, usually C>, and wondering why nobody
> > uses Forth anymore. I think it may be the Lispiest thing you
> > could get running on a device with 16K of RAM. :-)
>
> Not to disparage Forth, but Lisp is the Lispiest thing you can run in
> 16KB of RAM. (Perhaps not Common Lisp, I'd be impressed by a full
> implementation of CL in 16KB, but most Lisp until about 1986, were
> smaller).
I think you could get a Forth into 8KB.
Forth has been used in embedded because it is small, the OpenFirmware
system used in Apple machines uses it for example.
This is much less of a problem now than it was in the past though. A
single module bluetooth implementation for example has ~200KB of Flash
memory and ~32KB of RAM in it for example. Even the smartcards in your
wallet often have enough memory to host a J2ME VM and run J2ME
programs, they could probably me made to run Forth or Lisp too.
Development tools, speed and real-time constraints are often bigger
issues than memory these days.
From: Josip Gracin
Subject: Re: Too Much Caffeine II -- Is Lisp the new Erlang?
Date:
Message-ID: <edhnu9$82a$1@sunce.iskon.hr>
········@gmail.com wrote:
> What would one lose to make an extremely
> lightweight Lisp, and get it onto these platforms?
>
> I don't think that an experiment would be out of order.
There's an interesting project at http://www.lispme.de/index.html
It's a Scheme implementation for Palm.
<········@gmail.com> wrote:
+---------------
| My (limited) understanding of these devices is that thay are current
| programmed using extremely lightweight languages: Forth, Erlang, C,
| assembly.
+---------------
IIUIC, almost all currently-shipping cell phones can run Java,
if not directly on their core platforms, then in a (limited?)
JVM hosted on their core platforms. Java is used especially
heavily for downloadable games...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> <········@gmail.com> wrote:
> +---------------
> | My (limited) understanding of these devices is that thay are current
> | programmed using extremely lightweight languages: Forth, Erlang, C,
> | assembly.
> +---------------
>
> IIUIC, almost all currently-shipping cell phones can run Java,
> if not directly on their core platforms, then in a (limited?)
> JVM hosted on their core platforms. Java is used especially
> heavily for downloadable games...
Many cell phones have a J2ME JVM for running Java games, so it can
certainly be done. I wouldn't say almost all shipping cell phone have
it though, high end phones tend to have J2ME, but not mid/low end ones
so much. I read an article that said ~75% of 3G phones have it. I
expect the figure is much lower for 2/2.5G phones though, which still
make up the largest part of the volume shipped. Most of the games on
those phones are written in as part of the phones software in something
like C.
No processor runs Java directly, even so-called Java processors. They
may execute the most common java bytecode though, leaving only the
complex ones to the JVM. ARM and various others have systems for this.
> Many cell phones have a J2ME JVM for running Java games, so it can
> certainly be done.
The particular langauage(s) aside, do these on-board programming
systems (whether phone or ipod or whatever) let you actually program
THE PLATFORM or are they boxed in s/t you can only program games on
them -- that is, you can make stuff come up on the screen, but you
don't have an API to operate the platform. Someone, for example,
mentioned LispMe for the Palm (which I have played with a little a
while back). But programming ON the Palm is different than >Programming
The Palm< ... and the same for phones, and esp. iPods and the like.
What I have in mind is not writing Lisp programs on your phone to do
games, or whatever, on the phone -- that would really be a waste of
human life. What I have in mind is controlling the phone itself! I have
the sense (with absolutely no evidence or direct knowledge) that it's
more like the LispMe Palm where you can write whatever doodads you
like, but only the phone manufaturer gets to control the phone. One
test would be, can you program it to call all your friends (and, if we
really wanted to get fancy: leave them all a message (that you speak,
obviously! -- I'm not proposing voice synthesis!)).
········@gmail.com wrote:
> > Many cell phones have a J2ME JVM for running Java games, so it can
> > certainly be done.
>
> The particular langauage(s) aside, do these on-board programming
> systems (whether phone or ipod or whatever) let you actually program
> THE PLATFORM or are they boxed in s/t you can only program games on
> them -- that is, you can make stuff come up on the screen, but you
> don't have an API to operate the platform. Someone, for example,
> mentioned LispMe for the Palm (which I have played with a little a
> while back). But programming ON the Palm is different than >Programming
> The Palm< ... and the same for phones, and esp. iPods and the like.
> What I have in mind is not writing Lisp programs on your phone to do
> games, or whatever, on the phone -- that would really be a waste of
> human life. What I have in mind is controlling the phone itself! I have
> the sense (with absolutely no evidence or direct knowledge) that it's
> more like the LispMe Palm where you can write whatever doodads you
> like, but only the phone manufaturer gets to control the phone. One
> test would be, can you program it to call all your friends (and, if we
> really wanted to get fancy: leave them all a message (that you speak,
> obviously! -- I'm not proposing voice synthesis!)).
I'm not quite clear what you mean, but ....Phone manufacturers consider
protection of the interfaces to their hardware similarly to how men
consider protection of their gonads.
The JVM on a phone is a restricted environment, similarly on a Palm a
program is a user program within the Palm operating system. Sometimes
this restricted environment has access to the phones capabilities
though. J2ME applications can dial number I believe. There are
limitations though I think.
These things could causes a problem for operators, for example a user
with free text messaging could program his phone to text message
everyone with a cellphone. Equally a malign Java game could dial
expensive phone numbers without the user knowing. These things are
prevented by the APIs as far as I know.
Rob Thorpe wrote:
>
> The JVM on a phone is a restricted environment, similarly on a Palm a
> program is a user program within the Palm operating system. Sometimes
> this restricted environment has access to the phones capabilities
> though. J2ME applications can dial number I believe. There are
> limitations though I think.
J2ME applications can generally, for instance, access the net if the
phone can. I use Opera mini on my phone (in fact on a couple of
different phones) a fair bit, which is fine. In a previous life I used
irc & ssh clients on a phone (well, actually on a BB, but it was a J2ME
application and would run on a phone I'm sure, though typing might be a
pain on typical phone kbds). using ssh to talk to the system
controller of a 6800 at 3AM was particularly exciting, in a bad way.
--tim
Shame; Yeah, seems too dangerous. How about less dangerous things:
Anyone here know how to program an iPod? Could we run a Lisp on it? (A
tiny amount of web surfing reveals that you can program them in C:
http://ipodlinux.org/IPod_Programming) but I don't know to what extent
this gives one control of the iPod itself (v., again, just doing stuff
on the screen). One could imagine a lisp-based visual programming
language on the iPod that let you use the iPod input gizmos to actually
write simple programs to do things with your media, no? If you can get
run a Lisp in C, and get to the screen and service input interrupts
this shouldn't be all that hard, actually! (And a lot less dangerous
than programming a cell phone.)
> The JVM on a phone is a restricted environment, similarly on a Palm a
> program is a user program within the Palm operating system. Sometimes
> this restricted environment has access to the phones capabilities
> though. J2ME applications can dial number I believe. There are
> limitations though I think.
>
> These things could causes a problem for operators, for example a user
> with free text messaging could program his phone to text message
> everyone with a cellphone. Equally a malign Java game could dial
> expensive phone numbers without the user knowing. These things are
> prevented by the APIs as far as I know.
> One could imagine a lisp-based visual programming
> language on the iPod that let you use the iPod input gizmos to actually
> write simple programs to do things with your media, no? If you can get
> run a Lisp in C, and get to the screen and service input interrupts
> this shouldn't be all that hard, actually! (And a lot less dangerous
> than programming a cell phone.)
I answered my own question:
http://www.informit.com/articles/article.asp?p=375499&rl=1
It's JavaScript! So, how hard could it be to write a lisp on it?!
Oops! Gong! Spoke too soon! (Too much caffeine! :-) This describes how
to program iTunes, NOT the iPod itself, which this article claims you
can't do unless you load Linux onto it, which you CAN do, but then I
don't know that you still have an iPod, as opposed to a portable Linux
box, which is a very different thing.
········@gmail.com wrote:
> > One could imagine a lisp-based visual programming
> > language on the iPod that let you use the iPod input gizmos to actually
> > write simple programs to do things with your media, no? If you can get
> > run a Lisp in C, and get to the screen and service input interrupts
> > this shouldn't be all that hard, actually! (And a lot less dangerous
> > than programming a cell phone.)
>
> I answered my own question:
>
> http://www.informit.com/articles/article.asp?p=375499&rl=1
>
> It's JavaScript! So, how hard could it be to write a lisp on it?!
········@gmail.com writes:
> Oops! Gong! Spoke too soon! (Too much caffeine! :-) This describes
> how to program iTunes, NOT the iPod itself, which this article
> claims you can't do unless you load Linux onto it, which you CAN do,
> but then I don't know that you still have an iPod, as opposed to a
> portable Linux box, which is a very different thing.
The Linux on iPod setup allows you to "dual-boot" your iPod
between firmwares.
--jon