Nathan Wiger <[EMAIL PROTECTED]> writes:
[...]
> =head1 Implementation
>
> This will avoid internals, but instead get into the details of how the
> implementation should *act*:
>
>1. Have the tainting engine "trust" any variables declared
> when tainting is off. So:
>
> #!
> Language
> Miscellaneous language issues
> item 1.
> Perl is not like other programming languages. Ilya used to say that
> 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
On Tue, Aug 01, 2000 at 01:13:17PM +0200, Edwin Steiner wrote:
> > 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 $n
Moving the discussion to perl6-language:
Thus it was written in the epistle of Nathan Wiger,
> Chaim Frenkel wrote:
> >
> > Language
> > -> Obsolete Features
> > -> 1. Formats are not commonly used
> >
> > I'm sorry where did this come from. I use formats regularly and quite
> > use
Simon Cozens schrieb:
>
> On Tue, Aug 01, 2000 at 01:13:17PM +0200, Edwin Steiner wrote:
> > > 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.
> "Tim" == Tim Jenness <[EMAIL PROTECTED]> writes:
Tim> Agreed. The localtime() docs suffer from a 'read the C manual' problem at
Tim> the moment
Well, as long as "deleting a file" is spelled u-n-l-i-n-k,
we might as well have the output of localtime() be consistent with
the C function o
On Tue, Aug 01, 2000 at 07:29:05AM -0600, Tom Christiansen wrote:
> I suggest that the language list discuss this very matter: what
> Perl really *is*, so that we know the tenets and principles against
> which proposals can be measured.
Let's do that. Here's my opening gambit:
Well, enough clo
Thus it was written in the epistle of Tom Christiansen,
> >This is why we need people what Perl *is* to get on the language list
> >and fight the incoming. Perl 6 is meant to be the next version of Perl,
> >not the bastard child of Python and Java.
>
> Could have fooled me. :-(
>
> I suggest tha
On Tue, Aug 01, 2000 at 08:00:54AM -0600, Tom Christiansen wrote:
> I did the "What is Perl?" thing to focus folks on what this was
> really for, since many seem to be trying to create a new and different
> language now. And you've said all that here just fine.
Bingo. We're redesigning *Perl*. W
Thus it was written in the epistle of Tom Christiansen,
> 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
On Tue, Aug 01, 2000 at 06:31:45AM -0700, Randal L. Schwartz wrote:
>
> 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!
Tim.
On Tue, Aug 01, 2000 at 10:34:51PM +0900, Simon Cozens wrote:
> On Tue, Aug 01, 2000 at 07:29:05AM -0600, Tom Christiansen wrote:
> > I suggest that the language list discuss this very matter: what
> > Perl really *is*, so that we know the tenets and principles against
> > which proposals can be
Tom Christiansen schrieb:
[snip]
> "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: "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 s
> 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;
I would argue that's what "use English" is for. Personally, I like the
shortcut of $^W et al.
-Nate
> "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 va
> "TA" == Ted Ashton <[EMAIL PROTECTED]> writes:
TA> In general, they do what you want, unless you want consistency.
Randal, Tom, et. al.
How locked in to your brain is this lack of consistency? How un-perlish
would it be to cleanup, crypto-context, or the meaning of a list in
a scalar co
Magic words.
Iterators
Reduce (e.g. $x = reduce { sum } @list;
Case/Switch
Make some of the unaddressable into first class objects.
FILEHANDLE
DIRHANDLE
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAI
(I speak now as a user of Perl)
Perl is for making easy things easy and hard things possible. Perl
currently makes a lot of things easy:
- text manipulation
- filters
- reading and writing data from files
- making/deleting/reading directories and contents
- short programs to do minor tasks
> "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 t
And how about
continuations, generators and co-routines.
> "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 objec
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
=head1 TITLE
loop control and do
=head1 VERSION
Maintainer: Nathan Torkington <[EMAIL PROTECTED]>
Date: 1 Aug 2000
Version: 0 (unreleased)
Mailing List: [EMAIL PROTECTED]
Number: (unassigned)
=head1 ABSTRACT
In version 5 and earlier, C does not create a block.
Thus the loop controls
=head1 DESCRIPTION
The C<{}> in C and C do not define blocks. This is a
problem because C is the only way to get a bottom-testing
"loop". This is not a real loop because the statement modifier version
of C modifies the C statement, not the non-block of code
in the C<{}>. Thus C, C, and C do
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
Chaim Frenkel writes:
: > "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
:
: DC> Only if you simultaneously remove Perl 5!
:
: DC> My (limited) understanding of the aims of Perl 6 were to start again with a
: DC> clean slate and fix the things that are broken, or that could be designed
:
There was some discussion at TPC4 that typeglobs could be expunged from
P6. If this is likely, it would free up a type-defining punctuation
character (*).
Could this be used for filehandles? I have often thought that filehandles
were handicapped unnecesarily by looking like barewords. Grant
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-d
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.
Garrett
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. T
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
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 co
Speaking from the "peanut gallery" as just some guy who uses perl a lot...
I agree with the idea of cleaning up the builtin functions so that they're
obvious to the widest possible audience. However, I don't know that what's
"obvious" is that clearcut -- I mostly work on Unix, so I expect "unlin
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
To me, Perl is like a good book. It's a good quick read that takes you in
quickly and entertains you without wasting your time. But you can also go
back and re-read it again and again, and each time you re-examine it you
find another level of depth and complexity.
As a programming language, it is
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 /#
--Michael
Dirk wrote:
> How about considering the idea of "synonyms", though?Is
> it unreasonable to have "unlink()" and "fdelete()" (or
> whatever it is on Win32) mean the same thing?
This brings back an idea I had a while ago. How about defining a module,
that could be part of the standard distri
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
> >
At 01:00 PM 8/1/00 -0500, Garrett Goebel wrote:
>It'd be nice if taint, strict, and other "bondage and discipline" coding
>practices were things you had to turn off, instead of automatically on. That
>would give the casual coder a beaten path from which they could chose to
>depart in whole or incr
At 02:08 PM 8/1/00 -0400, Dan Sugalski wrote:
>At 06:59 PM 8/1/00 +0100, Hildo Biersma wrote:
>
>>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
On Tue, 1 Aug 2000, Buddha Buck wrote:
> I haven't looked at the internals for local, but isn't:
Nope. Local works on globals and "$unnamed_foo" isn't a lexical, its a
global available inside called functions. So when you call
uses_foo() from within the block it will see the local value of $fo
Ala wrote:
>Dirk wrote:
>
>> How about considering the idea of "synonyms", though?Is
>> it unreasonable to have "unlink()" and "fdelete()" (or
>> whatever it is on Win32) mean the same thing?
>
>This brings back an idea I had a while ago. How about defining a module,
>that could be part of
On Tue, Aug 01, 2000 at 01:17:25PM +1000, Damian Conway wrote:
> 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.
>
>
>> > > 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'
>On Tue, Aug 01, 2000 at 07:29:05AM -0600, Tom Christiansen wrote:
>> I suggest that the language list discuss this very matter: what
>> Perl really *is*, so that we know the tenets and principles against
>> which proposals can be measured.
>
>Let's do that. Here's my opening gambit:
>Well, eno
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."
'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, mo
>'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 place
Tom Christiansen wrote:
> You're probably right, on every single point.
>
> I did the "What is Perl?" thing to focus folks on what this was
> really for, since many seem to be trying to create a new and different
> language now. And you've said all that here just fine.
Thanks :-)
There is ano
Ted Ashton wrote:
>
> Moving the discussion to perl6-language:
>
> Thus it was written in the epistle of Nathan Wiger,
> > Chaim Frenkel wrote:
> > >
> > > Language
> > > -> Obsolete Features
> > > -> 1. Formats are not commonly used
> > >
> > > I'm sorry where did this come from. I
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 aw
[I'm splitting this up, to make it easier to know what we're talking
about]
Chaim Frenkel <[EMAIL PROTECTED]> writes:
[...]
> Reduce (e.g. $x = reduce { sum } @list;
reduce needs to be able to take an (optional?) "distinguished element"
to start from. Consider this:
reduce
On Tue, Aug 01, 2000 at 08:30:44AM -0700, Nathan Wiger wrote:
> So perhaps:
>
>#! perl -T
># [ ... ]
>{ local $^T = 0; $ENV{PATH} = $unsafe_data; }
># [ ... ]
>system "sh -c echo 'Hello, world!'"; # ?
I would rather have it as a pragm instead of a special var ie
use t
On Tue, Aug 01, 2000 at 11:59:22AM -0400, Chaim Frenkel wrote:
> Reduce (e.g. $x = reduce { sum } @list;
I mentioned this to Larry on the Friday after the conference
and his response was that he did think about it originally but
$sum = reduce + @list; # assuming I got the verbal
Chaim Frenkel <[EMAIL PROTECTED]> writes:
> > "TA" == Ted Ashton <[EMAIL PROTECTED]> writes:
>
> TA> In general, they do what you want, unless you want consistency.
>
> Randal, Tom, et. al.
>
> How locked in to your brain is this lack of consistency? How un-perlish
> would it be to clean
Chaim Frenkel <[EMAIL PROTECTED]> writes:
> Magic words.
>
> 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.
--
Piers
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
Chaim Frenkel <[EMAIL PROTECTED]> writes:
> And how about
>
> continuations, generators and co-routines.
Now those'd be nice if they could be added without slowing down the
rest of perl.
--
Piers
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)
No. No no no no. This approach is fundamentally wrong. Bad programmers
can write bad code in *any* language. Your solution is t
Garrett Goebel wrote:
> As a programming language, it is a quick and dirty scripting tool... "shell
> scripting on steroids". Using it for larger projects with a single
> implementor requires experience and wisdom. Using Perl for a large project
> with multiple-coders adds the requirement for dis
Graham Barr wrote:
> > Reduce (e.g. $x = reduce { sum } @list;
Is it sufficiently more useful than:
$x = 0; map $x += $_, @list;
?
Alan Burlison
> On Tue, Aug 01, 2000 at 11:59:22AM -0400, Chaim Frenkel wrote:
> > Reduce (e.g. $x = reduce { sum } @list;
>
> I mentioned this to Larry on the Friday after the conference
> and his response was that he did think about it originally but
>
> $sum = reduce + @lis
> "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'
I want them as first class objects/verbs. 'for', 'each', 'values',
etc. should know how to do handle these objects.
I should be able to pass any operator through reduce.
> "PC" == Piers Cawley <[EMAIL PROTECTED]> writes:
PC> Chaim Frenkel <[EMAIL PROTECTED]> writes:
>> Magic words.
>>
>>
> "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.
Make that _NOT_ escaping a subroutine.
map { ...; last; ...} @foo
should simply terminate the map, not go to the next c
> "PC" == Piers Cawley <[EMAIL PROTECTED]> writes:
>> How locked in to your brain is this lack of consistency? How un-perlish
>> would it be to cleanup, crypto-context, or the meaning of a list in
>> a scalar context, or ...
PC> Don't you go touching the meaning of a list in a scalar context
At 05:32 PM 8/1/00 +0100, Piers Cawley wrote:
>Chaim Frenkel <[EMAIL PROTECTED]> writes:
>
> > And how about
> >
> > continuations, generators and co-routines.
>
>Now those'd be nice if they could be added without slowing down the
>rest of perl.
Could someone point me to a reference on thes
At 05:08 PM 8/1/00 +0100, Graham Barr wrote:
>On Tue, Aug 01, 2000 at 11:59:22AM -0400, Chaim Frenkel wrote:
> > Reduce (e.g. $x = reduce { sum } @list;
>
>I mentioned this to Larry on the Friday after the conference
>and his response was that he did think about it originally but
>
At 07:19 PM 8/1/00 +0100, Alan Burlison wrote:
>Tony Payne wrote:
> > Strong support for OO (including the ability to have compile-time method
> > lookups)
>
>Bit difficult when polymorphism enters the picture - I guess this is
>more a request for intelligent optimisation, although I suspect an
>e
> "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
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 05:32 PM 8/1/00 +0100, Piers Cawley wrote:
> >Chaim Frenkel <[EMAIL PROTECTED]> writes:
> >
> > > And how about
> > >
> > > continuations, generators and co-routines.
> >
> >Now those'd be nice if they could be added without slowing down the
> >
> "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 w
A good language can help produce good programers, though. Perhaps Tom's
team can be required to 'use OurStrictness' which sets up stuff like
exporting use of strict and taint
-Corwin
-Original Message-
From: Alan Burlison [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 01, 2000 1:20 PM
In re the discussion of $^O, etc, etc, I'd like to throw out
some ideas on these line noise features and (for lack of a better
name) perl control values.
IMHO there are two distinct sets of problems here. One is that
the existing $[linenoise] vars are horrible names and really need
some syntacti
But is this useful?
sub baz { return ( 'one','two' ) }
my ($foo, $bar) = &baz; # $foo == 'one', $bar == 'two'
-Corwin
-Original Message-
From: Chaim Frenkel [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 01, 2000 3:10 PM
To: Piers Cawley
Cc: Ted Ashton; Tom Christiansen; Simon Cozens
Steve Simmons writes:
> 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 $-
P
Could this then also give the programer control over the content of
error/warning messages produced by Perl at runtime?
Am I way off track here?
-Corwin
-Original Message-
From: Steve Simmons [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 01, 2000 3:37 PM
To: Perl6 Language Changes
S
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 togeth
Nathan Torkington wrote:
> Perhaps reserve the PERL or Perl namespace?
>
> $PERL::CORE{warnings}
> $PERL::FORMATS{name}
We remember that packages with lc names are already reserved by convention;
and this is one place to exploit that. [why "Config", anyway?]
$perl::core{warnings}
On Tue, Aug 01, 2000 at 04:47:47PM -0400, Dan Sugalski wrote:
> 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 . . .
Uh, OK - but how about we wa
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 $-
H
OK, I'm going to do that, tonight or over lunch wednesday.
Specificly I'll create an RFC for Programer Modifiable Warnings and Error
Messages.
Please direct thoughts on this subject to me.
-Corwin
-Original Message-
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 01
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 belon
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
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
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
NT> Piers Cawley writes:
>> > Case/Switch
>> Why? And Damian's already proved it can be done.
NT> Perl's goal is to make easy things easy. I think case/switch is
NT> something that belongs in the core, not in a module. Just
"Brust, Corwin" wrote:
> A good language can help produce good programers, though. Perhaps Tom's
> team can be required to 'use OurStrictness' which sets up stuff like
> exporting use of strict and taint
No it can't. It is a bit like fitting a speed limiter to a lorry - it
limits the damage ca
At 04:58 PM 8/1/00 -0400, Steve Simmons wrote:
>On Tue, Aug 01, 2000 at 04:47:47PM -0400, Dan Sugalski wrote:
>
> > 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
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
>
> ...
>
> $foo = $unnamed_foo;
>}
>
>Is there something in
Okay, so no one seemed to be offended at my original post/suggestion -- must
mean I should try to take it a little further :)
Here's the RFC in POD even.
--Michael
=head1 TITLE
Multiline Comments for Perl.
=head1 VERSION
Maintainer: Michael J. Mathews <[EMAIL PROTECTED]>
Date: 01 Aug 20
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 y
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 clothe
Nathan Torkington wrote:
> 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
> 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 typ
> 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 actually allows you to specify that "argument 3
> sho
Despite my throw-it-over the transom comments on global vars, that's
not really why I came here (tho I will pitch in on the topic).
The perl features that most bites me in the ass is how module versioning
and searching works. The easiest way to describe what I want is by
examples, so here are se
Michael Mathews wrote:
>
> =head2 Proposal
>
> Using a two-character syntax to start and end a multiline comment seems to
> be a good way to satisfy both the desired similarity to "#" and the desired
> uniqueness to avoid collision with real single-line quotes. I would suggest
> a (# many lines
On Tue, 1 Aug 2000, 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
Okay, here's my first attempt at an RFC, contributing to the community,
and dredging back up my design experience after being forced to hack for
8+ years. I'm not completely familiar with POD format, so I've probably
made mistakes. I'm also not a full-blown perl or C guru, so I've
probably made
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 c
1 - 100 of 205 matches
Mail list logo
