Replies: 10 comments 41 replies
-
|
What I want to do for libraries is make it more of a centrally managed thing. It doesn't scale infinitely but it is much easier to use and we have the option of doing updates ourselves in here. My dislike of dub is no secret anyway, so some kind of full replacement is in order. Most the code there will probably not break for a while anyway; I'm kinda conservative when it comes to language breakage.... but I'm not necessarily the dictator so we'll see what happens. Still there's so much other work to do i don't see us breaking that much for a while. |
Beta Was this translation helpful? Give feedback.
-
|
In an ideal world I prefer package management to be separate from building. This can make it more inconvenient for the end user, but would solve a lot of the limitations built into dub right now. One approach is to bundle it by default so that the easy use cases are still as easy as before, but internally design it separately so that for unusual use cases it's still possible to make it do the right thing, without having to throw out the baby with the bathwater like you have to with dub when you need to go beyond what it was designed to do. |
Beta Was this translation helpful? Give feedback.
-
|
You bring up dub packages, but the issue extends to existing D libraries more generally. If existing D code cannot be compiled with openD or otherwise existing D libraries cannot be used with it, then it places a burden on existing D users to transition to openD. |
Beta Was this translation helpful? Give feedback.
-
Currently, upstream has not merged any string interpolation implementation yet, and who knows how long it will be before they come to any agreement on it. So in the meantime, there will be no interpolated strings in upstream code, which means they will be compatible with openD, at least the current state ot it. The transition is unfortunately only one-way: DIP1036e interpolation string syntax does not parse with upstream D, so even a One thought is to implement some way of maintaining backward compatibility, such that upstream code, at least existing upstream code sans new divergent features, will always be compilable with openD, it just won't take advantage of new changes. Maybe a compatibility mode in the compiler or something that retains the old semantics, turned off by default.
Yeah we're gonna hafta recreate all of this infrastructure. It isn't going to be easy. To mitigate the difficulty we probably should have some bridging mechanism for importing existing dub libraries without additional effort. Any hindrance in this area means less adoption of openD. Maybe something like what Devuan does with Debian repos: they don't clone the entire Debian repo as that's too onerous, instead, they have a redirector that redirects most requests to the Debian repos except for a few hand-crafted exceptions that are replaced with Devuan-specific packages, and a blacklist of a small number of incompatible packages. Essentially a "diff" against Debian, if you will. So basically what we need is a "diff" against code.dlang.org, with a replacement list and a blacklist. |
Beta Was this translation helpful? Give feedback.
-
Related to this point, there are relatively simple changes D could make that would improve the experience for this type of work:
I had an unfinished blog post sitting around for months because I knew this would never go anywhere with upstream D. I thought about ways to do it myself but never had the time. If OpenD were to implement them, it would be a genuine improvement over upstream for this type of work. https://bachmeil.github.io/the-blog/2024/01/09/numerical-limitations.html |
Beta Was this translation helpful? Give feedback.
-
|
[...]
What operators would be needed?
I'm no fan of dub either. It's just too restricted and refuses to understand that there exists a world outside of its own. And it does a whole bunch of unnecessary stuff that I don't need, yet it makes me pay for it. We need a better model. Auto-scanning imports sounds like an awesome way of doing this. Maybe a compiler-based tool that downloads dependencies based on the imports parsed by the compiler would be the ticket. There are technical issues to be resolved on this front, though. Like allowing the user to override cache settings, use a local package repository, etc.. But no insurmountable challenges that I can think of, as long as we're willing to put in the work to implement it.
What kind of compiler support would be needed for these new extern types? If this requires a lot of compiler changes I'm not sure if it will fly. OTOH, if the compiler can expose some kind of generic internal API for adding foreign language support, then this could potentially become a killer feature. For example, if we didn't have to change the compiler in order to have
I'm not so sure about adding additional operators to the language that doesn't do anything by default. I sympathize with the need for custom operators, but I'm just not sure how to do it in a way that doesn't end up being a mess. If we add a '**' operator, for example, that could break subtle lexing cases like multiplying numbers dereferenced from pointers. But assuming we choose a syntax that doesn't have such problems. Then there's the question of what the operator should mean in the default language outside of overloads. What precedence should it have? What should it do by default, since there's no basic operation it could correspond to with basic types? And how many of these custom operators do we need, how should they be named, what precedence/associativity should they have, and when do we stop? One solution I can think of is to use Unicode math operators that already have a clear meaning in math. But that brings up the issue of how to easily type Unicode operators in your code -- if the user has to open up a Unicode character map to select the operator every time it's needed, it's going to be a no-go because of its impracticality. Either way, the question of precedence and associativity still stands. You still have to assign a precedence and associativity to every custom operator, and do it in such a way that an expression involving a mix of these operators with the current ones is still readable and easily understood. Having user code define precedence/associativity is a no-go, because it means the compiler has to parse such definitions before it can lex expressions that use these operators -- this immediately brings us into the C++ realm of complexity (and unmaintainability -- OpenD code would become unreadable if operator precedence depends on what you import -- even C++ isn't bold enough to do this). |
Beta Was this translation helpful? Give feedback.
-
I don't actually mind Dub as a way to install packages. I can use
There wouldn't be a ton of new operators needed for operator overloading (additional versions of
Yes. And now that I think about it, one of the Octave developers was posting on the mailing list about using D as an extension language for Octave, so extern(Octave). Maybe even extern(Fortran) since that's severely limited outside of numerical functionality. It already has C interoperability built in. |
Beta Was this translation helpful? Give feedback.
-
At this point, not many: alternative versions of
In the case of R, nothing beyond recognizing From the example on that page: That converts
I'm not proposing custom operators. If we go that route, however, we definitely wouldn't want custom precedence. R has custom operators and they all get the same precedence. Actually, custom precedence is already supported by D, in the form of appropriately placed parenthesis. I want to emphasize the importance of having an adequate set of operators for this kind of work. Lisp has always suffered from writing things in the form |
Beta Was this translation helpful? Give feedback.
-
It wouldn't work in the general case, but it should for overloading any existing unary or binary operator, or any identifier that starts with one of those operators or a |
Beta Was this translation helpful? Give feedback.
-
|
Sine I've already started the |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
What's our policy wrt code.dlang.org packages? Obviously outright breaking them isn't an option, we need all the help we can get to have existing people move over here, which means we can't just totally break all their existing dub projects. But as this fork diverges from upstream, there's bound to be incompatibilities with upstream dub packages. What should be the solution here?
One idea is to use a selective forwarder for opend's equivalent of dub: it would redirect requests to upstream dub for most cases, but maintain a blacklist of packages that are no longer compatible, for which it would redirect to an alternative opend-specific substitute, or return an error if no substitute is available. (Kinda similar to what Devuan, a Debian fork, is doing for their package repo.)
Beta Was this translation helpful? Give feedback.
All reactions