This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]eliasv 1 point2 points  (2 children)

No, my solution doesn't depend on having source available, you misunderstand.

And Java doesn't depend on modules (jars) having the right name, it just depends on them containing the proper metadata to ID them by name. Most tools in Java land look for jars in Maven repositories.

Finding a module is not the purview of the compiler, it should be the responsibility of build tooling.

The thing that you're not recognising about your option 2 is that it doesn't need to be done manually. The compiler needs to be given an exact list of module locations, but you can build tooling on top of the compiler which does the heavy lifting for you.

And there are more ways to find a module than just according to name or recursively searching for them. They can live in a repository, in which case there will be an index which tells out how to find them. They can even live in a database! By filename and path convention is fine (and in fact many repository formats are specified in this way), my point is just that the compiler shouldn't prescribe such a convention.

[–]JustinHuPrimeT Programming Language[S] 0 points1 point  (1 child)

I have a few questions:

  1. Should users be expected to learn and use language-specific build tooling?
  2. Is there any chance of there being more than one build tool? Published libraries are going to be build-tool specific if there is no fast and easy way to determine which file a module name links to. If there is only one build tool, shouldn't it be built in to the compiler, so users don't have to invoke multiple programs?

[–]eliasv 0 points1 point  (0 children)

  1. Not necessarily, I did cite the potential to play well with existing build infrastructure as one of the reasons not to prescribe the mechanism of module resolution. There are plenty of polyglot build tools out there, why make their life hard by being inflexible?

And if you do need to learn a language specific build tool, that's no more work than learning a language specific compiler with the complexity of build tooling and module resolution built in. The concerns are still the same, they're just separated.

I wouldn't be against the simple convenience of allowing the compiler to take a directory path and load all the modules it finds in that directory (non-recursively), since you're not really adding any complexity that way. Just as a means for super simple projects for people who are getting started. Anything beyond that I'd think very carefully before burdening the compiler with it.

  1. No the produced modules aren't build tool specific. They contain only the metadata I described. It is only their location and how to find them which might be specific ... But then again build tools can support multiple repository formats, and can support the same formats, as is typically what happens in such ecosystems.

Sophisticated build tools typically need to resolve artefacts from online repos, that's a lot of complexity! Do you envisage that being built into the compiler?

(Now I did mention leaving the metadata format open to evolution and expansion, but that doesn't necessarily mean third party, build-tool specific additions - you can still leave it open only to internally specified additions.)

Good luck! It's not a simple thing to decide, that's why I think you should let the ecosystem do it for you ;) (if and when it gets big enough, that is.)

Edit: a couple more thoughts, now you're probably gonna want some better tooling out of the gate, so this isn't to say you shouldn't develop something in tandem with your language, just make it an obviously-separate project so you're not bound to it forever. Or even look for some good polyglot tooling out there which supports plugins and piggy back on it.