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
