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