On Tue, 1 Aug 2000, Tony Payne wrote:
>
> > Isn't this almost a case for revamping the prototyping system? You can
> > define your API in terms the current perl variables (nothing in the above
> > suggests that integers versus floats is the main problem) and have a
> > prototype system that actu
=head1 TITLE
type inference
=head1 VERSION
Maintainer: Steve Fink <[EMAIL PROTECTED]>
Date: 1 Aug 2000
Version: 0 (unreleased)
Mailing List: [EMAIL PROTECTED]
Number: (unassigned)
=head1 ABSTRACT
Types should be inferred whenever possible, and optional type qualifiers
may be used to
John Porter wrote:
> qc( here's some text which will evaluate to "silent undef". );
> Could be very much like qw() ...
Cool, I like the perlishness of your proposal. But not so sure about "qc".
Would this be a function? Why would it be a function? What would qc imply,
"quote comment"? This is co
On Tue, Aug 01, 2000 at 05:28:08PM -0400, Michael Mathews wrote:
> Unlike many programming languages Perl does not currently implement true
> multiline comments. This can be confusing/tedious to programmers. This could
> be solved by adding a syntax to Perl 6 that would allow for true multiline
>
Michael Fowler wrote:
> On Tue, Aug 01, 2000 at 05:28:08PM -0400, Michael Mathews wrote:
> > Unlike many programming languages Perl does not currently implement true
> > multiline comments. This can be confusing/tedious to programmers. This could
> > be solved by adding a syntax to Perl 6 that wou
On Mon, Jul 31, 2000 at 09:50:11PM -0600, Nathan Torkington wrote:
> So Larry is doing most of the evaluation for us. He's the one who
> gave us the good things in the Perl language we have now. He'll be
> the one vetoing the ridiculous ideas.
Larry said: "Perl5 was my rewrite of Perl, Perl6 wi
To see why not, try this (because it won't work)
print "foo" =pod ."bar" =cut . "baz"
whereas in javascript this will work (prints "foobaz")
document.write("foo" /* + "bar" */ + "baz");
Also (as stated in the RFC) wouldn't adding POD "comments" all over a script
interfere with real POD (
Michael Fowler wrote:
> I'm not sure exactly what you consider to be a "true multiline comment", but
> Perl definitely has them by my definition.
>
> =pod
>
> Hi, this is a multiline comment.
>
> =cut
...and there are a lot WORSE ways to do this in current Perl:
sub multiline-comment {}
mul
On Tue, 01 Aug 2000, Alan Burlison wrote:
> > Threading constructs built into the language
>
> The majority of perl programs won't be threaded - beware of making
> simple things harder.
That is, to me, a backwards way of thinking about it. Every perl
program is threaded. Most just have one th
On Tue, Aug 01, 2000 at 03:07:36PM -0600, Nathan Torkington wrote:
> I disagree. If there was a bsdm.pm or -B option that gave strong type
> checking, then many would be happy.
You can do this with attributes and tying.
--
Also note that i knew _far_ more about the people that call address
mu
On Tue, 1 Aug 2000, John Barnette wrote:
> Michael Fowler wrote:
> > On Tue, Aug 01, 2000 at 05:28:08PM -0400, Michael Mathews wrote:
> > > Unlike many programming languages Perl does not currently implement true
> > > multiline comments. This can be confusing/tedious to programmers. This could
>
Moving from bootstrap to perl6-language ...
In response to [EMAIL PROTECTED]'s requirements document, Hildo
Biersma wrote:
> In issue 3.2.1 (localtime), note that the month starting at 0 is very
> useful for arrays - which is of the course the reason it is done this
> way. I am not convinced goi
>Typeglobs != symbol tables.
>You can access individual variable bits in the symbol table now without
>using typeglobs. I don't see why that would have to change.
NB: $main::{fred} does not autoviv a typeglob when used lvaluably,
but *main::fred does.
--tom
>I apologize if this has already been gone over but I would really like to
>throw one out there: real Multi-line comments.
>This one has been bugging me for a long time. Any ideas?
>How about #/ lots of lines of code here, this is not backwards compatable,
>however /#
Do you really think
Plus you're still running à la pod mode, not à la code mode,
as mentioned on p630 of PP3. (I just looked to make sure multiline
comments were in the index. They are.)
--tom
>Several people have suggested strong typing as a feature, and have been shot
>down one by one. However, I think it can be done without forcing it on
>everyone.
Can it? Are you prepared to make everyone declare the full, formal, and
fancy types for the return values of all their functions?
C
Dan Sugalski wrote:
> I've been thinking that it'd be nice to support extended array/list stuff
> to allow the rudiments of matrix operations into perl:
>
> @foo = @bar x 3;
> @foo = @bar * 4;
> @LoL = @foo * @bar;
> @baz =~ s/here/there/;
>
This would really fill a gap, if the speed is th
On Tue, 1 Aug 2000, J. David Blackstone wrote:
> Moving from bootstrap to perl6-language ...
>
> In response to [EMAIL PROTECTED]'s requirements document, Hildo
> Biersma wrote:
> > In issue 3.2.1 (localtime), note that the month starting at 0 is very
> > useful for arrays - which is of the cour
On Wed, 2 Aug 2000, Jeremy Howard wrote:
> Dan Sugalski wrote:
> > I've been thinking that it'd be nice to support extended array/list stuff
> > to allow the rudiments of matrix operations into perl:
> >
> > @foo = @bar x 3;
> > @foo = @bar * 4;
> > @LoL = @foo * @bar;
> > @baz =~ s/here/
>3. It no longer has a unix specific flavour (PS I am not anti-unix in any
>sense) so Mac, VMS and Windows users feel less confused.
Did it get decided that we were *supposed* to make Unix and C programmers
feel more confused and less at home with Perl?
--tom
On Tue, Aug 01, 2000 at 05:51:29PM -0600, Tom Christiansen wrote:
> >3. It no longer has a unix specific flavour (PS I am not anti-unix in any
> >sense) so Mac, VMS and Windows users feel less confused.
>
> Did it get decided that we were *supposed* to make Unix and C programmers
> feel more conf
On Tue, 1 Aug 2000, Tom Christiansen wrote:
> >3. It no longer has a unix specific flavour (PS I am not anti-unix in any
> >sense) so Mac, VMS and Windows users feel less confused.
>
> Did it get decided that we were *supposed* to make Unix and C programmers
> feel more confused and less at home
Re: the Time::Object module, Tim Jenness wrote:
> Sounds good since:
>
> 1. It removes unnecesary core functionality to a loadable module
>
> 2. Can be retrofitted to perl5 code fairly easily (essentially as easy as
> exporting a backwards compatible localtime() function).
>
> 3. It no longer h
Tom Christiansen wrote:
>
> >3. It no longer has a unix specific flavour (PS I am not anti-unix in any
> >sense) so Mac, VMS and Windows users feel less confused.
>
> Did it get decided that we were *supposed* to make Unix and C programmers
> feel more confused and less at home with Perl?
>
> -
Tom Christiansen wrote:
>
> >Several people have suggested strong typing as a feature, and have been shot
> >down one by one. However, I think it can be done without forcing it on
> >everyone.
>
> Can it? Are you prepared to make everyone declare the full, formal, and
> fancy types for the ret
> "Chaim" == Chaim Frenkel <[EMAIL PROTECTED]> writes:
Chaim> I don't find this meaningful:
Chaim> sub foo() { return (1,7) }
Chaim> $x = &foo();# $x == 7;
I do. It's perfectly consistent.
$x = SUBROUTINE CALL
...
SUBROUTINE CALL = (1,7)
You just factor out the subro
> "Chaim" == Chaim Frenkel <[EMAIL PROTECTED]> writes:
> "CF" == Chaim Frenkel <[EMAIL PROTECTED]> writes:
CF> (Kirrily, this one is for the record.)
CF> I'd also like to add, redo, next, last escaping a subroutine.
Chaim> Make that _NOT_ escaping a subroutine.
Chaim> map { ...; last
=head1 TITLE
messages.rfc - An RFC to discussing the wisdom of allowing run time error
and warning messages to be modified at run time
=head1 VERSION
Maintainer: Corwin Brust <[EMAIL PROTECTED]>
Date: 1 Aug 2000
Version: 1
Mailing List: perl6-language
Number: ???
=head1 ABS
> "Ariel" == Ariel Scolnicov <[EMAIL PROTECTED]> writes:
Ariel> reduce needs to be able to take an (optional?) "distinguished element"
Ariel> to start from. Consider this:
Ariel>reduce sum () == 0
Ariel>reduce times () == 1
Ariel>reduce catenate () == ''
Ariel> Where do we get
> "Alan" == Alan Burlison <[EMAIL PROTECTED]> writes:
Alan> Graham Barr wrote:
>> > Reduce (e.g. $x = reduce { sum } @list;
Alan> Is it sufficiently more useful than:
Alan>$x = 0; map $x += $_, @list;
As long as you write that as:
$x = 0; $x += $_ for @list;
su
> "Damian" == Damian Conway <[EMAIL PROTECTED]> writes:
Damian> There's a protoype implementation available as part of the
Damian> switch.pm module, which will hit the CPAN some time this week
Damian> (assuming I don't actually *die* of jet-lag :-)
Not to be morbid, but you do have the code
> "Christopher" == Christopher K Oei <[EMAIL PROTECTED]> writes:
>> This brings back an idea I had a while ago. How about defining a module,
>> that could be part of the standard distribution, that offered those
>> shortcuts. So newbies could do something like
>>
>> use newbie;
>> or
>> use
On Tue, Aug 01, 2000 at 05:31:56PM -0600, Tom Christiansen wrote:
> >Several people have suggested strong typing as a feature, and have been shot
> >down one by one. However, I think it can be done without forcing it on
> >everyone.
>
> Can it? Are you prepared to make everyone declare the full
On Tue, Aug 01, 2000 at 10:27:18PM +0100, Alan Burlison wrote:
> Michael Fowler wrote:
>
> > use typing qw(very-strict);
> >
> > my integer $foo : very-strict = 4;
> >
> > Which would enforce that you can only assign integer constants to $foo
> > (which are seen at compile-time), or oth
The librarian address doesn't seem to be working, so I'm injecting this
here.
=head1 TITLE
Request For New Pragma: Implicit
=head1 VERSION
Maintainer: Bryan C. Warnock <[EMAIL PROTECTED]>
Date: 01 Aug 2000
Version: 1
Mailing List: perl6-language
Number: TBD
=head1 ABSTRACT
On Tue, 01 Aug 2000, Simon Cozens wrote:
> On Tue, Aug 01, 2000 at 03:07:36PM -0600, Nathan Torkington wrote:
> > I disagree. If there was a bsdm.pm or -B option that gave strong type
> > checking, then many would be happy.
>
> You can do this with attributes and tying.
Doesn't tying slow things
On Tue, 01 Aug 2000, Matthew Cline wrote:
> Doesn't tying slow things down? If you did compile time type
> checking, this would take no perfromance hit. Also you could, say,
> add some opcodes for doing runtime checking, so that runtime
> checking would be faster than doing it with tying, but w
At 05:19 PM 8/1/00 -0600, Tom Christiansen wrote:
> >Typeglobs != symbol tables.
>
> >You can access individual variable bits in the symbol table now without
> >using typeglobs. I don't see why that would have to change.
>
>NB: $main::{fred} does not autoviv a typeglob when used lvaluably,
>but *
At 09:38 AM 8/2/00 +1000, Jeremy Howard wrote:
>Dan Sugalski wrote:
> > I've been thinking that it'd be nice to support extended array/list stuff
> > to allow the rudiments of matrix operations into perl:
> >
> > @foo = @bar x 3;
> > @foo = @bar * 4;
> > @LoL = @foo * @bar;
> > @baz =~ s/h
At 06:59 PM 8/1/00 -0500, J. David Blackstone wrote:
> I'm presuming we can count on really fast methods to be one of the
>goals of the internals group. Perl is where I learned O-O
>(discovering wasn't just a useless buzzword), and I'd like to see
>Perl6 make O-O much more natural, without forc
At 05:51 PM 8/1/00 -0600, Tom Christiansen wrote:
> >3. It no longer has a unix specific flavour (PS I am not anti-unix in any
> >sense) so Mac, VMS and Windows users feel less confused.
>
>Did it get decided that we were *supposed* to make Unix and C programmers
>feel more confused and less at ho
On Tue, 01 Aug 2000, Tom Christiansen wrote:
> >3. It no longer has a unix specific flavour (PS I am not anti-unix in any
> >sense) so Mac, VMS and Windows users feel less confused.
>
> Did it get decided that we were *supposed* to make Unix and C programmers
> feel more confused and less at home
Alan Burlison wrote:
>
> Steve Simmons wrote:
>
> > I'd prefer that we break these vars out into a set of hashes with
> > appropriate names:
> >
> > $PERL_CORE{warnings} vs $^W
> > $PERL_CORE{version} vs $^V
> > $PERL_FORMATS{name} vs $^
> > $P
At 09:12 PM 8/1/00 -0400, Bryan C. Warnock wrote:
>On Tue, 01 Aug 2000, Matthew Cline wrote:
>
> > Doesn't tying slow things down? If you did compile time type
> > checking, this would take no perfromance hit. Also you could, say,
> > add some opcodes for doing runtime checking, so that runtime
> C is, at times, less than logical. Witness the localtime fun: some of it's
> zero-based, some of it's one-based, and some of it's -1900-based. All from the
> same function. The localtime concept is needed, the localtime brain damage is
> really not.
I agree completely. I take issue with changin
On Tue, Aug 01, 2000 at 09:39:28PM -0400, Dan Sugalski wrote:
> I like perl's smart built-in IO just fine, thanks. :) Don't mind making it
> better, but I do mind making it optional.
If we're going to do line disciplines, we need a built-in stdio replacement.
Full ground-up rewrite, like sfio bu
Dan Sugalski wrote:
> >Languages like C and
> >Pascal even go so far as to make I/O an "option" that you have to
> >#include (or whatever, depending on the language; Pascal makes you
> >specify it explicitly in some way I don't quite remember), and they
> >seem to do fine.
>
> For some pretty pat
> > I disagree with keeping the same name as a Unix function, but having a
> > radically different calling sequence or return value. If you want a
> > new interface, *name* a new interface.
>
> Amen!
Agreed, completely. I posted a follow-up under "Re: date interface" that
some might be interest
Nathan Wiger wrote:
>
> > C is, at times, less than logical. Witness the localtime fun: some of it's
> > zero-based, some of it's one-based, and some of it's -1900-based. All from the
> > same function. The localtime concept is needed, the localtime brain damage is
> > really not.
>
> I agree co
On Tue, 01 Aug 2000, J. David Blackstone wrote:
> How about this: perhaps we should compile a list of system calls
> that _should_ remain in the core language. I think it will probably
> be very small.
I would suspect no more than the ones that perl needs internally for
itself, excluding, of
On Tue, Aug 01, 2000 at 03:04:27PM -0600, Nathan Torkington wrote:
> Piers Cawley writes:
> > > Iterators
> > Doable in perl5 already.
> > > Reduce (e.g. $x = reduce { sum } @list;
> > Doable in perl5
> > > Case/Switch
> > Why? And Damian's already proved it can be done.
>
> Perl's
Nick Ing-Simmons wrote:
>
> Buddha Buck <[EMAIL PROTECTED]> writes:
> >I haven't looked at the internals for local, but isn't:
> >
> >{
> > local $foo;
> >
> > ...
> >}
> >
> >effectively syntactic sugar for:
> >
> >{
> > my $unnamed_foo = $foo; # $unnamed_foo not accessible
> >
> > .
> "BC" == Brust, Corwin <[EMAIL PROTECTED]> writes:
BC> But is this useful?
BC> sub baz { return ( 'one','two' ) }
BC> my ($foo, $bar) = &baz; # $foo == 'one', $bar == 'two'
Certainly.
I just don't like the fact that the runtime scalar context is having
a compile time semantic effect.
It'
> "Chaim" == Chaim Frenkel <[EMAIL PROTECTED]> writes:
Chaim> It's the overloading of the ',' operator.
Just like the overloading of the @ARRAY_NAME operator or the
getpwuid() operator. Perhaps you are back to merely complaining about
all context-sensitive things again. :-)
--
Randal L. S
> At 09:38 AM 8/2/00 +1000, Jeremy Howard wrote:
> >Dan Sugalski wrote:
> > > I've been thinking that it'd be nice to support extended array/list
stuff
> > > to allow the rudiments of matrix operations into perl:
> > >
> > > @foo = @bar x 3;
> > > @foo = @bar * 4;
> > > @LoL = @foo * @bar;
>
We may need that all variables are by default lexical.
Without the explicit declaration of cross-thread visible variables, doing
threading may well be difficult (on one's fingers)
> "PC" == Piers Cawley <[EMAIL PROTECTED]> writes:
>> * no need to declare variables: I think variables shoul
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> I'd rather not do it for globals, though. (Actually I'd be just as happy to
DS> see local go missing entirely, but that's just me looking at the guts...)
But local() is so useful. A nice anonymous place to store a value and have
it rest
What do things that are moving out of the executable to auto loaded
space be called?
perl near core?
"We've got insertion. Formats have entered near-core space..."
> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
NI> I assume 'core perl engine' i.e. /usr/bin/perl or perl.e
At 09:39 PM 8/1/00 -0400, Bryan C. Warnock wrote:
>On Tue, 01 Aug 2000, Tom Christiansen wrote:
> > >3. It no longer has a unix specific flavour (PS I am not anti-unix in any
> > >sense) so Mac, VMS and Windows users feel less confused.
> >
> > Did it get decided that we were *supposed* to make Un
> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
PS> Perhaps the best of both worlds would be design-by-contract? A la Conway?
Conway? Who's Conway?
Anyway, the design by contract might be interesting...
(I wonder if internals should require it. (Dan are you listening.))
And how would
At 11:04 AM 8/2/00 +0900, Simon Cozens wrote:
>On Tue, Aug 01, 2000 at 09:39:28PM -0400, Dan Sugalski wrote:
> > I like perl's smart built-in IO just fine, thanks. :) Don't mind making it
> > better, but I do mind making it optional.
>
>If we're going to do line disciplines, we need a built-in std
At 10:45 PM 8/1/00 -0400, Chaim Frenkel wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>DS> I'd rather not do it for globals, though. (Actually I'd be just as
>happy to
>DS> see local go missing entirely, but that's just me looking at the guts...)
>
>But local() is so useful. A
At 11:08 PM 8/1/00 -0400, Chaim Frenkel wrote:
> > "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
>
>PS> Perhaps the best of both worlds would be design-by-contract? A la Conway?
>
>Conway? Who's Conway?
http://www.csse.monash.edu.au/~damian/TPC/2000/Contract/paper.html
--
Peter Scott
Paci
On Tue, Aug 01, 2000 at 11:01:14PM -0400, Dan Sugalski wrote:
> Right, I know the underside will be yanked and redone. (Hopefully with
> async support on platforms that have it to do some I/O and processing
> overlap) It's not getting removed from the core language from a perl
> programmer stan
At 12:24 PM 8/2/00 +0900, Simon Cozens wrote:
>On Tue, Aug 01, 2000 at 11:01:14PM -0400, Dan Sugalski wrote:
> > Right, I know the underside will be yanked and redone. (Hopefully with
> > async support on platforms that have it to do some I/O and processing
> > overlap) It's not getting removed fr
At 10:42 PM 8/1/00 -0400, Chaim Frenkel wrote:
>We may need that all variables are by default lexical.
>
>Without the explicit declaration of cross-thread visible variables, doing
>threading may well be difficult (on one's fingers)
The two things are orthogonal. Threading doesn't place any sort o
At 06:47 PM 8/1/00 -0700, Nathan Wiger wrote:
>Now *that's* an advantage I like! Being able to turn on certain warnings
>just for certain packages (rather than just a global all-or-nothing $^W)
>would be really cool.
Like, like... Lexical Warnings! Now *that* would be a keen idea! :)
At 11:08 PM 8/1/00 -0400, Chaim Frenkel wrote:
> > "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
>
>PS> Perhaps the best of both worlds would be design-by-contract? A la Conway?
>
>Conway? Who's Conway?
Dunno. He had some sort of thing a few weeks ago. The Public Conway 4.0 or
something,
At 10:53 PM 8/1/00 -0400, Chaim Frenkel wrote:
>What do things that are moving out of the executable to auto loaded
>space be called?
>
> perl near core?
>
>"We've got insertion. Formats have entered near-core space..."
I've been thinking of 'em as "opcode wannabes", but I like yours bett
The following RFC reflects an assumption I've been making about
where Perl6 will go. Feel free to shoot it down, if I'm the only who
feels this way. :)
=head1 TITLE
Lexical variables made default
=head1 VERSION
Maintainer: J. David Blackstone <[EMAIL PROTECTED]>
Date: 1 August 2000
Versi
> >PS> Perhaps the best of both worlds would be
> >PS> design-by-contract? A la Conway?
> >
> >Conway? Who's Conway?
>
> Dunno. He had some sort of thing a few weeks ago. The Public Conway 4.0 or
> something, I think it was. :)
According to the latest TPJ, he's "the Mad Sci
On Tue, Aug 01, 2000 at 08:54:27PM -0400, Bryan C.Warnock wrote:
> There should be an C pragma that gives new life and meaning to
> void context constructs. In my case, I want it to print to the default
> filehandle, (which is also implicit, I might add.)
Well, one of the rumors bandied about wa
On Tue, Aug 01, 2000 at 11:02:01PM -0500, J. David Blackstone wrote:
> The C operator should be retained due to its usefulness for
> dynamic scoping, but should be renamed to avoid confusion. I'm
> currently suggesting a name of C. More euphonious
> suggestions are requested.
This should probab
At 02:18 PM 8/2/00 +1000, Damian Conway wrote:
>> >PS> Perhaps the best of both worlds would be
>> >PS> design-by-contract? A la Conway?
>> >
>> >Conway? Who's Conway?
>>
>> Dunno. He had some sort of thing a few weeks ago. The Public Conway
> 4.0 or
>> something, I th
On Tue, Aug 01, 2000 at 09:13:44PM -0500, J. David Blackstone wrote:
> Creating an all new function is a very good idea, I think. The
> whole function "localtime" should just plain go away.
Also remember that localtime() is intimately tied to gmtime(), and
timelocal(), timegm() of Time::Local.
On Tue, 01 Aug 2000, Dan Sugalski wrote:
> At 02:18 PM 8/2/00 +1000, Damian Conway wrote:
> >According to the latest TPJ, he's "the Mad Scientist of Perl".
> >Clearly a trouble-maker of the worse kind!
>
> The fiend! We shall have to deal with him straightaway. Time to dispatch
> the Perl Police!
Jeremy Howard wrote:
> > > > @foo = @bar x 3;
> > > > @foo = @bar * 4;
> > > > @LoL = @foo * @bar;
> > > > @baz =~ s/here/there/;
> Exactly. Currently PDL provides a lot of the numeric side of this, but
> wouldn't it be nice if perl 6 had the hooks in place to allow PDL to
> integrate ev
On Tue, Aug 01, 2000 at 12:27:56PM -0400, Chaim Frenkel wrote:
>
>(Kirrily, this one is for the record.)
>
>I'd also like to add, redo, next, last escaping a subroutine.
Can you please give me more detail on that? An RFC would be ideal :)
K.
--
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://
J. David Blackstone writes:
> Re: #1, above, I'd go so far as to suggest that nearly every system
> call in Perl (along with just about every punctuation variable) should
> find itself in a module and only in a module.
(nat as nat)
I'd like to suggest that Pascal is a language to *avoid* emula
> Another note: your examples with:
>
> local ($^T) = 0;
> $ENV{PATH} = read_config_file();
> local ($^T) = 1;
>
> is only using local() to confuse; it should be written with a block,
> correctly restoring the old value of $^T.
Sorry about that - I contemplated taking it
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> $Config{osname}, I think. I'm not thrilled with that, mainly because it
DS> means loading up Config, which ain't cheap.
Why not have $Config hard coded into the executable? Perl has to have
it or know it. So why not make it part of the
At 11:57 PM 7/31/00 -0700, Matthew Cline wrote:
>Something else which might be useful for tainting would be something like:
>
> taint_var($foo);
> no_taint_var($bar);
>
>With this, any value assigned to $foo would become tainted, and any value
>assigned to $bar would become untainted.
Whi
At 11:57 PM 7/31/00 -0700, Matthew Cline wrote:
>On Mon, 31 Jul 2000, Nathan Wiger wrote:
>
> > Instead, it would be really cool if Perl6 let you do this:
> >
> >#! perl -T
> >local($^T) = 0;
> >$ENV{PATH} = read_config_file();
> >local($^T) = 1;
>
>I would prefer something like:
>
I respectfully request that one list be picked for this topic and
discussion confined to that one list even if it should occasionally
spill into the other bailiwick. Or perhaps it's a candidate for a new
working group.
If all messages are CC:ed to all lists, then simply have p5p reborn
(and the
On Tue, 01 Aug 2000, Dan Sugalski wrote:
> At 11:57 PM 7/31/00 -0700, Matthew Cline wrote:
> >Something else which might be useful for tainting would be something like:
> >
> > taint_var($foo);
> > no_taint_var($bar);
> >
> >With this, any value assigned to $foo would become tainted, and a
Johan Vromans writes:
: On Mon, Jul 31, 2000 at 09:50:11PM -0600, Nathan Torkington wrote:
: > So Larry is doing most of the evaluation for us. He's the one who
: > gave us the good things in the Perl language we have now. He'll be
: > the one vetoing the ridiculous ideas.
:
: Larry said: "Perl
Thus it was written in the epistle of Matthew Persico,
> Johan Vromans wrote:
> >
> > On Mon, Jul 31, 2000 at 09:50:11PM -0600, Nathan Torkington wrote:
> > > So Larry is doing most of the evaluation for us. He's the one who
> > > gave us the good things in the Perl language we have now. He'll
<[EMAIL PROTECTED]>, aka Skud, aka Kirrily Robert, will be the
chair for the language working group. Her job is to make sure
you all produce lots of RFCs. Many thanks, Kirrily, for taking
on this, uh, "rewarding" task. :-)
WORKING GROUP: perl6-language
CHAIR: Kirrily Robert
DEADLINE: 13 O
Johan Vromans wrote:
>
> On Mon, Jul 31, 2000 at 09:50:11PM -0600, Nathan Torkington wrote:
> > So Larry is doing most of the evaluation for us. He's the one who
> > gave us the good things in the Perl language we have now. He'll be
> > the one vetoing the ridiculous ideas.
>
> Larry said: "Pe
At 15:19 +0100 2000-08-01, Tim Bunce wrote:
> >RegEx (internals?)
>
>Yes, Yes, Yes.
I could argue for regex being language too: it's a little language,
and it's got very crufty of late. Yes, it's sexy cruft which can be
justified because it allows one to do neat things which were
pre
On Mon, Jul 31, 2000 at 10:42:54PM -0700, Nathan Wiger wrote:
> Dan Sugalski wrote:
> >
> > > existence of a $^T variable for controlling tainting in the same way
> > > that $^W controls warnings.
> >
> > So put in an RFC. :)
>
> Dan-
>
> Ask and ye shall receive...in POD format ala Tim...
I
At 02:52 PM 8/1/00 -0400, Chaim Frenkel wrote:
>Please explain how having a no taint block would still keep the spirit
>of not making untainting easy?
Hadn't thought that much about it. That is an issue which'd need to be
dealt with if this proposal goes anywhere, which it very well might not.
>Perl's regex syntax in not poorly documented (IMHO, of couse).
Some of the new stuff is. (Poorly documented, that is.)
>MRE made me feel like a ghod (after I read chapter 7 for the third time ;)
Some of the new stuff's not in MRE, which is, I suppose, partly why
Jeffrey Friedl's working on a
Just trying to catch up. This is where I understand the discussion
stands:
INTERNALS(?)
modular language:
Scanner/Symbol Table/Parser/Executor
Standard Functions separate from core (moving to language?)
Modules Separate from everything (definitely language)
Strict(er)
Please explain how having a no taint block would still keep the spirit
of not making untainting easy?
Just add a no taint at the top of ones code, and the -T goes away.
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> I think I'd prefer to leave untainting to regexes.
DS> What I wa
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 01, 2000 at 01:43:05PM +0100, Graham Barr wrote:
> > Let me just say that Larry has said in the past that untainting was
> > deliberatly left difficult to do, on the basis that something which
> > can have serious effect (ie security) should no
Nick Ing-Simmons wrote:
> Cross posted to internals ('cos it is...)
Be it on your head... ;-)
> We should consider using "vtables" to avoid the cost of the conditional
> branches (and running out of flag bits).
>
> Thus this function would call variables "type check" "method" -
> which for nor
At 09:25 PM 8/1/00 +, Nick Ing-Simmons wrote:
>Alan Burlison <[EMAIL PROTECTED]> writes:
> >
> >No, I disagree. Perl gains a lot of its expressive power from being lax
> >about typing. I suspect it will also impose an unacceptable overhed for
> >the vast majority who don't want it - at the v
On Tue, Aug 01, 2000 at 07:03:42AM -0400, Grant M. wrote:
> Just trying to catch up. This is where I understand the discussion
> stands:
> INTERNALS(?)
> modular language:
>Scanner/Symbol Table/Parser/Executor
Internals.
>Standard Functions separate from core (moving to langu
On Tue, Aug 01, 2000 at 05:23:27PM +0200, Dominic Dunlop wrote:
> At 15:19 +0100 2000-08-01, Tim Bunce wrote:
> > >RegEx (internals?)
> >
> >Yes, Yes, Yes.
>
> I could argue for regex being language too:
> If the language group is
> going to give each of perl's reserved words (and much
101 - 200 of 205 matches
Mail list logo
