Re: More fun with argument passing

On Oct-05, Luke Palmer wrote: > Steve Fink writes: > > Ok, I'm back to argument passing. I'm starting a new thread because > > I'm lazy and I have to scroll back too far in my mailer to see the old > > arg passing thread. :-) And yes, most of this mess

Re: Parrot 0.0.11 "Doubloon" Released!

On Sep-21, Gerrit P. Haase wrote: > Hallo again, > > >>>http://cpan.perl.org/authors/id/S/SF/SFINK/parrot-0.0.11.1.tar.gz > > >> And all we need now is a 0.0.11.2, with patches to allow four-element > >> version numbers... > > [...] > > Ouch, better take this: > $ diff -urd parrot-0.0.11.1/VER

Re: Parrot 0.0.11 "Doubloon" Released!

On Sep-20, Steve Fink wrote: > At long last, Parrot-0.0.11 "Doubloon" has been released! And so has Parrot-0.0.11.1, for those of you who want correct native bytecode tests! http://cpan.perl.org/authors/id/S/SF/SFINK/parrot-0.0.11.1.tar.gz Hmm... for symmetry, I'm now thinki

Parrot 0.0.11 "Doubloon" Released!

At long last, Parrot-0.0.11 "Doubloon" has been released! This release features direct generation of executable binaries, dramatically improved documentation, and a built-in bread maker! Get it while it's hot at , or join the party by

Parrot 0.0.10 released

The Parrot team is proud to announce the release of Parrot version 0.0.10, code named "Juice" (based on the new -Oj optimization flag). It is downloadable from . If you would like to check the latest copy out from CVS, see the instruct

Re: This week's Perl Summary

On Jan-04, Leopold Toetsch wrote: > Damian Conway wrote: > > >Piers Cawley wrote: > > > >>Acknowledgements > > > >But, of course, modesty forebade him from thanking the tireless Perl 6 > >summarizer himself, for his sterling efforts wading through the morasses > >that are P6-language and P6-intern

[ANNOUNCE] Parrot v0.0.9

The Parrot team is proud to announce the release of Parrot version 0.0.9, code named "Nazgul". It is downloadable from . If you would like to check the latest copy out from CVS, see the instructions at . Try i

Re: Backtracking syntax

On Sun, Sep 22, 2002 at 01:39:29PM -0500, Me wrote: > So, how about something like: > > : # lock in current atom, ie as now > :] # lock in surrounding group, currently :: > :> # lock in surrounding rule, currently ::: > :/ # lock in top level r

Re: hotplug regexes, other misc regex questions

On Wed, Sep 18, 2002 at 05:01:35PM +0200, Damian Conway wrote: > Steve Fink wrote: > > >What possible outputs are legal for this: > > > > "aaa" =~ /( a { print 1 } | a { print 2 })* { print "\n" } x/ > > Unless Larry specifies a required seman

Re: hotplug regexes, other misc regex questions

On Mon, Sep 16, 2002 at 10:32:17AM +0300, Markus Laire wrote: > On 15 Sep 2002 at 22:41, Steve Fink wrote: > > Your code seems to backtrack to the beginning at every failure. First > code only backtracks one char at time. > > Huh? What implementation is that? I think my na

Re: Does ::: constrain the pattern engine implementation?

On Wed, Aug 28, 2002 at 12:55:44PM -0400, Deven T. Corzine wrote: > On Wed, 28 Aug 2002, Dan Sugalski wrote: > > At 10:57 AM -0400 8/28/02, Deven T. Corzine wrote: > > On the other hand, :, ::, ::: and don't necessarily need to be a > problem if they can be treated as hints that can be ignored.

Re: Regular and Context-Free languages

On Fri, Aug 09, 2002 at 09:50:00PM -0400, Mark J. Reed wrote: > On Fri, Aug 09, 2002 at 05:23:58PM -0700, Steve Fink wrote: > > On Thu, Aug 08, 2002 at 12:05:00AM -0400, Mark J. Reed wrote: > > > Finite state machines can match regular expressions whose only operations

Re: Regular and Context-Free languages

Wow. Since you went to the trouble of writing all this up, it really ought to go in a FAQ somewhere. On Thu, Aug 08, 2002 at 12:05:00AM -0400, Mark J. Reed wrote: > Finite state machines can match regular expressions whose only operations > are closure (*), alternation (|), and grouping. Some of

