Dan Sugalski <[EMAIL PROTECTED]> wrote: > None of this is set in stone, but take a look and see how everyone feels > about this.
> I'll get to IO after, since the two are pretty tightly intertwined, and > changes to this will affect the IO stuff too. > ------------>Snip here<--------------- > Events, another design sketch I don't have the time to go through it thorougly, but nethertheless here are some remarks in no particular order: 1) Before discussing it, the document needs a glossary of all used terms There's already enough confusion. 2) I think, the exception related part should just be postponed until exceptions are layed out. 3) This "here are some opcodes" part isn't really needed at this stage. (not to talk about 12 additional op variants, just to set a timer, which is already possible now with *no* additional opcode) The ops do and can't in no way cover all possible event's data. You started off with "array/hash" combination PMC, which is good, then that idea got lost and here's again the opcode explosion. 4) I don't think, that the *internal* event is already a PMC. You can't create one in a signal handler (yes the term pre-creation was uttered - how many do you pre-create?) PMCs can *only* be created in user code. For signals and such, that's at event delivery just before a PASM handler get's running. 5) "event level" jumps in at the end in the opcode section. See 1) 6) A lot of Uri's comments apply, e.g. event states ... Enough for now leo
