Utilize the embedded literal value information in `CodeType`

[Xinlu-Y]

The initial goal was to optimize the GOOL by enhancing support for literal values and enabling more efficient operations, such as smartAdd and smartSub across different literal types (e.g., integers, floats, doubles, strings). https://github.com/JacquesCarette/Drasil/blob/8490ac28a5efc8fa6a0ce2c249444611d3295110/code/drasil-gool/lib/Drasil/GOOL/LanguageRenderer/LanguagePolymorphic.hs#L132-L148

• Initial Approach Initially, we attempted to introduce a new data type LitValue and replaced valInt :: Maybe Integer with litVal :: LitValue. The purpose of LitValue was to capture a wider range of literal values. However, this approach proved to be too generic, resulting in a loss of type information. Details of this attempt are documented in #3945.

• Current Approach The current approach focuses on modifying the CodeType data structure to include an additional field to hold optional literal values (Maybe a). By adding this parameter, CodeType can store literals like Maybe Int, Maybe Double, or Maybe String, specific to each type.

  The updated definition for CodeType is as follows:

  data CodeType = Boolean (Maybe Bool)
                | Integer (Maybe Int)
                | Float (Maybe Float)
                | Double (Maybe Double)
                | Char (Maybe Char)
                | String (Maybe String)
                ...
  

  Since cType :: CodeType is a field within TypeData, this modification allows TypeData to carry literal value information as part of the type itself. This way, we can leverage the embedded literal values in CodeType for optimization in operations like smartAdd and smartSub.

• Changes to valFromData With the new CodeType structure, the signature of valFromData was modified to include an additional Maybe a parameter that represents the literal value: valFromData :: Maybe Int -> Maybe a -> VSType r -> Doc -> SValue r

  • The main challenge was to properly insert the Maybe a value into CodeType, which already contains optional literal values for specific types. After that, the updated CodeType needed to be propagated into the TypeData and ValData structures effectively. This is where I am currently stuck.

Currently, functions like valueOf and inlineIf rely on valFromData by passing Nothing for the literal value parameter, as they don’t require this information to function correctly. This ensures compatibility with other parts of the code, such as listSlice. Most of the time, the literal value information is not necessary except for certain optimizations like smartAdd and smartSub. Therefore, it’s important to consider if there are more straightforward ways to utilize these literal values effectively. For example, are there other operations or optimizations that could benefit from accessing literal values in CodeType?

[JacquesCarette]

I'm wondering if the problem has now moved to valFromData, i.e. it is general to too many types. I think maybe there should be different functions so that the new argument should be Maybe Bool for valFromBoolData, Maybe Int for valFromIntData, etc.

But maybe I misunderstand exactly where you are stuck in the propagation?

As to your last question: the main way for us to know how to use these more effectively is to look at Drasil-generated code and see if there are pieces of code that should have been simpler, i.e. where 'static computations' are present in the generated code.