5 ms·

I guess GP's point is that it can be statically determined that the given expression evaluates to null.

by p4bl0 11y ago

chrisseaton 11y ago
To support this wouldn't you have to encode in the language spec the exact set of constant folding optimisations applied? Just 'false' is a trivial example, but maybe your compiler can see that 'true && false' is false, but mine can't? What about if the expression is some massive operation that could theoretically be found to be constant, but no real compiler is actually going to do that. You'd have different compilers determining different types based on optimisation which are supposed to be transparent. Doesn't seem desirable to me.
- lsd5you 11y ago
  Besides, I would say (in my experience) having 'false' like this will tend to occur when debugging, to force a certain execution path. In this case it is undesirable for the compiler/model to change the static type since that may then let you make other changes which you should'nt be making, or cause compiler errors further down.
- junke 11y ago
  This is how the existing type checker works, from primitive types and combination rules. Some rules are more precise than others, though. I think in Scala the type system does not depend on the implementation, but it is specified by the language.
  - chrisseaton 11y ago
    But 'false' isn't a type, it's just a value. The Scala type system doesn't encode boolean values as far as I know (not an expert).
- CuriousSkeptic 11y ago
  Not necessarily, it could also be a result of encoding literals as types. If true is the unit value of True a subtype of Bool you could probably have the typsystem figure out which overload to look at (True,False or Bool) From my understanding DOT could turn out to be quite similar to this pure subtype approach http://lambda-the-ultimate.org/node/4835 http://lambda-the-ultimate.org/node/4835 so isn't that farfetched either.

5 ms·

I guess GP's point is that it can be statically determined that the given expression evaluates to null.

by p4bl0 11y ago

I guess GP's point is that it can be statically determined that the given expression evaluates to null.

chrisseaton 11y ago
To support this wouldn't you have to encode in the language spec the exact set of constant folding optimisations applied? Just 'false' is a trivial example, but maybe your compiler can see that 'true && false' is false, but mine can't? What about if the expression is some massive operation that could theoretically be found to be constant, but no real compiler is actually going to do that. You'd have different compilers determining different types based on optimisation which are supposed to be transparent. Doesn't seem desirable to me.
- lsd5you 11y ago
  Besides, I would say (in my experience) having 'false' like this will tend to occur when debugging, to force a certain execution path. In this case it is undesirable for the compiler/model to change the static type since that may then let you make other changes which you should'nt be making, or cause compiler errors further down.
- junke 11y ago
  This is how the existing type checker works, from primitive types and combination rules. Some rules are more precise than others, though. I think in Scala the type system does not depend on the implementation, but it is specified by the language.
  - chrisseaton 11y ago
    But 'false' isn't a type, it's just a value. The Scala type system doesn't encode boolean values as far as I know (not an expert).
- CuriousSkeptic 11y ago
  Not necessarily, it could also be a result of encoding literals as types. If true is the unit value of True a subtype of Bool you could probably have the typsystem figure out which overload to look at (True,False or Bool) From my understanding DOT could turn out to be quite similar to this pure subtype approach http://lambda-the-ultimate.org/node/4835 http://lambda-the-ultimate.org/node/4835 so isn't that farfetched either.