On Sat, Jan 5, 2013 at 11:19 PM, Jonathan S. Shapiro <[email protected]> wrote: > On Sat, Jan 5, 2013 at 10:02 PM, Matt Rice <[email protected]> wrote: >> >> On Sat, Jan 5, 2013 at 3:44 PM, Jonathan S. Shapiro <[email protected]> >> wrote: >> >> > >> > 1. Is this worth it? It seems to be driven by the desire to mix >> > imperative >> > and pure programming without an explosion of type definition variations >> > (due >> > to case analysis getting embedded at the type level). >> >> It seems to me that one property lost due to the mix of imperative and >> pure when data structures >> are built this way is the notion of persistence, although I guess >> maybe its quasi persistent or immutably persistent or something. >> >> http://en.wikipedia.org/wiki/Persistent_data_structure > > > I agree. The ability to *express* persistent data structures is desirable, > but data structure persistence shouldn't be required. > > The main application of what might be termed "partially invariant" data > structures is specifying what happens in the presence of concurrency.
I am not really sure I explained myself well. what I suppose I mean is the intersection between aliasing and persistence, and how that should be defined, in the dequeue.c thing I attached if something is a 'next_only_type' it may turn into a 'next_prev_type', if you keep an alias to the 'next_only_type', it must not be able to turn again into a different 'next_prev_type'. in order to avoid turning this into a runtime error one might leverage uniqueness, struggling for a counter example, something that does memoization, or some kind of caching, might want to toss some cached computation and recalculate it again due to memory pressure or something. http://en.wikipedia.org/wiki/Memoization though that might be better expressed as a invariant loop or something this -> this&that -> this I suppose I just see aliasing in these having some tangible amount of usefulness, but am somewhat struggling to grasp it at the bottom of the jar of worms. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
