Versioned Dependencies (Was: Re: Stability domains in rakudo *)
Em Sáb, 2010-03-20 às 12:16 +0300, Richard Hainsworth escreveu: Suppose we define a domain of stability as syntax/functionality/features that will not be changed until a milestone is reached, with the guarantee that if the language specification changes before then, backwards compatibility will be retained so that the syntax/feature/functionality will continue to function without a need to change it or the surrounding code. I think this is more a case for versioned dependencies. I'm not sure this is written down anywhere in the spec, but I guess there should be a way to tell this code was written targetting version $x of the implementation $y - if the code is compiled to bytecode that is really easy. Then the implementation might have a way to adapt itself to provide the intended semantics. Of course this requires an entire different set of maintainance challenges, including a very precise delta documentation and probably a lot of coercion functions, i.e: coerce from Int version 0.003 to Int 0.004 back and forth. That way we have both the grammar, the CORE and the setting being versioned, and it will be easier to adapt for the future... daniel
Re: Versioned Dependencies (Was: Re: Stability domains in rakudo *)
Daniel Ruoso wrote: Em Sáb, 2010-03-20 às 12:16 +0300, Richard Hainsworth escreveu: Suppose we define a domain of stability as syntax/functionality/features that will not be changed until a milestone is reached, with the guarantee that if the language specification changes before then, backwards compatibility will be retained so that the syntax/feature/functionality will continue to function without a need to change it or the surrounding code. I think this is more a case for versioned dependencies. I'm not sure this is written down anywhere in the spec, but I guess there should be a way to tell this code was written targetting version $x of the implementation $y - if the code is compiled to bytecode that is really easy. Then the implementation might have a way to adapt itself to provide the intended semantics. Of course this requires an entire different set of maintainance challenges, including a very precise delta documentation and probably a lot of coercion functions, i.e: coerce from Int version 0.003 to Int 0.004 back and forth. That way we have both the grammar, the CORE and the setting being versioned, and it will be easier to adapt for the future... Declaring the semantics you require by version is good. However, especially in these earlier days when lots of things are still changing, I think it would be onerous for Rakudo to actually support coersion for old semantics in general. So in the short term I see it reasonable for Rakudo to just support its current version, and when it encounters code expecting an older version of semantics, to just throw up an error message saying it can't run this and please use X version of Rakudo to run it. Or as a midway, Rakudo could support specific older versions on a case by case basis. I see 2 most-reasonable options in the short term: 1. People writing applications now could just tell their users, this requires version X of Rakudo, so make sure to install that version rather than the latest. This should be reasonable short-term, but said users should expect that they can get an updated version that works with the then-newest Rakudo say every year or 6 months or whatever. 2. Rakudo could follow Parrot's example of having more end-user focused releases every 3 months (2.0, 2.3, 2.6, etc) and just support emulation of semantics for the versions of Rakudo that correspond to those more stable Parrot releases, essentially treating them like more-stable Rakudo releases. Then, as long as the program specifies one of those every-third Rakudo versions, it will run with the latest Rakudo, for at least a year's worth of Rakudo releases since the version they require comes out. That's what I suggest for calendar 2010, starting with Rakudo * which as it happens would correspond to Parrot 2.3 if released in April; make that the oldest emulatable version, if you want to do that. And then re-evaluate or change the support strategy a year later. -- Darren Duncan
Re: Versioned Dependencies (Was: Re: Stability domains in rakudo *)
Not really a versioned dependencies. When a working module is updated to have new functionality, the old version continues to work. Here it is the very language that is changing. For instance, =$fh was used to generate input from a file. Now it is $fh.lines Old examples that I wrote using =$fh have to be changed. But there are parts of the language that have stablized, such as regexen, if/given/take statements. There are others that still havent been written, such as sets and the specs on concurrency. Suppose you have a solution that would be neat using sets. If you are scratching an itch, use sets. But if you want something even semi-permanent, avoid sets. In other words, I am suggesting a sort of mapping of the syntax of perl6 so that stable areas can us be used, perhaps avoiding instruments that are not yet explicitly stable. Daniel Ruoso wrote: Em Sáb, 2010-03-20 às 12:16 +0300, Richard Hainsworth escreveu: Suppose we define a domain of stability as syntax/functionality/features that will not be changed until a milestone is reached, with the guarantee that if the language specification changes before then, backwards compatibility will be retained so that the syntax/feature/functionality will continue to function without a need to change it or the surrounding code. I think this is more a case for versioned dependencies. I'm not sure this is written down anywhere in the spec, but I guess there should be a way to tell this code was written targetting version $x of the implementation $y - if the code is compiled to bytecode that is really easy. Then the implementation might have a way to adapt itself to provide the intended semantics. Of course this requires an entire different set of maintainance challenges, including a very precise delta documentation and probably a lot of coercion functions, i.e: coerce from Int version 0.003 to Int 0.004 back and forth. That way we have both the grammar, the CORE and the setting being versioned, and it will be easier to adapt for the future... daniel
Re: Versioned Dependencies (Was: Re: Stability domains in rakudo *)
On Saturday 20 March 2010 at 12:23, Richard Hainsworth wrote: In other words, I am suggesting a sort of mapping of the syntax of perl6 so that stable areas can us be used, perhaps avoiding instruments that are not yet explicitly stable. That assumes it's possible to know with sufficient certainty which pieces of syntax are sufficiently stable to mark as such. It's not *impossible*, and I encourage anyone willing to work on it to do so, but it seems like a large task. I wouldn't have predicted that =$fh would become $fh.lines. Manifest version number dependencies are an eventual necessity for Perl 6 (and hopefully Perl 5); moving to that model sooner rather than later could reduce a lot of pain. That seems like a smaller task which will pay off much more over time. -- c
Re: Versioned Dependencies (Was: Re: Stability domains in rakudo *)
Em Sáb, 2010-03-20 às 22:23 +0300, Richard Hainsworth escreveu: Here it is the very language that is changing. For instance, =$fh was used to generate input from a file. Now it is $fh.lines Note that I did mention versioned dependencies for grammar, CORE and setting. So yes, considering the code was properly tagged with the specific version, running it would either: 1) Run normally if the implementation provides backward emulation of an older version. 2) complain upfront that the version is not available in backward emulation and it would be subject to failure. or even 3) complain upfront that the version os not available in backward emulation, but try to get the closest version that could be emulated and give it a try. daniel