Re: Hashes, Stringification, Hashing and Strings

On Tue, Apr 16, 2002 at 02:00:33PM -0400, Mike Lambert wrote: > Speaking of which, how do we ensure the immutability of keys being put > into the hash? I think Perl copied the string, so that: RFC266 talks about these issues, though it was just really my take on the problem at the time. http://de

Re: Perl6/Parrot status

On Thu, Feb 07, 2002 at 06:13:47AM -0800, Ask Bjoern Hansen wrote: > Hi, > > I am tired of people thinking that we are not getting anywhere at > all, so if (some|any|every)one can send me a reasonably updated text > for the "Where are we" section at http://www.parrotcode.org/ and > likewise for h

Re: Apoc4: The loop keyword

On Fri, Jan 25, 2002 at 11:31:13PM -0500, Melvin Smith wrote: > At 11:40 AM 1/25/2002 -0600, Jonathan Scott Duff wrote: > >On Fri, Jan 25, 2002 at 11:57:25AM +0100, Bart Lateur wrote: > >> On Mon, 21 Jan 2002 15:43:07 -0500, Damian Conway wrote: > >> > >> >What we're cleaning up is the ickiness of

Re: Apoc4: The loop keyword

On Sun, Jan 27, 2002 at 10:43:08PM -, Rafael Garcia-Suarez wrote: > Melvin Smith wrote in perl6-language: > >> > >>Besides no one has commented on Steve Fink's (I think it was him) idea > >>to store the result of the most recently executed conditional in $?. I > >>kinda like that idea myself.

Re: Apoc4: The loop keyword

On Mon, Jan 21, 2002 at 12:50:38PM -0800, Larry Wall wrote: > In most other languages, you wouldn't even have the opportunity to put > a declaration into the conditional. You'd have to say something like: > > my $line = <$in>; > if $line ne "" { ... } > > Since > > if my $line = <$

Another nice to have: make # less ambiguous

On my wishlist is forbidding the use of # just about anywhere but as a comment starter and in strings or regular expressions. Not a big deal, but it would make it easier to write 90% correct perl syntax parsers. It's a pain dealing with q#not a comment# and m#still not# and s(even)#this#. Espe

Re: as long as we are discussing 'nice to have's...

[EMAIL PROTECTED] wrote: > On Sat, Jul 21, 2001 at 02:47:43PM -0700, Dave Storrs wrote: > >>I discovered today that I had forgotten to put 'use strict' at the top of >>one of my modules...it was in the script that _used_ the module, but not >>in the module itself. Putting it in instantly caught

Re: "Implied types, first try." Or "Its amazing what you can do with potatoes"

Michael G Schwern wrote: > On Mon, Jul 09, 2001 at 08:54:49PM -0700, Steve Fink wrote: > >>my Num $x = 3.0; >>$x++; >>my Int $y = $x; >> >>Could be compile-time, if you do constant folding first. >> > > Alot of how much checking we can do

Re: "Implied types, first try." Or "Its amazing what you can do with potatoes"

[EMAIL PROTECTED] wrote: > Here's me thinking out loud. I'm thinking about how to avoid alot of > explicit type casting without entering a maze of twisty typecasing > rules, all different. > > > Imagine we have a typing system where types are allowed to > automatically cast AS LONG AS NO INFOR

Re: Acceptable speeds (was Re: TIL redux (was Re: What will thePerl6 code name be?))

Most of the time, perl's performance is a total non-issue for me. When it is, I'm generally doing the same things as Dan (ie, things resembling dd if=/dev/hda | perl -e ...). I posted some vague benchmarky ideas to perl6-meta at one point. Here they are again: - You did ask at one point for

Re: my and local

Tom Christiansen wrote: > > As we sneak under the wire here, I'm hoping someone > has posted an RFC that alters the meaning of my/local. > It's very hard to explain as is. my is fine, but local > should be changed to something like "temporary" (yes, that > is supposed to be annoying to type) or

Re: RFC 12 (v2) variable usage warnings

Eric Roode wrote: > > Allow me to throw another log on the fire: > > my $x; > if (something) > { > $x = 1; > } > my $y = $x; > > This would give a compile-time warning under your RFC, warning the > user of a possibly uninitialized $x. Okay. Next: Yes. > my $x;

Re: RFC 12 (v2) variable usage warnings

