Earlier quoted context omitted.
> Mentioned statically typed languages C,C++ and Java are pretty old and therefore carry some baggage of verbosity that is no longer needed. hahaha. Just getting people to adopt `auto` in C++ is an uphill battle. People want to write types.
Not only in C++, everywhere. It is incredible the FUD in C# and Java against var , you see endless threads of how they are now dynamically typed like JavaScript. Sometimes I wonder how did those ended up learning to program, don't people read books any more?!
Predicting Variable Types in Dynamically Typed Programming Languages
31–37 of 37 posts
Re: Predicting Variable Types in Dynamically Typed Programming Languages
#32Earlier quoted context omitted.
Data flow analysis will certainly predict a fair number of types in typical programs in dynamically-typed languages, but there will also be lots of cases it can't handle. I don't know the details of the CMUCL/SBCL type inference algorithm, but I've worked on whole-program data flow analysis, and there are still lots of types it fails to recover, for various reasons. Often, for example, the entire program is not avail…
DFA isn’t usually used in type inferencing algorithms, at least ones that generate types for programmers rather than compiler optimizations. It isn’t that it is expensive, but in general syntax tree walking works well enough. Whole program analysis is too expensive for type inference (or much of anything for that matter) even with its precision ramped all the way down via something like CFA0. Type inference with sub…
Re: Predicting Variable Types in Dynamically Typed Programming Languages
#33Earlier quoted context omitted.
Sometimes writing out the types make the code clearer (while auto is good for long type names like std::vector::iterator). And although this is an edge case, if you use template-expression libraries like Eigen, you are forbidden to use auto (otherwise the template deductions don’t work properly)
I'm curious of when this would actually happen. Some kind of recursive implicit specialization? AFAIK auto x=foo; is just sugar for decltype(foo) x=foo; rather than MLish inference.
e.g. it more or less looks like this in a trivial case :
#include
template
struct add {
add(const T1& t1, const T2& t2): lhs{t1}, rhs{t2} { }
const T1& lhs;
const T2& rhs;
constexpr auto get() const { return lhs.get() + rhs.get(); }
};
struct integer
{
const int& i;
constexpr const int& get() const { return i; }
};
int f();
int main()
{
auto x = add{add{integer{f()}, integer{f()}}, add{integer{f()}, integer{f()}}};
}
Here, storing the value in `auto` is wrong because by the time the expression has ended, the references point to stuff that isn't in scope anymoreHence the solution is to introduce a type that will actually do the computation or store the result during the expression ; but before C++11 you had to introduce a type here anyways, which is what was done and of course it worked.
Re: Predicting Variable Types in Dynamically Typed Programming Languages
#34Earlier quoted context omitted.
I’ve always wondered why Swift and Kotlin, which are two very similar languages of approximately the same age, have such widely different compiler stability. Kotlin feels quite solid and mature, while Swift sometimes just feels like one big hack. Considering the enormous resources Apple has compared to JetBrains, I find it strange their trajectories have been so very different.
JetBrains business is all about understanding programming languages - Java in particular. And Kotlin is very, very close to Java.
Re: Predicting Variable Types in Dynamically Typed Programming Languages
#35Earlier quoted context omitted.
> Modern compilers for statically typed languages are really good at inferring types of various identifiers based on multiple hints in a deterministic way. Hell, in Haskell inference can take you pretty far, and you can defer type errors til runtime in development and basically get an opt-in dynamically typed experience!
> you can defer type errors til runtime in development dumb question: is there any reason you'd actually want to do this?
Re: Predicting Variable Types in Dynamically Typed Programming Languages
#36Earlier quoted context omitted.
> Modern compilers for statically typed languages are really good at inferring types of various identifiers based on multiple hints in a deterministic way (see Kotlin, Swift etc) I think it’s importatnt to mention that in Swift this lookup has exponential behavior, and can time out if the expression is too complex.
I’ve always wondered why Swift and Kotlin, which are two very similar languages of approximately the same age, have such widely different compiler stability. Kotlin feels quite solid and mature, while Swift sometimes just feels like one big hack. Considering the enormous resources Apple has compared to JetBrains, I find it strange their trajectories have been so very different.
Re: Predicting Variable Types in Dynamically Typed Programming Languages
#37> ...allows programmers to write code quickly by not requiring to declare the types of each variable which are determined at run-time based on the values assigned to that variable, thereby increasing programmer productivity Modern compilers for statically typed languages are really good at inferring types of various identifiers based on multiple hints in a deterministic way (see Kotlin, Swift etc). Mentioned statical…