Re: [perl6/specs] 761178: remove some some duplicate words words
On Tue, Sep 7, 2010 at 11:29 AM, Moritz Lenz mor...@faui2k3.org 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 wayl...@wayland.id.auwrote: 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, pugs-comm...@feather.perl6.nl 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, nigelsande...@btconnect.com 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 jonat...@jnthn.netwrote: 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 cma...@gmail.com 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 wayl...@wayland.id.auwrote: 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
Connected by MOTOBLUR™ on T-Mobile -Original message- From: Juan Madrigal jua...@mac.com 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
Re: Interactive Perl 6 shell
On Mon, Dec 28, 2009 at 9:59 PM, Jason jswit...@gmail.com 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
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!divbr/divdivWe are planning on having another Dallas.p6m meeting soon. span style=border-collapse: collapse\; color: r gb(51\, 51\, 51)\;We are meeting next week (Tuesday\, June 9th 7:00PM) at a coffee shop with free wifi. The address isnbsp\;span style=font-famil y: Arial\;985 W Bethany Dr Allen\, TX 75013 (span style=font-family: ar ial\;Pete's Coffee inside the Market Street).span style=font-family: Ar ial\;br/span/span/span/span/div\nspan style=border-collapse : collapse\; color: rgb(51\, 51\, 51)\;divbr/div\ndivspan style= font-family: Arial\;This 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).brbrAlso\, 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.brbr/spanEveryone is invited to come and have a good time. See you there!brbr-Jason s1n Switzerbr/div/span\n\nView your event at http://www.google.com/calendar/event?action=VIEWeid=ZzNyc3Rz NjZhdnNhYWNwODE3bjdyaTFuMmcgcGVybDYtbGFuZ3VhZ2VAcGVybC5vcmctok=MTgjanN3aXR 6ZXJAZ21haWwuY29tNmRiNDU1ODk3YTMyZmI2ZjNlYjY4ZTQwNGQ1YmFiOTExMDgzNzRjYQctz =America%2FChicagohl=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!divbr/divdivWe are planning on having another Dallas.p6m meeting soon. span style=border-collapse: collapse\; color: r gb(51\, 51\, 51)\;We are meeting next week (Tuesday\, June 9th 7:00PM) at a coffee shop with free wifi. The address isnbsp\;span style=font-famil y: Arial\;985 W Bethany Dr Allen\, TX 75013 (span style=font-family: ar ial\;Pete's Coffee inside the Market Street).span style=font-family: Ar ial\;br/span/span/span/span/div\nspan style=border-collapse : collapse\; color: rgb(51\, 51\, 51)\;divbr/div\ndivspan style= font-family: Arial\;This 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).brbrAlso\, 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.brbr/spanEveryone is invited to come and have a good time. See you there!brbr-Jason s1n Switzerbr/div/span\n\nView your event at http://www.google.com/calendar/event?action=VIEWueid=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 datawea...@gmail.com wrote: On Mon, Jun 1, 2009 at 5:44 PM, Daniel Carrera daniel.carr...@theingots.org 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 james.fuller.2...@gmail.comwrote: 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=2hl=enq=kitchen+sink -Jason s1n Switzer
Re: r25490 - docs/Perl6/Spec
On Sun, Feb 22, 2009 at 9:47 PM, pugs-comm...@feather.perl6.nl 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 Thu, Jan 22, 2009 at 4:51 PM, jerry gay jerry@gmail.com wrote:
$x == $y
:ok({ .true ?? 'message' !! 'failure message' })
:diag( 'tap comment', :some_tap_propertysome values)
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 mor...@faui2k3.org 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 datawea...@gmail.com 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 9:07 AM, jesse je...@fsck.com 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: Not a bug?
On Mon, Jan 12, 2009 at 3:54 PM, Larry Wall la...@wall.org 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 6:26 PM, Ovid publiustemp-perl6langua...@yahoo.comwrote: - Original Message From: jason switzer jswit...@gmail.com 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: r24737 - docs/Perl6/Spec
On Fri, Jan 2, 2009 at 8:12 PM, Geoffrey Broadwell ge...@broadwell.orgwrote: 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. Cperl6 --doc replaces p5's Cperldoc (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
/); 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: Working with files wish list
On Mon, Dec 15, 2008 at 6:59 PM, Leon Timmermans faw...@gmail.com wrote:
On Mon, Dec 15, 2008 at 6:42 PM, jason switzer jswit...@gmail.com 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: 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: 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 ab and bc, what is it doing
calling my_compare(a,c)? It should be able to figure that out without
the call! The fact that it dumps core if ca means that it has called
my_compare() when it didn't need to. Similarly, a qsort that dumps
core if my_compare(a,a) != 0 has obviously wasted time by calling
my_compare() at all in this case; it should *assume* that my_compare
will return 0 here.
So perhaps the best answer to the whole discussion is that if qsort()
dumps core when given an inconsistent comparator, you should replace
it with a better qsort.
Re: RFC 308 (v1) Ban Perl hooks into regexes
I think the proposal that Joe McMahon and I are finishing up now will make these obsolete anyway.
Re: RFC 308 (v1) Ban Perl hooks into regexes
On Mon, Sep 25, 2000 at 08:56:47PM +, Mark-Jason Dominus wrote:
I think the proposal that Joe McMahon and I are finishing up now will
make these obsolete anyway.
Good! The less I have to maintain the better...
Sorry, I meant that it would make (??...) and (?{...}) obsolete, not
that it will make your RFC obsolete. Our proposal is agnostic about
whether (??...) and (?{...}) should be eliminated.
Re: Perlstorm #0040
I lie: the other reason qr{} currently doesn't behave like that is that
when we interpolate a compiled regexp into a context that requires it be
recompiled,
Interpolated qr() items shouldn't be recompiled anyway. They should
be treated as subroutine calls. Unfortunately, this requires a
reentrant regex engine, which Perl doesn't have. But I think it's the
right way to go, and it would solve the backreference problem, as well
as many other related problems.
RFC255: Fix iteration of nested hashes
This RFC proposes that the internal cursor iterated by the Ceach function
be attached to the instance of Ceach (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: RFC 166 (v2) Alternative lists and quoting of things
(?Q$foo) Quotes the contents of the scalar $foo - equivalent to
(??{ quotemeta $foo }).
How is this different from
\Q$foo\E
?
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: 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.
'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.
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.
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 72 (v1) The regexp engine should go backward as well as forward.
Simply put, I want variable-length lookbehind. Why didn't you simply propose that the (?...) operator be fixed to support variable-length expressions? Why so much additional machinery?
Re: $ and copying: rfc 158 (was Re: RFC 110 (v3) counting matches)
in any case, i think we have a fair agreement on rfc 158 and i will freeze it if there is no further comments on it. I think you should remove the parts of your propsal about making $ be autolocalized. If you're not planning to revise your RFC, let me know so that I can ask the librarian to mark it as withdrawn.
Re: XML/HTML-specific ? and ? operators?
: it looks worse and dumps core.
That's because the first non-paren forces it to recurse into the
second branch until you hit REG_INFTY or overflow the stack. Swap
second and third branches and you have a better chance:
I think something else goes wrong there too.
$re = qr{...}
(I haven't checked that there aren't other problems with it, though.)
Try this:
"(x)(y)" -~ /^$re$/;
This should match, but it dumps core. I don't think there is infinite
recursion, although I might be mistaken.
Anyway, Snobol has a nice heuristic to prevent infinite recursion in
cases like this, but I'm not sure it's applicable to the way the Perl
regex engine works. I will think about it.
Re: XML/HTML-specific ? and ? operators?
:Anyway, Snobol has a nice heuristic to prevent infinite recursion in :cases like this, but I'm not sure it's applicable to the way the Perl :regex engine works. I will think about it. It is probably worth adding the heuristic above: anytime you recurse into the same re at the same position, there is an infinite loop. That is basically it, except that in snobol it is inside out: Each recursively interpolated pattern is assumed to match a string of at least length 1, and if the remaining part of the target string isn't sufficiently long to match the rest of the pattern after recursion, then the recursion is skipped.
Re: What's in a Regex (was RFC 145)
2. Many people - including Larry - have voiced their desire to see =~ die a horrible death Please provide a look-up-able reference to Larry's saying that he wanted to =~ to die horrible death. Larry said: # Well, the fact is, I've been thinking about possible ways to get rid # of =~ for some time now, so I certainly don't mind brainstorming in # this direction. That is in [EMAIL PROTECTED] which is archived at http://www.mail-archive.com/perl6-language-regex@perl.org/msg3.html I think Nathan was exaggerating here, but maybe he knows something I don't.
Re: XML/HTML-specific ? and ? operators? (was Re: RFC 145 (alternate approach))
...My point is that I think we're approaching this
the wrong way. We're trying to apply more and more parser power into what
classically has been the lexer / tokenizer, namely our beloved
regular-expression engine.
I've been thinking the same thing. It seems to me that the attempts to
shoehorn parsers into regex syntax have either been unsuccessful
(yielding an underpowered extension) or illegible or both.
An approach that appears to have been more successful is to find ways
to integrate regexes *into* parser code more effectively. Damian
Conway's Parse::RecDescent module does this, and so does SNOBOL.
In SNOBOL, if you want to write a pattern that matches balanced
parenteses, it's easy and straightforward and legible:
parenstring = '(' *parenstring ')'
| *parenstring *parenstring
| span('()')
(span('()') is like [^()]* in Perl.)
The solution in Parse::RecDescent is similar.
Compare this with the solutions that work now:
# man page solution
$re = qr{
\(
(?:
(? [^()]+ )# Non-parens without backtracking
|
(??{ $re }) # Group with matching parens
)*
\)
}x;
This is not exactly the same, but I tried a direct translation:
$re = qr{ \( (??{$re}) \)
| (??{$re}) (??{$re})
| (? [^()]+)
}x;
and it looks worse and dumps core.
This works:
qr{
^
(?{ local $d=0 })
(?:
\(
(?{$d++})
|
\)
(?{$d--})
(?
(?{$d0})
(?!)
)
|
(? [^()]* )
)*
(?
(?{$d!=0})
(?!)
)
$
}x;
but it's rather difficult to take seriously.
The solution proposed in the recent RFC 145:
/([^\m]*)(\m)(.*?)(\M)([^\m\M]*)/g
is not a lot better. David Corbin's alternative looks about the same.
On a different topic from the same barrel, we just got a proposal that
([23,39]) should match only numbers between 23 and 39. It seems to me
that rather than trying to shoehorn one special-purpose syntax after
another into the regex language, which is already overloaded, that it
would be better to try to integrate regex matching better with Perl
itself. Then you could use regular Perl code to control things like
numeric ranges.
Note that at present, you can get the effect of [(23,39)] by writing
this:
(\d+)(?(?{$1 23 || $1 39})(?!))
which isn't pleasant to look at, but I think it points in the right
direction, because it is a lot more flexible than [(23,39)]. If you
need to fix it to match 23.2 but not 39.5, it is straightforward to do
that:
(\d+(\.\d*)?)(?(?{$1 23 || $1 39})(?!))
The [(23,39)] notation, however, is doomed.All you can do is
propose Yet Another Extension for Perl 7.
The big problem with
(\d+)(?(?{$1 23 || $1 39})(?!))
is that it is hard to read and understand.
The real problem here is that regexes are single strings. When you
try to compress a programming language into a single string this way,
you end up with something that looks like Befunge or TECO. We are
going in the same direction here.
Suppose there were an alternative syntax for regexes that did *not*
require that everything be compressed into a single string? Rather
than trying to pack all of Perl into the regex syntax, bit by bit,
using ever longer and more bizarre punctuation sequences, I think a
better solution would be to try to expose the parts of the regex
engine that we are trying to control.
I have some ideas about how to do this, and I will try to write up an
RFC this week.
Re: RFC 110 (v3) counting matches
(mystery: how can filling in $ be a lot slower than filling in $1?) It isn't. It's the same. $1 might even be more expensive than $. It appears that many people don't understand the problem with $. I will try to explain. Maintaining the information required by $1 or $ slows down the regex match, possibly by as much as forty to sixty percent, or more. (How much depends on details of the regex and the target string.) For this reason, Perl has an optimization in it so that if you never use $ anywhere in your program, Perl never maintains the information, and every regex in your program runs faster. But if you do use $ somewhere, Perl cannot apply the optimization, and it must compute the $ information for every regex in the program. Every regex becomes much slower. In particular, if you load a module whose author happened to use $, all your regexes get slower, which might be an unpleasant surprise, since you might not be aware of the cause. A regex with backreferences is *also* slow. But using backreferences in one regex does not make all the *other* regexes slow. If you have /(...)/ # regex 1 /.../ # regex 2 Perl knows that it must compute the backreference information for regex 1, and knows that it can skip computing the backreference information for regex 2, because regex 2 contains no parentheses. If you use a module that contains regexes that use backreferences, those regexes run slowly, but there is no effect on *your* regexes. The cost is just as high for backreferences as for $, but the backreference cost is paid only by regexes that actually need it. The $ cost is paid by every regex in the entire program, whether they used it or not. This is because Perl has no way to tell which regexes use $ and which do not. One of Uri's suggestions in RFC 158 was to compute $ only for regexes that have a /k modifier. This would solve the $ problem because Perl would compute $ only when asked to, and not for every other regex in the rest of the program.
RFC 166 (disambiguator)
Richard Proctor suggests that (?) will match the empty string.
Then it can be inserted into regexes to separate elements that need to
be separated. For example, /$foo(?)bar/ interpolates the value of
$foo and then looks for that pattern followed by 'bar'. You cannot
simply write /$foobar/ because then Perl tries to interpolate $foobar,
which is not what you wanted.
1. You can already write /${foo}bar/ to get what you wanted. This
solution already works inside of double-quoted strings. (?) would
not work inside of double-quoted strings.
2. You can already write /$foo(?:)bar/ to get what you wanted. This
is almost identical to what Richard proposed anyway.
It is really not clear to me that this problem needs to be solved any
better than it is already.
I suggest that this section be removed from the RFC.
Mark-Jason Dominus [EMAIL PROTECTED]
I am boycotting Amazon. See http://www.plover.com/~mjd/amazon.html for details.
Re: RFC 110 (v3) counting matches
On Mon, 28 Aug 2000, Mark-Jason Dominus wrote:
But there is no convenient way to run the loop once for each date and
split the dates into pieces:
# WRONG
while (($mo, $dy, $yr) = ($string =~ /(\d\d)-(\d\d)-(\d\d)/g)) {
...
}
What I use in a script of mine is:
while ($string =~ /(\d\d)-(\d\d)-(\d\d)/g) {
($mo, $dy, $yr) = ($1, $2, $3);
}
Although this, of course, also requires that you know the number of
backreferences.
The real problem I was trying to discuss was not this particular
application. I was trying to point out a larger problem, which is
that there are several regex features that are enabled or disabled
depending on what context the match is in, so that if you want one
scalar-context feature and one list-context feature at the same time,
there is no direct way to do it.
Nicer would be to be able to assign from @matchdata or something
like that :)
I agree. There are many operations that would be simpler if there was
a magic array that contained ($1, $2, $3, ...). If anyone wants to
write an RFC on this, I will help.
Re: RFC 110 (v2) counting matches
On Tue, 29 Aug 2000 08:47:25 -0400, Mark-Jason Dominus wrote: m/.../Count,Insensitive (instead of m/.../ti) That would escape the problem that we are running out of letters and also the problem that the current letters are hard to remember. Yes, but wouldn't this give us backward compatibility problems? For example, code like $result = m/(.)/Insensitive, ord $1; No, because that is presently a syntax error. The one you have to watch out for is: $result = m/(.)/s,Insensitive, ord $1; And, I don't really see the need for the comma. m/.../CountInsensitive (instead of m/.../ti) I guess, but to me CountInsensitive looks like one option, not two.
Overlapping RFCs 135 138 164
RFC135: Require explicit m on matches, even with ?? and // as delimiters. C?...? and C/.../ are what makes Perl hard to tokenize. Requiring them to be written Cm?...? and Cm/.../ would solve this. (Nathan Torkington) RFC138: Eliminate =~ operator. Replace EXPR =~ m/.../ with m/.../ EXPR, and similarly for s/// and tr///. Force an explicit dereference when using qr/.../. Disallow the implicit treatment of a string as a regular expression to match against. (Steve Fink) RFC164: Replace =~, !~, m//, and s/// with match() and subst() Several people (including Larry) have expressed a desire to get rid of C=~ and C!~. This RFC proposes a way to replace Cm// and Cs/// with two new builtins, Cmatch() and Csubst(). (Nathan Widger) I would like to see these three RFCs merged into one if this is appropriate. I am calling on the three authors to discuss in private email how this may be done. I hope that the discussion will result in the withdrawal at least two of the three RFCs, and that this private discussion produces a new RFC. The new RFC should discuss the points raised by all three existing RFCs, should investigate several solutions in parallel, and should compare them with one another and contrast the benefits and drawbacks of each one. Mark-Jason Dominus [EMAIL PROTECTED] I am boycotting Amazon. See http://www.plover.com/~mjd/amazon.html for details.
Re: RFC 158 (v1) Regular Expression Special Variables
Please correct me if I'm mistaken, but I believe that that's the way they are implemented now. A regex match populates the -startp and -endp parts of the regex structure, and the elements of these items are byte offsets into the original string. I haven't looked at it at all, and perhaps that 's sometihng Ilya did when creating @+ etc. So you might be right. As far as I know it's the same in 5.000. I thought the problem with $ was that the regex engine has to adjust the offsets in the startp/endp arrays every time it scans forward a character or backtracks a character. But maybe the effect of $ is greatly exaggerated or is a relic from perl4? Has anyone actually benchmarked this recently?
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 Ialways 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 Cfred.com if you don't backslash the C@. See Lhttp://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 = FH;
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.
