Re: [perl6/specs] 761178: remove some some duplicate words words
On Tue, Sep 7, 2010 at 11:29 AM, Moritz Lenz wrote: > Brandon S Allbery KF8NH wrote: > > On 9/7/10 08:17 , nore...@github.com wrote: > >> Commit: 7611788411e5aff5f3ae150e2da9929ee546d6d8 > >> > http://github.com/perl6/specs/commit/7611788411e5aff5f3ae150e2da9929ee546d6d8 > > > > It was nicer when these contained the actual diffs like they used to, > > instead of forcing me to go poke at the tree. > > Indeed. Any contributions to restoring that behavior are very welcome. > I'm surprised anyone actually ever read the diff part of the message. I would prefer to never see that feature again. This has a link to the commit, which has a much better diff viewer than plaintext email (hello? 1997 called, they want their change notices back). It links to the actual change and even highlights the changes. Now I'll actually take a moment to sift through the changes. I vote to never see those diff emails ever again. In fact, if the diffs are brought back, I'll just subscribe to the commit feed and skip the email notice all together. -Jason
Re: Natural Language and Perl 6
On Sun, Aug 1, 2010 at 5:46 AM, Timothy S. Nelson wrote: >Hi. I'm wondering if any thought has been given to natural language > processing with Perl 6 grammars. > No specific tool is best suited for natural language processing. There was apparently a time in which everyone thought that a formal grammar could clearly define any natural language, but I don't think anyone succeeded at creating a complete formal grammar for any language other than something like Esperanto. Modern NLP seems to be focused on (empirical based) stochastic models or other statistical models. Most languages can be used to build and represent such systems. That being said, there are sub-fields where it might help, such as stemming, POS tagging, or text generation. Perl 6 grammars seem best suited to reduce the workload to build and manipulate parse trees or lattice models. Depending on what task is at hand, this may be of no use. I am finishing a masters in NLP and after all this work, p6 grammars wouldn't have helped much. -Jason "s1n" Switzer
Re: r31043 -[S32/Containers] Buf does Stringy, too
On Wed, Jun 2, 2010 at 5:10 AM, wrote:
> Author: masak
> Date: 2010-06-02 12:10:22 +0200 (Wed, 02 Jun 2010)
> New Revision: 31043
>
> Modified:
> docs/Perl6/Spec/S32-setting-library/Containers.pod
> Log:
> [S32/Containers] Buf does Stringy, too
>
> -class Buf does Positional {...}
> +class Buf does Positional does Stringy {...}
>
I never really thought about this, but now that I see it here, it made me
realize that how 'does' works seems verbose. I think we should be able to
specify a list instead of a bunch of 'does' statements. For example, the
above example should be written as
class Buf does Positional, Stringy { ... }
The repetitive 'does' statements is about as annoying as how you have to
specify public/private inheritance scoping for each class in C++. Even Java
gets this right:
http://en.wikipedia.org/wiki/Interface_(Java)#Defining_an_interface
Just an idea.
-Jason "s1n" Switzer
Re: Ideas for a "Object-Belongs-to-Thread" threading model (nntp: message 5 of 20)
On Thu, May 13, 2010 at 3:59 AM, wrote: > This should be a reply to Daniel Ruoso's post above, but I cannot persuade > my nntp reader > to reply to a post made before I subscribed here. Sorry > > And at the core of that, is the need for preemptive (kernel) threading and > shared memory. > > These can (and should!) be hidden from the application programmer, through > the use of language and/or library > level abstractions, of which there are many promising [sic] candidates. > > But fundamentally, they all require that: > >1) Preemptive scheduling be utilised. >2) The core interpreter be fully reentrant. >3) The core runtime libraries be fully reentrant. >4) That the language distinguishes between, and handles > appropriately, >- process-global entites: IO handles; environment; pwd etc. >- runtime stack-based(*) (lexical) entities: locals (my vars > in perl's terms). > I agree with this more than anything Daniel proposed. I prefer Perl 6 providing a thin interface to a kernel thread (i.e. NPTL), a means of creating shared memory objects between processes and threads, maintain reentrancy as per Buk's summary, and leave the rest for non-core modules. This allows for different threading, event, and shared memory models to emerge. You could then have different models, such as one that emulates Java's abandoned green thread model, something similar to POE, or something that emulates Erlangs process management. If you keep Buk's bullet points and give me a minimalistic interface to threads/shared memory, then it would allow me to create whatever wacky threading/shared memory model I can imagine. I think that's better than doing something that sounds dangerously similar to Java's RMI. -Jason "s1n" Switzer
Re: expression of seconds (was Re: A new era for Temporal)
On Fri, Apr 9, 2010 at 3:06 PM, Jonathan Worthington wrote: > Though even clearer and same number of characters as whole_seconds is: > > $dt.seconds.round This makes more sense to me than the first example you listed because when dealing with time measurement, I rarely think of seconds that are broken down to sub-measurements. Rather, I often think of seconds as an aggregation of milliseconds, so rounding the fraction (a second is internally a fraction of milliseconds) Just Makes Sense. The idea continues downwards to the smallest represented unit of time and upwards to the largest represented unit. -Jason "s1n" Switzer
Re: You never have privacy from your children in Perl 6
On Fri, Mar 26, 2010 at 7:16 AM, Carl Mäsak wrote: > You're using it wrong. You need to put 'trusts B;' in A in order for B to > > see A's privates. I hope it is obvious why this is the case. -- Darren > > Duncan > > Aye, my mistake. Apparently the syntax I used to try to get at the > private attribute would instead have called a private method. So much > for rooting things in the concreteness of an implementation. ;) I'm assuming Moritz is right in that Rakudo is currently leaky with private members (such as $!b in Masak's example), and I agree that truly private members has great value. It was unclear to me from the discussion so far whether this is the case for Perl 6. Also, this discussion of "trusts" piqued my interest; this sounds like a bad idea. Those of you who have worked extensively with C++ should bemoan "trusts" as much as friend classes. They break encapsulation for special cases, almost encouraging truly hideous object models that ultimately become purely public (painful on a large scale). I can't stress enough that if these are of similar nature, "trusts" should be removed. I'm all ears though if someone knows of a reason why they're more useful than onerous. -Jason "s1n" Switzer
Re: Gripes about Pod6 (S26)
On Fri, Feb 12, 2010 at 10:12 PM, Timothy S. Nelson wrote: > There's a school of thought, common among printing/publishing types, that >> insists that underline was intended solely to replace italics when they >> couldn't be represented (i.e. no fonts, as with ASCII terminals and >> printers). Thus Markdown's use of _italic_. (See also nroff.) >> > >I'm aware of that idea, and don't use underlining myself for that > reason. But since /italic/ looks like italic, and _underline_ looks like > underline, why are we using the thing that looks like underline for italics? > I mean, sure, I'm happy to get rid of _underline_ if that's what people > want, but using _ for italic is just ... well, I don't see any sense in it. If I recall correctly, this was a limitation of typewriters. Typewriters were incapable of displaying italics so underlining was taught as a replacement, though italics are/were considered the professional format. I somehow doubt that Markdown chose the _ for italics for that reason, though I will say that wayland's suggestion just makes more sense. -Jason "s1n" Switzer
Re: Interactive Perl 6 shell
On Mon, Dec 28, 2009 at 9:59 PM, Jason wrote: > > > *Connected by MOTOBLUR™ on T-Mobile > * > My phone accidentally sent an empty reply to this. What I was supposed to reply with was information regarding the built-in Rakudo REPL. You can see it in action here: http://perl6advent.wordpress.com/2009/12/01/day-1-getting-rakudo/ Sorry about that empty reply. -Jason Switzer
Re: Interactive Perl 6 shell
Connected by MOTOBLUR™ on T-Mobile -Original message- From: Juan Madrigal To: perl6-language@perl.org Sent: Tue, 29 Dec 2009 03:41:50 GMT+00:00 Subject: Interactive Perl 6 shell Does Perl6/Rakudo have an interactive perl shell like ruby does with irb? http://en.wikipedia.org/wiki/Interactive_Ruby_Shell Would be great for trying out the new syntax quickly. A Perl 6 TextMate bundle and Panic Coda plugin would be great too! Thanks! Juan
S19 questions
I was reading over S19 and had a few questions.
1) The colon delimiter (":name") is specified but no options are declared to
use it specifically. It's not clear why we would need this delimiter on top
of the other more popular delimiters. Are the long form (double dash), meta
syntax form (double plus), and short form (single dash) delimiters
insufficient?
2) The format for negative boolean options ("--/name" and "-/n" but not
"++/NAME") seems fairly non-standard in Unix AFAIK. This strikes me as a bit
awkward and I have been pondering if there is anything better. Maybe all
boolean options should default to false, making this format unnecessary?
3) Why have --verbose-config and not just --verbose?
4) The default is to always enable warnings (similar to the deprecated -w).
I would imagine warnings should be enabled, not disabled, similar to perl5,
GCC, python, and lots of other compilers/interpreters.
-Jason "s1n" Switzer
Re: Rukudo-Star => Rakudo-lite?
Since I don't know anything about nuclear power plants, I think the BikeShed should be painted blue and called "Rakudo Whatever" or just "Rakudo". -Jason "s1n" Switzer
[Invitation] June Dallas.p6m Meeting @ Tue Jun 9 7pm – 10pm (perl6-language@perl.org)
BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VEVENT DTSTART:20090610T00Z DTEND:20090610T03Z DTSTAMP:20090605T035152Z ORGANIZER;CN=jason switzer:mailto:jswit...@gmail.com UID:g3rsts66avsaacp817n7ri1...@google.com ATTENDEE;CUTYPE=GAIA_GROUP;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=Dallas.p6m;X-NUM-GUESTS=0:mailto:dallas...@googlegroups.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;cn=perl6-langu...@perl.org;X-NUM-GUESTS=0:mailto:perl6-langu...@perl.o rg ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE ;CN=jason switzer;X-NUM-GUESTS=0:mailto:jswit...@gmail.com CLASS:PRIVATE CREATED:20090605T035151Z DESCRIPTION:Hello All!We are planning on having another Dallas.p6m meeting soon. We are meeting next week (Tuesday\, June 9th 7:00PM) at a coffee shop with free wifi. The address is \;985 W Bethany Dr Allen\, TX 75013 (Pete's Coffee inside the Market Street).\n\nThis is a pre-YAPC|10 meeting\, so the agenda will b e focused around recent Perl 6 advancements and YAPC. Since the group is ju st beginning\, all agenda plans are tentative and are open to changes. We'r e also looking for speakers and presentations\, locals only (no travel fund ing yet).Also\, since this will be our third meeting\, I have start ed a Google Group (possibly temporary) to help filter any future group traf fic from pestering the Perl 6 mailing list. The direct invitees from last m onth's meeting have been automatically added. The group is open to anyone w ho wants to join.Everyone is invited to come and have a good time. See you there!-Jason "s1n" Switzer\n\nView your event at http://www.google.com/calendar/event?action=VIEW&eid=ZzNyc3Rz NjZhdnNhYWNwODE3bjdyaTFuMmcgcGVybDYtbGFuZ3VhZ2VAcGVybC5vcmc&tok=MTgjanN3aXR 6ZXJAZ21haWwuY29tNmRiNDU1ODk3YTMyZmI2ZjNlYjY4ZTQwNGQ1YmFiOTExMDgzNzRjYQ&ctz =America%2FChicago&hl=en. LAST-MODIFIED:20090605T035151Z LOCATION:985 W Bethany Dr Allen\, TX 75013 (Pete's Coffee inside the Market Street.) SEQUENCE:0 STATUS:CONFIRMED SUMMARY:June Dallas.p6m Meeting TRANSP:OPAQUE END:VEVENT END:VCALENDAR invite.ics Description: application/ics
June Dallas.p6m Meeting
BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VEVENT DTSTART:20090610T00Z DTEND:20090610T03Z DTSTAMP:20090605T035153Z ORGANIZER;CN=jason switzer:mailto:jswit...@gmail.com UID:g3rsts66avsaacp817n7ri1...@google.com ATTENDEE;CUTYPE=GAIA_GROUP;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=Dallas.p6m;X-NUM-GUESTS=0:mailto:dallas...@googlegroups.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;cn=perl6-langu...@perl.org;X-NUM-GUESTS=0:mailto:perl6-langu...@perl.o rg ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE ;CN=jason switzer;X-NUM-GUESTS=0:mailto:jswit...@gmail.com CLASS:PRIVATE CREATED:20090605T035151Z DESCRIPTION:Hello All!We are planning on having another Dallas.p6m meeting soon. We are meeting next week (Tuesday\, June 9th 7:00PM) at a coffee shop with free wifi. The address is \;985 W Bethany Dr Allen\, TX 75013 (Pete's Coffee inside the Market Street).\n\nThis is a pre-YAPC|10 meeting\, so the agenda will b e focused around recent Perl 6 advancements and YAPC. Since the group is ju st beginning\, all agenda plans are tentative and are open to changes. We'r e also looking for speakers and presentations\, locals only (no travel fund ing yet).Also\, since this will be our third meeting\, I have start ed a Google Group (possibly temporary) to help filter any future group traf fic from pestering the Perl 6 mailing list. The direct invitees from last m onth's meeting have been automatically added. The group is open to anyone w ho wants to join.Everyone is invited to come and have a good time. See you there!-Jason "s1n" Switzer\n\nView your event at http://www.google.com/calendar/event?action=VIEW&ueid=g3rsts6 6avsaacp817n7ri1n2g. LAST-MODIFIED:20090605T035151Z LOCATION:985 W Bethany Dr Allen\, TX 75013 (Pete's Coffee inside the Market Street.) SEQUENCE:0 STATUS:CONFIRMED SUMMARY:June Dallas.p6m Meeting TRANSP:OPAQUE END:VEVENT END:VCALENDAR invite20090609T19.ics Description: application/ics
Re: Module naming conventions
On Mon, Jun 1, 2009 at 7:50 PM, Jon Lang wrote: > On Mon, Jun 1, 2009 at 5:44 PM, Daniel Carrera > wrote: > > I think we might need to come up with some sort of standard naming > > convention to distinguish dependencies. Something that the *user* can > > recognize quickly when he browses CPAN. > > Why do we need the dependencies to be part of the name? Perl 6 > provides a rugged versioning system for its modules; we should use it. I agree entirely with Jon. This sounds like a fruitless idea and outside the scope of the language. The only idea that I would give any consideration to would be to extend the versioning metadata to allow for the user to define new metadata. That sounds too similar to the goals of XML, but it would at least allow the community to define what metadata is important. Some things are best left unsaid. -Jason "s1n" Switzer
use v5 Support
I want to pose the same question for clarification that I asked #perl6: S01 says that perl5 code will be supported via "use v5". Can someone confirm that embedded perl5 code is still required of any valid implementation? If so, how will XS code be supported? Will the namespace between v5 code and v6 be shared? Will this be accomplished by linking libperl or libperl++ (if completed)? From what I've heard, there are issues with using libperl. This seems like a heavy burden for each implementation to bear. I want to propose another idea (that seems better to me at least). This sounds like a good place where a user module could create a perl5 grammar (a version of STD.pm). I'm not too familiar with how the perl6 STD.pm works, but I've heard there were efforts to attach actions to its YAML output, similar to how Parse::RecDescent does in perl5 to yacc-like grammars. That may be a bit naive, but someone pointed this section out to me and it raised a ton of questions. -Jason "s1n" Switzer
Re: Logo considerations
On Tue, Mar 24, 2009 at 3:10 PM, James Fuller wrote: > Is there any sponsorship money to spend on a very good graphic > designer to create something based on a small list of requirements as > to what meaning it should convey ? > I would agree; have a professional do it and we'll probably get better results. > Of course the logo should represent the community fundamentally, but I > find all of the suggestions little to do with addressing needs of a > logo versus needs of what I would call more of a 'club' badge. Having said that here's my idea: Basically, the perl community has largely adopted TIMTOWTDI as a philosophy (as well as DWIM, but that's harder to model). For that, a cluster of arrows in different directions seems fitting: http://3.bp.blogspot.com/_yy_uiqKCf0Q/RcEfrHZ_0hI/AB8/Mk1xayjGaSQ/s1600-h/arrows3.jpg http://www.sxc.hu/photo/1060296 http://www.sxc.hu/photo/659267 I personally like the idea of the last one (retains geek cred). [warning: light-hearted humor ahead] There's also the notion that perl6's scope has creeped to accommodate a large enough set of ideas. Seems like an appropriate logo: http://images.google.com/images?gbv=2&hl=en&q=kitchen+sink -Jason "s1n" Switzer
Re: r25490 - docs/Perl6/Spec
On Sun, Feb 22, 2009 at 9:47 PM, wrote: > Added: docs/Perl6/Spec/S28-special-variables.pod > === > +=head2 Named variables (see S02): > +$?OS # operating system compiled for > +$*OS # operating system running under > +$?OSVER# operating system version compiled for > +$*OSVER# operating system version running under How are you possibly going to get this in a remotely portable basis? How could an implementation handle the case of compiling a perl6 script down to native binary? Would the native binary always report the same OS and OSVER no matter where it executes after turned into a binary? > > +$?PACKAGE # current package (as object) > +@?PACKAGE # current packages > +$?PACKAGENAME # name of current package (see S10) $?PACKAGENAME seems kind of redundant when I could similarly do a $?PACKAGE.perl to get a coderef back as well. In fact, all of the variables that are named version of the coderef version should probably be removed in the favor of something like ~$?FOO or ~$*FOO. > > +$*PROGRAM_NAME # name of the program being executed > How does this differ from $*EXECUTABLE_NAME? > +$?PUGS_VERSION # Pugs version (not canonical) > +$*PUGS_HAS_HSPLUGINS # True if Pugs was compiled with support for > hsplugins > + # (not canonical) How do these apply to anything other than a single specific implementation? What motivation would Rakudo or elf have for defining these? > +&?ROUTINE # current sub or method (itself, see S06) > +@?ROUTINE # current subs or methods (themselves) > I'm sure this is a typo for $?ROUTINE. Besides, I think $?SUB makes more sense. > + > + $*OSNAME ...or some such > + $^O $OSNAME > + Doesn't correlate with the list above. > + > + $* and $# have been deprecated half of forever and are gone. $[ > + is a fossil that I suppose could turn into an evil pragma, if we > + try to translate it at all. (Frees up * twigil for $*FOO syntax.) I'm not even sure this makes sense to me. Is this saying that $* and $# are largely not in use anymore (in perl6)? -Jason "s1n" Switzer
Re: RFD: Built-in testing
On Fri, Jan 23, 2009 at 6:39 PM, Dave Whipp wrote:
> A spec-test is (or should be) different from an ad-hoc test. I want to be
> able to say "test S09.237 passes on pugs but not on Rakudo" (perhaps with a
> nicer name). Unique identifiers allow comparisons of specific tests across
> multiple implementations, and over time. It is possible to derive IDs using
> line numbers (perhaps block-relative), but that's only a good idea if the
> test suite is reasonably stable (and it requires tool support).
>
That sounds useful on the surface but often turns out to be more difficult
to do than you might think. There are many cases where tests are performed
from within loops. Something like S09.237 may or may not be in a loop, may
be difficult to identify in files with many tests. This sort of test name
could be the test message output by Test.pm's verbose output, but it then
makes the verbose output virtually useless in that Test.pm could just keep
records of the test numbers instead. There can also be multiple tests per
single line of code, especially if provided as an adverb, such as :ok
Test labels seems like an aspect that is highly susceptible to bit-rot due
to the ever evolving nature. Given the multitude of things that can go wrong
trying to keep records, it might not be a good idea to focus on this.
Rather, it might be a good idea to have the language provide a base test and
a means to extend the test. This would allow for the tests previously
written to transparently change the back-end testing mechanism.
Here's a very crude example. Lets say that ok() is defined by the Core (and
thus the language):
multi sub ok(Bool $test, Str $msg) { if $test { say "ok $msg" } else { say
"not ok $msg" } }
Then let's say I don't want the default (psuedo)-tap test output, I could
redefine what ok() does:
multi sub ok(Bool $test) { say "A test has failed at some point somewhere"
if $test }
ok(?($x == 4), "no good has come of this"); #calls Core's ok()
ok(?($x == 2)); #calls my crappy ok()
That's just an example to show that the language could provide a basic
version that is extensible with various implementations and various
compilers such that I don't have to write constantly unique test names (or
poorly identified names) and still only have to write a test once.
-Jason "s1n" Switzer
Re: RFD: Built-in testing
On Thu, Jan 22, 2009 at 4:51 PM, jerry gay wrote:
> $x == $y
>:ok({ .true ?? 'message' !! 'failure message' })
>:diag( 'tap comment', :some_tap_property)
I just want to stress again that I would like to see no focus on just tap
emitters. While I realize this is just an example, adverbs that apply to a
specific emitter would not be my preference. Extensible emitters would allow
integrators the opportunity to mix perl6 tests in with perl5 tests and xUnit
tests (for easily integrated test reports).
-Jason "s1n" Switzer
Re: RFD: Built-in testing
On Tue, Jan 20, 2009 at 1:08 PM, Moritz Lenz wrote:
> So Larry and Patrick developed the idea of creating an
> adverb on the test operator instead:
>
>$x == 1e5 :ok('the :ok makes this is a test');
>
> This is an adverb on the infix:<==> operator, and might
> desugar to something like this:
>
> multi sub infix:<==>($left, $right, :$ok) {
>$*TEST_BACKEND.proclaim($left == $right, $ok)
>or $*TEST_BACKEND.diag(
>"Got: «$left.perl()»; Expected: «$right.perl»");
> }
>
> (Daniel Ruoso also proposed to call the adverb :test
> instead of :ok, making it easier to read but a bit
> longer; my happiness doesn't depend on the exact name,
> but of course we can discuss it once we have settled
> on this scheme, if we do so).
I like this idea and with it built into the language itself, there will be
much less of an excuse to skip testing. I like the adverb form, which seems
more perl6 than C. Naming it something like :test is a better idea than :ok
as that seems a bit more direct.
There isn't much in the spec concerning namespaces, other than the default *
namespace. Is there any reason why the testing framework can't go in it's
own namespace?
> * We nearly double the number of built-in operators
> by adding an :ok multi
> * We force implementors to handle operator adverbs
> and named arguments very early in their progress
> (don't know how easy or hard that is)
> * Testing of operators becomes somewhat clumsy. If you
> * want to test infix:<==>, you won't write
> '2 == 2 :ok("== works")', because you test a
> different multi there. Instead you'd have to write
> something like '?(2 == 2) :ok("== works")', where
> :ok is an adverb on prefix:.
>
These are mostly disadvantages to implementors, not users of the testing
framework. I'd rather the implementations struggle to implement a built-in
testing functionality than users of the language struggle to use the
built-in testing.
> I'll send another mail on the subject of pluggable
> testing backends in order to allow different emitters
> (TAP output, storage into databases, whatever)
This is a requirement for me. Having only TAP emitters may not integrate
well. It would be nice if the spec, if added, would allow flexibility in
this realm. I would actually like to see a flexible system that allowed me
to define a new emitter, say for the cases where you want to integrate perl6
testing into an existing testing framework (think automated builds and
tests).
-Jason "s1n" Switzer
Re: design of the Prelude (was Re: Rakudo leaving the Parrot nest)
On Thu, Jan 15, 2009 at 8:59 PM, Jon Lang wrote: > OK, then. If I'm understanding this correctly, the problem being > raised has to do with deciding which language features to treat as > primitives and which ones to bootstrap from those primitives. The > difficulty is that different compilers provide different sets of > primitives; and you're looking for a way to avoid having to write a > whole new Prelude for each compiler. Correct? > > Note my use of the term "language features" in the above. Presumably, > you're going to have to decide on some primitive functions as well as > some primitive datatypes, etc. For instance: before you can use > meta-operators in the Prelude, you're going to have to define them in > terms of some choice of primitive functions - and that choice is > likely to be compiler-specific. So how is that any easier to address > than the matter of defining datatypes? Or is it? Did I miss something here? I've never heard Prelude. I'm not really convinced that each implementation should have a large set of shared code; that seems contrary of the idea of having independent implementations. Having to support a common set of implemented classes like this may end up being more of a burden than a benefit. You may find each implementation replacing parts of the Prelude to serve their needs. It also seems like that Prelude.pm is dated and also very pugs specific, which is ironic. What are all the references to Pugs::Internals and pugs_internals_m:perl5? Is rx:Perl5 and rd:P5 valid perl6? I'm skeptical of the this idea unless someone can convince me otherwise. -Jason "s1n" Switzer
Re: [PATCH] Add .trim method
On Mon, Jan 12, 2009 at 6:26 PM, Ovid wrote: > - Original Message > > > From: jason switzer > > > If we wanted language dependent version, use :leading, :trailing, and > :both. > > That will require each implementation properly handle the language > > variations. > > I think :start and :end are my favorites. Huffman++ (maybe :begin and :end > for consistency?). My best advise is to keep it consistant. .chomp makes references to chomping from the end, not the trailing. .substr makes reference to start. I think that's better to just find terminology that has already been agreed upon and keep abusing it.
Re: Not a bug?
On Mon, Jan 12, 2009 at 3:54 PM, Larry Wall wrote:
> On Mon, Jan 12, 2009 at 01:19:12PM -0800, Jon Lang wrote:
> : As well, isn't there a way to escape a character that would otherwise
> : be interpolated? If the intent were as you suppose, the original
> : could be rewritten as:
> :
> : $ perl6 -e 'my $foo = "foo";say "\{" ~ $foo ~ "}"'
>
> Sure, though in any case I'd probably prefer:
>
>$ perl6 -e 'my $foo = "foo"; say Qs/{$foo}/'
>
> : (Or would you need to escape the closing curly brace as well as the
> : opening one?)
>
> Not unless something outside of it all was attempting to count braces.
> But the P6 parser has sworn off all such activities for P6-derived
> code. Parsing something first as a string and then again as some
> other language is generally looked upon as a Bad Plan these days.
>
> Which is, of course, why "{" is a problem now. Perhaps use of nested
> double quotes deserves a warning.
>
masak++ was right, if you use single quotes it works properly. Here's how
you do it from a bash prompt:
$ ./perl6 -e 'my $foo = '\''foo'\''; say '\''{'\'' ~ $foo ~ '\''}'\'' '
{foo}
Notice the overly redundant single-quotes; in fact, all of those quotes are
single quotes.
-Jason "s1n" Switzer
Re: [PATCH] Add .trim method
On Mon, Jan 12, 2009 at 9:07 AM, jesse wrote: > > 'left' and 'right' are probably not the right names for functions which > trim leading and/or trailing space, since their meanings get somewhat > ambiguous if a language renders right-to-left instead of left-to-right > or vice-versa > I'm in favor of using the proposed syntax, but I will agree with lwall that it seems like overkill to have the specialized trims. .trim should be non-destructive and .=trim should be destructive (these seems intuitive). Some languages run in the direction of left-to-right, some in the direction right-to-left (some even top-to-bottom). No matter what language you speak or which direction your native language reads, left is the same for everyone as well as right. If we wanted to simplify matters, use :left, :right and :both. Those have the same meaning everywhere. If we wanted language dependent version, use :leading, :trailing, and :both. That will require each implementation properly handle the language variations. By the way, good work on this. Everyone loves useful string functions. -Jason "s1n" Switzer
Re: r24737 - docs/Perl6/Spec
On Fri, Jan 2, 2009 at 8:12 PM, Geoffrey Broadwell wrote: > On Fri, 2009-01-02 at 12:27 -0800, jerry gay wrote: > > oh, yes, whoops! i responded to someone else in #pugs earlier, and > > forgot to address the item here. C replaces p5's > > C (that's the latest idea from damian, although it seems not > > to be published yet). > > Ah, I get it! What about perldoc's special modes? Will these go in > ++DOC ... ++/DOC sections? Jerry mentioned in IRC that he intends on documenting the metasyntax options more. I'm guessing this is sort of a special meta argument given perldoc's modes, so it should probably be documented there. I would like to raise the question of whether implementations must be required to fully parse/present perldoc or just recognize it's presence. This would allow for POD "fluffers" like pod2html and for streamlined perl6 implementations to skip things like --doc. -Jason "s1n" Switzer
Re: Working with files wish list
On Mon, Dec 15, 2008 at 6:59 PM, Leon Timmermans wrote:
> On Mon, Dec 15, 2008 at 6:42 PM, jason switzer wrote:
> > It's lazy and kinda cheating, but for small simple tasks, it gets the job
> > done. I'm not up to speed with the IO spec, but a sort of auto-slurp
> > functionality would be nice. Something to the effect:
> >
> > @data = :slurp("mydatafile.txt");
>
> A slurp() function has been specced to slurp a file into a string, as
> well as a lines() function that does the same into an array of lines.
>
Okay, that's good to know.
> You didn't get the point of my Roles idea. It should not be added to a
> role File, but to the Role Nameable, which would be composed into
> whatever implements file filehandles, but for example also into Unix
> sockets. IMNSHO interfaces and implementation should be kept separate
> to maintain a proper abstraction level.
>
I hadn't seen a Nameable role mentioned yet, so I wasn't able to understand
any such concept. That is a good idea, but the idea is so general that
anything can be nameable and thus the specificity of the role could quickly
become lost. I was suggesting specific naming functionalities be added to
the File role. If you want to abstract that, that's fine, but beware that
something like Nameable can be too broad of a role (maybe just IONameable?).
> You can already easily mix it in using 'does':
>
> $fstab = open('/etc/fstab', :r);
> $fstab does WhitespaceTrim;
>
> I don't think it's really necessary to include that into open(),
> though it might be useful syntactic sugar.
I haven't spent the time to understand mix-ins yet, but this does look like
a feasible (clean) idea. However, how do you specify one/more filters? For
example, say you want to :rw a file. How can you provide an input filter and
an output filter (or multiples of either)? Can you layer filters if done
with mix-ins? If so, how do you specify direction?
-Jason "s1n" Switzer
Re: Working with files wish list
readed applications. > Perhaps, too a module for a specific environment, eg., Windows, would > provide the syntatic sugar that makes specifying a location look like > specifying a directory natively, eg. > use IO::Windows; > my Location $x .= new(:OSpath); > whilst for linux it would be > use IO::Linux; > my Location $x .=new(:OSpath); This looks like a good start to the whole file path issue discussed above but gets too OS specific. I think things like FUSE and Samba on linux could throw a real curveball into that but I'm not sure how much latitude the kernel gives file systems and userspace applications the power to change the default naming scheme (i.e. if / can be changed to \). -Jason "s1n" Switzer
Re: Split with negative limits, and other weirdnesses
It makes sense to me to go with option 1; you get what you ask for. It also
makes sense to make to not use magical implied numbers, such as negatives,
to accomplish things that either ranges or whatever star can accomplish.
Just my 2 cents.
-Jason "s1n" Switzer
On Tue, Sep 23, 2008 at 4:27 AM, Moritz Lenz <[EMAIL PROTECTED]>wrote:
> Today a patch to rakudo brought up the question what split() should do
> if the $limit argument is either zero or negative.
>
> In Perl 5 a negative limit means "unlimited", which we don't have to do
> because we have the Whatever star. A limit of 0 is basically ignored.
>
> Here are a few solution I could think of
> 1) A limit of 0 returns the empty list (you want zero items, you get them)
> 2) A limit of 0 fail()s
> 3) non-positive $limit arguments are rejected by the signature (Int
> where { $_ > 0 })
>
Re: explicitly declare closures???
Says Dave Mitchell:
> Closures ... can also be dangerous and counter-intuitive, espcially to
> the uninitiated. For example, how many people could say what the
> following should output, with and without $x commented out, and why:
>
> {
> my $x = "bar";
> sub foo {
> # $x # <- uncommenting this line changes the outcome
> return sub {$x};
> }
> }
> print foo()->();
>
That is confusing, but it is not because closures are confusing. It
is confusing because it is a BUG. In Perl 5, named subroutines are
not properly closed.
If the bug were fixed, the result would be 'bar' regardless of whether
or not $x was commented.
This would solve the problems with mod_perl also.
The right way to fix this is not to eliminate closures, or to require
declarations. The right way to fix this is to FIX THE BUG.
Re: Please make "last" work in "grep"
On (03 May 2001 10:23:15 +0300) you wrote:
> Michael Schwern:
> >
> > Would be neat if: my($first) = grep {...} @list; knew to stop itself, yes.
> >
> > It also reminds me of mjd's mention of: my($first) = sort {...} @list;
> > being O(n) if Perl were really Lazy.
>
> But it would need a completely different algorithm.
Not precisely. If you have lazy evaluation, then quicksort is exactly
what is wanted here. For example, if you implement qsort in the
straightforward way in Haskell, and write
min = first quicksort list;
then it *does* run in O(n) time; in this case qucksort reduces to
Hoare's algorithm for min.
> my ($first, $second, $third) = sort {...} @list;
The Haskell version of this also runs in O(n) time.
> is kind-of plausible. So we'd definitely want
>
> ((undef)x((@list+1)/2), $median) = sort {...} @list;
The Haskell equivalent of this (still using quicksort) runs in O(n log
n) time, which I believe is optimal for finding the median.
Re: Schwartzian Transform
> So you can say
>
> use Memoize;
> # ...
> memoize 'f';
> @sorted = sort { my_compare(f($a),f($b)) } @unsorted
>
> to get a lot of the effect of the S word.
Yes, and of course the inline version of this technique is also
common:
@sorted = sort { my $ac = $cache{$a} ||= f($a);
my $bc = $cache{$b} ||= f($b);
my_compare($ac,$bc);
} @unsorted;
Joseph Hall calls this the 'Orcish Maneuver'.
However (I don't know who suggested this, but:)
> > > > >I'd think /perl/ should complain if your comparison function isn't
> > > > >idempotent (if warnings on, of course). If nothing else, it's probably an
> > > > >indicator that you should be using that schwartz thang.
I have to agree with whoever followed up that this is a really dumb
idea. It reminds me of the time I was teaching the regex class at
TPC3, and I explained how the /o in
/$foo/o
represents a promise to Perl that $foo will never change, so Perl can
skip the operation of checking to see if it has changed every time the
match is performed. Then there was a question from someone in the
audience, asking if Perl would emit a warning if $foo changed.
On the other side of the argument, however, I should mention that I've
planned for a long time to write a Sort::Test module which *would*
check to make sure the comparator function behaved properly, and would
report problems. When you use the module, it would make all your
sorts run really slowly, but you would get a warning if your
comparator was bad.
Idempotency is not the important thing here. The *important* property
that the comparator needs, and the one that bad comparators usually
lack is
if my_compare(a,b) < 0, and
my_compare(b,c) < 0, then it should also be the case that
my_compare(a,c) < 0
for all keys a, b, and c.
Sort::Test would run a quadratic sort such as a bubble sort, and make
sure that this essential condition held true. Note in particular that
if the comparator has the form { my_compare(f(a),f(b)) }, then it does
not matter if f() is idempotent; what really matters is that
my_compare should have the property above.
I had also planned to have optional checks:
use Sort::Test 'self';
(Make sure that my_compare(a,a) == 0 for all a)
use Sort::Test 'twice';
(Make sure that my_compare(a,b) == my_compare(a,b) for all a,b)
This last is essentially the idempotency restriction again. The
reason I've never implemented this module is that in perl 5, sort()
cannot be overridden, so the usefulness seemed low; you would have to
rewrite your source code to use it. I hope this limitation is fixed
in perl 6, because it would be a cool hack.
Finally, another argument in the opposite direction yet again. It has
always seemed to me that this 'inconsistent sort comparator' thing is
a tempest in a teapot. In the past it has gotten a lot of attention
because some system libraries have a qsort() function that dumps core
if the comparator is inconsistent.
To me, this obviously indicates a defective implementation of
qsort(). If the sort function dumps core or otherwise detects an
inconsistent comparator, it is obviously functioning suboptimally. An
optimal sort will not notice that the comparator is inconsistent,
because the only you can find out that the comparator is returning
inconsistent results is if you call it in a situation where you
already know what the result should be, and it returns a different
result. An optimal sort function will not call the comparator if it
already knows what the result should be!
For example, consider the property from above:
if my_compare(a,b) < 0, and
my_compare(b,c) < 0, then
my_compare(a,c) < 0.
If the qsort() already knows that a
Re: RFC 208 (v2) crypt() default salt
Bart Lateur: > >If there are no objections, I will freeze this in twenty-four hours. > > Oh, I have a small one: I feel that this pseudo-random salt should NOT > affect the standard random generator. I'll clarify: by default, if you > feed the pseudo-random generator with a certain number, you'll get the > same sequence of output numbers, every single time. There are > applications for this. I think that any call to crypt() should NEVER > change this sequence of numbers, in particular, it should not skip a > number every time crypt() is called with one parameter. > > Therefore, crypt() should have it's own pseudo-random generator. A > simple task, really: same code, but a different seed variable. I had considered this for the original RFC, but I decided against it. To implement it, Perl would have to have its own built-in random number generator, because there is no way to save and restore the old state of rand() (for example). It would substantially complicate the code. And the problem you describe is not really a problem. There has never been any guarantee that a program would produce the same sequence of random numbers after a change to the Perl binary. More recent versions of Perl use random() or drand48() if they are available, instead of rand(). A program run under an old version of Perl and then a newer version that used random() instead of rand() would generate a different sequence of random numbers depending on which version of Perl was running it, even if the seed was the same. This has never been an issue in the past, so I did not consider it important. I will add a note aboput this to the RFC. If there are no other comments, I will freeze it in 24 hours.
RFC255: Fix iteration of nested hashes
> This RFC proposes that the internal cursor iterated by the C function
> be attached to the instance of C (i.e. its op-tree node),
In the past, this has been a mistake, because it breaks the identity
of closures. For example, with your proposal, the following code,
which works now, will no longer work at all:
%a = ...;
%b = ...;
sub make_iterator {
my $hashref = shift;
return sub { each %$hashref }
}
my $a_iterator = make_iterator(\%a);
my $b_iterator = make_iterator(\%b);
for (1 .. 100) {
push @a, $a_iterator->();
push @b, $b_iterator->();
}
We want to get the data from %a into @a, and the data from %b into @b.
With your proposal, this code must fail. The most likely failure mode
is that you get 100 copies of %a's first key and value in @a, and 100
copies of %b's first key and value in @b.
The code fails because you said to attach the iterator state to the op
node, and there is only a single op node here. Unless that op node
has room for an arbitrarily large number of states, the call to
$b_iterator->() is going to destroy the iterator information that was
saved during the call to $a_iterator->().
The solution to this is that the iterator state should be stored in
the pad for the block in which the each() appears. The op node can
hold the index of this pad element. Since the two closures do not
share pads, the code will continue to work.
So your proposal can be saved, but it needs to be fixed.
Mark-Jason Dominus [EMAIL PROTECTED]
I am boycotting Amazon. See http://www.plover.com/~mjd/amazon.html for details.
Re: 'eval' odd thought
Bart Lateur: > If your P5->P6 translator is slow, i.e. written > in Perl, this would imply a pretty big performace hit. It is better for translated programs to do the right thing slowly than to do the wrong thing as quickly as possible. > What would help is a debugging mode that prints out the > converted code string, This is such a debugging mode. The translated script will run properly and do the right thing without intervention, although it may run slowly. The programmer can modify the perl5_eval code so that it issues a warning or calls 'die' or whatever. The programmer can also examine the occurrences of 'perl5_eval' in the source code to decide whether they can be converted immediately to plain 'eval'. Once all the appearances of perl5_eval have been replaced, the translator is no longer needed. Mark-Jason Dominus [EMAIL PROTECTED] I am boycotting Amazon. See http://www.plover.com/~mjd/amazon.html for details.
Re: 'eval' odd thought
> eval should stay eval. Yes, and this is the way to do that. When you translate a script, the translator should translate things so that they have the same meanings as they did before. If it doesn't also translate eval, then your Perl 5 scripts will be using the Perl 6 eval, which isn't what you wanted.
Re: RFC 226 (v1) Selective interpolation in single quotish context.
> > One could for example have a pragma to *really* tag variables
> > lexically to be expanded within singlequotes.
Or a pragma that simply changes the semantics of q{...} so that it has
the proposed feature for the rest of the scope of the current block.
'eval' odd thought
The perl 5 -> perl 6 translator should replace calls to 'eval' with calls to 'perl5_eval', which will recursively call the 5->6 translator to translate the eval'ed string into perl 6, and will then eval the result. Mark-Jason Dominus [EMAIL PROTECTED] I am boycotting Amazon. See http://www.plover.com/~mjd/amazon.html for details.
Re: RFC 226 (v1) Selective interpolation in single quotish context.
> seconded by Mark-Jason Dominus <[EMAIL PROTECTED]>
Except that I don't think adding this feature to the existing q{...}
is a good idea. If I had to vote on your proposal, I would instantaly
vote against it. I think you should have invented a new operator or a
pragma or something.
Re: RFC 208 (v2) crypt() default salt
> =head1 TITLE > > crypt() default salt > > =head1 VERSION > > Maintainer: Mark Dominus <[EMAIL PROTECTED]> > Date: 11 Sep 2000 > Last Modified: 13 Sep 2000 > Mailing List: [EMAIL PROTECTED] > Number: 208 > Version: 2 > Status: Developing If there are no objections, I will freeze this in twenty-four hours.
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 remember why just now. (I think have some notes somewhere about it.) I will RFC it if you want. Note that there's prior art here: It's like Lisp's backquote operator.
Re: types that fail to suck
> You talked about Good Typing at YAPC, but I missed it. There's a > discussion of typing on perl6-language. Do you have notes or a > redux of your talk available to inform this debate? http://www.plover.com/~mjd/perl/yak/typing/TABLE_OF_CONTENTS.html http://www.plover.com/~mjd/perl/yak/typing/typing.html Executive summary of the talk: 1. Type checking in C and Pascal sucks. 2. Just because static type checking is a failure in C and Pascal doesn't mean you have to give up on the idea. 3. Languages like ML have powerful compile-time type checking that is successful beyond the wildest imaginings of people who suffered from Pascal. 4. It is probably impossible to get static, ML-like type checking into Perl without altering it beyond recognition. 5. However, Perl does have some type checking mechanisms, and more are coming up. 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.
Re: RFC 105 (v1) Downgrade or remove "In string @ must be \@" error
This has already been done for Perl 5.6.1. Here is what perldelta.pod has to say. =head2 Arrays now Always Interpolate Into Double-Quoted Strings In double-quoted strings, arrays now interpolate, no matter what. The behavior in perl 5 was that arrays would interpolate into strings if the array had been mentioned before the string was compiled, and otherwise Perl would raise a fatal compile-time error. In versions 5.000 through 5.003, the error was Literal @example now requires backslash In versions 5.004_01 through 5.6.0, the error was In string, @example now must be written as \@example The idea here was to get people into the habit of writing C<"fred\@example.com"> when they wanted a literal C<@> sign, just as they have always written C<"Give me back my \$5"> when they wanted a literal C<$> sign. Starting with 5.6.1, when Perl now sees an C<@> sign in a double-quoted string, it I attempts to interpolate an array, regardless of whether or not the array has been used or declared already. The fatal error has been downgraded to an optional warning: Array @example will be interpolated in string This warns you that C<"[EMAIL PROTECTED]"> is going to turn into C if you don't backslash the C<@>. See L<http://www.plover.com/~mjd/perl/at-error.html> for more details about the history here. Mark-Jason Dominus [EMAIL PROTECTED] I am boycotting Amazon. See http://www.plover.com/~mjd/amazon.html for details.
Portable upper/lower case regexp matches
As far as I know, there is a basic bit of regexp functionality which Perl should support but doesn't. Perl regexps support the following features, though they're a bit obscure to my tastes... (from perlre:) \l lowercase next char (think vi) \u uppercase next char (think vi) \L lowercase till \E (think vi) \U uppercase till \E (think vi) \E end case modification (think vi) ...but Perl doesn't offer a regexp pattern to match all alphabetical characters of a particular case. Something like: \x match lowercase alpha char \X match uppercase alpha char Thus /\X\x*/ would match all capitalized words, while /\X+/ would match acronyms, and /(\X\x+)+/ would match Java class names. What's the big deal, you ask? Just use [A-Z] and [a-z]! Well, perlre notes: "If use locale is in effect, the case map used by \l, \L, \u and \U is taken from the current locale." And to quote perllocale: "Perl supports language-specific notions of data such as `is this a letter', `what is the uppercase equivalent of this letter', and `which of these letters comes first'. These are important issues, especially for languages other than English--but also for English: it would be naive to imagine that A-Za-z defines all the `letters' needed to write in English." So explicit regexp matching for upper/lower alpha characters is necessary to support locales, not to mention to be consistent with the perl docs themselves. There is no convenient way to imitate this functionality in Perl while supporting locales. There should be. Jason Elbaum [EMAIL PROTECTED]
Re: Deep copy
Lisp, which you might expect would have a 'deep copy' operator, doesn't have one. The Lisp folks have apparently thought about this very carefully, and decided that the semantics are unclear, and that the obvious options are all wrong; I've read a number of articles about this in the past. I don't remember all the details, unfortunately. But I think it's worth paying attention to prior art where there is some. This article http://world.std.com/~pitman/PS/EQUAL.html discusses this in some detail. I haven't thought about this in the context of Perl yet, so I'm not sure if all the reasons apply. Also if you do a Deja search in comp.lang.lisp for the phrase "deep copy", you'll find an extensive discussion of why it doesn't make sense, at least in Lisp. I'll also note the the same problems comes up when comparing for equality; if you want a deep copy operator, you should also want a deep compare oprator. But Lisp has not one but *five* equality comparison operators, and part of the proliferation is for the reason that the 'deepness' of the desired comparison varies from application to application. Perl has two equality comparison operators and people aready complain that that is too many. Mark-Jason Dominus [EMAIL PROTECTED] I am boycotting Amazon. See http://www.plover.com/~mjd/amazon.html for details.
RFC17
I don't want to join the discussion in general, and I'm not on the
language list. So this is a one-shot manifesto.
I agree with the goal of RFC17:
Organization and Rationalization of Perl State Variables
but I think the implementation ideas are making a terrible mistake.
Specifically:
> =head1 IMPLEMENTATION
> =head3 Well-Named Global Hashes And Keys
I think if there's one thing we have learned (or should have leanred)
from Perl 5, it's that this sort of global state variable is a
terrible idea regardless of what its name is.
Why is $* deprecated? Because it's dangerous.
Why is $* dangerous?
Because some function eleven calls down in some module you never heard
of that was loaded by some other module might do this:
$* = 1;
which suddenly changes the semantics of *every* regex match in your
*entire* program.
Conclusion: The real problem with $* isn't the name (although the
name is nasty.) The real problem is that it's a global variable with
a global effect, and it changes the meaning of code that is far away.
RFC17 fixes the little problem and leaves the big problem gaping and
festering.
But OK, $* is deprecated, so we can assume that it won't be in Perl 6.
Maybe the real problem has gone away? No. RFC17 specifically
mentions $^W, which has exactly the same problem. Some function
eleven calls down in some module that was loaded by some other module
might do
$^W = 1;
(or $PERL::CORE{warnings} = 1 if you prefer) and suddenly change the
warning behavior of *every* part of your *entire* program. If $* were
not a global, it would be at worst an odd wart, and possibly even a
convenience. Because it is a global, it is a dangerous hazard. $^W
is similar.
$/ is a necessary evil that must be carefully used because it is a
global. If you set $/ and forget to localize the change, the rest of
the program blows up in a bizarre way because *every* filehandle read
operation in (every* part of the program changes behavior. If $/ were
per-filehandle, or if it were lexically scoped, it would be an
unmitigated advantage.
Similarly for each of $\ $, $" $; $# $* $= $^L $^A $@ $^I $^P $^R $^W
and especially the putrid $[.
$| $^ $~ are less problematic because they are per-filehandle.
$. $% $` $& $' $- $+ @+ @- $? $! $^E $$ $[ $^O $^R $^T $^V are less
problematic because they are read-only. Some, like $., are still
problematic, because, for example:
$line = ;
subr();
print "Line $. is $line";
might work, or it might not.
$0 $< $> $( $) $^C $^D $^F $^H $^M @ARGV are not problems because they
really are global. Each process has one real UID, and only one, so a
global variable for $< is perfectly OK.
$_ is in a class by itself.
Summary of manifesto: Global variables must be expunged.
Replacing the old rotten global variables with new rotten global
variables is not enough of an improvement.
Mark-Jason Dominus [EMAIL PROTECTED]
I am boycotting Amazon. See http://www.plover.com/~mjd/amazon.html for details.
