On 2/13/14, "Jörg F. Wittenberger" <joerg.wittenber...@softeyes.net> wrote: > > Am 13.02.2014 09:50, schrieb Alan Manuel Gloria: >> I'm kinda sorta vaguely planning on a Scheme implementation which has >> STM at its core (basically, all non-transactional mutations are >> implicitly considered to be inside tiny transactions containing only >> that mutation). > > Have you seen http://ball.askemos.org ?
Err..... not really, and it's a bit more large-scale than what I had in mind. > > Your idea reminds me so much to our reasoning. Just because our > transactional memory was known to be horribly slow, we decided to have > two complementary Scheme-alike languages: one without any side effects > (no effects to be handled in STM, zero overhead) and one sub-language > having only the effects. ((Though to distinguish them we chose to > express the latter in "long-wielded-s-expressions" a.k.a. "XML".)) > > I'm pretty interested in your plans and progess. Please keep me posted. It strikes me that the separation of purity and impurity here is almost precisely what Haskell does with the separation of the "actual" language and the IO data type. Truly pure functions return an IO object, which can be combined in specific ways with other IO objects (and with pure functions that return an IO object - for example, a "read character" IO object can be combined with a pure function that accepts a character and returns another IO object, forming a larger IO object that reads a character and then does some other IO action in response to that character). Which is a rather big digression from readable lisps, haha. In any case, my (vague) plan is a relatively simple R7RS compiler, with everything as a transaction (both mutations and reads), and the possibility to combine multiple transactions into a larger transaction. I/O is a bit mind-bending, so I'll go with "not a transaction, and will throw an error if you put in a transaction," which is the default handling in pretty much every STM implementation I've seen. Sincerely, AmkG > > /Jörg > >> If ever, it will of course have SRFI-105 by default >> and SRFI-110 on #!sweet. >> > > > ------------------------------------------------------------------------------ > Android apps run on BlackBerry 10 > Introducing the new BlackBerry 10.2.1 Runtime for Android apps. > Now with support for Jelly Bean, Bluetooth, Mapview and more. > Get your Android app in front of a whole new audience. Start now. > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk > _______________________________________________ > Readable-discuss mailing list > Readable-discuss@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/readable-discuss > ------------------------------------------------------------------------------ Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk _______________________________________________ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
