Introduced LitValue for expanded literal value handling

[Xinlu-Y]

As discussed in #1867, smartAdd and smartSub are currently using literal integer values as SValue to perform simple optimizations. By creating a new datatype LitValue, we could extend support to more simple types of literal values (such as floats, doubles, and strings, which I believe would be useful) for addition and subtraction operations.

However, after making these changes, I noticed that the generated test code for listSlice has been altered. This change seems to occur specifically when the step is a variable and the issue arises from how I'm handling the return value of valueInt in the instances of ValueElim.

The problem might stem from how these values are being unpacked and interpreted in the context of listSlice which remains somewhat puzzling to me.

[JacquesCarette]

This is suspicious to me: why is the static value defaulting to 0? (same in other places in this PR)

[JacquesCarette]

I think you should be able to abstract out the

case litVal x of
   LitChar c -> Just c
   _  -> Nothing

part in a separate function so that it can be re-used across the different renderers

[JacquesCarette]

I wonder if smartAdd should be "more typed", so that this cascade of checking doesn't happen.

[JacquesCarette]

Here again, why default to 0?

[JacquesCarette]

The previous type was more precise! Perhaps LitValue is not the best way to go, but instead a synonym for Maybe a would be, where the type could be more precise.

[JacquesCarette]

I would not be surprised if this change was due to your defaulting some things to 0!

It is also strange that this changed, as you don't have any code for simplifying constraints / boolean expressions. So I really suspect it's the defaults.

[B-rando1]

These should be the relevant lines of code:

Drasil/code/drasil-gool/lib/Drasil/GOOL/LanguageRenderer/Macros.hs

Lines 98 to 109 in e72dd92

	let cond = case mbStepV of
	-- If step is a litInt, do a one-sided check
	(Just s) -> if s >= 0 then v_i ?< endVal else v_i ?> endVal
	Nothing -> case (mbBegV, mbEndV) of
	-- If both bounds are litInt's, do a two-sided check.
	-- Also, make sure step is in same direction as check.
	(Just b, Just e) -> if e >= b
	then begVal ?<= v_i ?&& v_i ?< endVal ?&& step' ?> IC.litInt 0
	else endVal ?< v_i ?&& v_i ?<= begVal ?&& step' ?< IC.litInt 0
	-- If bounds are not litInt's, do both two-sided checks
	_ -> begVal ?<= v_i ?&& v_i ?< endVal ?&& step' ?> IC.litInt 0 ?||
	endVal ?< v_i ?&& v_i ?<= begVal ?&& step' ?< IC.litInt 0

I believe @JacquesCarette was right: setting values to litInt 0 makes the line 100 case trigger instead of the line 101 case.

[Xinlu-Y]

In this case, where step is a variable with a negative value, valueInt stepV will return Nothing, making mbStepV = Nothing, which I believe would trigger the logic starting at line 101. However, in this code, how does the default value litInt 0 affect mbStepV and result in mbStepV getting a value of 0, which subsequently generates the code for (int i4 = 3; i4 < 0; i4 += z)?

[B-rando1]

This is the line creating the listSlice in the example:

Drasil/code/drasil-code/test/HelloWorld.hs

Lines 170 to 173 in e72dd92

	-- | List slicing where the step is a variable with negative value
	listSlice mySlicedList8
	(valueOf myOtherList) (Just (litInt 3))
	(Just (litInt 0)) (Just (valueOf (var "z" int))),

I believe that the specific reason that line 100 is triggering instead of line 101 is that the value of step uses valueOf, which gives litInt 0 as its literal value.

Variables aren't literal values; they hold values. Since GOOL doesn't know what the value they're holding is, the correct litVal for them should be Nothing, as they aren't literal values.

[JacquesCarette]

Looking at this code again, I don't think this is quite the right approach -- it loses too much type information. I think the 'static' information should be tracked in a different way. Most likely abandoning this PR and re-starting will be the easiest way forward.