Re: RFC: On-the-fly tainting via $^T
Ariel Scolnicov wrote:
Unfortunately, this would mean your example above doesn't quite work.
One possibility is to say that $^T controls taint *checking*, but not
tainting itself[1]!
This is actually a good distinction that's worth some more discussion.
One could set the implementation so that you still had to use -T if you
wanted tainting, but could selectively turn taint *checking* off in a
scope by setting $^T = 0 (trusting any *data* used).
So perhaps:
#! perl -T
# [ ... ]
{ local $^T = 0; $ENV{PATH} = $unsafe_data; }
# [ ... ]
system "sh -c echo 'Hello, world!'"; # ?
However, the question here is: "Would $ENV{PATH} be tainted?" If so, I
would argue you don't gain much, since the system() call would still
result in an "Insecure dependency" error.
Also, this presents a problem:
#! perl
# [ ... ]
$^T = 1;
If -T is specified, we can turn tainting on. However, if $^T is only a
toggle for taint checking, then there are three possibilities in this
example:
1. Tainting must always be on, just in case the user sets $^T
2. The above example generates an error, like "Invalid attempt
to turn tainting on with $^T (must specify -T switch)"
3. Some type of pre-parsing must occur, looking for $^T ahead
of time so that it can work like -T.
-Nate
Re: formats and localtime
"RLS" == Randal L Schwartz [EMAIL PROTECTED] writes: RLS But yes, the manuals should be completely self-contained and not RLS require examining some C doc. RLS I disagree with keeping the same name as a Unix function, but having a RLS radically different calling sequence or return value. If you want a RLS new interface, *name* a new interface. Agreed. This thought seems to lead to having a layered approach. There would/could be a prefered portable layer. That may be implemented upon a native layer. The native layer would be available for those that prefer the C interface. Architecture Layers that aren't native could be ported so that useful modules could be easily used (for some value of easily). chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Random items (old p5p issues)
And how about
continuations, generators and co-routines.
chaim
"CF" == Chaim Frenkel [EMAIL PROTECTED] writes:
CF Magic words.
CF Iterators
CF Reduce (e.g. $x = reduce { sum } @list;
CF Case/Switch
CF Make some of the unaddressable into first class objects.
CF FILEHANDLE
CF DIRHANDLE
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: formats and localtime
Nathan Torkington writes: : Damian Conway writes: : My (limited) understanding of the aims of Perl 6 were to start again with a : clean slate and fix the things that are broken, or that could be designed : better with hindsight. Backwards compatibily was to be fed to the lions. : : Larry's the one who will decide what goes into perl6, and I'm speaking : here as Nat the Perl Hacker not Nat the Project Leader. So understand : that what follows is not holy writ, but a mere mortal's understanding. : : I would be surprised if perl5 programmers didn't feel at home in : perl6, so I'm not expecting lots of massive changes to the language. : I doubt int/string/etc typing will be mandatory. I doubt dollar signs : will disappear. "If you want Ada, you know where to find it" still : rings as true today as ever. You'd need pretty convincing arguments : to get any of those changes through. : : That said, if you can make a convincing argument for a feature's : inclusion then do so. The types of arguments that are likely to win : over Larry (I'm guessing) are things that make easy things easier, : hard things easier, or previously impossible things possible. : : So while backwards compatibility should not be an issue in the : brainstorming process we're in now, this doesn't mean that perl6 will : be unrecognizable. Nor is this merely thinking of new things to bolt : onto perl5. Some of the most important changes will be underlying : structural changes (e.g., internals, corners of language syntax) that : make some previously hard things easier (extending with C, : pretty-printing, run-time ability to optimize for memory or speed). : : Larry, is this what you had in mind? That's pretty close. Just because everything is negotiable doesn't mean that we plan to negotiate everything away. To say we're feeding backward compatibility to the lions is a bit misleading, in that it doesn't say what we're putting in its place. What we're putting in its place is the notion of a clear migration path--a land bridge from the old continent to the new one. As long as people have an easy way to upgrade (most of) their Perl 5 programs to Perl 6, I think we've done our job. Many syntactic constructs will be easy to translate. Some kinds of semantic shifts would make translation next to impossible. We're looking for some kind of 80/20 inflection point. Let me just add that I don't mind the brainstorming at all. To be a good language designer, you have to stuff your brain with what you *could* do before you can reasonably choose what you *will* do. At the moment, I'm not only trying to follow along here; I'm also reading all the books on computer languaes I can get my hands on--not just to look for ideas to steal, but also to remind myself of the mindset Perl was designed to escape. In fact, I'd go as far as to say that it's imperative that you overstuff your brain to the point where you no longer feel tempted to overstuff the language. Hypotheticality is your friend. Larry
RE: draft RFC: loop control and do
snip
=head1 DESCRIPTION
The C{} in Ceval{} and Cdo{} do not define blocks. This is a
problem because Cdo {} while is the only way to get a bottom-testing
"loop". This is not a real loop because the statement modifier version
of Cwhile modifies the Cdo statement, not the non-block of code
in the C{}. Thus Clast, Cnext, and Credo do not work on a
Cdo {} while.
However, they should. Just because you want to test the loop at the
bottom doesn't mean that don't want to break out of the loop early.
So a modified Cdo{} should count as a block.
I've used Cwhile, but the same goes for Cuntil.
/snip
Would simple do { } blocks then also be cantidates for becoming Code Blocks?
ie:
do { next if somthing }
which currently give us:
Can't "next" outside a block
-Corwin
Re: What is Perl?
As far as Perl being an offspring of Unix I think that's great if it is in meant **in spirit**. But any opportunity for Perl6 can make things more understandable to the average programmer vs. the average Unix user should be taken advantage of. The "unlink()" example is a good one. Now that Perl is thriving on Mac and Win this sort of Unix-speak seems out-of-place. In spite of where Perl came from I don't think we should feel like we can't grow the language into something easier. --Michael
RE: What is Perl?
The "definition" I've been hearing alot recently is that Perl is a "quick and dirty scripting language." Fine, I think it does quite well at that. But as of perl5, it is not a language which makes large development easy. I think Perl needs a couple different faces. It should keep the quick-n-dirty face which so many people have come to love, but it also needs a serious face. This would include, among other things: The ability to have strong-typing (I don't trust Junior Engineers to get it right and I don't have time to check every line of code they write) Strong support for OO (including the ability to have compile-time method lookups) Threading constructs built into the language Binary compilation And many others None of these would force us to make Perl disgusting to the quick-n-dirty lovers, but they should by all means be available to those of us who want to do real work in the language. One of the ideas I've heard mentioned that I really liked was to have only one kind of variable: a scalar. All the other types could be accessed via references. It also allows us to get rid of the $ symbol except for interpolation. ++t
Re: What is Perl?
At 01:01 PM 8/1/00 -0400, Michael Mathews wrote: As far as Perl being an offspring of Unix I think that's great if it is in meant **in spirit**. But any opportunity for Perl6 can make things more understandable to the average programmer vs. the average Unix user should be taken advantage of. The "unlink()" example is a good one. Now that Perl is thriving on Mac and Win this sort of Unix-speak seems out-of-place. In spite of where Perl came from I don't think we should feel like we can't grow the language into something easier. Let's also not forget that Unix (or insert your favorite OS here) got some things just fundamentally wrong. (Signals anyone? :) It is, after all, software, and all software sucks by definition. Extracting out the Good Bits while tossing the Bad Bits and building an abstraction layer's not a bad thing. I'd quite like to see this happening. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: draft RFC: loop control and do
At 11:58 AM 8/1/00 -0500, Brust, Corwin wrote:
Would simple do { } blocks then also be cantidates for becoming Code Blocks?
I would hope not--I've used them in code specifically because they are
*not* control blocks, yet still get you a new level of scope.
What I'd rather see is the concept of the 'looped statement'--i.e. any
single statement that has a loop modifier on it could be lasted. So this:
last while 1;
would be a noop, but people doing Evil Things with lists and whatnot could
still last out, like so:
(foo(), bar() || die, baz() || last) while (xyzzy());
which would exit out of the looping statement as soon as baz() returned false.
You could, I suppose, separate out the lexical scoping properties of a
block from the loop control properties, so we have non-looping blocks that
define scope, or looping blocks that don't. (I'd propose characters, but I
passed on picking up the Unicode spec over lunch (didn't want to throw my
back out... ;))
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
RE: Typeglobs, filehandles, asterisks
At 12:18 PM 8/1/00 -0500, Garrett Goebel wrote:
Personally, I like to be able to directly access the symbol table. It is
nice when generating classes from a template. I hope typeglobs go in the
washing machine instead of the bathtub. But, I don't mind it they are hard
to recognize when they come back.
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.
I'd also like to see lexicals addressed by name through some sort of symbol
table-ish thing. Maybe:
$PAD{my_var}[-1]
would give a ref to the lexical my_var that exists one level of scope out
from the current, or at least the my_var that's masked by the most recent
declaration of my_var. (So [0] is the current, [-1] the next most recent,
[-2] the one outside that, and so on)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Typeglobs, filehandles, asterisks
At 06:59 PM 8/1/00 +0100, Hildo Biersma wrote:
Dan Sugalski wrote:
I'd also like to see lexicals addressed by name through some sort of symbol
table-ish thing. Maybe:
$PAD{my_var}[-1]
would give a ref to the lexical my_var that exists one level of scope out
from the current, or at least the my_var that's masked by the most recent
declaration of my_var. (So [0] is the current, [-1] the next most recent,
[-2] the one outside that, and so on)
I like the idea... it's evil. (I hope it never makes it into the
language though.)
Damn straight! (And why?)
my @lexicals = keys %PAD;
would be quite nice. Folks would kill (or at least inflict really nasty
paper cuts) to have this available in the debugger.
Can you imagine doing this for 'local'? That would lead to some pretty
neat obfuscated code...
Sure. long_distance($var, -1) could give the most-recently-localized
version of $var. :-)
I'd rather not do it for globals, though. (Actually I'd be just as happy to
see local go missing entirely, but that's just me looking at the guts...)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: perl6 requirements
Perl isn't a programming language - Perl's grammar is much more like
a natural language than a computer one.
Well, $I wonder if anyone except @computers can find it natural to put a
f... $dollar_sign in front of every $noun you use.
Grammar != vocabulary.
You're right. Strictly speaking this reduces my posting to
misaimed babbling. :-)
So, why does all these readers wants this nounmarkers on those program
she writes?
If you don't care for $ or @ for inflections, I welcome the discussion
of "-s", "-'s", and "-es'" as the preferred inflections. Or we can
simply use Damian's recent bilingual work with Latin and Perl if
you prefer a more formal system to sloppy English.
I don't know a lot about CS but since the perl6 community seems to
be concerned about Perl6 being as widely accepted as possible I will
make the following observations.
"Seems" may be the operative term here. Feckless worship of the
false idol of universal popularity will, in attempting to please
everyone, be doomed to please no one. A less proselytist message
would be much useful, perhaps one more along the lines of: "This
is who we are (read: what Perl is). If you like how we are, that's
great--use Perl and be happy. But if you don't like who we are--that
is, *how* we are--then don't use Perl; there are plenty of other
languages for you."
In my opinion Perl lacks (at least partially) some features which
I consider important for scripting languages:
Scripting language? What's a scripting language? We're not talking
staging notes from the playwrite now, are we? Try rephrasing using
something unambiguous, such as the generally accepted "programming
language". "Scripting language" has no meaning -- it is nothing but
marketing buzzhype and associate political spin. Ignore it.
* elimination of pointers (If I want to spend my time considering how
many dereference operators to use I'll go for ***C++).
I'm aware, however, that switching from variable assignment to
name binding (like in Python or Scheme) is a very fundamental change
and therefore not an issue for perl6 (or is it?).
I wasn't aware that it wasn't an issue. Larry once seriously
contemplated this for perl4++, so why not revisit the notion?
* no need to declare variables: I think variables should be
lexically scoped by default, without having to think about and write
all those 'my's.
* convenient handling of structured data/records/objects with
attributes: I'm referring to what you can do (for example) with
Python instances: foo.member = bar
$foo-{member} = bar;
"If you want Python, you know where to find it."
I guess I'm not the only one who prefers this to
$$foo{'member'} = $bar (which of course has nothing to do
with $foo{'member'} = $bar).
Maybe Perl is sane and I'm just not getting the point. :-)
Making Perl look just like Java, Python, and BASIC is specifically
*not* the point.
If you want to write a new language, then please do. The world
needs more of them. Just please don't call it Perl.
--tom
Re: perl 6 requirements
Thank you for your compliments. Would you be willing to give us a first shot at what Perl *is* to get the discussion going? Only as slogans; deep analysis will require ascending a nearby summit. "Perl is a language you already know, but that you just don't know that you know." "Perl is a language for getting your job done." "Perl is the Cliff Notes of Unix." "Perl tries to fit itself around your brain instead of insisting on the reverse." And most importantly: "Perl makes programming fun again." --tom
Re: perl 6 requirements
'Scuse me, but I'm a bit puzzled by this whole 'What is Perl' thing. My
understanding of the rewrite was that it was primarily to provide a
cleaner implementation than the current 'worn out' one, and to remove
some of the more egregious features, e.g. the over-reliance on globs in
some places, move some functionality out of the core and into modules
etc. I certainly didn't expect a wholesale language redesign to be on
the cards. After all, I *like* the current language features (well,
mostly). I *like* the punctuation characters (they tell me what sort of
thing I am looking at). What other language allows such poetry as
"@{$hash}{@keys} = @values"? I humbly submit that perl without the
perlisms is not perl.
--
Alan Burlison
CARP - CAmpaign for Real Perl
Re: perl6 requirements
Edwin Steiner [EMAIL PROTECTED] writes:
In my opinion Perl lacks (at least partially) some features which
I consider important for scripting languages:
* elimination of pointers (If I want to spend my time considering how
many dereference operators to use I'll go for ***C++).
I'm aware, however, that switching from variable assignment to
name binding (like in Python or Scheme) is a very fundamental change
and therefore not an issue for perl6 (or is it?).
Please ghod no. There was once a perl without pointers, and it was
perl 5. And I'd walk a very long way barefoot over broken glass
before I went back to programming in perl 4 now we have perl 5.
* no need to declare variables: I think variables should be
lexically scoped by default, without having to think about and write
all those 'my's.
I'd like to see that as a pragma:
no need_for_my
Et voila, all variables are lexical by default, and you run the risk
of typoing. But -w should spot that for you.
* convenient handling of structured data/records/objects with
attributes: I'm referring to what you can do (for example) with
Python instances: foo.member = bar
I guess I'm not the only one who prefers this to
$$foo{'member'} = $bar (which of course has nothing to do
with $foo{'member'} = $bar).
Personally I like $foo-{member}, it's explicit and it does what you
need. Again, this is merely personal, but I find the
object.with.lots.of.dots = "Bloody annoying" style to be, well, bloody
annoying.
--
Piers
Re: perl 6 requirements
Chaim Frenkel [EMAIL PROTECTED] writes: "CF" == Chaim Frenkel [EMAIL PROTECTED] writes: "TA" == Ted Ashton [EMAIL PROTECTED] writes: TA In general, they do what you want, unless you want consistency. CF Randal, Tom, et. al. CF How locked in to your brain is this lack of consistency? How un-perlish CF would it be to cleanup, crypto-context, or the meaning of a list in CF a scalar context, or ... (Kirrily, this one is for the record.) I'd also like to add, redo, next, last escaping a subroutine. They do? Cool. -- Piers
Re: Random items (old p5p issues)
"PC" == Piers Cawley [EMAIL PROTECTED] writes: PC Chaim Frenkel [EMAIL PROTECTED] writes: And how about continuations, generators and co-routines. PC Now those'd be nice if they could be added without slowing down the PC rest of perl. (I didn't mention implementation) I'd consider them special forms of subroutine call and return. From my location and hand waving. It should be possible to require a declaration and have the opcode engine use a specialized form of call. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: formats and localtime
"LW" == Larry Wall [EMAIL PROTECTED] writes: LW Let me just add that I don't mind the brainstorming at all. To be a LW good language designer, you have to stuff your brain with what you LW *could* do before you can reasonably choose what you *will* do. At the LW moment, I'm not only trying to follow along here; I'm also reading all LW the books on computer languaes I can get my hands on--not just to look LW for ideas to steal, but also to remind myself of the mindset Perl was LW designed to escape. Stolen any ideas from APL or J? How about ICON? chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
RE: Removing/fixing $[line noise here] variables
At 03:53 PM 8/1/00 -0500, Brust, Corwin wrote:
Could this then also give the programer control over the content of
error/warning messages produced by Perl at runtime?
That's feasable. It'd be a performance hit, but I can't picture this really
being a performance-critical area... :)
Put together an RFC for it. (Soon!) This is a language topic, but it will
impact internals a touch, and I'd like to get as many of the "impact
internals" things spec'd out as soon as possible. Even if the final form
differs, it's easier to modify a capability than bolt it on after. (cf
perl5 threads...)
-Original Message-
From: Steve Simmons [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 01, 2000 3:37 PM
To: Perl6 Language Changes
Subject: Removing/fixing $[line noise here] variables
For deprecation, we should have a %PERL_DEPRECATED{mod}{thing} hash as
well. `mod' is `CORE', `FORMATS', etc, as above. A value of 0 means the
function is actually gone, 1 means it's disappearing next major release,
2 mean next minor, etc. The programmer can control what happens when
the feature is used by setting a %PERL_DEPRECATED{mod}{warning} value
to 0 for default, 1 for once, 2 for never, etc, etc.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Removing/fixing $[line noise here] variables
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 $^
$PERL_FORMATS{lines_left} vs $-
Hmm - I quite like this. I'd like it even more if they were package
scoped and/or localisable. My choice of warning level in my package
shouldn't affect your choice in your package.
--
Alan Burlison
Re: Random items (old p5p issues)
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 goal is to make easy things easy. I think case/switch is
something that belongs in the core, not in a module. Just because
something can be done now doesn't mean it doesn't deserve tighter
integration in the next version of Perl, or that it can't be done
better.
Nat
Re: What is Perl?
Alan Burlison writes: The ability to have strong-typing (I don't trust Junior Engineers to get it right and I don't have time to check every line of code they write) No. No no no no. This approach is fundamentally wrong. (I think I forgot to say this last time, but I'm not speaking with a Voice of Authority now, I'm just someone with an opinion) I disagree. If there was a bsdm.pm or -B option that gave strong type checking, then many would be happy. Sometimes you have to say "ok, you need a different language for this", but sometimes you have to ask whether Perl can make this thing easy too. Nat
type-checking [Was: What is Perl?]
On Tue, Aug 01, 2000 at 10:09:32AM -0700, Tony Payne wrote:
The ability to have strong-typing (I don't trust Junior Engineers to get it
right and I don't have time to check every line of code they write)
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.
In fact, it can be done with Perl 5, as various people have pointed out,
through tying. Unfortunately, accessing and manipulating tied variables is
incredibly slow. Improving their speed is obviously an implementation
detail (not belonging to a -language list), but would improve the language
by allowing the addition of extra syntax, like type checking, without
requiring it to be in core (that is, perl core, not the core distribution).
So, I envision syntax like this:
use typing; # place your fingers on the home row..
integer $foo, $bar, $blah;
string($baz, $qux) = ("bazarific", "quxaroni");
# and even..
my integer $quux = 4;
Except for the last part, the above syntax is doable in Perl 5. At least, I
assume the string example is; I couldn't quite get lvalue subs to work as I
expected when testing things.
With tying, however, exceptions (That's not an integer! *croak*) are made at
run-time, rather than compile-time (as would be more useful). So you have
to test all code paths if you are to use this as any sort of internal sanity
checking; I assume most everyone does this, but it would be useful for it to
be a compile-time check, so that perl -c would catch all of your errors.
This could possibly be accomplished by allowing arguments to the pragma, or
variable initialization:
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 other similarly declared integers (or
possibly promoted floats, chars, etc. if you wanted to get C-like). This,
then, could allow you to do checking at compile-time.
Which then raises a few more problems (whew): how do you coax user input
(which is an SV) into a value $foo can accept with very-strict on?; what
happens when an external function (say, from a module) is being very-strict,
but is passed arguments from code that doesn't do type checking?
Now, once you have that, you could then extend the syntax (provided we have
a way of doing tie-like functions (where the first argument is any data
type) in user-space):
integer @ints = (1 .. 20);
Which is what someone out there was suggesting; this would give you an array
optimized to hold only integers, rather than SVs.
So, strong typing is doable, and not burdensome to those who don't want to
use it (which includes me). You can even get some efficiency gains from it.
This is not necessarily an endorsement for type checking, but I see more
than a few people asking for it, and if it can be done without severely
impacting those who don't want it, there's little reason to deny them (that
I can see).
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: type-checking [Was: What is Perl?]
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 other similarly declared integers (or possibly promoted floats, chars, etc. if you wanted to get C-like). This, then, could allow you to do checking at compile-time. my integer $foo : very-strict = 4; my $val = STDIN; $integer = $val; # This can only be checked at run-time So, strong typing is doable, and not burdensome to those who don't want to use it (which includes me). You can even get some efficiency gains from it. IMHO a slightly-strongly-typed language is like a slightly-pregnant woman - an impossibility. This is not necessarily an endorsement for type checking, but I see more than a few people asking for it, and if it can be done without severely impacting those who don't want it, there's little reason to deny them (that I can see). 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 very least every variable access will have to check an 'are you typed' flag. -- Alan Burlison
Re: formats and localtime
Chaim Frenkel [EMAIL PROTECTED] writes: "LW" == Larry Wall [EMAIL PROTECTED] writes: LW But yelling that formats are essential to the core reminds me of my LW kids, who sometimes act as if they're being excoriated when we're LW merely trying to get them out of their dirty clothes and into some LW clean clothes. As humans we identify too closely with our clothes. What do you mean by core? Core users or core perl engine? I assume 'core perl engine' i.e. /usr/bin/perl or perl.exe they will of course be provided in perl6.tar.gz We need a quick glossary: perl core: perl.exe + perl.dll or .../bin/perl + libperl.so perl distribution anything from perl6.tar.gz Optional module things in CPAN -- Nick Ing-Simmons
RE: type-checking [Was: What is Perl?]
At 02:31 PM 8/1/00 -0700, Tony Payne wrote: 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 very least every variable access will have to check an 'are you typed' flag. I agree that weak typing is a huge advantage for Perl -- if the task is small. However, for a large project with more than 2 engineers, strong typing can save weeks of integration effort. I believe this for C/C++ projects, but I am unconvinced of it for Perl. And I have managed large Perl projects. Strong typing was never something I missed. It would likely get in the way with the number of heterogeneous data structures that I am wont to employ. An easy facility for unit testing, on the other hand... Perhaps the best of both worlds would be design-by-contract? A la Conway? -- Peter Scott Pacific Systems Design Technologies
Re: date interface (was Re: perl6 requirements, on bootstrap)
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 confused and less at home with Perl? I think there's a distinction here between the Unix-and-C mentality (which is good) and the Unix-and-C syntax. (which is not always) 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. -- "Little else matters than to write good code." -- Karl Lehenbauer
Re: perl 6 requirements
"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 subroutine call there. It's the same
as
$x = (1,7) # $x is 7
I've never gotten why you don't get that. :) It's a very simple rule:
the return context is the context of the invocation, and is determined
at runtime as well as being detectable at runtime (see wantarray()) if
you want to do something special.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: perl 6 requirements
"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; ...} @foo
Chaim should simply terminate the map, not go to the next containing loop.
So using map as it SHOULD be used (heh), what would you have @a
contain after:
@a = map { last if $_ 5; $_ } 1..10;
Would it be 1..5, 1..6, 1..10, whatever it had before, or ()? I could
make arguments for each of them. :)
I think making that *not* a looping block makes more sense, so we
don't get into this nonsense. The "last" cleanly breaks out of the
innermost loopblock, which by definition doesn't have a return value,
so there's no chance we'll freak out an assignment.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: type-checking [Was: What is Perl?]
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, formal, and fancy types for the return values of all their functions? No, this was intended to be a suggestion to provide a pragma or hooks (all of which are nearly doable in Perl 5) for type checking. This moves the onus of setting up a proper type-checking environment onto the shoulders of developers who wish to have type checking. I raised the question about how to handle it when a subroutine doing type checking is called by code that isn't; the question can go the other way. For the first situation (a subroutine doing type-checking is called by code that is not) there will probably have to be a runtime penalty to coerce the parameters into type-checked values. For the second situation (code doing type checking calls a subroutine that is not) would be much like the previous situation (runtime penalty, coercion of return values into type-checked values). There is also a management problem: suddenly some of your values aren't being type-checked. The only solutions I can think of offhand are: take your lumps and accept that some things won't be checked; write wrapper functions that -do- check; have some sort of mechanism that's basically a language- or pragma-level construct that does the wrapping for you: typing_proto funcname = [qw(ARRAY INTEGER HASHREF)], [qw(FLOAT)]; I'm not sure how well this fits into my original musings on doing certain things at compile-time to provide for compile-time warnings. It probably doesn't. Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
RFC: Request For New Pragma: Implicit
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 Perl 6 should add a new pragma called Cimplicit. =head1 DESCRIPTION I am lazy. I am spoiled by the implicit $_. I like the implicit $_. Implicit $_ good. Ugh. I also came to the sysadm / programming world in a long, circuitous route. I never programmed with toggle switches. I've never seen a punch card. My first programming was in Commodore 64 Basic. C64 Basic. No safe-signals there, either. ;) It did have one good thing, though. One very useful thing, for lazy people like me. Cprint could be written like C?. It just rolled off the fingers. C10 ?"Port Perl for the 64!". Of course, those days have gone. I've seen the light. I'm a *nix head and JAPH. But how I still hate typing out print. Particularly because I do it so much. Oh, sure, I could play games with HERE docs and the ilk, but I'm too lazy. But I digress. There should be an Cimplicit 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.) Scoping needs to be tightly controlled, of course. Don't want someone else's void context to show up on your display, now do you? And, of course, it would be defaulted to off. It could continue to ignore constant 0s and 1s. (But those pre-pod embedded comment strings just Bhave to go.) Ideally, I'd like to use it for printing, but I suppose some other lazy person may want to use it for something else. =head1 MOTIVATORS Laziness, pure and simple. =head1 IMPLEMENTATION The front-end would have to detect void usage and either arrange to have the results passed to a callback, (in which case, would you know what wantarray() wants to know?) or inject the appropriate term in the optree. =head2 SUMMARY OF IMPLEMENTATION I've no real concrete ideas on this, sorry. =head2 IMPACT =over 4 =item * Impact on Perl 5. Mutual compatibility between Perl 5 and Perl 6, with the exception of Cuse implicit and the sematics it would add. (Obviously, other changes to the language notwithstanding.) =back =head2 UNKNOWNS =over 4 =item * What about subs? Backticks? Things that return meaningless printable information, like system()? Cno implicit would put it on the user. After all, he doesn't have to use it. =item * Would C; print the contents of $_ to the default filehandle? ;-) =back =head1 REFERENCES None, currently. -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: Typeglobs, filehandles, asterisks
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 *main::fred does.
Well, in perl 5 it doesn't, but that doesn't say anything about perl 6... :)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: What is Perl?
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 checking would be faster than doing it with tying, but wouldn't bog SVs down with having to carry around too much more extra info. (At least, this is the impression I get from my limmited knowledge of Perl internals). Except perl, because it is perl, and does perlish things, always needs to do runtime checking. Removing automatic runtime checking in favor of an op indicating runtime checking will double the size of the optree, and make regular perl that much slower with everything else. I doubt it'd double the size, especially if it was smart and only inserted check opcodes where it wasn't sure they weren't needed. However, a vtable setup for scalars (now that I've got a handle on that) would reduce the cost significantly. In that case the scalar (or hash, or array, or whatever) itself would be responsible for typechecking, so the ops could just willy-nilly assign things and let the variables fend for themseles. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: date interface (was Re: perl6 requirements, on bootstrap)
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 changing localtime(), though, because 1. *Many* Perl scripts already use it 2. *Many* C programmers are familiar with its stupidity If we want to "fix" it, why not offer up something like this? 1. Deprecate the current localtime() with a warning 2. Make a new, better date() function that returns the "correct" args in what we feel to be the "correct" format This has two key advantages: 1. Existing programs don't break 2. Existing programmers won't say "Oh, localtime()! I know how that works!" An existing Perl 5 script: my $date = localtime(); Could generate something like "Function localtime() deprecated - use date() instead" And then we could make date() return the year + 1900, months starting with 1, etc, etc. -Nate
Re: RFC: On-the-fly tainting via $^T
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 out but actually thought it
would help clarify for those familiar with the whole { local($^W) = 0;
create_a_warning() }. You're completely right.
Footnotes:
[1] For efficiency, you'd probably still want some command-line
option, perhaps -T itself, to say "this program involves taint
checking, so please keep track of tainted values". That way programs
that keep $^T == 0 (almost all of what I write) don't need to keep
track of tainting.
Definitely. I didn't want to eliminate -T at all, just give a means for
dynamically controlling it within the script as well. The idea would be
that tainting wouldn't be turned on unless -T, $^T = 1, or possibly "use
Taint" (another suggestion) was specified.
You've got some other excellent points in there regarding emphasis on
data and not variables that I'll add to further revisions.
As Tim points out, this is probably more perl6-language. I'll keep the
discussion over there on subsequent posts until something is
"finalized".
-Nate
Re: $^O and $^T variables (on-the-fly tainting)
"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 executable. Then moving
an executable around would carry the correct luggage.
However, this got me thinking. Here is an idea I'd like to see: The
existence of a $^T variable for controlling tainting in the same way
that $^W controls warnings. Now *that* would be cool. I realize the
current implementation of tainting requires it starts with the
interpreter, but hey we're rewriting the internals, right?
DS So put in an RFC. :) Seriously, finer grain control over tainting's not
DS unreasonable, and I can think of a few ways to do it, but they need to be
DS designed in *now*, not later.
Just remember, Larry's dislike of making untainting easy.
I'd rather not have multiple characters. A option hash or even a longer
namespace would be more readable.
$Perl::Warnings{undef} = 1;
$Perl::Tainting = 1;
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC: On-the-fly tainting via $^T
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:
#! perl -T
$ENV{PATH} = untaint( read_config_file() );
In other words, either make the 'Taint' and 'Untaint' packages part of the
standard distribution, or put them into the core language.
While a way to taint something could reasonably be part of the main
distribution (which'd be nice), I think I'd prefer to leave untainting to
regexes.
What I was thinking of was something along the lines of a lexically scoped
pragma--"use taint"/"no taint". (We could do this by sticking in an opcode
to set/unset the tainting status, as well as the warning status, and so on)
Taint checking is disabled in a no taint block. Whether we still set the
taint status on a scalar could depend on the -T switch, so data would still
be tainted in a no taint block.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: RFC: On-the-fly tainting via $^T
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 any value assigned to $bar would become untainted. While this is certainly doable (heck, you can do it now with tied variables), I'm not at all comfortable with a magic untainting variables. I think it's a rather bad idea. Shrug 'Twas just an off-the-top-of-my head idea; not something I'd really fight for in the inclusion of Perl6. -- Matthew Cline| Suppose you were an idiot. And suppose that [EMAIL PROTECTED] | you were a member of Congress. But I repeat | myself. -- Mark Twain
Re: perl 6 requirements
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: "Perl5 was my rewrite of Perl, Perl6 will be the community's : rewrite of Perl." I think it is not realistic to keep shooting around, : trusting Larry to prevent anyone from getting hurt. We have our own : responsibilities as well. Yes, I don't mind other people shooting down the bad ideas, as long as they do it politely, and with good reasoning to back it up. It's the mindless sniping that is destructive, particularly when we're still brainstorming. People need to have a safe forum for bringing up half-baked ideas, even if we're also trying to create a more official RFC mechanism. On the flip side, we need to be Very Careful not to get our egos irrevocably tied to our proposals. I have a particular distaste for the sort of argument that goes, "If I can't have it my way, I'm going to take all my marbles and go home." That's not an argument--that's nuclear blackmail. I'm the only one who's allowed to make that sort argument, and you'll never hear me making it. Unless, of course, you count Rule 1 as a form of it. :-) But you'll notice I almost never invoke Rule 1. I am, in fact, rather more fond of Rule 2. I think everyone should be allowed to change their mind occasionally. Larry
Re: perl 6 requirements
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 be the one vetoing the ridiculous ideas. Larry said: "Perl5 was my rewrite of Perl, Perl6 will be the community's rewrite of Perl." I think it is not realistic to keep shooting around, trusting Larry to prevent anyone from getting hurt. We have our own responsibilities as well. In support, I got the impression that Larry wasn't even going to play Supreme Court on this one and that this was the whole point of all these groups and Perl6 - get Larry out from under all the piles of responsibility and to make Perl truck-proof. ;_) If that's really the case, then the efficiency of the whole project just dropped massively. After all, if Perl is to stay Perl and Larry has abandoned us, then we as a community will have to function as a Larry-emulator, a task which p5p pretty-well established as impossible. Somebody needs to tell Larry that he can't get out of being dad to this kid even if it has grown up a little :-). Ted -- Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University == For God's sake, please give it up. Fear it no less than the sensual passion, because it, too, may take up all your time and deprive you of your health, peace of mind and happiness in life. -- Bolyai, Wolfgang (1775-1856) [Bolyai's father urging him to give up work on non-Euclidian geometry.] == Deep thoughts to be found at http://www.southern.edu/~ashted
Re: perl 6 requirements
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: "Perl5 was my rewrite of Perl, Perl6 will be the community's rewrite of Perl." I think it is not realistic to keep shooting around, trusting Larry to prevent anyone from getting hurt. We have our own responsibilities as well. In support, I got the impression that Larry wasn't even going to play Supreme Court on this one and that this was the whole point of all these groups and Perl6 - get Larry out from under all the piles of responsibility and to make Perl truck-proof. ;_) -- Matthew O. Persico "If you were supposed to understand it, we wouldn't call it code." - FedEx NetZero Free Internet Access and Email_ Download Now http://www.netzero.net/download/index.html Request a CDROM 1-800-333-3633 ___
Re: Summary...tell me where I'm worng...
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 previously difficult or impossible (or merely verbose). But it's also more or less poorly documented, more or less poorly understood, more or less well-used, and more or less poorly tested. (Indeed, some of it's still marked as experimental.) If the language group is going to give each of perl's reserved words (and much else besides) the third degree so as to decide whether it should stay in the core, be cast into outer darkness, or end up somewhere in between, then I'd say that the same should be done for the language supported by the regex engine. Once the language group has decided what are the required and optional features of the regex language, then the internals folks can start working out how to make it fly (or tell the language folks it won't). Pluggable regex engines would make supporting (say) core and optional regex language features easier. Want me to write this up as an RFC? -- Dominic Dunlop
Re: RFC: On-the-fly tainting via $^T
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. "DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS I think I'd prefer to leave untainting to regexes. DS What I was thinking of was something along the lines of a lexically scoped DS pragma--"use taint"/"no taint". (We could do this by sticking in an opcode DS to set/unset the tainting status, as well as the warning status, and so on) DS Taint checking is disabled in a no taint block. Whether we still set the DS taint status on a scalar could depend on the -T switch, so data would still DS be tainted in a no taint block. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183 Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Summary...tell me where I'm worng...
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 new edition (and trawling up a rich haul of bugs in the process -- see the p5p list). Of course, documentation in MRE II would lay that particular complaint of mine to rest (six feet deep in a in a lead-lined casket). -- Dominic Dunlop
Summary...tell me where I'm worng...
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) DataTypes: Automatic Type Conversion(?) (internal or language?) Native Size Allocation (Internal or language?) Items still under general discussion: Formats (probably language if it stays) Garbage Collection (internals?) RegEx (internals?) localtime() (arrays start at 0 or 1) (language) Backward compatibility in general (who knows) If someone could just tell me where these discussions go (as many aren't really defined yet) I would be grateful. Also, If I have missed anything let me know, Grant M. [EMAIL PROTECTED]
Re: RFC: On-the-fly tainting via $^T
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. chaim "DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS I think I'd prefer to leave untainting to regexes. DS What I was thinking of was something along the lines of a lexically scoped DS pragma--"use taint"/"no taint". (We could do this by sticking in an opcode DS to set/unset the tainting status, as well as the warning status, and so on) DS Taint checking is disabled in a no taint block. Whether we still set the DS taint status on a scalar could depend on the -T switch, so data would still DS be tainted in a no taint block. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC: On-the-fly tainting via $^T
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 not be easy to do. But then I suppose all previous decisions are up for re-deciding Yes, they are. If we're going to make it trivially easy to untaint, should we bother having tainting at all? :( Tainting has potential uses as data-tracking mechanism aside from security. If the keyword 'untaint' had to appear, it would be easier to find security issues than when m/(.*)/ is used. Uh-oh, now we're getting back into perl6-language territory... attempting to CC. -- John Tobey, late nite hacker [EMAIL PROTECTED] \\\ /// ]]] With enough bugs, all eyes are shallow. [[[ /// \\\
Re: type-checking [Was: What is Perl?]
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 very least every variable
access will have to check an 'are you typed' flag.
Cross posted to internals ('cos it is...)
We should consider using "vtables" to avoid the cost of the conditional
branches (and running out of flag bits).
Works for me. Anyone care to flesh this out a bit? (Take pity on a guy
who's not had C++ inflicted upon him... :)
Thus this function would call variables "type check" "method" -
which for normal case would be pointer to blue-white-hot "NoOp" function
which is near always in-cache, for a typed var it could be a slow
as you wanted...
I was thinking that, since the compiler has most of the information, a
"type check" opcode could be used, and inserted only where needed. If, for
example, you had:
my ($foo, $bar);
my ($here, $there) : Place;
$foo = $bar;
$here = $there;
You'd only need to typecheck the assignment to $here. Granted assignments
through references would need to check unconditionally, and a typecheck's
in order if you're not sure of the types (say, by directly referencing @_
elements), but the optimizer could certainly toss a lot of checks.
Strong typing could also get us a win other places. If, for example, we said:
my @foo : integer : strict;
meant that @foo *only* has integers in it, we don't need to store full SVs
in it, and use an integer array only.
If strict's off I don't see any reason to forbid bad assignments of 'known'
types--if someone, using the above example, did a "$foo[2] = 'bar'" I don't
see any reason not to make $foo[2] have a value of 0. (With a warning
emitted by -w, of course)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: RFC: On-the-fly tainting via $^T
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:
#! perl -T
$ENV{PATH} = untaint( read_config_file() );
In other words, either make the 'Taint' and 'Untaint' packages part of the
standard distribution, or put them into the core language.
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.
Also:
my $fh = new FileHandle("trusted_config_file");
$fh-setTrusted(1);
Then anything read from $fh wouldn't be tainted, rather than having to
untaint every single thing read from $fh.
--
Matthew Cline| Suppose you were an idiot. And suppose that
[EMAIL PROTECTED] | you were a member of Congress. But I repeat
| myself. -- Mark Twain
Re: Summary...tell me where I'm worng...
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 language?) Some of each. Modules Separate from everything (definitely language) Yes. Strict(er) DataTypes: Automatic Type Conversion(?) (internal or language?) Native Size Allocation (Internal or language?) Language for now. Items still under general discussion: Formats (probably language if it stays) Garbage Collection (internals?) RegEx (internals?) Yes, Yes, Yes. localtime() (arrays start at 0 or 1) (language) Yes. Backward compatibility in general (who knows) Script Backward compatibility = language. XS Backward compatibility = here (later) if someone volunteers to write the code to make old XS code work with the new APIs. If someone could just tell me where these discussions go (as many aren't really defined yet) I would be grateful. Also, I'd say "if in doubt then it's not for perl6-internals, at least not for now". I'd also say there's not much point at the moment in discussing details of implementing features that we're not pretty sure will be in the language. I think there's _lot's_ of valuable work we can do here we can do here prior to the language being firmed up. If we start getting into details of other things we won't make progress on the basics, like vtable interfaces for SV and libraries, analysis of GC implementations etc. We need to be pretty sure of most of those kind of issues by the time the language gets firmed up. Tim.
Re: Summary...tell me where I'm worng...
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 else besides) the third degree so as to decide whether it should stay in the core, be cast into outer darkness, or end up somewhere in between, then I'd say that the same should be done for the language supported by the regex engine. Yes. Yes. Yes. Tim.
Stuff in core (was Re: date interface, on language (was Re: perl6 requirements, on bootstrap))
On Tue, Aug 01, 2000 at 11:37:49PM -0400, Dan Sugalski wrote: Right. That was my point. (The original poster wanted to pull IO out of the core entirely) Ah. Barbarians-at-gates approach, then. On the other hand, there is a lot of rubbish that *can* go out of core; I'd like to see core being syntax-plus-essentials. System V IPC, for instance, isn't essential. I think "essential" could be easily defined as "stuff which is portable pretty much everywhere"; the socket stuff can go into a separate library, for instance. This probably wouldn't affect speed too drastically because these things could always be linked in statically a la Dynaloader. But this is now an internals issue, so the list football starts again. Don't you just love arbitrary distinctions? -- VMS must die!
Re: type-checking [Was: What is Perl?]
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 very least every variable
access will have to check an 'are you typed' flag.
Cross posted to internals ('cos it is...)
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 normal case would be pointer to blue-white-hot "NoOp" function
which is near always in-cache, for a typed var it could be a slow
as you wanted...
--
Nick Ing-Simmons
