You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is motivated by a discussion started in #2179, and summarized by @balacij's comment.
The core of the issue is that in programs, we call things constant for different reasons:
There are some things we call constant because they represent something unchanging. Examples include gravity, database information, etc.
There are some things we call constant because the flow of the program doesn't require that they change, so for safety or performance we say that they cannot change. Examples include intermediate calculations, e.g. const double discriminant = b*b - 4*a*c;, as the example @hrzhuang gave.
There are other places where the semantics of constant and immutable are less clear - e.g. references, classes, methods.
I don't know when, but it would be good to have more flexibility of expression here. Here are my thoughts for what we need to do to get there:
Slow down to do some more research and find a framework to organize our thinking on this.
Look at Drasil, how it handles constants and immutable variables. We might only need to change drasil-code and drasil-gool, but it would be worthwhile to look higher than that too, e.g. to see if our chunks encode the information that we need.
Start adding and using the necessary new functionality to enable the expressiveness we need.
If this is too much to do at once, we could start by limiting our scope to variables, not worrying yet about references, classes, etc.
The text was updated successfully, but these errors were encountered:
This is motivated by a discussion started in #2179, and summarized by @balacij's comment.
The core of the issue is that in programs, we call things
constant
for different reasons:constant
because they represent something unchanging. Examples include gravity, database information, etc.constant
because the flow of the program doesn't require that they change, so for safety or performance we say that they cannot change. Examples include intermediate calculations, e.g.const double discriminant = b*b - 4*a*c;
, as the example @hrzhuang gave.constant
andimmutable
are less clear - e.g. references, classes, methods.I don't know when, but it would be good to have more flexibility of expression here. Here are my thoughts for what we need to do to get there:
drasil-code
anddrasil-gool
, but it would be worthwhile to look higher than that too, e.g. to see if ourchunk
s encode the information that we need.If this is too much to do at once, we could start by limiting our scope to variables, not worrying yet about references, classes, etc.
The text was updated successfully, but these errors were encountered: