Embedded Racket reimplementation for constrained hardware?

[dbohdan]

Has anyone tried making a small embedded implementation of Racket?  I mean "embedded" not in the sense of 8-bit microcontrollers but more powerful yet still constrained devices, like routers with 64 MB RAM running Linux or the PlayStation 2.  I think you don't have to work from scratch to make one.  You can implement Racket on top of an embedded Scheme like Chibi-Scheme.  It doesn't need to be a full, maximally compatible port of Racket like Racket CS, just a large subset.  For example, you can skip  futures and places.

What features do you need to implement natively in the interpreter rather than in Scheme?  You can implement delimited continuations in terms of call/cc.  The concurrency primitives (threads, boxes, etc.) and the FFI?  You may be able to, but don't have to, optimize the interpreter for immutable conses.

This is just something I have been musing about.  If no project like this exists, I am not starting one soon.

[George Neuner]

On Sat, 5 Jun 2021 06:45:44 -0700 (PDT), dbohdan
<danyil...@gmail.com> wrote:

>Has anyone tried making a small embedded implementation of Racket? I mean
>"embedded" not in the sense of 8-bit microcontrollers but more powerful yet
>still constrained devices, like routers with 64 MB RAM running Linux or the
>PlayStation 2. I think you don't have to work from scratch to make one.
>You can implement Racket on top of an embedded Scheme like Chibi-Scheme

><https://github.com/ashinn/chibi-scheme>. It doesn't need to be a full,

>maximally compatible port of Racket like Racket CS, just a large subset.
>For example, you can skip futures and places.
>
>What features do you need to implement natively in the interpreter rather
>than in Scheme? You can implement delimited continuations in terms of
>call/cc. The concurrency primitives (threads, boxes, etc.) and the FFI?
>You may be able to, but don't have to, optimize the interpreter for
>immutable conses.
>
>This is just something I have been musing about. If no project like this
>exists, I am not starting one soon.

Racket can run in less than 64MB, but severely limited memory
typically results in a lot of GC churn.

George

[schle...@gmail.com]

I think in such an environment I would like to control memory usage myself, or maybe have a #lang that allows very fine grained and low level control over resources. (outputting lowerlevel code than racket/base).

If you need persistent data-structures they are nice, but often times you don't need them.

Basically I would use a smaller language and build only the things I really need, instead of starting with racket and stripping away everything I don't need.

(although if you manage to create a tool that accomplishes this in a very radical manner that could be cool as well, I just don't think that is easy)

That would boil down to partially evaluating racket specializing it to the target program, I don't think tools like `raco exe`, `raco distribute` etc. go so far that they would try to eliminate

base language features, which probably aren't "unused" anyway in any reasonably complex program.

Said another way: I think in a lot of cases it is easier to start creating a program with a language with less features, than trying to get rid of certain features after the program was already written using these features. If you start out without the features it is easier to reason about what features are worth implementing, for the particular program and what is over-engineered for the use-case.

That is just my perspective, I think there are many approaches to this, depending on the circumstances and concrete goals.

Simon

[Arthur Nunes-Harwitt]

Hi,

Marc Feeley has done some work on embedded scheme. Here are a couple of
links:

http://www.iro.umontreal.ca/~feeley/papers/StAmourBouchardFeeleySW08.pdf

http://www.iro.umontreal.ca/~feeley/papers/DubeFeeleyHOSC05.pdf

==============================================================
Arthur Nunes-Harwitt
Computer Science Department, Rochester Institute of Technology
Room GOL-3509
585-475-4916
==============================================================

"I don't know what the language of the future will be
called, but it will look like LISP."

This email is confidential and intended for the named recipient(s). In
the event the email is received by someone other than the recipient,
please notify the sender at a...@cs.rit.edu.

> --
> You received this message because you are subscribed to the Google Groups "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
> racket-users...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/da72cdd0-2143-4610-9e4d-f987931c9314n%40googlegroups.com.
>
>

[George Neuner]

On Sun, 6 Jun 2021 07:26:09 -0700 (PDT),
"schle...@gmail.com"

<schle...@gmail.com> wrote:

>I think in such an environment I would like to control memory usage myself,
>or maybe have a #lang that allows very fine grained and low level control
>over resources. (outputting lowerlevel code than racket/base).
>If you need persistent data-structures they are nice, but often times you
>don't need them.
>Basically I would use a smaller language and build only the things I really
>need, instead of starting with racket and stripping away everything I don't
>need.
>(although if you manage to create a tool that accomplishes this in a very
>radical manner that could be cool as well, I just don't think that is easy)

I doubt Racket can be used directly as it was not designed to work
with programmer managed memory, but it could be used as a cross
development environment. For reference there is Scheme48 which was
designed for embedded use. Scheme48 compiles to C and does /not/ use
GC but rather forces the programmer to manage memory explicitly.
However, there's no particular need to go through C if you're willing
to write your own compiler and runtime.

>That would boil down to partially evaluating racket specializing it to the
>target program, I don't think tools like `raco exe`, `raco distribute` etc.
>go so far that they would try to eliminate
>base language features, which probably aren't "unused" anyway in any
>reasonably complex program.

Yeah, I think some significant work would have to be done to separate
'base' into smaller libraries ... if that even can be done at all.

>Said another way: I think in a lot of cases it is easier to start creating
>a program with a language with less features, than trying to get rid of
>certain features after the program was already written using these
>features. If you start out without the features it is easier to reason
>about what features are worth implementing, for the particular program and
>what is over-engineered for the use-case.
>That is just my perspective, I think there are many approaches to this,
>depending on the circumstances and concrete goals.
>
>Simon

As a technical matter, GC works fine in small memory as long as it is
designed for that purpose. The problem is that the GCs employed by
(BC and CS versions of) Racket were /not/ designed for particularly
small systems.

But the design space of GC is large, and collectors have been designed
to work in almost every environment except HRT with sub-millisecond
deadlines. There are systems that are completely deterministic and
which can be used for HRT as long as the periods when the mutator must
be stopped are short enough for the purpose.

YMMV,
George