Re: Rules and hypotheticals: continuations versus callbacks
At 12:00 AM + 3/20/03, Simon Cozens wrote: [EMAIL PROTECTED] (Matthijs Van Duin) writes: OK, I suppose that works although that still means you're moving the complexity from the perl implementation to its usage: in this case, the perl 6 parser which is written in perl 6 No, I don't believe that's what's happening. My concern is that at some point, there *will* need to be a bootstrapped parser which is written in some low level language, outputting Parrot bytecode, and it *will* need to be able to reconfigure itself mid-match. I think. I can't remember why I'm so convinced of this, and I'm too tired to think it through with examples right now, and I might be wrong anyway, but at least I can be ready with a solution if it proves necessary. :) You may well be right--I don't think so, but I'm not at my clearest either. I don't see that it'll be needed outside the initial bootstrap parser if at all, so I'm not too worried. (And the low-level language for it will probably be perl 5, since I'd far rather build something with a Parse::RecDescent grammar than a hand-nibbler in C) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Funding the design team
On Sat, Mar 15, 2003 at 05:32:39PM -0500, James Mastros wrote: On 03/14/2003 3:22 PM, Dan Sugalski wrote: That means that TPF's perl development grant fund is fine to donate to, and if there's only enough cash for one grantee, and Larry's the best candidate, that's keen. Setting up a Fund Larry Wall fund is where things get much less easy. [it's not a problem if] there was both a perl development fund, and a perl6 development fund. Then people who wanted to see things like DBI and mod_perl get funded could give to the first, and people who wanted to see Larry, you (Dan), Damian, and the gang get funded (or, unfornatly, some subset thereof, depending on how Such a fund would be the ideal but, until it is set up, there is a very easy way to fund the design team: Folks, give us your address (or a PO box, or something), where we can send checks. The checks won't be tax deductible, but are we really doing this for the tax deduction? --Dks
Re: Funding the design team
On Thu, 20 Mar 2003, David Storrs wrote: Folks, give us your address (or a PO box, or something), where we can send checks. The checks won't be tax deductible, but are we really doing this for the tax deduction? ... or a PayPal account. I've got $1.36 in my account ready to send to the development team. Sorry, the Electronic Frontier Foundation got the other $5 that was in that account this morning. -Miko Miko O'Sullivan Programmer Analyst Rescue Mission of Roanoke
Re: Rules and hypotheticals: continuations versus callbacks
--- Matthijs van Duin [EMAIL PROTECTED] wrote:
On Wed, Mar 19, 2003 at 03:46:50PM -0500, Dan Sugalski wrote:
They should be though, if a variable was hypothesized when the
continuation was taken, then it should be hypothesized when that
continuation is invoked.
Should they? Does hypotheticalization count as data modification (in
which case it shouldn't) or control modification (in which case it
should),
Isn't that the whole point of hypotheses in perl 6? You talk about
successful and unsuccessful de-hypothesizing, and about abormals
exits etc.. you seem to have a much complexer model of hypotheses
than what's in my head.
The complex model is right -- in other words, if hypotheses are to be a
first-class part of the language then they must interoperate with all
the other language features.
So there's several ways out of a sub. What does a hypo do in all these
cases?
let $x - Declares a hypothesis. I think this should be a verb.
(Which is to say, a function instead of a storage
class.)
(This in turn suggests that primitive types can't be
hypothesized, although arrays thereof could be.)
fail - Pretty strongly suggests that the hypo is ignored.
Also suggests continuation/backtracking behavior. Do we
really know what fail does? See discard, below.
discard $x - (suggested) Obvious keyword for failing one single
hypothesis.
keep $x - Suggests the value is made permanent. This should be
a verb. Ckeep with no args should just keep every
hypo in the current fillintheSCOPE.
return - This is unclear. On the one hand, it's a transfer of
control and I think that Clet and Ckeep are data,
not control, modifiers. On the other hand, it's one of
the normal ways to leave a block, and could be argued
either way.
(Also: remember the bad old days of Cmy vs. Clocal.
I propose that hypos fail by default - to keep the
distinction clear in the minds of newbies.)
throw- Exceptions unwind the call stack. If let is a
control action, it should undo. If let is a data
action, it should not. To me, Clet is an explicit
action taken against a variable, and should not be
undone by this. (Of course, if unwinding the call stack
causes the variable to go out of scope, it's not an
issue.)
continuation: goto
- Again: continuations are transfers of control, not
data. If let is a control action, continuations
will have to know if they are transferring back up
the stack or if they are transferring to some new,
never-before-seen (on the stack) place. I think that
Clet should be a data action, in which case this
doesn't affect the hypothesis.
generators: yield
- Same issues, although the argument can be made that
since you can resume a generator, the hypo should
be confined to the extant-but-inactive scope.
To me, what 'let' does is temporize a variable except it doesn't get
restored if you leave the scope, but only if you use a continuation
to go back to a point where it wasn't hypothesized yet.
Yes and no.
I agree it shouldn't get restored, see above. However, continuations
don't touch data. So a global variable that has been hypo'ed should
(IMO) remain so after the continuation.
Frankly, if you mix the two, it's YOUR job to understand the
ramifications.
When the last continuation taken *before* the hypothesis is gone, so
is the old version and thus the hypothesized variable becomes
permanent.
I disagree. Proposal and acceptance should be explicit actions.
The behavior regarding coroutines followed naturally from this, and
so does the behavior inside regexen if they use the continuation
semantics for backtracking -- which is what I'm suggesting.
This leave only behavior regarding preemptive threads, which is
actually very easy to solve: disallow hypothesizing shared
variables -- it simply makes no sense to do that. Now that
I think of it, temporizing shared variables is equally bad news,
so this isn't something new.
Why?
If you constrain hypotheses to the thread (making it a control action
instead of a data action) this could be a way to get cheap MUXing.
Hypothesize all the new values you wish, then pay once to get a mux,
then keep all the data values while you've got the mux. Shrinks your
critical region:
{: is synchronized($mux)
keep all;
}
OTOH, if you are really using threads well, then your app may construct
a hypothesis based on user input, and the math and visualizer and gui
threads may all need to work in that hypothetical space.
(Which makes continuations
Re: Rules and hypotheticals: continuations versus callbacks
On Thu, Mar 20, 2003 at 08:49:28AM -0800, Austin Hastings wrote: --- Matthijs van Duin [EMAIL PROTECTED] wrote: you seem to have a much complexer model of hypotheses than what's in my head. The complex model is right -- in other words, if hypotheses are to be a first-class part of the language then they must interoperate with all the other language features. (lots of explanation here) You're simply expanding on the details your complex model - not on the need for it in the first place. I'll see if I can write some details/examples of my model later, and show how it interacts with various language features in a simple way. This leave only behavior regarding preemptive threads, which is actually very easy to solve: disallow hypothesizing shared variables -- it simply makes no sense to do that. Now that I think of it, temporizing shared variables is equally bad news, so this isn't something new. I just realize there's another simple alternative: make it cause the variable become thread-local for that particular thread. Hypothesize all the new values you wish, then pay once to get a mux, then keep all the data values while you've got the mux. Shrinks your critical region You're introducing entirely new semantics here, and personally I think you're abusing hypotheses, although I admit in an interesting and potentially useful way. I'll spend some thought on that. My experience has been that when anyone says I don't see why anyone would ..., Damian immediately posts an example of why. No problem since it works fine in my model (I had already mentioned that earlier) - I just said *I* don't see why anyone would.. :-) So, stop talking about rexen. When everyone groks how continuations should work, it'll fall out. rexen were the main issue: Dan was worried about performance (And if you reimplement the rexengine using continuations and outperform Dan's version by 5x or better, then we'll have another Geek Cruise to Glacier Bay and strand Dan on an iceberg. :-) I don't intend to outperform him.. I intend to get the same performance with cleaner, simpler and more generic semantics. But as I said in my previous post.. give me some time to work out the details.. maybe I'll run into fatal problems making the whole issue moot :) BTW, you say reimplement ? Last time I checked hypothetic variables weren't implemented yet, let alone properly interact with continuations. Maybe it's just sitting in someone's local version, but until I have something to examine, I can't really compare its performance to my system. -- Matthijs van Duin -- May the Forth be with you!
Re: prototype (was continuations and regexes)
On Thu, Mar 20, 2003 at 11:38:31AM -0800, Sean O'Rourke wrote: Here's what I take to be a (scheme) prototype of Matthijs' success continuations approach. It actually works mostly by passing closures and a state object, ... Matthijs -- is this what you're describing? It sounds like approach #2 (callback) I listed in my original post Unfortunately, #1 is the more appealing approach of the two and is what this whole thread has been about so far. I pretty much abandoned #2 early on. I'll see if I can take a look at it later. #2's only advantage was that - as you noted - it doesn't need continuations for backtracking, but uses the normal call-chain. I've never really done anything with scheme but I know the syntax mostly, so I'll see if I can read it later on -- you obviously put quite some effort in writing it, so it deserves to be read :-) Dan -- given that the real one could optimize simple operators by putting a bunch of them inside a single sub, does this look too painful? I doubt he'll like this -- while the continuations-model is still mostly like his model (structurally), the callback-model isn't. I also think it has less opportunity for optimizations but I might be wrong about that. -- Matthijs van Duin -- May the Forth be with you!
Re: prototype (was continuations and regexes)
Oops, I just noticed Sean had mailed Dan and me privately, not on the list.. sorry for sending the reply here :-) -- Matthijs van Duin -- May the Forth be with you!
Re: Funding the design team
David == David Storrs [EMAIL PROTECTED] writes: David Such a fund would be the ideal but, until it is set up, there is a David very easy way to fund the design team: David Folks, give us your address (or a PO box, or something), where we can David send checks. The checks won't be tax deductible, but are we really David doing this for the tax deduction? I really don't see a need to donate to other than YAS. If you earmark your donation, I'm sure YAS will ensure that the money goes to your requested destination as much as is practically (and legally) possible. Stonehenge has been a major contributor to YAS. I don't see why we should start changing plans in midstream. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
