[Haskell-cafe] New type of ($) operator in GHC 8.0 is problematic

[Joachim Durchholz]

Am 13.02.2016 um 10:41 schrieb Bardur Arantsson:
> It's terrible and basically name-space only.

That's just "do one thing, and do it well".
Or, conversely, "just the namespace, look elsewhere for what you think a 
module system is".

I guess the worst problem with SML's module system is that it does so 
many thing all rolled into one.

 > What's even stranger is
> that it's an *open* namespace (apart from the standard ones, I believe?)
> which means that I can retroactively add a class in say,
>
>     org.spring.integration
>
> and access package-scope bits of the original org.spring.integration
> namespace.

Yes, but you get into all sorts of trouble when packaging, and all kinds 
of tools will detect that and your software will be seen as low-quality.
Also, you can't do this unintentionally, so it's not a source of bugs.
So while possible in theory, it does not happen in practice unless in 
the most dire circumstances, and even then it's not the workaround 
people choose because it's too painful.

> It's a pretty weird system that seems to be driven by Java's
> "one-class-per-file" mentality[1].

Nah, that's unrelated.

> Disclaimer: Java 9 is getting a new module system, Jigsaw, but I'm not
> really too familiar with what it actually does, so I won't comment
> beyond this disclaimer :).

Jigsaw is about the ability to define large-scale modules.
I doubt it's a good approach, but I guess I'll work with it and see 
whether that's really going to be the case.
The Java culture isn't so much about good theory but about good 
engineering, so it's quite possible that my fears are unfounded.

>> The only thing that sets Java apart is that the DNS namespace is used as
>> the basis, and that's not even a language rule, just a recommendation;
>> the fascinating thing is that a mere recommendation was enough to make
>> clear who's responsible for fixing a name conflict, and virtually
>> eliminate name conflicts from the Java world.
>
> Yes, *this* was a FANTASTIC idea and it's soooo simple once you're aware
> of it. (No sarcasm intended, btw.)

Agreed, but if you were designing a language in the pre-Java times, the 
DNS was not the global registry where every programming-related entity 
would have a globally unique name. Most companies didn't even know what 
a domain name is, let alone have it registered.
Java went public roughly at the time that the Internet^W^W HTTP took 
off, and I suppose the idea to use domain names as the global namespace 
was more of a lucky accident because the plan was to make Java the 
Lingua Franca of browser scripting, and they *had* to have a way to make 
all those dynamically-loaded modules coexist, and in the WWW, the domain 
names come naturally.

Had Java been planned to become the server language it is today, I doubt 
they'd have had that idea.

> Unfortunately, the Scala people seem to be tiring of the long names and
> are regressing towards just using top-level names like "play" and
> "argonaut" and such... :/

I think that's mostly exceptions for the really-well-known frameworks.
Similar to the "java.*" and "javax.*" namespaces.
I can understand why they prefer "play.*" over "com.playframework.*", 
but I don't really get why they say "argonaut.*" instead of 
"io.argonaut.*". Weird.

OT3H it's not a really serious problem. The DNS as namespace means you 
have a spot that's guaranteed to be free for your code, and as long as 
nobody uses a TLD for his package root, it's all fine.
Things could become ugly for the Play framework is somebody registers 
"play" as a new TLD. It would be a clearly a problem for the Play 
framework, not for the DNS, so at least the responsibilities for fixing 
the problem will be easy to assign. Or maybe the Playframework guys will 
get a chance at reserving whatever .play domains would collide with 
their package names, it's quite possible they'd get heard during the 
sunrise period of a hypothetical new .play TLD.

So... things will muddle through as usual, and the main benefit is that 
you can choose a DNS-based spot in the namespace and be guaranteed that 
nobody else can usurp it because you registered that domain. And if 
somebody publishes code in that part of the namespace anyway, they will 
get labelled as "misleading" or even "abusive" and will be forced to 
move elsewhere.

> [1] Yes, I'm aware that you can actually have multiple classes in a
> file. Almost nobody does that.

It's mostly useless because you cannot have multiple public classes in a 
file, the other classes need to be package-private. And almost nobody 
uses package-private because the visibility rules around that are 
complicated, i.e. it is almost never what you want and also bad for 
maintenance.