Dave Storrs wrote: > > On Wed, 20 Sep 2000, Eric Roode wrote: > > > foo(); > > print $x; > > > > Generate a warning, or not? Which one? Remember, foo() may initialize $x. > > My suggest (FWIW) would be that, if there is no execution path > which leads to $x being defined in the

Re: RFC 12 (v2) variable usage warnings

Daniel Chetlin wrote: > > On Wed, Sep 20, 2000 at 07:20:44PM -0700, Steve Fink wrote: > > % perl -le '$x = 3; eval "\$x++"' > > (no warning issued) > > [~] $ perl -wle'$x = 3; eval "\$x++"' > Name "main::x" used only once: possible typo at -e line 1. Doh! Thanks.

Re: RFC 12 (v3) variable usage warnings

Michael Fowler wrote: > > Ok, at this point I'm trying to clear up misunderstandings. I believe you > know where I stand with relation to your RFC. Thanks, you caught several of my mistakes. > > On Wed, Sep 20, 2000 at 06:41:52PM -0700, Steve Fink wrote: >

Re: RFC 12 (v3) variable usage warnings

Eric Roode wrote: > > Steve Fink, via the Perl6 Librarian, wrote: > >=head2 EXAMPLE > > > >1 my ($x, $y, $z, $r); > >2 $z = 1; > >3 f(\$r); > >4 my $logfile = "/tmp/log"; > >5 $x = 1 if cond(); > >6 prin

Re: RFC 12 (v2) variable usage warnings

Tom Christiansen wrote: > > >Tom Christiansen wrote: > >> > >> >Anything else? Any opinion on whether eval "" should do what it does > >> >now, and be invisible for the purposes of this analysis; or if it should > >> >be assumed to instead both use and initialize all visible variables? The > >> >

Re: RFC 12 (v3) variable usage warnings

Tom Christiansen wrote: > > >Tom Christiansen wrote: > >> > >> >It happens when I don't bother to declare something. My company has > >> >several dozen machines with an 'our'-less perl, and 'use vars qw($x)' is > >> >a pain. As is $My::Package::Name::x. > >> > >> Far, far easier to fix behavioral

Re: RFC 12 (v3) variable usage warnings

Michael Fowler wrote: > > On Wed, Sep 20, 2000 at 05:20:54PM -0700, Steve Fink wrote: > > > $foobal = 3; > > > if (@ARGV) { > > > $foobar = @ARGV; > > > } > > > > > > print $foobar; > > > > >

Re: RFC 12 (v2) variable usage warnings

Tom Christiansen wrote: > > >Anything else? Any opinion on whether eval "" should do what it does > >now, and be invisible for the purposes of this analysis; or if it should > >be assumed to instead both use and initialize all visible variables? The > >former produces more spurious warnings, the

Re: RFC 12 (v3) variable usage warnings

Tom Christiansen wrote: > > >It happens when I don't bother to declare something. My company has > >several dozen machines with an 'our'-less perl, and 'use vars qw($x)' is > >a pain. As is $My::Package::Name::x. > > Far, far easier to fix behavioral problems than to hack Perl. > > --tom Not s

Re: RFC 12 (v3) variable usage warnings

Michael Fowler wrote: > > On Wed, Sep 20, 2000 at 03:25:11PM -0700, Steve Fink wrote: > > > > complains, but > > > > > > > > $x = 3; $x = 3 > > > > > > As it shouldn't; you've mentioned $x twice, which means you probably d

Re: RFC 12 (v3) variable usage warnings

> >Which is silly, because you shouldn't have to say '$x = $x = 3' when you > >mean '$x = 3'. Just because there's a real reason behind it doesn't make it > >any less silly. > > I'd like to see where this can happen. Sounds like someone forgot to > declare something: > > our $x; > $x =

Re: RFC 12 (v2) variable usage warnings

Tom Christiansen wrote: > > >Same thing. If $x is lexical, it gives a definite warning. If $x is a > >global, it says nothing. You're right; I need to point this out in the > >RFC. > > Careful: > > sub ouch { > my $x; > my $fn = sub { $x++ }; > register($fn); >

Re: RFC 12 (v2) variable usage warnings

Tom Christiansen wrote: > > And what about $$x? > > Dang, are we back to this incredible confusion about what it is to be > defined in Perl.? > > undef $a; > > That is now UNINITIALIZED. So is this: > > $a = undef; > > You have initialized it to undef. There is no reasonable differ

