>>>>> "UG" == Uri Guttman <[EMAIL PROTECTED]> writes:
>>>>> "CF" == Chaim Frenkel <[EMAIL PROTECTED]> writes:
CF> Please explain how any of this will make signals safer? Safer
CF> signals is a core issue. Not a language issue. Whatever mechanism
CF> you select it will not make signals safer.
UG> then tell me how you request delivery of a safe signal without any
UG> language hooks? the delivery must be controlled by the program, hence it
UG> has to have language to access that control.
As I said, just make up the syntax and semantics. With respect to the
language constructs.
CF> This is appropriate here in -language(-flow) if you want to change
CF> the user level interface. Otherwise, it belongs in -core.
UG> it affect both levels. as i have stated, i want to explain the reasons
UG> for the language changes and to show a path for how it can be
UG> implemented. and also showing how the signal delivery would interact
UG> with other flow control areas.
I haven't seen where in the _language_ there is anything about how to
implement. I don't think there should be.
UG> the mailbox thing is a language issue. so is the pragma that tells perl
UG> how to deliver signals, via op code check every N ops or via a mailbox
UG> or via event loops. since perl is interpeted and signals are
UG> asynchronous with regard to that interpreter, there has to be a code
UG> level method of describing the method of synchronization. the only
UG> alternative is forcing the insertion of signal checking op codes. and no
UG> one wants that.
Where in the language is there any mention of op codes? Why are you
bringing it in?
CF> Perhaps this RFC should simply be renamed. "New singal handling
CF> metaphor" or whatever.
UG> i disagree. it is a language issue and then it will evolve into an
UG> internals issue.
Keep it at a language level. If the semantics are hard to implement
then go back to the drawing board.
<chaim>
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
