Incorporting "WhatIf"
Luke Palmer
> (http://search.cpan.org/author/SIMONW/Whatif-1.01/). This module has
> the ability to provide rollback functionality for arbitrary code.
Crazy... I was just thinking about this for an experimental language
called "Snapshot" I'm about to implement for my job.
> I don't really understand continuations yet (although I'm reading up
> on them), so perhaps they would allow this to be done trivially.
> However, I think it would be very cool to roll this module into the
> core language and provide the keyword support in core.
This is what Larry wants with
let subcall();
(from Appendix C of A6). It would be great to have it in the core, if
it's feasable to implement.
The way Snapshot will probably do it is have a "local mark" on all its
variables. Then when a variable is set, it will set a field
corresponding to that local mark, and append itself to the queue
associated with that mark. Correspondingly, when it's accessed, it
would instead return the value in the local mark if it has one.
Then, upon success, it would go through that mark's queue and tell the
variables to commit themselves (maybe onto another mark field, if the
let is nested). Upon failure, it would go through the queue and tell
them to rollback.
This could be implemented with very little overhead for variables that
don't ever get assigned to during a "hypothetical" state.
> Is this feasible? What would the overhead costs be?
I'm thinking about whether this could be done as a module in P6. If
so, wow, what an extensible language.
Maybe you could, by very early on overriding the builtin Scalar
container. I'm not sure what implications that would have for
variables declared C<int>, and such. Probably just wouldn't work for
them.
Like:
our LocalMark @*LOCAL_MARK;
class LocalMark {
method add(Ref $in) {
push @.set: $in;
}
method commit() {
for @.set {
.commit;
}
}
method rollback() {
for @.set {
.rollback;
}
}
has Ref @.set is Set;
}
my class NewScalar is Scalar {
method STORE($newval is copy) {
%.mark{@*LOCAL_MARK[0]} = $newval;
}
method FETCH() {
for @*LOCAL_MARK {
return %.mark{$_} if %.mark.exists($_)
}
undef;
}
method commit() {
%.mark{@*LOCAL_MARK[1]} = %.mark{@*LOCAL_MARK[0]};
}
method rollback() {
%.mark.delete(@*LOCAL_MARK[0]);
}
has %.mark is keyed(LocalMark);
}
Scalar := NewScalar;
And then:
sub {
let foo();
}
Turns into:
sub {
unshift @*LOCAL_MARK, new LocalMark;
foo();
KEEP {
@*LOCAL_MARK[0].commit;
shift @*LOCAL_MARK;
}
UNDO {
@*LOCAL_MARK[0].rollback;
shift @*LOCAL_MARK;
}
}
Or something.
I think it's a very powerful concept at the language level, however.
Luke
David Storrs
(http://search.cpan.org/author/SIMONW/Whatif-1.01/). This module has
the ability to provide rollback functionality for arbitrary code.
I don't really understand continuations yet (although I'm reading up
on them), so perhaps they would allow this to be done trivially.
However, I think it would be very cool to roll this module into the
core language and provide the keyword support in core.
Is this feasible? What would the overhead costs be?
--Dks
Simon Cozens
> > Is this feasible? What would the overhead costs be?
>
> I'm thinking about whether this could be done as a module in P6. If
> so, wow, what an extensible language.
If not, given that it's already been done in Perl 5, that would really suck.
> I think it's a very powerful concept at the language level, however.
That way lies madness, but we already may well be a fair distance down
that way.
--
It starts like fascination, it ends up like a trance
You've gotta use your imagination on some of that magazine romance
And these bones--they don't look so good to me
Jokers talk and they all disagree
One day soon, I will laugh right in the face of the poison moon
Luke Palmer
> > > Is this feasible? What would the overhead costs be?
> >
> > I'm thinking about whether this could be done as a module in P6. If
> > so, wow, what an extensible language.
>
> If not, given that it's already been done in Perl 5, that would really suck.
LOL, naturally I meant the more efficient way I described, not relying
on fork()'s copying of every single variable.
David Storrs
> fibo...@babylonia.flatirons.org (Luke Palmer) writes:
> > dst...@dstorrs.com (David Storrs) writes:
> > > Is this feasible? What would the overhead costs be?
> >
> > I'm thinking about whether this could be done as a module in P6. If
> > so, wow, what an extensible language.
>
> If not, given that it's already been done in Perl 5, that would really suck.
I'm sure it can be done in a P6 module. What I'm wondering is can we
do it in the P6 core, such that it is not necessary to invoke any
pragmas/use an modules. Furthermore, the current implementation
depends on fork(), and thus will not work on platforms that do not
support it. Could we do away with that requirement by having the
interpreter save the necessary state internally?
--Dks
Simon Cozens
> I'm sure it can be done in a P6 module. What I'm wondering is can we
> do it in the P6 core, such that it is not necessary to invoke any
> pragmas/use an modules.
Can you run the 'why' past me once again before we start on the 'can'?
--
A booming voice says, "Wrong, cretin!", and you notice that you have
turned into a pile of dust.
David Storrs
> dst...@dstorrs.com (David Storrs) writes:
> > I'm sure it can be done in a P6 module. What I'm wondering is can we
> > do it in the P6 core, such that it is not necessary to invoke any
> > pragmas/use an modules.
>
> Can you run the 'why' past me once again before we start on the 'can'?
Hmmm...I'm not sure if you're asking me "Why do you want to have this
feature in core (i.e. w/o using a module)?" or "Why do you want to
have this feature at all?"
If you are asking the latter, then I fear that we're having a rift; to
me, this feature is so obviously useful that I will need you to
explain why you see it as an issue.
If you are asking the former, then the answer is "I would like to see
this feature supported in a way similar to how we support P5's
$&--that is, it doesn't cost you anything unless you use it. If this
is the case, then there is no reason that it should not be in core,
and therefore it should not require a use/pragma/etc."
--Dks
Simon Cozens
> If you are asking the latter, then I fear that we're having a rift; to
> me, this feature is so obviously useful that I will need you to
> explain why you see it as an issue.
I haven't needed it (or even really wanted it) in any of the
programming I've done in the last ten years, and I don't know of many
programming languages that have needed it in the last thirty.
> If you are asking the former, then the answer is "I would like to see
> this feature supported in a way similar to how we support P5's
> $&--that is, it doesn't cost you anything unless you use it. If this
> is the case, then there is no reason that it should not be in core,
> and therefore it should not require a use/pragma/etc."
If you are determining whether or not something ought to go in core
based on the resulting number of "use" statements in your program, then
I fear we're never going to see eye to eye on this one.
--
Apr 13 11:05:20 apollo13 fsck[3927]: root, we have a problem.
- Jeff Gostin <jgo...@shell2.ba.best.com>
David Storrs
> dst...@dstorrs.com (David Storrs) writes:
> > If you are asking the latter, then I fear that we're having a rift; to
> > me, this feature is so obviously useful that I will need you to
> > explain why you see it as an issue.
>
> I haven't needed it (or even really wanted it) in any of the
> programming I've done in the last ten years, and I don't know of many
> programming languages that have needed it in the last thirty.
As to needing it: you don't *need* recursion, or iterators, or
hashes, or exceptions, or inheritance; all of these things can be done
without. But they certainly make your life easier under certain
circumstances.
As to wanting it...fine. But that's a subjective thing. But *I* have
wanted it, pretty often. And obviously Simon Winstow wanted it enough
to write a module for it. And based on what I see in the release
notes, a bunch of the members of London.pm wanted it enough to help
him out.
> If you are determining whether or not something ought to go in core
> based on the resulting number of "use" statements in your program, then
> I fear we're never going to see eye to eye on this one.
That's not how I'm determining whether or not it should go in core. I
would like to see it in core because I think it's a feature of such
power and such versatility that it deserves to be there.
What are your criteria for putting something in core?
--Dks
Joseph F. Ryan
By that argument, why isn't LWP in the core of Perl5? Or what about the
Template Toolkit?
The core should be a smallest set of possible modules to define the
language and its features, and possibly a few utility modules that are
used often enough to seem like a core-language feature (e.g. CGI.pm).
To me, WhatIf certainly wouldn't be a core-language feature, and I
don't think that it would be used often enough to be included as a
utility module. Something like WhatIf should be fine as a CPAN
module.
Hopefully the Perl6 core will remain (relatively) small and
lightweight. It will be hard to convince someone to use it if they
need to sit through a 100M download and a 2 hour make.
Joseph F. Ryan
ryan...@osu.edu
Dan Sugalski
Mine is that it provides extra utility at marginal cost. This doesn't
(the cost isn't marginal) and it has some significant issues attached
to it, like trying to roll back things with side-effects, of which
there are potentially a lot of issues. (Or don't, and have
potentially bizarre things happen)
Not going to be core. If someone does the work to make it happen, great.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
David Storrs
[criteria for putting things in core]
> Mine is that it provides extra utility at marginal cost. This doesn't
> (the cost isn't marginal)[...]
>
> Not going to be core. If someone does the work to make it happen, great.
See, this is all I was looking for; I'm fine with the idea of "the
cost is non-marginal so it's not core." My original question was "is
this feasible and what would the costs be?" I just wanted to know if
there was a way to do it at marginal cost. Since there isn't, I'll
shut up.
Thanks for settling it Dan. :>
--Dks
Austin Hastings
My argument for including it in the core would be that it enables a
paradigm. This is essentially true of patterns (which will soon be
available in P5, non-core) and continuations. It's true of threads,
which is why I believe that thread support should be a part of the
fundamental language design. It's true of multiple dispatch (as seen by
the hideous result of attempting to implement it out-of-core in P5) and
true for the (much-improved) object system.
Frankly, I've never used whatif. I can't, of course, because most of my
work is on windows, where fork is both slow AND unreliable. I think
that whatif could be implemented as a module using threads, if threads
are done right (stack fanning), and so I'm willing to forego whatif
myself.
However, if someone can show a simple, clean piece of code that only
works because of whatif, maybe I'll get excited about it and push.
So, someone's got a selling job ahead...
=Austin
Larry Wall
: > I'm sure it can be done in a P6 module. What I'm wondering is can we
: > do it in the P6 core, such that it is not necessary to invoke any
: > pragmas/use an modules.
:
: Can you run the 'why' past me once again before we start on the 'can'?
For exactly the same reason we added closures--to support alternate
programming paradigms. I believe that management of hypotheticality
is the essence of logic programming. And like closures, it'd oughta
just work the way people expect, so that those who think they only
know about procedural programming can accidentally discover that they
already know about logic programming too.
Fact of the matter is that many Perl programmers already have a pretty
good grasp of logic programming in the domain of regexes. And temp
variables are already a weak form of hypothetical.
Larry
Simon Cozens
> My argument for including it in the core would be that it enables a
> paradigm.
"And it should be a law..."
> This is essentially true of patterns (which will soon be
> available in P5, non-core) and continuations. It's true of threads,
> which is why I believe that thread support should be a part of the
> fundamental language design. It's true of multiple dispatch (as seen by
> the hideous result of attempting to implement it out-of-core in P5) and
> true for the (much-improved) object system.
It's also true of AOP, test-driven design, encapsulators, code hiding, (for
the all-important commercial software paradigm) logic programming, automatic
network distribution, generics, genetic and ontogenetic programming, MPI,
OOBP, plug-and-play software, and Brainfuck.
Should these all be in core too?
--
I respect faith, but doubt is what gives you an education.
-- Wilson Mizner
Simon Cozens
> What are your criteria for putting something in core?
If I Were King, things would be in core if they couldn't possibly be
implemented outside of core. This worked for Perl 5 prior to 5.6, and
works for C, shell, Ruby (depending on your definition of core) and a
bunch of other languages.
But then, why ask me? I'm not king.
--
You are in a maze of little twisting passages, all alike.
Austin Hastings
Yes. Provided they are of value (frankly, OOBP/PnPS looks to me like a
rehash of shell scripting, dragged out of the corner to justify some
sort of government grant) and that they couldn't be done without core
support, then it's reasonable to ask for core support for them.
This could be as simple as making the object vtables visible from the
language level (to support AOP), or it could be voodoo. But the rule
stands: if your paradigm can't be done in Perl without core support,
then ask for core support.
The worst that can happen is that @Larry says "no."
=Austin
Andy Wardley
> For exactly the same reason we added closures--to support alternate
> programming paradigms. I believe that management of hypotheticality
> is the essence of logic programming.
Management of hypotheticality sounds a little like the temporal logic
programming I was just reading about.
CTL (Computation Tree Logic), for example, defines the following
operators:
A = all
E = Exists
X = neXt
G = Global
F = Future
U = Until
And here are some example expressing temporal logic:
EXp => some state 'p' can happen next
AFp => all states 'p' can happen some time in the future
A[p U q] => all states 'p' can happen until state 'q'
Other than the theoretical curiosity, I'm afraid I have no idea how
this might relate to Perl. It just occurred to me that there was
a similarity between the kind of hypothetical logic that you describe
and temporal logic. Perhaps there is some insight that can be gained
from the correlation.
A