OK, OK. I happen to agree that qs// would be helpful to a lot of people. But please don't rant. It just makes me move closer to writing that long-reply-post-with-no-patches-in-it filter I've been considering. Putting words into your mouth (and using a long spoon), it seems to me that what you want could be satisfied by use esql; # Argue about the name later, if at all! ... $SIG{__SQLERR__} = \&myhandler; ... @result = qs/select @cols from $table where $col = $val/; which is the embedded SQL fan's (count me in) particular special case of use MyDreamPerl; For more on that, see Larry's http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-04/msg01610.html, which follows up Tim Bunce's http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-04/msg01558.html. For thoughts on a subject which has been sporadically discussed without anything happening, see Marc Lehmann's http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-10/msg00704.html. Well, without anything happening for Perl 5, where it's not even on the Todo list, that is: it's meant to happen in Perl 6, but I don't follow those developments. Larry's mail suggests he's open to it happening in Perl 5 too. So, a couple of questions: Given that support for C<use MyDreamPerl> (or some sufficient subset thereof) appeared reasonably promptly in Perl 5, would my suggestion fill the need you perceive? Given that the medium-complex underpinnings of C<use esql> would not be part of the core, and would need to be maintained separately, can you suggest a constituency that might be prevailed upon to take responsibility for development and maintenance? And finally, a question for the porters in general: Given that C<use MyDreamPerl> isn't with us yet, what would it take? (Which is intimately related to "How badly does anybody want it?".) Could it or should it be a possibility for 5.8? -- Dominic DunlopThread Previous | Thread Next