Hacker News Reader

Comment by unholiness | Hacker News Reader

Turing complete systems are highly capable, and thus, are harder to prove anything about. The halting problem notwithstanding, there's first the "there are things that don't halt" problem: that is, you can write a valid TypeScript program that will never finish compiling.

Now, this really shouldn't be an issue unless someone is deliberately abusive. Java's generic types are also Turing complete[0], and it hasn't been problematic. Just because an abusive program exists doesn't mean it will be written.

But who am I kidding... this is the JavaScript community. I'll give it 2 weeks until someone releases a framework allowing you to write functions that don't compile unless their input is a prime number.

[0] https://arxiv.org/pdf/1605.05274.pdf

View on HN

> you can write a valid TypeScript program that will never finish compiling

Sure, typescript program may never finish compiling, although it will still halt: Just `kill -9`. The halting problem solved! ;-)

Seriously though, there are many languages / systems that are 'accidentally Turing complete', including CSS + HTML, and it doesn't really impede them. See http://beza1e1.tuxen.de/articles/accidentally_turing_complet...

> Sure, typescript program may never finish compiling, although it will still halt: Just `kill -9`. The halting problem solved! ;-)

The problem is that you can't really tell when a long compile is an infinite or just a really long one. You want non-Turing completeness because your tools need to be reliable.

Turing complete means that it's a simulation of a Turing machine, but not actually one. A TM is something purely abstract that was invented to prove the halting problem, and infinity of the tape is arguably the most crucial concept. Computers do not have infinite memory / power / time so the halting problem doesn't really make sense unless you talk about a pure Turing machine with infinite tape.

In most cases, you know something is wrong once your typescript compilation takes more than a few seconds. At most, it could be an interesting DOS attack, but most continuous integration systems should have a limit on how much seconds they can run the compiler for. So it's really not a problem if you have constraints on resources...

Except you know no such thing, that's the point. That could very well be the intended and correct behaviour of the compiler for that input.

Sure, I can see your point. It's a problem for computer scientists, and good to know as an anecdote. I'm talking about it in practice - when using TypeScript the 'halting problem' has never been an issue. I was joking about the 'kill -9' but also meant it in a half-hearted way!

So, if not turing complete, what kind of automata would you use to accept your language, say if you were designing your own language?

Isn't that irrelevant in that case?

If the type checker takes too long, sonething isn't right.

How could you possibly quantify "too long" when you can perform arbitrary computation at compile-time? How do you know the library you're using doesn't need you to compute and embed the first N primes in the final output?

At least if your type checker weren't Turing complete, you know it will finish at some point.

But if you got a deadline, everything over it is bad.

Sure, but "not fast enough for me because X" and simply "wrong/incorrect" are completely different claims.

Yes, but you want your tools to be powerful at the same time.

There's plenty of power below Turing completeness. Turing completeness is overrated.

That's an opinion, of course.

What's not an opinion is that most programs we write are more easily and compactly expressed with general recursion, but often don't need general recursion to reproduce the same output.

Seems like a non-opinionated classification of "overrated".

Or we could go even more meta, since no physical system is Turing complete due to the Bekenstein bound, so any expressible system is necessarily at most an FSA.

>CSS + HTML

AFAIK, CSS + HTML is not Turing complete, but CSS + HTML + "Human pumping tab and space" is, which makes infinite loops less of a problem.

Aha! I had a look to confirm, and you are right! In essence, html + css is not. However if we have a human hitting tabs and spaces for a long enough time, then for all intents and purposes, perhaps it is? Anyhow, it's still very impressive that we can do a lot of complex computations simply by hitting tabs and spaces!

I'd like to emphasize what you said---that's not an inherently bad thing, but as most powerful features of languages, it can be abused. A lot of languages have Turing-complete type systems, and I have yet to see a serious abuse of this in production code. For example, C++ has some really cool libraries that do a lot of stuff at the type-level, and this has been acknowledged and even made more explicit and usable, with the introduction of constexpr, which basically lets you run plain old imperative code at compile-time.

Yea, turns out programmers are pretty good at writing code that halts in Turing complete languages.

> you can write a valid TypeScript program that will never finish compiling.

Specifically, for any implementation of a TS compiler, there is some correct TS program that will never finish compiling.

Every program has a TS compiler that will compile it, but no compiler can work on all programs.

This is addressed by (1) not finishing in these cases or (2) imposing practical limits on the compilation and concluding failure if these are surpassed.

> Every program has a TS compiler that will compile it, but no compiler can work on all programs.

How would you correctly compile a program that has an actual infinite loop in the type system. Some equivalent of while (1) {}

The equivalent of "while (true) {}" depends on how you want to reduce your Turing program to the type system.

For example, you could translate "the Turning program yields 1" as "the types are valid", and anything else (0 or nontermination) as "the types are not valid".

So "while (true) {}" would correspond to invalid types. And a sufficiently smart interpreter/runtime could conclude that "while (true) {}" does not yield 1, just as a sufficiently smart complier could conclude the type constraints are not met.

But no interpreter (and no compiler) would be able to reach a correct conclusion in all cases.

I see. I got confused by the fact that for me a program that never ends is still valid, but I understand how this makes no sense for a type system.

A program like that isn't a valid typescript program, so failing to compile it is less of a bug. The point is that there are correctly-typed typescript programs that the compile won't compile.

How can you, specifically you the human, typecheck the program if it has an infinite loop in the types? If you can typecheck it, then I can write a compiler to typecheck it, repeat until my compiler can typecheck every correctly-typed program a human can write, at which point the problem becomes moot.

For every specific typescript compiler, there is a correct typescript program that that complier fails to compile. The ones for particular humans will generally not be the same as the ones for particular compilers.

In my mentioned bug report I even showed an implementation of a type "IsPrime<T>" which can only be instantiated if T represents a prime number :D

> I'll give it 2 weeks until someone releases a framework allowing you to write functions that don't compile unless their input is a prime number.

Honestly that seems like it could be pretty useful for making sure that "correct" data is passed at compile-time...

I believe "don't compile," in this context, is short for "their compilation doesn't halt." That seems like a bad thing to me. ;)

Not necessarily. You should be able to write a halting computation to determine whether a number is prime in a Turing complete language. It may be stupid hard to encode, or take a really long time to run, however.

The halting problem says that you can't write a halting decision procedure that takes an arbitrary program as input and determines whether that program halts, for any program. That doesn't mean that no programs halt. On the contrary, most programs in Turing complete languages obviously do halt and it's often trivial to tell if a particular program halts or not (e.g., `print "hello"` obviously halts). A Turing complete language can compute anything that is computable. So if the type system is Turing complete, you should be able to type a function that only takes primes... in theory.

I don't understand how this is fundamentally different from just doing it in regular javascript. You could write a javascript function that recurses forever on condition x: just write a function that calls itself with the same parameters unless condition x is met. How is it fundamentally different if the type system does it?

> How is it fundamentally different if the type system does it?

runtime vs compile time. For example someone could write some TypeScript that would forever compile, which is intuitively unexpected when compiling.

C++ templates are also Turing complete.

I think most people knowing C++ know that. But since then we've tried to avoid the same complexity in most newer languages. Thus, the fact that TypeScript, Java, and C# all have Turing-completeness more or less by accident in their type systems may be surprising. (Granted, template metaprogramming was also more an accidental discovery than a design goal of C++, but it's been around for a while longer.)

Reply on news.ycombinator.com