Re: Using Perl in QA departments
Looks a little familiar.. Great job! I'm glad your examples make use of lexically scoping temporary variables. That's a technique I picked up a little too late for PTDN, unfortunately. On 6/17/06, Gabor Szabo <[EMAIL PROTECTED]> wrote: If anybody is interested on this list, the slides and the examples of my 2 days course are available here: http://www.szabgab.com/perl_in_test_automation.html regards Gabor -- Ian Langworth
Re: Exceptions, dynamic scope, Scheme, and Lisp: A modest proposal
On Sat, Jun 24, 2006 at 11:18:41PM -0400, Bob Rogers wrote: >From: Chip Salzenberg <[EMAIL PROTECTED]> >Date: Tue, 20 Jun 2006 20:59:45 -0700 > >WRT exception handling, I think the lisp condition/handler model is a good >starting point. It's simple enough to explain and use, and static models >can easily be implemented in terms of it. > > Excellent; I'm sure you won't be surprised to learn that I agree. ;-} Consensus is easy to achieve when one party is obviously correct. :-) >But I really don't like one thing about the CL handler model: it conflates >non-local transfers of control with "this exception is now handled". > > FWIW, some pre-ANSI implementations did have a mechanism for marking a > condition as having being handled [...] No, nothing like a 'handled' flag in the condition. It's just a question of how Parrot should be informed that an exception is caught ... whether all languages, rather than CL, should make non-local control flow semantically significant. Consider: from Parrot's low-level POV, how could Parrot notice when it's leaving the dynamic context of a condition handler specifically, so as to change its internal state of "There's a live condition that's in the process of being handled" into "Ah, all done then, the handling is over"? The most obvious answer involves extra processing checking for the situation of exception-handling, but that would slow down every continuation invocation. Fortunately, we don't have to go there. To quote myself: >If dynamic-wind is implemented (see below), it seems to me that a CL >compiler could wrap each handler in a dynamic scope in such a way as to > trap >a non-local transfer distinctly from a return, and in the former case, >automatically invoke the hypothetical Parrot "caught" opcode. So CL users >get full CL semantics, and everybody gets a faster continuation.invoke() >operation. In other words: Dymamic-wind processing will be required in every continuation invocation. Therefore, if Lisp-style condition handling is build on D-W, CL will *not* require a special flag/check/slowdown. In fact, CL would not be alone in this: most of the exception code for most languages could be written in PIR. That's not only nice in itself, but it's a very good sign for the power of PIR. Quoting you out of order: >I even intend to use continations to implement THROW and CATCH; I > just won't be able to expose them to users via standard Lisp constructs. > So, yes, I could install the equivalent of an UNDO block around the Lisp > code that does whatever Parrot maintenance is required on the Parrot > exception object (which, it now occurs to me, may need to be distinct > from the Lisp condition object). But would I really need to do anything > here? If an exception is caught by Lisp, why would Parrot even need to > know? S04 seems to require a great deal of bookkeeping for unhandled > exceptions, but would that necessarily impact Lisp handlers? It's just a little hack, no big deal. Imagine this scenario: 1. Parrot has exceptions 2. Parrot requires handlers to mark exceptions handled with a "caught" opcode 3. Parrot has dynamic-wind Given: (handler-case (signal condition) (printer-on-fire () YOUR_FORM_HERE)) Your CL compiler would replace YOUR_FORM_HERE with the equivalent of this, written in pidgin Scheme: (let ((handled #t)) (dynamic-wind ;; entry thunk (none) nil ;; body thunk (CL handler code goes here) (lambda () YOUR_FORM_HERE (set! handled #f)) ;; departure thunk (lambda () (when handled;; only a non-local transfer could avoid (set! ... #f) (parrot-emit "caught") ;; here's where you tell Parrot the exception is handled (set! handled #f) ;; ... but we only want to do so once per exception I suspect that the lexical nature of the 'handled' flag may not match the interpreter-wide-dynamic nature of the signal stack, leading to incorrect results with nested signals. But with that caveat, I think this would work. Anyway, the point of this whole dance is to implement the CL semantics, which require you to *detect* and *take special action on* the handler body making a non-local transfer out of the dynamic scope ... something which you want, since non-local transfers are semantically significant in the definition of CL condition handlers (and only CL condition handlers :-)). Moving on: I may have missed some of the implications of what I'm not quoting, but this: > Such an implementation is truly and utterly stackless, which means that > dynamic-wind needs to keep its own stack explicitly, and similarly for > dynamic binding (which, IIUC, is generally implemented in terms of > dynamic-wind). ... actually describes Parrot, present and future. Parrot doesn't need to recurse in C to invoke continuations or closures (even if maybe it does in s
Exceptions, dynamic scope, Scheme, and Lisp: A modest proposal
From: Chip Salzenberg <[EMAIL PROTECTED]> Date: Tue, 20 Jun 2006 20:59:45 -0700 WRT exception handling, I think the lisp condition/handler model is a good starting point. It's simple enough to explain and use, and static models can easily be implemented in terms of it. Excellent; I'm sure you won't be surprised to learn that I agree. ;-} But I really don't like one thing about the CL handler model: it conflates non-local transfers of control with "this exception is now handled". FWIW, some pre-ANSI implementations did have a mechanism for marking a condition as having being handled, but in the long run, I believe this was considered not useful. In particular, having a "stateless" condition object (i.e. one that does not record its progress through the signalling mechanism) makes it cleaner to resignal the same condition object later on. So (1) every continuation invocation has to check to see whether an exception is live so it can be marked dead, which complicates what should be as efficient as possible, . . . I don't understand this. Is the exception itself a first-class object? If so, then whether it's live or dead is up to the GC. If not, then users can't be allowed to get their grubby paws on it, lest they stuff it away in some persistent data structure. But probably I have a fundamental misunderstanding here; maybe you meant "live" and "dead" in a different sense? . . . and (2) creative condition handlers can't use continuations as an implementation tool. I don't understand this either (I'm certainly planning on doing so), but that is probably because you've already lost me. But I see a way out; see below. On Thu, Jun 15, 2006 at 12:03:56AM -0400, Bob Rogers wrote: >3. FWIW, the Scheme dynamic-wind feature requires an action to be > invoked when re-entering the context as well as leaving it. But this is > probably not relevant, as a real Scheme implementation would probably > not need Parrot continuations or actions in any case. Huh, that's odd, coming from you. Having just spent the better part of my evening wrapping my head around call/cc and dynamic-wind, I'm about to modify pdd23 to replace push_handler with: push_handler?? I assume you mean pushaction? $P0 = newclosure sub_to_call_when_entering_scope $P1 = newclosure sub_to_call_when_leaving_scope $P2 = newclosure sub_to_call_when_scope_is_finally_inaccessible push_dynscope $P0, $P1, $P2 # [*] ... pop_dynscope # [**] So, having chosen Scheme as a good model for scope and continuation handling, wouldn't a Scheme compiler want to take advantage of that? Good question. ;-} I could be mistaken, but I said this because I believe that Scheme has a different idea of continuation than Parrot. In brief [1], if you rewrite call-and-return into pure continuation-passing calling, it looks like a call into the sub followed by another call to the continuation. All of these can in fact be implemented as tail calls, since there are no returns, and Scheme stipulates that you *must* tail-merge where possible. This means you don't need a stack -- there is never more than one activation record at any given time -- so all of the state required for a continuation can be captured by a closure. In the Lisp community generally, "closure" and "continuation" are therefore often used interchangeably, though this does sweep some distinctions under the rug. So all a CPS language really needs is support for closures. Such an implementation is truly and utterly stackless, which means that dynamic-wind needs to keep its own stack explicitly, and similarly for dynamic binding (which, IIUC, is generally implemented in terms of dynamic-wind). Mind you, my knowledge of Scheme is purely theoretical. In fact, I hadn't even encountered dynamic-wind myself until just a few months ago. So my guesses about what a Scheme implementer would or would not do must be taken with a large grain of salt. It might be possible to create a conforming Scheme implementation without CPS, but on the other hand, every time I encounter CWCC I learn something new, so what do I know? One question about push_dynscope, though: Is the sub_to_call_when_scope_is_finally_inaccessible called when the Parrot_Context is reclaimed? If so, why is that needed? And getting back to exceptions, I'm seeing something that's pretty much like the CL model, where the 'push_eh' opcode takes a _closure_, and the list of handlers is its own array in the interpreter, not in the generic control stack, and which is called at 'throw' time in the dynamic context of the 'throw'. For conventional static languages like Perl 6 (:-)), the handler would pretty much report that the exception was handled (e.g. with a 'caught' opcode) and then invoke a continuation which had been taken by the Perl 6 compiler to point to the 'catch' code . . .
Re: lexical lookup and OUTER::
On Sat, Jun 24, 2006 at 04:52:26PM -0700, Audrey Tang wrote: > $x = 1 if my $x; > > The compiler is "allowed" to complain, but does that means it's also > okay to not die fatally, and recover by pretending as if the user has > said this? > > # Current Pugs behaviour > $OUTER::x = 1 if my $x; I think that a statement like C<< $x = 1 if my $x; >> ought to complain. Put slightly differently, if it's an error in any of the compilers, it probably should be an error in all of them. > If it's required to complain, then the parser need to remember all > such uses and check it against declaration later, and it'd be better > to say that in the spec instead. I think that S04's phrase "then it's an error to declare it" indicates that this should always be treated as an error. How/when the compiler chooses to report the error is up to the compiler. :-) That said, I wouldn't have any objection to removing or altering "the compiler is allowed to complain at that point" phrase so as to remove this particular ambiguity. Pm
Re: lexical lookup and OUTER::
在 2006/6/24 上午 8:41 時，Patrick R. Michaud 寫到： because later in the scope $x may be declared, so it's safer to just put OUTER right there. I don't think $x can be declared later in the scope. According to S04, If you've referred to $x prior to the first declaration, and the compiler tentatively bound it to $OUTER::x, then it's an error to declare it, and the compiler is allowed to complain at that point. Hmm, looks like it's been changed this April. In that case, indeed the emitter can safely remove the implicit OUTER calls. Pugs's Parrot backend has been updated accordingly. Thanks! (...and Cc'ing p6l for the part below) However, the spec wording is ambiguous: $x = 1 if my $x; The compiler is "allowed" to complain, but does that means it's also okay to not die fatally, and recover by pretending as if the user has said this? # Current Pugs behaviour $OUTER::x = 1 if my $x; If it's required to complain, then the parser need to remember all such uses and check it against declaration later, and it'd be better to say that in the spec instead. Thanks, Audrey PGP.sig Description: This is a digitally signed message part
Parrot IO
Hi, Is Parrot IO going to be implemented via opcodes or PMC? I looked at some old email discussion. There were discussions on refactoring some IO opcodes to PMC's (e.g socket opcodes). Have we reached on any decisions as to how we are going to implement the Parrot IO? -- Thanks, Vishal
Re: lexical lookup and OUTER::
On Sat, Jun 24, 2006 at 10:41:44AM -0500, Patrick R. Michaud wrote: > On Sat, Jun 24, 2006 at 08:03:47AM -0700, Audrey Tang wrote: > > 2006/6/24, Nicholas Clark <[EMAIL PROTECTED]>: > > >Is Parrot assembler considered a more productive language to write in than > > >C? > > >If yes, is it logical to write opcodes such as this one in Parrot assembler > > >itself? > > > > Err, well, that will likely completely kill the performance. :-) > Part of me wonders if OUTER occurs frequently enough that it > needs a C-based opcode. However, given that we have at least Which was sort of my question, although I wasn't clear. > two languages (Perl 6 and Tcl) that are indicating they need > to be able to do OUTER lookups, it may deserve an opcode. Is it only possible to write parrot opcodes in C? Nicholas Clark
Re: lexical lookup and OUTER::
On Sat, Jun 24, 2006 at 08:03:47AM -0700, Audrey Tang wrote:
> 2006/6/24, Nicholas Clark <[EMAIL PROTECTED]>:
> >Is Parrot assembler considered a more productive language to write in than
> >C?
> >If yes, is it logical to write opcodes such as this one in Parrot assembler
> >itself?
>
> Err, well, that will likely completely kill the performance. :-)
>
> I had an implementation before Parrot had lexical pads, using global
> variables and manual walking to emulate it. It was horribly slow.
> Especially consider that Pugs currently compiles:
>
>my $x; sub f { say $x; ...
>
> to
>
>my $x; sub f { say $OUTER::x; ...
>
> because later in the scope $x may be declared, so it's safer to just
> put OUTER right there.
I don't think $x can be declared later in the scope. According to S04,
If you've referred to $x prior to the first declaration,
and the compiler tentatively bound it to $OUTER::x,
then it's an error to declare it, and the compiler is
allowed to complain at that point.
The Perl 6/Parrot compiler is simply using the find_lex opcode,
which of course does the outer lookups directly. OUTER comes into
play only when we need to explicitly exclude the current lexical
scope from the lookup.
> Of course, if we cannot have an efficient OUTER lookup, we can always
> do a post analysis on the block body and convert unneccessary OUTER::
> away, but I don't think it's a good idea to force compile writers to
> do that.
Part of me wonders if OUTER occurs frequently enough that it
needs a C-based opcode. However, given that we have at least
two languages (Perl 6 and Tcl) that are indicating they need
to be able to do OUTER lookups, it may deserve an opcode.
Pm
Re: lexical lookup and OUTER::
2006/6/24, Nicholas Clark <[EMAIL PROTECTED]>:
On Fri, Jun 23, 2006 at 01:43:03PM -0700, Matt Diephouse wrote:
[Parrot assembler implementation]
> Of course, that doesn't mean that I wouldn't like an opcode to do it for
> me. :-)
Is Parrot assembler considered a more productive language to write in than C?
If yes, is it logical to write opcodes such as this one in Parrot assembler
itself?
Err, well, that will likely completely kill the performance. :-)
I had an implementation before Parrot had lexical pads, using global
variables and manual walking to emulate it. It was horribly slow.
Especially consider that Pugs currently compiles:
my $x; sub f { say $x; ...
to
my $x; sub f { say $OUTER::x; ...
because later in the scope $x may be declared, so it's safer to just
put OUTER right there.
Of course, if we cannot have an efficient OUTER lookup, we can always
do a post analysis on the block body and convert unneccessary OUTER::
away, but I don't think it's a good idea to force compile writers to
do that.
Thanks,
Audrey
Re: Can foo("123") dispatch to foo(Int) (was: Mutil Method Questions)
so back to foo("bar"). What's the default behavior? String doesn't Num,
does it? though is does convert if the value is good
Does that mean foo("123") should or should not dispatch to foo(Int)?
Or even foo(Num), for that matter Oy, I could see some headaches
around setting these rules in mind, lol What's the DWIMmiest
behavior hear?
I assume foo(1) would dispatch to foo(Int) rather than foo(Num), as the
most restrictive fit, and I could see how that could blow up in my
face. Is there some basic compile time warning (and a way to tell it
"shut up, I know what I'm doing") that says "hey, these are
suspiciously close signatures, are you sure this is what you wanted?"
Is the difference that foo("123") can be easily converted to foo(123)
without data loss, whereas foo("bar") to foo(0) cannot?
--- Jonathan Scott Duff <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 23, 2006 at 09:11:44PM +0300, Markus Laire wrote:
> > And what about other types?
> > e.g. if String can't ever be "best candidate" for Int,
> > then does that mean that neither can Int ever be "best candidate"
> > for Num, because they are different types?
>
> Well, I think Num and Int *aren't* different types because as far as
> duck typing goes, Num does Int. I wouldn't expect that String does
> Int though (at least not without some help :).
>
> The way I see it, the types specified in the signature are like
> constraints. When you say
>
> sub foo (Num) { ... }
>
> the signature says that "only an item that can perform the Num role
> may fit in this slot". When perl tries to match Capture to Signature,
> it checks the type of each argument in the Capture against the
> "does list" for each parameter in the Signature. If the argument
> type appears in the "does list" of the Signature, then it's a match
> and all is well. Otherwise it's an error. Since "Num does Int",
> a call such as C succeeds.
>
> At least that's my vague interpretation of this aspect of perl6 at
> this moment. :-)
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: lexical lookup and OUTER::
On Fri, Jun 23, 2006 at 01:43:03PM -0700, Matt Diephouse wrote: > While you can't do this with find_lex currently, you *can* do it. Tcl > walks the lexpads to find lexicals. (See > languages/tcl/runtime/variables.pir): [Parrot assembler implementation] > Of course, that doesn't mean that I wouldn't like an opcode to do it for > me. :-) Is Parrot assembler considered a more productive language to write in than C? If yes, is it logical to write opcodes such as this one in Parrot assembler itself? Nicholas Clark
