core and sdk: Add Hash and Show instances

[iRevive]

Motivation

• Provide a universal typesafe option to compare two instances
• Meaningful .toString for debugging purposes (the format is identical to open-telemetry java)
• To preserve binary compatibility, most data types in Experimental sdk-trace module #325 are represented as sealed traits. Hash and Show are used to calculate hash and toString for such data types
• Out of the box integration with typelevel ecosystem (e.g. weaver-test)

[armanbilge]

This is a bit weird, we definitely don't want to keep it gated in a testkit or behind an extra import?

Either way, Any is distinct from _ which I think is called "existential".

[iRevive]

I guess we can keep it behind the certain import.

There are several places in (upcoming) Otel4s SDK where we don't know a concrete type of an Attritube

[iRevive]

Could you suggest the object's name where I can place this implicit, please?

Should the structure be similar to something like this?:

object AttributeKey {
  object Implicits {
    object Extra {
      implicit val attributeKeyExistentialHash: Hash[AttributeKey[_]] = ...
    }
  }
}

Extra / Existential / Unsafe / Internal?

[iRevive]

Hm, we already define some Show[Attribute[_]] instances in the public implicit lookup scope:

otel4s/core/common/src/main/scala/org/typelevel/otel4s/Attribute.scala

Line 73 in 571900a

implicit val showAttribute: Show[Attribute[_]] = (a: Attribute[_]) =>

.

[iRevive]

@armanbilge what are the implications if we keep existential instances in the public scope?

We need existential instances for:

1. AttributeType[_] - a sealed trait with case objects, universal hashcode is fine here
2. AttributeKey[_] - created from key => (key.name, key.type), where the name is a String and the type is an AttributeType[_] (a coproduct)
3. Attribute[_] - created from a => (a.key, a.value), where the key is AttributeKey, the value is one of Boolean, Double, String, Long, List[Boolean], List[Double], List[String], List[Long].

The Hash[Attribute[List[String]]] should generate the same hashcode as Hash[Attribute[_]].

[armanbilge]

If we are confident that universal hashing will work for all the possible types (now and future) then it seems fine. e.g. could there ever be an attribute for a CIString?

[iRevive]

Spec says the following:

The attribute value is either:

• A primitive type: string, boolean, double precision floating point (IEEE 754-1985) or signed 64 bit integer.
• An array of primitive type values. The array MUST be homogeneous, i.e., it MUST NOT contain values of different types.

I don't think we should allow any other types other than these.
So, I doubt Attribute[CIString] should be a thing.

[NthPortal]

regardless, CIString has a case-insensitive hashCode implementation, so universal hashing should still work anyway

[armanbilge]

regardless, CIString has a case-insensitive hashCode implementation

Yes, it does today, but I'm considering a future where we might want to make it an opaque type.

[iRevive]

Currently, the attribute value can exactly be one of: Boolean, Double, String, Long, List[Boolean], List[Double], List[String], List[Long].

So using a universal hashcode should be safe here.

[iRevive]

@armanbilge I didn't use Cogen before. Am I defining it correctly?

Do I understand this in the right way:

1. Gen - produces a value of type A from Seed
2. Cogen - produces a Seed from the given value A

Is Cogen used to adjust the seed for the structured values, and, as a result, produce better pseudo-random values?

[armanbilge]

Is Cogen used to adjust the seed for the structured values, and, as a result, produce better pseudo-random values?

Cogen is used to generate arbitrary lambdas e.g. Arbitrary[A => B]. If you have Cogen[A] and Gen[B] then you can chain A => Seed, Seed => Seed, and Seed => B to get an arbitrary but deterministic A => B function.

---

I think your implementation looks good, typically I try to avoid the manual plumbing of seeds and instead transform to some datatype for which Cogen already exists. In this case that would be very messy 😁 but it could look something like this (basically an Either encoding of a sum type).

Either[
  Boolean,
  Either[
    Double,
    Either[
      String,
      Either[
        Long,
        Either[...]
      ]
    ]
  ]
]