miniPicoLisp (c to asm.js via emscripten)
HTML, PiL i/o to Server, JSON, ...
localStorage, indexedDB, cookies, sessionStorage, ...
PiL i/o from miniPicoLisp/Browser
PiL i/o to Browser/miniPicoLisp
http://software-lab.de/doc/ref.html#io: ...read-eval-print loop...
http://software-lab.de/doc/tut.html#funio: ...functions operate on implicit
input and output channels...
On Fri, May 9, 2014 at 8:19 AM, Joe Bogner <joebog...@gmail.com> wrote:
> Hi Rick, Christophe,
> I was thinking the same thing. miniPicolisp might be a simpler first step
> to port
> On Fri, May 9, 2014 at 7:51 AM, Rick Lyman
> > wrote:
>> How about porting the c version using:
>> On Thu, May 8, 2014 at 5:08 PM, Christophe Gragnic <
>> christophegrag...@gmail.com> wrote:
>>> I'm currently embedding a «pedagogical pseudo-code like language» in
>>> As using plain browsers is a nice thing to have in front of students,
>>> I tried with
>>> EmuLisp (PicoLisp in JS, by Jon Kleiser, that I won't thank enough, with
>>> which proved to be a good solution for me.
>>> So I had some thoughts, ideas and questions.
>>> 1) EmuLisp lacks some functions. The first idea I had was to write them
>>> in the
>>> available functions (like 'glue' with 'pack'). It worked for some, but
>>> some others
>>> needed to be implemented in JS. Now my question: how far could be pushed
>>> idea to write a maximal subset of Picolisp in a minimal subset of
>>> Picolisp? Like in
>>> the original paper of McCarthy or «the Jewel» in SICP? I'm not talking
>>> performance here, just functions availability.
>>> 2) Since PicoLisp64 is written in a «generic assembly» embedded in
>>> I was wondering (only wondering, since the concepts are a bit vague for
>>> me) if
>>> instead of building the .s files we could build some
>>> 3) Regarding EmuLisp again, and for your information, I've created
>>> (and am using seriously!) a JS pil, that I named `piljs` which runs on