"This is my personal programming environment. There are many like it, but this one is mine."
With regard to naming (that's a lot of naming discussion for a *tacit*programming environment - don't you think?), I like the idea of personal sets of PetNames. After all, we're discussing *personal* programming environment as an extension of *self*. It should assist the person and extend their personal capabilities. I believe most users of such enhancing system will appreciate communicating with their personal assistant in their own language, even if it's just a slightly modified dialect of some common language. And when I re-read the original post, I wonder if debates of ambiguity are not going the wrong way. So I'd like to offer my own incomplete metaphor: Recall that "every user action is an act of meta-programming". And user actions are inherently unambiguous - at least in the personal frame of reference. Thus, the problem is actually a problem of change in coordinates systems. As an example, consider how one's notion of "naming" is another's shifted notion of "identity". This "relativity of semantics" can perhaps be practically reconciled using some rewriting protocols (transformations), helping communicating parties find common ground. On the other hand, a foundational problem with name reconciliation is that it's basically a unification problem -and this problem is undecidable for some logic theories/type systems. I'm not sure understand enough of David's idea (or substructural logic) to tell if this is a real problem or not, but I wanted to chime in, since I find the thread fascinating. Best regards, Eran. On Thu, Sep 26, 2013 at 2:23 AM, David Barbour <[email protected]> wrote: > ... > If I assume those responsibilities are handled, and also elimination of > local variable or parameter names because of tacit programming, the > remaining uses of 'names' I'm likely to encounter are: > > * names for dynamic scope, config, or implicit params > * names for associative lookup in shared spaces > * names as human short-hand for values or actions > > It is this last item that I think most directly corresponds to what Sean > and Matt call names, though there might also be a bit of 'independent > maintenance' (external state via the programming environment) mixed in. > Regarding shorthand, I'm quite interested in alternative designs, such as > binding human names to values based on pattern-matching (so when you write > 'foo' I might read 'bar'), but Sean's against this due to out-of-band > communication concerns. To address those concerns, use of an extended > dictionary that tracks different origins for words seems reasonable. > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