Re: RFC 12 (v3) variable usage warnings

Michael Fowler wrote: > > On Wed, Sep 20, 2000 at 07:45:16PM -, Perl6 RFC Librarian wrote: > > "VARIABLE used only once: possible typo" should be replaced with > > warnings on uses of uninitialized variables (including lexicals). > > > $x = 3 > > I don't understand, who's to say you didn't

Re: RFC 12 (v2) variable usage warnings

Eric Roode wrote: > > Steve Fink wrote: > >I am merely suggesting that the compiler detect, when it can, that > >you're trying to use the value of a variable without ever having > >assigned a value to that variable. And in THAT message, you had better > >know t

Re: RFC 12 (v2) variable usage warnings

Tom Christiansen wrote: > > >The warning for the use of an unassigned variable should be "use of > >uninitialized variable C<$x>". > > The problem with that idea, now as before, is that this check happens > where Perl is looking at a value, not a variable. Even were it possible > to arduously m

Re: RFC 226 (v2) Selective interpolation in single quotish context.

Nathan Wiger wrote: > > Andy Dougherty wrote: > > > > How do you turn it off? I want to keep a way to specify stuff without any > > interpolation whatsoever. I see the usefulness of this sort of quoting, > > but I also see the usefulness of being absolutely able to turn all > > interpolation off

Re: Conversion of undef() to string user overridable for easy debugging

> > This reminds me of a related but rather opposite desire I have had > > more than once: a quotish context that would be otherwise like q() but > > with some minimal extra typing I could mark a scalar or an array to be > > expanded as in qq(). > > I have wanted that also, although I don't remem

Re: types that fail to suck

Mark-Jason Dominus wrote: > > Maybe I should also mention that last week I had a dream in which I > had a brilliant idea for adding strong compile-time type checking to > Perl, but when I woke up I realized it wasn't going to work. What do you see as the major obstructions? eval "" isn't too ba

Re: $a in @b (RFC 199)

Jarkko Hietaniemi wrote: > > Allow me to repeat: instead of trying to shoehorn (or piledrive) new > semantics onto existing keywords/syntax, let's create something new. > The blocks of grep/map/... are special. They are not quite looping > blocks, they are not quite sub blocks, they are differen

Re: RFC 103 (v1) Fix print "$r->func" and $pkg::$var precedence

Nathan Wiger wrote: > > > Foo::Bar->stickysnort() > > Right, knew I forgot something... > > > I wonder whether the "I want to expand arbitrary expressions within > > strings even when there aren't any $ or @ symbols about" people > > just need better familiarity with the alternatives. > > This

Re: $a in @b

Damian Conway wrote: > >> Both are pretty much the same. Combining them, I'd say that exceptions >> should remain exceptional. > > I'd say short-circuiting a vector operation was exceptional enough. :-) I'd say it's exceptional sometimes, and very ordinary other times, and I'd prefer to

Re: $a in @b

Damian Conway wrote: > >> > I would propose that the C operation should short-circuit if the >> > block throws an exception, with the value of the expection determining >> > whether the final invocation of the block should accept the element it >> > was filtering: >> >> Ot

Quantum computing

Can't quite run perl yet. http://www.tomshardware.com/cpu/00q3/000901/index.html

Re: RFC 175 (v1) Add C keyword to force list context (like C)

> for reality here. That should be written more like: > > 1 while ; $burp = $.; > > or even: > > for ($burp = 0; my $line = ; $burp++) {} I'd go for my $burp = 0; $burp++ while ; > This proposal should be dropped. I read your message and agree. Not that I liked the

Re: RFC 110 (v3) counting matches

[redirected to perl6-language] Tom Christiansen wrote: > > Note the difference between > > my $var = func(); > > and > > my($var) = func(); > > Those are completely different in that they call func() in scalar > and list contexts. Why? Because of hte presence or absence of (), > of

Re: RFC 147 (v1) Split Scalars and Objects/References into Two Types

Tom Christiansen wrote: > > I happen to strongly appreciate that the invocant in > > $a->blah > > can be of either sort; that is: > > $a = "MyClass"; > $a->blah; > > or > > $a = MyClass->generate(); > $a->blah(); > > In fact, who knows what generate() returned? It could

Filtering rules

