Hacker News Reader

> Any such bizarre behaviors need to be treated as a bug, and eliminated in the next release.

Going back in time (sorry for the long story).

From what I observed, there seems to have been a split in the community. The split is between the importance for PyPy and its future vs the "core" CPython.

When PyPy was making very fast progress there was a feeling that maybe in the next big release PyPy will merge into CPython. So maybe if you downloaded python 3.0 you'd just get PyPy with it. There was a lot of hype and hope. And I think at some level the old guard (Guido and some other core developers) saw that as bit of threat and they made public remarks that I understood to mean: "CPython is not PyPy", "it won't be merged in any time soon", "CPython is fast enough".

So why all this background? Well that might explain why there would be resistance to modifying CPython to "help out" PyPy.

I think Python had one chance to do what you suggest - remove bizarre behaviors. This chance was Python 3.

This is also one of the things that bothers me a bit about Rust. The complexity of the compiler means that writing an actual language spec is hard, and the spec is very much tied to "what rustc's borrow checker is capable of".

There is a relative formal document describing the borrow checker's behaviour: http://doc.rust-lang.org/master/rustc/middle/borrowck/doc/

A language spec (other than "cpython is the spec") would probably be good. But I know of jython, iron python, stackless python and micro python, in addition to pypy -- that are all more or less complete and/or alive as alternative implementations. I'm not sure of the .net variant (iron python) -- I've heard rumours that it's dead. So it's not like the lack of a spec is an insurmountable obstacle, nor like it's not something that no-one is working on...

It's probably not an insurmountable obstacle, but getting over it is by no means trivial. Exhibit A: None of the alternative Python implementations are 100% compatible with CPython. I get the impression that, in practice, the "Python spec" is something that can only be approached asymptotically.

Python 3 should have been a from the ground rewrite of a new core runtime written to a language specification. Maybe we can get that in Python 4.

Who's going to work on that, and most importantly bless it as official and unite people? I haven't seen anything from Guido on the criticisms of Python 3 and CPython, like this post and other unicode complexity complaints in Python 3. It seems that a lot of people who like Python because it lets them move fast hit a wall when they encounter main Python developers as moving so slow as to consider it okey to have two major versions of a language competing until 2020.

There should be a spec and M versions of the runtime. The batteries should be portable between those versions. I used to split by time evenly between Jython, CPython and PyPy. Now I use PyPy about 80% of the time. But having the spec defined as how CPython and the included libraries operate is detrimental to the language. Python3 could have been a chance to clean up the syntax, define and excellent FFI protocol and split the standard library. Python3 could have been a reference implementation that spread Python to all corners of computation.

What are good examples of languages with specifications and at least two implementations that fully implement the spec?

Given how complicated any specification for a non-trivial language is, I wonder if there are any. But I think this is beside the point.

Not having a specification for a language pushes every language feature discussion down onto application and library developers 'in situ'. When a developer or library maintainer stumbles onto unexpected interpreter or compiler behavior in a language without a specification, it means that in the short term there's no guidance about how they should deal with it. Do I hack this for Visual C++ in a way that can be removed eventually or do I really have to assume going forward that variadic templates aren't going to be available?

C99 and C++11 have several compliant implementations, as does ECMAScript 5 (javascript).

The benefit of a spec is not so much that all implementations are necessarily completely compliant, it's that you know what the behavior is supposed to be so you can implement to the spec and work around any differences in implementation. Plus, you can report bugs without them being closed as "by design".

Go has gc and gccgo. They made two implementations to keep the spec honest and not just "whatever the compiler does".

Common Lisp, for sure

Yes, the various Lisps were the first possible examples I came up with (I think Scheme probably qualifies as well).

In Lua the user manual is the reference, so if the language does something different, it is considered a bug. If something is not described in the manual then it is an implementation detail (unspecified) and code that relies on it is broken.

This led to several alternative implementations, among which at least one (LuaJIT) implements completely a version of the language (Lua 5.1).