On 19 May 2014, at 22:58, Mark van Gulik <[email protected]> wrote:
> Avail's different from most languages – as I'm sure you've noticed. There is
> no fixed list of operations that are accessible everywhere in the code (by
> design, for DSLs), so technically there are no base methods that objects
> (values) respond to. You're always free to import and define as many or as
> few methods as you want that accept an argument of type "any" (the highest
> usable type).
yes, avail is different, but it does have built-in vm primitives that i want to
know about.
and no, i don't want to implement a 32bit hashcode for every type of object if
i don’t have to (and where would i efficiently store such a hash?)
> (1) People might build their own hashed structures that provide no more
> actual power than sets and maps, and
> (2) Exposing the hash values may lead to pathologically hashed sets and maps.
> Imagine manually building a bin-like structure in a misguided attempt to
> improve the performance of sets. Such a structure would segregate values
> based on their hash values, potentially placing them into sets acting as bins
> of this construction. Those sets would have hash values that were highly
> correlated, which can degrade performance.
Regarding (1): that’s *exactly* what i want to build - my own hashed
structures, most notably treaps.
avail’s sets and maps are powerful and efficient, but lack (imo) destructuring
operations (such as split) and/or optional ordering.
these can be added (may be), but i’d like to experiment with data structures
myself!
Regarding (2): even without exposing avail’s hashcode, there are always
malicious attacks possible, even when 32bit hashes are close to perfect.
it requires a lot of effort to harden hashtables (and avail's sets and maps)
against such malicious attacks.
that’s why i want to experiment with - and possible offer alternative - set and
map implementations (which need not be vm primitives).
that said, believe me that i do think that providing tuples, sets and maps
natively is a *good* thing, because they covers 99% of the use-cases.
> There's a third, minor issue as well: (3) exposing the hash value also
> exposes the fact that it fits in a 32-bit int. If we expose that, then we'll
> have to break working user-written code if we change the number of bits to
> 64, or provide some horribly kludgey "_’s⁇NEW hash" method (heh, like "The
> New iPad" or "Scott Joplin's New Rag"). Worse, Avail may eventually be
> picked up for use "in the small", and some space-constrained implementations
> of Avail may ultimately choose to compute and store fewer hash bits, like 24
> or even 16. Or eliminate hashing entirely if there aren't going to be any
> large hashed structures. They are just a VM optimization, after all.
why not expose it as a special hash type object, and some methods to combine
hash objects to new hash objects.
> To answer your second point, however, you might want to include the subtype
> test "_⊆_" in your list. This, like the others, uses a paper-thin primitive
> (P_033_IsSubtypeOf) to access Avail's built-in, complete rules about
> compatibility of types. See implementors of o_IsInstanceOf() and its
> numerous helpers for the vast variety of ways in which types comparisons
> actually happen.
ah, that’s a nice paper-thin primitive to know about.
> You might want to add some other basic operations to your list as well, like
> "<«_‡,»>" and "{«_‡,»}", since any value can be put in a tuple or set. Also
> "“_”" (the inner quotes are smart double-quotes), the user-overridable
> stringification operation. The VM gets told what to name this in the very
> first module, Origin.avail. The default implementation for [any]→string
> simply asks the value's descriptor to produce something somewhat suitable,
> but the Avail method should be overridden for types of values that can be
> presented more appropriately in some other way.
yeah, avail's bootstrapping is quite ingenious.
cheers,
Robbert.
