Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Implement a Way to Know Caller's Language #1289
This was originally listed on 6.d-prep, but I'm filing it here, since this is the only known to me blocker for 6.d language release and I'd like to put more attention to it.
I can do all the work, but I'm unfamiliar with this area of the codebase and would need someone to give some hints on what needs to be implemented.
Per IRC comments the
I think lizmat++ proposed adding a variable similar to
Some discussion occurred: https://irclog.perlgeek.de/perl6-dev/2018-01-24#i_15732173
This issue comes up very often. I understand that volunteers will do whatever they want to do, and that's fine, but it would be great if this issue got more attention. Maybe someone can write a step-by-step guide on how to get this done? Maybe a checklist of some sort? Or does anybody have any idea on how to get this thing moving?
I think before we can write an implementation guide, we need to decide what semantics we want, and make sure those support some concrete use cases.
The situation at present seems to be something like this:
I figure the last point is the key one under consideration here. Here's some questions to try and get the ball rolling.
Do we want an imperative solution?
That is, are we expected code to be written like
Do we want to declaratively specify the version availability of methods?
For example, we could provide ways to indicate:
Do we want to declaratively specify the version availability of types?
For example, we could provide a way to mark a type as "only available up to language version X" or "only available from language version X". But what would this mean?
I think this is an orthogonal issue from versions of types themselves (e.g.
What is the effective language version?
It's not just as simple as "what is the language version of my caller".
One immediate case is where multiple dispatch where the
Another issue is in code like:
Which is then called by
This is an issue whether we have an imperative or a declarative approach. It feels to me like a declarative approach might be easier to optimize and have less edge-cases, but it may turn out to be just as bad.
At least on my part, it's not so much "volunteers will do whatever they want to do", but also that this isn't a trivial problem. I suspect anyone digging into it more deeply will realize the same (or they'll see a simple solution that I've not realized yet, which would be wonderful :-)). At the moment, I can't just write an implementation guide for willing volunteers, because I don't know what we should implement.
It's a difficult language design issue. It needs some proposals exploring, along with examples of concrete problems they solve. A solution potentially deals in performance-sensitive matters like dispatch, and so optimization has to be a consideration. An imperative solution probably would also have performance considerations ("how can we optimize out the condition"). Either way, "we'll figure out how to make that perform well later" isn't a good enough answer.
Just an idle thought: don't spesh plugins give us a way to optimize an imperative
Any way, my feeling is that it's gonna be a mixture of some declarative ways and a couple of imperative ifs scattered around. They all have their place.
added a commit
Jun 28, 2018
referenced this issue
Jul 4, 2018
referenced this issue
Jul 26, 2018
added a commit
Jul 30, 2018
Just hit another problem, similar in scope to the OP problem in the issue: perl6/6.d-prep@12b28ed
Basically, we want
So I differed that 6.d-prep item to later language versions, in case we figure out some better system for this stuff when this issue is resolved.
Another problem is