On Tue, 6 Feb 2001 04:36:36 +1100 (EST), Damian Conway wrote:
>RFC 271 handles this. Your example would be:
>
>sub readit {
>open F, "< $f" ...
>scalar()
>}
>post readit {
>close F;
>}
The connection between these two things is
Dan Sugalski wrote:
[snip]
> That's OK, since my example was wrong. (D'oh! Chalk it up to remnants of
> the martian death flu, along with too much blood in my caffeine stream) The
> example
>
> $foo{bar} = $baz + $xyzzy[42];
>
> turns into
>
>baz->vtable->add[NATIVE](foo, baz, xyzzy, key)
On Tue, Feb 06, 2001 at 12:28:23PM -0500, Dan Sugalski wrote:
> At 11:26 AM 2/6/2001 +, Tim Bunce wrote:
> >[First off: I've not really been paying attention so forgive me if I'm
> >being dumb here. And many thanks for helping to drive this forwards.]
> >
> >On Mon, Feb 05, 2001 at 05:14:44PM
Bart Lateur <[EMAIL PROTECTED]> writes:
> The place where it would be put, would be irrelevant.
>
> sub readit {
> POST {
> close F;
> }
> open F, "< $f" ...
> scalar()
> }
Would the POST be executed if the open fails? Wh
On Tue, 6 Feb 2001 17:53:17 -0200, Branden wrote:
>It appears you're blessing one reference and returning another... like
>
>sub new {
>my $key;
>my $a = \$key;
>my $b = \$key;
>bless $a;
>return $b;
>}
>
>I think the problem is not with the overloa
Edwin Steiner wrote:
>
> Dan Sugalski wrote:
> [snip]
> > That's OK, since my example was wrong. (D'oh! Chalk it up to remnants of
> > the martian death flu, along with too much blood in my caffeine stream) The
> > example
> >
> > $foo{bar} = $baz + $xyzzy[42];
> >
> > turns into
> >
> >baz
[CC'ed to language, because I think it's there that it belongs]
On Mon, 5 Feb 2001 15:35:18 -0200, Branden wrote:
>There are two possible things that could happen when you say:
>$a = $b;
>@a = @b; # or
>%a = %b;
>
>These two things are assignment and aliasing.
No way. Although I th
Johan Vromans wrote:
>
> Would the POST be executed if the open fails? Why? Why not?
Of course. It's a post-handler on the sub.
> All that POST and such do, is obfuscate the flow of control.
No more so than contine{} on a loop, or END{} in a file, or DESTROY{}
in a class.
--
John Porter
Tony Olekshy wrote:
>
> I think "always" should be part of an explicit statement, such
> as "try", not some implied property of block structure introduced
> by a dangling clause (inside or outside).
Why? For that matter, why must "try" itself be explicit?
It says, "I'm probly gonna put some e
Johan Vromans <[EMAIL PROTECTED]> writes:
[...]
> But I think this is getting ridiculous. $slightly_joking++; I'd
> propose a much nicer and cleaner concept:
>
> sub readit {
> open F ... ;
> prog1 {
> scalar();
> close F;
> }
> }
>
> 'prog1' e
Tony Olekshy wrote:
> I think "always" should be part of an explicit statement, such
> as "try", not some implied property of block structure introduced
> by a dangling clause (inside or outside).
Funny, during the perl6 RFC period, during the discussion of the exception
handling RFCs 88 and 119
At 09:59 AM 2/7/01 -0500, John Porter wrote:
>Tony Olekshy wrote:
> >
> > I think "always" should be part of an explicit statement, such
> > as "try", not some implied property of block structure introduced
> > by a dangling clause (inside or outside).
>
>Why? For that matter, why must "try" itse
Peter Scott wrote:
>
> I want the 'try' there for my sake, not Perl's; ... it
> helps alert me that the following block is subject to non-local control
> flow rules.
Huh? Down that road lies the Java madness.
eval {
foo();
};
sub foo {
b
Dan Sugalski wrote:
> At 01:35 PM 2/7/2001 -0200, Branden wrote:
> >2. Making the implementation of `tie' and `overload' more efficient
('cause
> >it's very slow in Perl 5).
>
> No, not at all. This isn't really a consideration as such. (The vtable
> functions as desinged are inadequate for most o
Dan Sugalski wrote:
> Splitting the vtable into two pieces, with one piece not tied to a PMC,
> makes some things impossible. Consider this:
>
>@foo = @bar * @baz;
>
> where all three arrays are really matrix types.
By the PDD's notion of `key', what would be the `key' of a matrix type ?
(I
Dan, before I followup your reply to my list of nits about the PDD,
can I clarify one thing: destruction.
I am assuming that many PMCs will require destruction, eg calling
destroy() on a string PMC will cause the memory used by the string
data to be freed or whatever. Only very simple PMCs (such
David Mitchell wrote:
> Perl 5 only supports Perl-mode tieing and overloading - ie, where
> the tied or overloaded functions that get called are Perl functions.
> This is slow and heavyweight, but it is easy to code (ie you write
> a Perl module with a few functions).
>
Actually, I think Perl 5 s
At 01:14 PM 02-07-2001 -0500, Dan Sugalski wrote:
>At 01:35 PM 2/7/2001 -0200, Branden wrote:
>>As far as I know (and I could be _very_ wrong), the primary objectives of
>>vtables are:
>>1. Allowing extensible datatypes to be created by extensions and used in
>>Perl.
>
>Secondarily, yes.
>
>>2. Ma
At 07:05 PM 2/7/2001 +, David Mitchell wrote:
>Dan, before I followup your reply to my list of nits about the PDD,
>can I clarify one thing: destruction.
>
>I am assuming that many PMCs will require destruction, eg calling
>destroy() on a string PMC will cause the memory used by the string
>da
On Wed, Feb 07, 2001 at 05:15:41PM -0600, David L. Nicol wrote:
> Nicholas Clark wrote:
> >
> > On Wed, Feb 07, 2001 at 04:30:24PM -0600, David L. Nicol wrote:
> >
> > > sub has_post_blocks{
> > > my $i = 3;
> > > post { print "i ended up as $i"};
> > >
At 06:12 PM 2/7/2001 +, Nicholas Clark wrote:
>On Wed, Feb 07, 2001 at 05:54:14PM +, David Mitchell wrote:
> > Well, many of the vtable methods are operator-ish rather than value-ish,
> > presumably on the grounds of efficiency. A pure 'value' vtable wouldnt
> > have add(), concatenate() e
At 04:02 PM 2/7/2001 +, David Mitchell wrote:
> > >Please see my previous post on the subject. As I pointed there,
> implementing
> > >|| and && like that breaks short-circuits.
> >
> > No, it doesn't. Just because you pass in two PMCs doesn't mean that they
> > both need to be evaluated. Tho
At 11:13 AM 2/7/2001 +0100, Edwin Steiner wrote:
>Dan Sugalski wrote:
>[snip]
> > That's OK, since my example was wrong. (D'oh! Chalk it up to remnants of
> > the martian death flu, along with too much blood in my caffeine stream) The
> > example
> >
> > $foo{bar} = $baz + $xyzzy[42];
> >
> > tu
BTW, should the vtable include all the mutator operators too, ie
++, += and so on, on the grounds that an implementation may be able
do this more efficiently internally?
On Wed, Feb 07, 2001 at 04:03:49PM +, David Mitchell wrote:
> BTW, should the vtable include all the mutator operators too, ie
> ++, += and so on, on the grounds that an implementation may be able
> do this more efficiently internally?
++ and -- are already slightly messy in perl5
pp_preinc,
Nicholas Clark wrote:
> ++ and -- are already slightly messy in perl5
>
> pp_preinc, pp_postinc, pp_predec and pp_postdec live in with all the ops.
> They know how to increment and decrement integers that don't overflow,
> and call routines in sv.c to increment and decrement anything else.
>
> Act
On Wed, 7 Feb 2001 15:05:55 +, Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 07, 2001 at 03:33:39PM +0100, H . Merijn Brand wrote:
> > On Wed, 7 Feb 2001 09:17:30 -0500, Joshua N Pritikin <[EMAIL PROTECTED]>
>wrote:
> > > http://www.nytimes.com/2001/02/07/science/07reuters-camel.html
Nicholas Clark <[EMAIL PROTECTED]> mused:
> On Wed, Feb 07, 2001 at 04:03:49PM +, David Mitchell wrote:
> > BTW, should the vtable include all the mutator operators too, ie
> > ++, += and so on, on the grounds that an implementation may be able
> > do this more efficiently internally?
>
> ++
From: Tim Bunce [mailto:[EMAIL PROTECTED]]
>
> On Tue, Feb 06, 2001 at 12:28:23PM -0500, Dan Sugalski wrote:
> >
> > At 11:26 AM 2/6/2001 +, Tim Bunce wrote:
> > >
> > > On Mon, Feb 05, 2001 at 05:14:44PM -0500, Dan Sugalski wrote:
> > > >
> > > > =head2 Core datatypes
> > > >
> > > > For eas
Dan Sugalski wrote:
> At 05:41 PM 2/6/2001 -0200, Branden wrote:
> > > >I actually don't see a reason why the vtable entries should be the
> >opcodes.
> > > >Is there?
> > >
> > > Speed.
> > >
> >
> >Actually, I don't see the problem of defining a C function that would do:
> >
> > void add(SVA
At 06:08 PM 2/7/2001 -0200, Branden wrote:
>Dan Sugalski wrote:
> > Splitting the vtable into two pieces, with one piece not tied to a PMC,
> > makes some things impossible. Consider this:
> >
> >@foo = @bar * @baz;
> >
> > where all three arrays are really matrix types.
>
>By the PDD's notion
http://www.nytimes.com/2001/02/07/science/07reuters-camel.html
--
May the best description of competition prevail.
(via, but not speaking for Deutsche Bank)
On Wed, 7 Feb 2001 09:17:30 -0500, Joshua N Pritikin <[EMAIL PROTECTED]> wrote:
> http://www.nytimes.com/2001/02/07/science/07reuters-camel.html
Which is of no use if you don't have a subscriber ID (and do not want to have
one) to th NYT, since it is quite useless in europe ...
--
H.Merijn Bran
On Wed, Feb 07, 2001 at 03:33:39PM +0100, H . Merijn Brand wrote:
> On Wed, 7 Feb 2001 09:17:30 -0500, Joshua N Pritikin <[EMAIL PROTECTED]> wrote:
> > http://www.nytimes.com/2001/02/07/science/07reuters-camel.html
>
> Which is of no use if you don't have a subscriber ID (and do not want to have
Some comments about the vtable PDD...
First a general comment. I think we really need to make it clear for
each method, which arg respresents the object that is having its method
called (ie which is $self/this so to speak). One way to make this clear
would be to insist that the first arg is alway
> >Please see my previous post on the subject. As I pointed there, implementing
> >|| and && like that breaks short-circuits.
>
> No, it doesn't. Just because you pass in two PMCs doesn't mean that they
> both need to be evaluated. Though the PDD does need to be clearer about how
> that happens
At 04:15 PM 2/7/2001 -0200, Branden wrote:
>David Mitchell wrote:
> >
> > Well, many of the vtable methods are operator-ish rather than value-ish,
> > presumably on the grounds of efficiency. A pure 'value' vtable wouldnt
> > have add(), concatenate() etc. Whihc leads me back to: I'm not sure
> >
Dan Sugalski wrote:
>
> >2. Making the implementation of `tie' and `overload' more efficient
('cause
> >it's very slow in Perl 5).
>
> No, not at all. This isn't really a consideration as such. (The vtable
> functions as desinged are inadequate for most overloading, for example)
>
Well, if it's
> Dan,
>
> I think there is a real problem with your vtable approach.
[ etc etc ]
I think there's an important misconception about tieing and overloading
going on hre which I will attempt to clear up. (Then Dan and co
can point out that I;'m I;m wrong and have just made matters worsse ;-)
Firs
Branden wrote:
>
> Well, if it's not tie/overload, I didn't really understand why a vtable
> would have to be attached to a variable. I'd really like to see an example
> of variables whose vtables would have set_* and get_* different one from
> another, and another example of variables whose vtabl
> > > ++ and -- are already slightly messy in perl5
> > >
> > > pp_preinc, pp_postinc, pp_predec and pp_postdec live in with all the ops.
> > > They know how to increment and decrement integers that don't overflow,
> > > and call routines in sv.c to increment and decrement anything else.
> > >
>
> >I'm not either. They feel like they should be operators.
> >But I don't like the thought of going in and out of a lot of generic
> >routines for
> >
> >$a = 3;
> >$a += 2;
> >
> >when the integer scalar ought to know what the inside of another integer
> >scalar looks like, and that 2 + 3 doesn'
At 03:09 PM 2/7/2001 +, David Mitchell wrote:
>Some comments about the vtable PDD...
>
>First a general comment. I think we really need to make it clear for
>each method, which arg respresents the object that is having its method
>called (ie which is $self/this so to speak). One way to make th
Dan,
I think there is a real problem with your vtable approach. It involves
tying, overloading and assignment. I'm not sure if I really got what you
meant with the PDD, but I'm assuming:
1. PMC's replace SV*.
2. Tying is handled by vtables that implement set_* and get_* entries to do
the magic s
At 02:33 PM 2/7/2001 -0500, Buddha Buck wrote:
>At 01:14 PM 02-07-2001 -0500, Dan Sugalski wrote:
>>At 01:35 PM 2/7/2001 -0200, Branden wrote:
>>>As far as I know (and I could be _very_ wrong), the primary objectives of
>>>vtables are:
>>>1. Allowing extensible datatypes to be created by extension
Dan Sugalski wrote:
> At 03:09 PM 2/7/2001 +, David Mitchell wrote:
> >A mere detail, but would it not be more efficient to just pass them
> >as extra args, ie add(PMC1, PMC2, PMC3, key1, key2, key3),
> >rather than having to potentially create and populate a tmp struct
> >just to call the fun
On Wed, Feb 07, 2001 at 05:54:14PM +, David Mitchell wrote:
> Well, many of the vtable methods are operator-ish rather than value-ish,
> presumably on the grounds of efficiency. A pure 'value' vtable wouldnt
> have add(), concatenate() etc. Whihc leads me back to: I'm not sure
> whether you ar
David Mitchell wrote:
>
> Well, many of the vtable methods are operator-ish rather than value-ish,
> presumably on the grounds of efficiency. A pure 'value' vtable wouldnt
> have add(), concatenate() etc. Whihc leads me back to: I'm not sure
> whether you are in favour of, or oppose, += etc being
At 01:35 PM 2/7/2001 -0200, Branden wrote:
>Dan Sugalski wrote:
> > At 05:41 PM 2/6/2001 -0200, Branden wrote:
> > > > >I actually don't see a reason why the vtable entries should be the
> > >opcodes.
> > > > >Is there?
> > > >
> > > > Speed.
> > > >
> > >
> > >Actually, I don't see the problem of
On Wed, Feb 07, 2001 at 05:19:16PM +, David Mitchell wrote:
> Nicholas Clark <[EMAIL PROTECTED]> mused:
> > On Wed, Feb 07, 2001 at 04:03:49PM +, David Mitchell wrote:
> > > BTW, should the vtable include all the mutator operators too, ie
> > > ++, += and so on, on the grounds that an impl
At 03:45 PM 2/7/2001 -0200, Branden wrote:
>Dan,
>
>I think there is a real problem with your vtable approach. It involves
>tying, overloading and assignment. I'm not sure if I really got what you
>meant with the PDD, but I'm assuming:
>1. PMC's replace SV*.
Yes.
>2. Tying is handled by vtables
At 05:07 PM 2/7/01 -0500, John Porter wrote:
>Peter Scott wrote:
> > Sorry, I wasn't clear. Let me rephrase. The 'try' helps me determine
> that
> > the following block is going to be subject to exception handlers which
> will
> > immediately follow as siblings of the block.
>
>O.k. That make
On Wed, Feb 07, 2001 at 04:30:24PM -0600, David L. Nicol wrote:
> sub has_post_blocks{
> my $i = 3;
> post { print "i ended up as $i"};
> my $arg1 = shift; $arg1 > 4 or die "arg1 ($arg1) too small";
> my $j = 2;
> post {
Nicholas Clark wrote:
>
> On Wed, Feb 07, 2001 at 04:30:24PM -0600, David L. Nicol wrote:
>
> > sub has_post_blocks{
> > my $i = 3;
> > post { print "i ended up as $i"};
> > my $arg1 = shift; $arg1 > 4 or die "arg1 ($arg1) too small";
> >
At 02:17 PM 2/7/01 -0500, John Porter wrote:
>Peter Scott wrote:
> >
> > I want the 'try' there for my sake, not Perl's; ... it
> > helps alert me that the following block is subject to non-local control
> > flow rules.
>
>Huh? Down that road lies the Java madness.
>
> eval {
>
> Sorry, I wasn't clear. Let me rephrase. The 'try' helps me determine that
> the following block is going to be subject to exception handlers which will
> immediately follow as siblings of the block. Somewhat as I would look at
> an if...elsif...else construct, it helps me put the block in c
Peter Scott wrote:
> Sorry, I wasn't clear. Let me rephrase. The 'try' helps me determine that
> the following block is going to be subject to exception handlers which will
> immediately follow as siblings of the block.
O.k. That makes sense if some blocks can be try blocks (by adding the
John Porter wrote:
> Note that END{} and BEGIN{} require no formal introduction.
> You can put them anywhere you want, and they run at the proper time.
>
> Even continue{} is an implicit goto. And it requires no introduction
> either.
So if a post{} block could appear anywhere inside a block,
[EMAIL PROTECTED] wrote:
> Hmm, so this is (kind of) akin to the regcomp fix - it is the "new" stuff
> that is in yyl?val that should be free-d. And it is worse than that
> as yyl?val is just the topmost the parser state, so if I understand correctly
> it isn't only their current values, but also
Alan Burlison <[EMAIL PROTECTED]> writes:
>If an eval{} fails because of a snytax error, yydestroy is called on
>leaving the eval scope. Unfortunately it does this:
>
>yyval = ysave->oldyyval;
>yylval = ysave->oldyylval;
>
>So anything that is in those 2 vars that hasn't made i
Nicholas Clark wrote:
> on the other hand, I'll argue the other side that
>
> {
> my $flag
> open FOO, " ...
> }
> post {
> close FOO if $flag;
> }
>
> is clearer because the tidy up doesn't visually get in the way of the flow
> of what you're doing, and you can see what $flag is meant
61 matches
Mail list logo
