Well, since we're talking about a concatenative bytecode, I'll try to speak Forthfully.
Normally when we define a word in a stack language we make up an ASCII symbol and say "this symbol refers to all these other symbols, in this definite order". Well and good, with two potential problems: we have to make up a symbol, and that symbol might conflict with someone else's symbol. Name clashes is an obvious problem. The fact that we must make up a symbol is less obviously a problem, except that the vast majority of our referents should be generated by a computer. A computer generated symbol may as well be a hash function, at which point, a user-generated symbol may as well be a hash also, in a special case where the data hashed includes an ASCII handle for user convenience. This is fine for immutable values, but for identities (referents to a series of immutable values, essentially), we need slightly more than this: a master hash, taken from the first value the identity refers to, the time of creation, and perhaps other useful information. This master hash then points to the various values the identity refers to, as they change. There are a few things that are nice about this approach, all of which derive from the fact that identical values have identical names and that relatively complex relationships between identifies and values may be established and modified programmatically. As an example, if I define a "foo" function which is identical to someone else's "bar" function, they should have the same "name" (hash) despite having different handles. With a little work, we should be able to retrieve all the contexts where a value appears, as well as all the handles and other metadata associated with that value in those contexts. On Wed, Sep 25, 2013 at 12:45 PM, David Barbour <dmbarb...@gmail.com> wrote: > What you first suggest is naming for compression and caching. I think > that's an okay performance hack (it's one I've contemplated before), but I > wouldn't call it naming. Names generally need to bind values that are > maintained independently or cannot be known at the local place or time. I > think that what you call identity, I might call naming. > > It is not clear to me what you hope to gain from the global namespace, or > by hashing the identities (e.g. what do you gain relative to full URLs?). > Maybe if you're pursuing a DHT or Chord-like system, identity might be a > great way to avoid depending on centralized domain name services. But we > also need to be careful about any values we share through such models, due > to security concerns and the overheads involved. I would tend to imagine > only physical devices should be represented in this manner. > > Any system that requires keeping a complete history for large, > automatically maintained objects has already doomed itself. We can handle > it for human-managed code - but only because humans are slow, our input is > low bandwidth, and the artifacts we build tend to naturally stabilize. None > of those apply to machine-managed objects. Exponential decay of history ( > http://awelonblue.wordpress.com/2013/01/24/exponential-decay-of-history-improved/) > provides a better alternative for keeping a long-running history (for both > humans and devices). > > Anyhow, can you explain what your global namespace offers? > > > On Wed, Sep 25, 2013 at 11:07 AM, Sam Putman <atmanis...@gmail.com> wrote: > >> I've been kicking around a model that may be useful here, vis à vis >> naming and the difficulties it implies. >> >> In short, a language may have a single global "namespace" that is a >> collision-resistant hash function. Values below say 256 bits are referred >> to as themselves, those above are referred to as the 256 bit digest of >> their value. >> >> Identities are also hashes, across the 'initial' value of the identity >> and some metadata recording the 'what where when' of that identity. An >> identity has a pointer to the current state/value of the identity, which >> is, of course, a hash of the value or the value itself depending on size. >> We'd also want a complete history of all values the identity has ever had, >> for convenience, which might easily obtain git levels of complexity. >> >> Code always and only refers to these hashes, so there is never ambiguity >> as to which value is which. "Symbols" are pointer cells in the classic Lisp >> fashion, but the canonical 'symbol' is a hash and the text string >> associated with it is for user convenience. I've envisioned this as Lispy >> for my own convenience, though a concatenative language has much to >> recommend it. >> >> >> >> On Wed, Sep 25, 2013 at 3:04 AM, Eugen Leitl <eu...@leitl.org> wrote: >> >>> On Wed, Sep 25, 2013 at 11:43:44AM +0200, Jb Labrune wrote: >>> >>> > as a friend of some designers who think in space & colors, it always >>> > strucks me that many (not all of course!) of my programmers friends >>> think >>> > like a turing-machine, in 1D, acting as if their code is a long >>> vector, some >>> > kind of snake which unlikes the ouroboros does not eat its own tail... >>> >>> Today's dominating programming model still assumes human-generated and >>> human-readable code. >>> >>> There are obvious ways where this is not working: GA-generated blobs >>> for 3d-integration hardware, for instance. People are really lousy at >>> dealing with massive parallelism and nondeterminism, yet this is not >>> optional, at least according to known physics of this universe. >>> >>> So, let's say you have Avogadro number of cells in a hardware CA >>> crystal, with an Edge of Chaos rule. Granted you can write the >>> tranformation rule down on the back of the napkin, but what about >>> the state residing in the volume of said crystal? And the state >>> is not really compressible, though you could of course write a >>> seed that grows into something which does something interesting >>> on a somewhat larger napkin, but there's no human way how you could >>> derive that seed, or even understand how that thing does even >>> work. >>> >>> Programmers of the future are more like gardeners and farmers >>> than architects. >>> >>> Programmers of the far future deal with APIs that are persons, >>> or are themselves integral parts of the API, and no longer people. >>> _______________________________________________ >>> fonc mailing list >>> fonc@vpri.org >>> http://vpri.org/mailman/listinfo/fonc >>> >> >> >> _______________________________________________ >> fonc mailing list >> fonc@vpri.org >> http://vpri.org/mailman/listinfo/fonc >> >> > > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
