On Sun, 6 Jun 2021 07:26:09 -0700 (PDT), "schle...@gmail.com" <schleesi...@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 -- 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/mmhubg92kiggthhlrfp483sfu0hga86r79%404ax.com.
