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 gneuner2 schrieb am Samstag, 5. Juni 2021 um 19:13:21 UTC+2: > 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 > > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/5d5f3114-ddaa-4e4b-af6b-e7f82a2fc670n%40googlegroups.com.
