Live data from Hacker News

Predicting Variable Types in Dynamically Typed Programming Languages

arxiv.org

31–37 of 37 posts

Re: Predicting Variable Types in Dynamically Typed Programming Languages

#31
post #17

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?!

yep, only did a few C# projects but had the same experience.

Re: Predicting Variable Types in Dynamically Typed Programming Languages

#32

Earlier 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…

If you don't need perfect soundness, whole-program 1-CFA can be made practical by heuristic pruning. I've done it successfully in a commercial static analysis product.

Re: Predicting Variable Types in Dynamically Typed Programming Languages

#33
post #15

Earlier 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.

The problem with the technique used by Eigen (and also Boost.Spirit among a few other famous libs), called expression templates, is that it leverages the fact that the references to temporaries in function calls will be maintained until the end of the expression. The last operation in the expression (assignment to a specific type) will do processing to preserve those temporaries, compute the result, etc...

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 anymore

Hence 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

#34

Earlier 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.

With Kotlin, JetBrains was able to see what went wrong when previous JVM languages Scala and Apache Groovy each tried to be a better Java, and not repeat their mistakes, e.g. excessive operator overloading in Scala, or lack of scalability in Groovy.

Re: Predicting Variable Types in Dynamically Typed Programming Languages

#35

Earlier 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?

I've never done it, but if you're used to a Python/JS/etc-like dev cycle and the idea of up-front type errors annoys you, Haskell has a perfect solution.

Re: Predicting Variable Types in Dynamically Typed Programming Languages

#36

Earlier 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.

Swift is one of the most complicated languages I have ever used, similar in complexity to C++. It’s also adding features relatively quickly. I think some of the earlier releases didn’t focus as much as they should have on stability, and that this technical debt is being repaid now.

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…

Now both Java10 and C++11 have auto type inferences: var and auto keywords respectively
Post reply on HN