On Fri, Aug 30, 2013 at 4:40 AM, Ian Piumarta <[email protected]> wrote: > > > > I'm doubting the "deepness" of this one, because you could certainly > construct a valid isomorphism where values are not used in a linear fashion. > > Your second statement says only that implication is not commutative. >
I had misread this as: values are "not used" (i.e. they are not consumed or used at all) in a linear fashion. Seemed trivially true to me. :) If Michael was saying that values are used in a non-linear fashion, yeah that could be an issue for an isomorphism. Fortunately my "not used" interpretation is vastly more relevant for lenses and zippers for navigating an ad-hoc heterogeneously typed environment. The usual case one would navigate to some part of the environment and perform a very specific operation, then return (which is basically what lenses do: there and back again!) *Hypothesis:* Full model transforms will disrupt the developers' intuitions of location and inertia. Humans will favor homeomorphism - i.e. an isomorphism that is additionally constrained to protect continuity in the small and modularity in the large. cf. http://awelonblue.wordpress.com/2012/01/03/isomorphism-is-not-enough/ > > Given the luxury of restricting your system to linear functions preserving > the isomorphism you care about, then your first statement has deep > consequences. For example: > http://home.pipeline.com/~hbaker1/LinearLisp.html LinearLisp doesn't seem to have any real linear types. It provides COPY and FREE operations universally. Consequently, it is not really restricted to linear functions. Tracking copies precisely (so there is no sharing) is useful for memory management... but if we want to model something like linear call/cc, or prevent file handles from being copied, it seems we'd be out of luck. But, yeah, my language does require explicit (and type-safe) copy/drop. In my language it's more logical (I can share structure if I want), since values aren't stateful. But there is no need for GC. It's very nice. :)
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
