-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Utilize the embedded literal value information in CodeType
#3973
Comments
I'm wondering if the problem has now moved to 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. |
The initial goal was to optimize the GOOL by enhancing support for literal values and enabling more efficient operations, such as
smartAdd
andsmartSub
across different literal types (e.g., integers, floats, doubles, strings).Drasil/code/drasil-gool/lib/Drasil/GOOL/LanguageRenderer/LanguagePolymorphic.hs
Lines 132 to 148 in 8490ac2
Initial Approach
Initially, we attempted to introduce a new data type
LitValue
and replacedvalInt :: Maybe Integer
withlitVal :: LitValue
. The purpose ofLitValue
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 IntroducedLitValue
for expanded literal value handling #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 likeMaybe Int, Maybe Double, or Maybe String
, specific to each type.The updated definition for
CodeType
is as follows:Since
cType :: CodeType
is a field withinTypeData
, this modification allowsTypeData
to carry literal value information as part of the type itself. This way, we can leverage the embedded literal values inCodeType
for optimization in operations likesmartAdd
andsmartSub
.Changes to
valFromData
With the new
CodeType
structure, the signature ofvalFromData
was modified to include an additionalMaybe a
parameter that represents the literal value:valFromData :: Maybe Int -> Maybe a -> VSType r -> Doc -> SValue r
Maybe a
value intoCodeType
, which already contains optional literal values for specific types. After that, the updatedCodeTyp
e needed to be propagated into theTypeData
andValData
structures effectively. This is where I am currently stuck.Currently, functions like
valueOf
andinlineIf
rely onvalFromData
by passingNothing
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 aslistSlice
.Most of the time, the literal value information is not necessary except for certain optimizations like
smartAdd
andsmartSub
. 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 inCodeType
?The text was updated successfully, but these errors were encountered: