Drasil icon indicating copy to clipboard operation
Drasil copied to clipboard

`Quantity` Typeclass

Open balacij opened this issue 7 months ago • 1 comments

Image

Immediate question: The note in the above mentions that adding MayHaveUnit would cause an import cycle and/or orphaned instances, but thinking about it, I don't quite see how this could happen. This could be attempted again to clarify what's happening.

Quantity is a typeclass that indicates some chunk is 'quantity-like', including:

  1. QuantityDict
  2. ConstrainedChunk
  3. ConstrConcept
  4. QDefinition

Now, immediately two questions (to look into):

  1. Why is QDefinition an instance of it? A QDefinition only provides a formula for one such chunk that would satisfy Quantity. It is not a quantity itself.
  2. Why isn't DefinedQuantityDict an instance of it? ConstrConcept is an instance of it, and its instance of all the requirements are based on the DefinedQuantityDict.

Designwise, I know we've discussed that an empty typeclass is a "smell" of sorts. Here, I wonder if it questions if HasSpace and HasSymbol are worth defining on their own at all:

λ rg "instance\s+HasSymbol" -ths --sort-files -l
drasil-code/lib/Language/Drasil/Chunk/CodeDefinition.hs
drasil-code/lib/Language/Drasil/Chunk/NamedArgument.hs
drasil-code/lib/Language/Drasil/Chunk/Parameter.hs
drasil-lang/lib/Language/Drasil/Chunk/CodeVar.hs
drasil-lang/lib/Language/Drasil/Chunk/Constrained.hs
drasil-lang/lib/Language/Drasil/Chunk/DefinedQuantity.hs
drasil-lang/lib/Language/Drasil/Chunk/Eq.hs
drasil-lang/lib/Language/Drasil/Chunk/Quantity.hs
drasil-lang/lib/Language/Drasil/Chunk/UncertainQuantity.hs
drasil-lang/lib/Language/Drasil/Chunk/Unital.hs
drasil-lang/lib/Language/Drasil/Chunk/Unitary.hs
drasil-theory/lib/Theory/Drasil/MultiDefn.hs
λ rg "instance\s+HasSpace" -ths -l --sort-files
drasil-code/lib/Language/Drasil/Chunk/CodeDefinition.hs
drasil-code/lib/Language/Drasil/Chunk/NamedArgument.hs
drasil-code/lib/Language/Drasil/Chunk/Parameter.hs
drasil-lang/lib/Language/Drasil/Chunk/CodeVar.hs
drasil-lang/lib/Language/Drasil/Chunk/Constrained.hs
drasil-lang/lib/Language/Drasil/Chunk/DefinedQuantity.hs
drasil-lang/lib/Language/Drasil/Chunk/Eq.hs
drasil-lang/lib/Language/Drasil/Chunk/Quantity.hs
drasil-lang/lib/Language/Drasil/Chunk/UncertainQuantity.hs
drasil-lang/lib/Language/Drasil/Chunk/Unital.hs
drasil-lang/lib/Language/Drasil/Chunk/Unitary.hs
drasil-theory/lib/Theory/Drasil/MultiDefn.hs

Both are defined for the same data types. We should look into if it is possible to merge them into Quanity so that Quantity is just a normal classy lens. Is this the right thing to do?

balacij avatar Jun 02 '25 07:06 balacij

Re: immediate question. Entirely possible that that comment is obsolete.

Also, I think our description of Quantity is also off. A Quantity is not actually a Quantity per se, it is always a 'variable' (thus the need for the symbol) that represents a future-stage Quantity. The 'term' (via Idea) associated with that variable should most definitely be by-reference and not 'contained', because we are representing an arbitrary quantity (i.e. variable) of that "kind" (i.e. whatever is names by that Idea).

What this brings to mind is that we're missing a layer. While term / Idea defines raw vocabulary, we need to know that some pieces of vocabulary are quantitative, i.e. may be instantiated. [It's like the opposite of Java's abstract classes, which can not be instantiated.] Once we know something is quantitative, we may then create variables that range over that.

JacquesCarette avatar Jun 02 '25 14:06 JacquesCarette