(provoked by @lspector’s nearly drooling enthusiasm the other day)
OK here are some observations and questions from 20 minutes spent on a branch:
- The keys want to be type
:number, which doesn’t exist yet /shrug (see earlier discussion of wanting to fix numerics soon)
- In the same way that the old
name type never worked very well because it was so onerous for the interpreter to make keys up and associate them meaningfully with values, in this case there will need to be a source for a shit-ton of numbers for keys: either some kind of generator, or just some sort of reliable feed. Without an indefinitely large source of genetically-encoded non-random numeric keys, evolvability will suck.
- On that front, I find I’m musing about something like a deterministic L-system or (also deterministic) Barnsley fractal as a generator. Fine for experiments, but what type is such a thing? Is it a
:number-source or what?
- I have a sense that the
:range type from pushSwift will be useful here, too, since operations on
:tagspace instances will probably involve range-based manipulation. For instance, crossover, inversion, affine scaling, and so forth.
- I think part of the confusion I feel when I read what you’ve written about
:tagspace behavior is that you seem to want to treat them as something more than a simple type. I see them as another useful collection type, and essentially interoperable with the standard Push
:range and so forth. That is, they’re not privileged as far as I can see: they’re “just” little storage things that use approximate lookup.
Some practical design questions:
I assume there’s nothing magical about the tuples you used in the sketch you’ve posted. I suspect that was written before there were a lot of collection types in Push, right? I like the idea of multiple items being retrieved, but we already have
:vector and strongly-typed tuples, so the meaning of “retrieve this vector or its elements” is ambiguous.
So it seems reasonable that the lookup behavior in my implementation can be split into at least two variants, something like
:get-as-items. The first would push the collection itself onto
:exec, and the second would push the contents of the item onto
:exec in canonical order.
I take you at your word that any literal can be stored in a
- We’re all OK that any
:tagspace item can also get stored in a
I can tell that in working through your “threaded items” example, you really really want those weird little
imap maps to be a full-fledged type, but can’t quite bring yourself to say it. Clearly if we permit arbitrary tuples to be stored in a
:tagspace collection, the fraction of them that “mean” this thing and also look up another thing right away will be vanishingly small.
If you want that to be able to happen (and it seems reasonable), then consider (1) some flexible and convenient way of generating a deterministic series of numeric keys to define a “sequence” of lookups, (2) a way of conveniently pulling a
:range of values all at once, or (3) whether a special "
:tagspace link" like your
imap is in fact necessary, to pump the numbers up. I would count the last solution unlikely to help, since we’re already going to be short of just-plain-numbers if these things start to work. In fact, I’m really pessimistic about the
imap chaining thing, since it feels very fragile and remote from the Push genome itself.
- Riff on that for a bit: What’s an evolvable, highly compressed, mostly-deterministic way of getting a wide variety of little “lookup chains”? The more I think about it, the more I think some flexible class of “generators” (of some sort) seem to be in order.