Remove defunct +hard and ;; rune

[belisarius222]

These expressions are now both wrong, since they check for mold idempotence, i.e. they call the mold function on a piece of data to coerce it to the desired type, then check whether the coerced value equals the original value.

This made sense back when molds were supposed to always produce a value of the correct type; however, now a mold is supposed to crash if given an invalid piece of data, and it is not required to produce an identical noun to its input; in fact, each type can declare a normalizer function that can be used to migrate old data to new, or to canonicalize data.

Now that a valid noun can be modified during coercion, checking for equality will lead to false negatives for type validation -- not to mention incurring the extra runtime cost of the equality check.

These expressions are now technically invalid (although they will work for now, since the type does not have a custom validator function):

((hard (list ship)) ~[~zod ~nec])

;;  (list ship)  ~[~zod ~nec]

They should be replaced with this:

((list ship) ~[~zod ~nec])

The ;; rune should be removed, and the +hard function should also be removed (we still need +soft, which now virtualizes the call to the mold gate to catch a crash, for error handling).

[belisarius222]

On second thought, the ;; rune's macro expansion should be changed to just call the mold gate, and its first argument should be parsed in pattern mode so we don't need the comma when defining a mold inline. Having a rune for this also helps distinguish the type coercion from a normal function call.

%-  ,[a=@ b=^]
some-raw-noun

would become

;;  [a=@ b=^]
some-raw-noun

[joemfb]

This sounds like a good move.

/cc @pilfer-pandex, this seems like it would be immediately useful.

[pilfer-pandex]

Honestly, I think it would be great if you had to use a different rune to normalize a value to a type. This would allow us subsequently to separate out the notion of type from the notion of normalizing gate.

[pilfer-pandex]

@belisarius222 given the proposed new semantics for ;;, does it really make sense to consider it a ; rune still? Esp in a world where ;; is the only way to normalize, and you can no longer use %- or equivalent.

[ohAitch]

This would allow us subsequently to separate out the notion of type from the notion of normalizing gate.

imo having those notions forcefully entwined to reduce conceptual surface area is one of the like top 10 useful hoon design decisions. (The removal of molds proper strains, but does not break it.)