(Off-topic for this list, but I'm not sure where else to send it) Could we have a discussion somewhere of useful filtering rules for all these perl6 lists? Specifically, I'm looking to steal other people's .procmailrc snippets. I imagine that a lot of people have written their own, and everything

Re: Symbolic references, was Re: RFC 109 (v1) Less line noise - let's get rid of @%

Thanks! Ok, from a type inferencing perspective... Nathan Torkington wrote: > > Symbolic references are used for dynamic function generation: >foreach my $func (qw(red green blue)) { > *$func = sub { "@_" } >} Probably have to punt on checking user code in a main routine that does

Symbolic references, was Re: RFC 109 (v1) Less line noise - let's get rid of @%

(thread intentionally broken) Nathan Torkington wrote: > > Steve Fink writes: > > True. Would anyone mourn @$scalar_containing_variable_name if it died? > > I've never used it, and I'm rather glad I haven't. Perl5's -w doesn't > > notice $x

Re: RFCs (Re: Ideas that need RFCs?)

Jeremy Howard wrote: > > > Steve Fink writes: > > > And both those examples apply to the underpinnings. Ok, maybe I have an > > > unusually broad definition of the word "underpinnings". Think "anything > > > that can't be done with a p

Re: RFC 23 (v3) Higher order functions

Damian Conway wrote: > > It was simply attempting to explain why I choose to ignore what are (to > me, at least) trivial implementation issues, well documented in the > compiler literature. I choose to ignore them because I *have* to ignore > them or my brain is going to melt. So perhaps you sho

Re: Extended Regexs

Robert Mathews wrote: > > > James Mastros wrote: > > > [/f for fast DFA regexen] > Jeremy Howard wrote: > > The choice of algorithms is a great idea, but why do we need a modifier? > > Isn't it a pretty straightforward set of rules that allow us to decide if a > > DFA matcher will work? It would

Re: RFC 109 (v1) Less line noise - let's get rid of @%

Nathan Torkington wrote: > > Don't forget that the rationale behind the infix dereferencing is > this: > > @variable_name > @{variable_name} > @$scalar_containing_variable_name @$scalar_containing_value_ref > @{ code evaluating to variable name } @{ code giving value ref } True. Wou

Re: RFC 109 (v1) Less line noise - let's get rid of @%

"Casey R. Tweten" wrote: > > This looks counter intuitive, my brain says to dereference the reference at the > begining, just like you make the reference, in other words, keep it all the > same: > > $hashref->{key}->@ # Deref > $hashref->{key}->$ # Deref > $hashref->{key}->% # Deref > $hashref->

Re: RFCs (Re: Ideas that need RFCs?)

Nathan Torkington wrote: > > Steve Fink writes: > > We are NOT here to construct a radically better language. We are here to > > design the underpinnings of one. > > Perhaps. And by "perhaps", I mean "no". > > We're here to say what we&#x

Re: RFC 109 (v1) Less line noise - let's get rid of @%

Ted Ashton wrote: > > > all > > dereferencing can be done with ->. > > Is that "can be done with" or "must be done with"? > > Either way, I like the idea. To me it reads more smoothly, and as I seldom > dare to use the double-punctu

Re: RFC 109 (v1) Less line noise - let's get rid of @%

Damien Neil wrote: > > On Thu, Aug 17, 2000 at 03:10:44PM -0700, Steve Fink wrote: > > My proposal would be what I implemented for perl5 a while back (Sarathy > > didn't dislike it, but wasn't convinced enough to put it in): all > > dereferencing can be done wit

Re: Ideas that need RFCs?

Decklin Foster wrote: > > [replying from here since this is the only way I received it] > > > "Myers, Dirk" wrote: > > > > > > $line/pattern/ ; > > > > > /pattern/ ($line) ; > > I don't think these should be changed. Here's how I tend to pronouce > things: > > $x = 'foo'; #

Re: Ideas that need RFCs?

Nathan Wiger wrote: > > We're getting deluged with RFC's and emails. We should start thinking > "will this RFC or idea *add value* to Perl 6?". If not, and it just > makes something work differently, it _might_ not be worth an RFC. I disagree completely. For one thing, there's no such thing as P

Re: RFC 109 (v1) Less line noise - let's get rid of @%

Karl Glazebrook wrote: > > Ariel Scolnicov wrote: > > > > Karl Glazebrook <[EMAIL PROTECTED]> writes: > > > > [...] > > > > > o Why do I think perl has too much line noise? Because of code like this: > > > > > > @{$x->{$$fred{Blah}}}[1..3] > > > > This is indeed horrible. However, I fail to se

Re: RFC 109 (v1) Less line noise - let's get rid of @%

Ted Ashton wrote: > > > But the most direct way to measure how well the > > language slides into people's heads is by seeing how hard it is for them > > to get the hang of it. > > Nope. I've yet to be convinced that "fits in your head" is the same as > "went in easily". Hang

Re: Ideas that need RFCs?

(I'm assuming you intended this for perl6-language) "Myers, Dirk" wrote: > > > I certainly don't want m, > > tr, or s to go away (or /regex/ either.) But the =~ bothers me. How > > about disallowing m{...} and using m{expr}/.../? > > How about this, for the really compact way to do it: > >

Re: Ideas that need RFCs?

> On Thu, Aug 17, 2000 at 01:07:30PM -0400, Stephen P. Potter wrote: > > * Replace C, C, and C with equivalent regularized > > functions that take mulitple arguments instead of using specialized > > syntax. It would be best if the names could be more "complete", like > > match(), translate(

Re: RFC 109 (v1) Less line noise - let's get rid of @%

Ted Ashton wrote: > > Thus it was written in the epistle of Russ Allbery, > > > > This falls firmly in the category of things that are powerful for > > experienced users of the language but may be somewhat difficult to learn. > > I don't think Perl has being easy to learn as it's primary goal, no

Re: RFC 109 (v1) Less line noise - let's get rid of @%

Russ Allbery wrote: > > > All variables should be C<$x>. They should behave appropriately > > according to their object types and methods. > > No thanks. I frequently use variables $foo, @foo, and %foo at the same > time when they contain the same information in different formats. For > exampl

Re: RFC Archive

What about updating RFCs? Should I increment the version number and send each new revision to perl-rfc? Do I need to be careful about the RFC number when submitting updates? Also, I assumed the intention of the RFCs was to stimulate focused discussion and to keep a record of the decisions made du

Re: BiDirectional Support in Perl6

Steve Simmons wrote: > > By RTL, do you mean the intermediate representation used in the GNU > compiler family? If not, could you provide a pointer to the RTL you're > referring to? Acronyms are overloaded so easily... "Right To Left". This is the first I've seen it; RTL means many many other

Re: perl 6 requirements

"Randal L. Schwartz" wrote: > > > "Martyn" == Martyn Pearce <[EMAIL PROTECTED]> writes: > > Martyn> Possibly, although I must ask: since everything is up-for-grabs, I ask > Martyn> (without implying any feeling one-way-or-tother): > Martyn> How useful is the , operator in it's C-style statem

Re: RFC: variable usage warnings

Tom Christiansen wrote: > > >"symbol $main::x used only once" -> "use of uninitialized variable > >$main::x" > >"use of uninitialized value" -> "use of undefined value" > > Perhaps then > > "use of uninitialized value" -> "use of undef as discrete value" > or > "use of uninitialized val

Re: RFC: variable usage warnings

Updated RFC. --- =head1 TITLE variable usage warnings =head1 VERSION Maintainer: Steve Fink <[EMAIL PROTECTED]> for now Date: 2 Aug 2000 Version: 0.2 (unreleased) Mailing List: [EMAIL PROTECTED] Number: (unassigned) =head1 ABSTRACT "VARIABLE use

Re: RFC: variable usage warnings

Tom Christiansen wrote: > > >The warning message "use of uninitialized value" should also > >disappear, to be replaced with "use of undefined value", and the > >warning for the purpose described in this RFC should be "use of > >uninitialized variable C<$x>". > > What about if there's only an exp

RFC: variable usage warnings

Hey, this RFC stuff is fun! =head1 TITLE variable usage warnings =head1 VERSION Maintainer: Steve Fink <[EMAIL PROTECTED]> for now Date: 2 Aug 2000 Version: 0 (unreleased) Mailing List: [EMAIL PROTECTED] Number: (unassigned) =head1 ABSTRACT "VARIABLE used only once: po

Re: RFC: type inference

Ken Fox wrote: > > IMHO type inference is the best way to get typing into Perl. > We don't lose any expressiveness or hurt backwards compatibility. > About the only thing we need to make visible are a few additional > pragmas to enable type inference warnings. > > S

Re: type-checking [Was: What is 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

RFC: type inference

=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 b