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
The text was updated successfully, but these errors were encountered:
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.
Originally planned[^1] to be deprecated in 6.d for reasons[^1], but due to R#1289 [^2] we're postponing it for later language versions. [^1] https://github.com/perl6/6.d-prep/blob/master/TODO/FEATURES.md#deprecate-strsubst-mutate [^2] rakudo/rakudo#1289
Tried implementing it, but hitting a problem on the same scope as R#1289 rakudo/rakudo#1289 Basically the 6.d verions of the ops are currently loaded as if they were just comming from a module and aren't visible by the rest of the 6.c setting. There's a ton of trig and other math ops that aren't affected by the change, so I'm deferring it, until we figure out R#1289 and get a clearer picture on caller's lang ver.
Just hit another problem, similar in scope to the OP problem in the issue: Raku/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
6.c spec does not define how language switching is to behave, and that is still largely undefined and lacks a PoV in 6.d spec due to blockage by R#1289[^1]. The rudimentary PoV for language switching currently does not propage the active language version to EVALed code, and so `throws-like` tests with stringy code continue using default compiler's language version. Were that to be defined as the behaviour for language switching, then the tests being modified by this commit would be deemed wrong, as they do not set correct lang version. The same would actually apply to all `throws-like` tests with Str argument. It's more likely that this behaviour will be deemed unwanted and language switching will be defined in a way that lets EVAL use caller's lang ver. Since R#1289 isn't a trivial issue, I'm going to correct just these couple of tests until language switching behaviour is more fully defined. The change in a test module to move the version as first line is also part of undefinedness of lang switching, which is now more well-defined and makes it a requirement the lang is the first statement in code.  rakudo/rakudo#1289  https://colabti.org/irclogger/irclogger_log/perl6-dev?date=2018-10-27#l140
Suggestion: a unit can carry a symbol containing language revision the unit was compiled with. Then knowing your caller's language would be as simple as
Another possible solution could be use of
I have tested and can confirm that
The only thing which stops me from closing this ticket is the fact that CORE-SETTING-REV is a sub. Using it all over the place is highly ineffective thing performance-wise. It could as well be a constant, but there is a bug which results in only constants from the base
Closing via #3055. Caller language version is now available via
The script outputs:
Thanks for the work you do! :)
Has someone distributed to other GH issues the aspects jnthn wrote about?
If so, do these all share some tag or similar which can be searched for to find them?
If not, would you be able to provide a pointer to substantive discussion among core devs about how they plan to tackle the thorny issues jnthn raised, or to core devs actively agreeing not to do so (presumably punting them to 6.f or beyond)?
I'm hoping for something better than "try searching the IRC logs and/or GH issues for keywords X, Y or Z" but even that would be OK if you're saying you know the things I find if I do so will clarify what core devs plan for the future of raku language versioning.
TIA for any comment.
@raiph There were not much done to formally cover all aspects of the problem. But the most critical issues were discussed. First of all, rakudo docs now have a Jonathan's article on class versioning:
Also I can point you this problem-solving:
That's all I can come up with right now.
No specific attention was given to problem tracking issues related to this subject either. As always, it's a matter of time, you know.