Just thought I'd give everyone an update since it's been a little while. At the moment I'm implementing my stripped-down language as a module language that exports a subset of racket/base (and probably some other modules once I get through the huge number of symbols in racket/base). Because "no global mutable state" turns out to be much harder than I initially expected due to needing to detect closures with mutable variables, I just decided to start with immutable or simulated immutable datatypes (i.e. bytes but no functionality to mutate them) and then add mutability back in.
It's been slow going because I only end up spending a half hour a night between the time the kids finally settle down in bed and the time I go to bed myself, and sometimes my brain is too fried to focus on it. Once I have an initial stab at the set of symbols to include in the language I'll post some code. Of course, with no mutable state, there can be no capabilities, so figuring out how to implement state and make it easy to create limited capabilities to access that state will be the next step. Right now I'm thinking something along the lines of Clojure's agents in that they will be first class citizens with mutable references to immutable values representing state, updated by asynchronous messages, but encapsulated and requiring messages both for reading and mutation ala Erlang/OTP's gen_server. I guess there is no reason they couldn't be closures just like E objects. I tried some early experiments using hashes of serializable closures (using web-server/lang/serial-lambda), but those appear to silently discard set!s to local variables between calls, and having set! at all is somewhat problematic. So even if they are implemented as closures, it seems like I will probably need some opaque (to untrusted code) syntactic machinery to ensure that there is no state that can't be serialized and deserialized, and that mutation and inspection outside the object's methods requires a capability. If I use a box to store the object's state, for example, I have to make sure there isn't a way to make a box that is reachable from a global variable. Speaking of making boxes, that reminds me that I probably also need to strip down the reader, lest someone do (define foo #&17). It might be harmless without set-box! or box-cas!, but it should be an error since they are at best not particularly useful without the mutator functions. On Wed, Aug 19, 2015 at 10:40 PM Jack Firth <jackhfi...@gmail.com> wrote: > This idea in general is very cool, so do let us (or at least me) know when > you've got a prototype working. I'm quite curious to see the inner workings. > > -- > 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. > For more options, visit https://groups.google.com/d/optout. > -- 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. For more options, visit https://groups.google.com/d/optout.
