The discussion was about optimized code. WHere the original location
would have been lost. A multiline constant, seems like something that could
keep the location information.
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>> Yup. Worst case we can always point at where the line st
On Sun, 17 Sep 2000, Tom Christiansen wrote:
> >Heh. We can change the message from:
>
> >"Division by zero error on line xx"
>
> >to
>
> >"Division by zero error somewhere around line XX, give or take a few"
>
> >:)
>
> >Yup. Worst case we can always point at where the line starts, if it st
>Heh. We can change the message from:
>"Division by zero error on line xx"
>to
>"Division by zero error somewhere around line XX, give or take a few"
>:)
>Yup. Worst case we can always point at where the line starts, if it still
>exists.
Make it:
Division by zero error on statement beg
Steve Fink writes:
> I suspect perl can do a much better job than it does now, but if you
> make it a requirement, you prevent many optimizations. I think the RFC
> should be very specific about when it applies and when it gets out of
> the way.
I can't be more specific unless I know the optimiza
At 05:21 PM 9/15/00 -0400, Chaim Frenkel wrote:
>I don't believe that the optree has to be bloated. I think having the
>actual line number in the optree vs. having a seperate structure
>mapping offsets to line numbers are the same.
>
>Then an error report would be akin to
> error_me_this(c
I don't believe that the optree has to be bloated. I think having the
actual line number in the optree vs. having a seperate structure
mapping offsets to line numbers are the same.
Then an error report would be akin to
error_me_this(current_op_address, "Foo didn't baz in time. Aborting")
Dave Storrs wrote:
>
> As to solving problem #1 (which is, arguably, the bigger problem),
> suppose we add a new switch to perl? I propose we add the -H switch
> (mnemonic: *H*elpful errors/warnings). When -H is set, the optree would
> be generated with a sufficient amount of bloat that
It seems to me that everyone in this thread pretty much agrees that this
is a good idea, but has one of the following reservations:
1) Tracking sufficient information to be able to report errors at the
exact spot they happen involves bloating the optree a lot and slowing down
the whole program;
Bart Lateur wrote:
>
> On Thu, 14 Sep 2000 15:47:43 -0700, Steve Fink wrote:
>
> >Currently, toke.c turns "foo$bar" into "foo".$bar before the parser or
> >anything else sees it. So any features implemented in the tokenizer have
> >to get smarter about remembering what they did.
>
> This sound
At 10:27 PM 9/14/00 -0400, Chaim Frenkel wrote:
> > "SF" == Steve Fink <[EMAIL PROTECTED]> writes:
>
>SF> I suspect perl can do a much better job than it does now, but if you
>SF> make it a requirement, you prevent many optimizations. I think the RFC
>SF> should be very specific about when it
On Thu, 14 Sep 2000 15:47:43 -0700, Steve Fink wrote:
>Currently, toke.c turns "foo$bar" into "foo".$bar before the parser or
>anything else sees it. So any features implemented in the tokenizer have
>to get smarter about remembering what they did.
This sound pretty much like the same problem yo
> "SF" == Steve Fink <[EMAIL PROTECTED]> writes:
SF> I suspect perl can do a much better job than it does now, but if you
SF> make it a requirement, you prevent many optimizations. I think the RFC
SF> should be very specific about when it applies and when it gets out of
SF> the way.
Expressi
How much optimization are we talking about?
Currently, toke.c turns "foo$bar" into "foo".$bar before the parser or
anything else sees it. So any features implemented in the tokenizer have
to get smarter about remembering what they did.
If you do common subexpression elimination, one opcode may c
On Wed, 13 Sep 2000, Nathan Torkington wrote:
> Simon Cozens writes:
> > > Nice!
> > Efficient!
> > Practical!
> >
> > Choose two.
>
> I take this oblique comment to mean that it'd bloat the op-tree too
> much?
Well, suppose we simply add the -FOO (choose your letter) flag to
perl...
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
NT> I take this oblique comment to mean that it'd bloat the op-tree too
NT> much?
NT> I was thinking of this over lunch. I want to be able to strip the
NT> instruction sequence of line number, package, etc. information, in the
NT> name
Dan Sugalski writes:
> No, that's the point. But if someone explicitly strips out the debugging
> info then, well, you don't get much help in debugging, now do you? :)
I buy that. It'd be nice to be able to be one step better than C,
though, and given *something* that you can use to go back to
At 02:20 PM 9/13/00 -0600, Nathan Torkington wrote:
>Dan Sugalski writes:
> > I wouldn't worry about this too much. If it's all keyed off an opcode of
> > some sort ("Current line info"), we could easily just strip those opcodes
> > out. They won't take up that much space relative to the rest of t
At 07:09 AM 9/13/00 +, Perl6 RFC Librarian wrote:
>=head1 TITLE
>
>Emit warnings and errors based on unoptimized code
Yay! I'd add, in V2, that:
"Perl should report the *real* line an error took place in for those
statements that span multiple lines"
So if you do:
#! perl -w
my $foo
Dan Sugalski writes:
> I wouldn't worry about this too much. If it's all keyed off an opcode of
> some sort ("Current line info"), we could easily just strip those opcodes
> out. They won't take up that much space relative to the rest of the
> program, but I can see some sort of runtime overhead i
On Wed, 13 Sep 2000, Nathan Torkington wrote:
> Simon Cozens writes:
> > > Nice!
> > Efficient!
> > Practical!
> >
> > Choose two.
>
> I take this oblique comment to mean that it'd bloat the op-tree too
> much?
>
> I was thinking of this over lunch. I want to be able to strip the
> instructio
Simon Cozens writes:
> > Nice!
> Efficient!
> Practical!
>
> Choose two.
I take this oblique comment to mean that it'd bloat the op-tree too
much?
I was thinking of this over lunch. I want to be able to strip the
instruction sequence of line number, package, etc. information, in the
name of a
On Wed, Sep 13, 2000 at 07:24:26AM -0700, Nathan Wiger wrote:
> > print "what's that, $perl?";
> >
> > Use of uninitialized value in concatenation (.) at -e line 1.
>
> > This is misleading and confuses users. When Perl needs to report
> > errors or warnings, it should describe the code the
> print "what's that, $perl?";
>
> Use of uninitialized value in concatenation (.) at -e line 1.
> This is misleading and confuses users. When Perl needs to report
> errors or warnings, it should describe the code the programmer wrote,
> regardless of how that's been translated within Perl.
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Emit warnings and errors based on unoptimized code
=head1 VERSION
Maintainer: Nathan Torkington <[EMAIL PROTECTED]>
Date: Sep 12 2000
Mailing List: [EMAIL PROTECTED]
Number: 214
Version: 1
Statu
24 matches
Mail list logo
