Extended Regexs
Hi, There is one significant area of perl that has very little attention here (other than one of my RFCs) that is regexs. Perl has very powerfull regexs - but what other features might be desirable? I had one long term good idea on assignment and submitted that, but there may be other things people have thought - wouldn't it be nice if, - I wish XXX was easiler? Here is a few throw away thoughts - they don't constitute RFC material yet, I am not sure if they would be that useful and have not yet thought of any syntax, but any others? All of these can be done today but are not necessarily "easy". * Embeded patterns that do not match a pattern - you can do [^a]* for a string that does not have an a, but can you match a string that does not contain "and". * Repeated sub patterns - qr allows you to compile a pattern, but if you want to use a same sub pattern as part of many regexs this is not easy. (The keyword there is PART). * Using the pattern returned from some function as part of a regex * Using an array of "words" as an alternate list as part of a regex * Fill your idea in here [ ] Richard Proctor [ Years ago I did a significant pattern matching package (for another computer language), and know quite a lot about the theories so I am not exactly a novice] [[ Enough free time between now and Sunday Lunchtime [1] to be on list for once ]] [1] And the start of the next business trip... -- [EMAIL PROTECTED]
Re: Extended Regexs
On Fri 18 Aug, Damian Conway wrote:
>> All of these can be done today but are not necessarily "easy".
>>
>
> /\A(?s:(?!and).)*\Z/
>
> /pattern returned from ${\some_function} as part of a regex/
>
> /match any of (${\join'|',@list}) here/
>
I am not saying these things can't be done, in fact I was saying they can
but was rather asking what should be made easier?
Richard
--
[EMAIL PROTECTED]
Re: RFC 111 (v1) Whitespace and Here Docs
On Fri 25 Aug, Nathan Wiger wrote: > > I was sorta going under the assumption that <<< would cause leading and > > trailing whitespace to be ignored (not stripped) when looking for the > > end-of-here-doc indicator. Because whitespace is ignored, I was then > > proposing some new syntax for stripping whatever one likes from the > > contents of the here-doc. > > I think there's two ideas here in the RFC, one great, the other > debateable: Ok, lets split in 2 > >1. Ignore leading/trailing whitespace in here string terminators. > All of these should work: > > EOL >EOL > EOL # this is the end of the here doc > > I don't think a special syntax is needed just for this. Make > this the default (so "print < If this makes you nervous, use 'This_is_the_end_of_the_string' > or some other suitably long EOL marker. I will make this RFC 111 issue 2 > >2. That leading whitespace should be stripped off here docs. I > am personally against this, for all the reasons everyone has > mentioned. It's too specific a "special case". And there's > already an extremely easy way to do this (I think TomC posted > it again) in Perl 5. This will be in another RFC. Considering the posts, this might die, but perhaps a more generic filtering of Heredoc input might be more usefull. Richard -- [EMAIL PROTECTED]
Re: RFC 111 (v2) Here Docs Terminators (Was Whitespace and Here Docs)
On Mon 28 Aug, Eric Roode wrote: > Richard Proctor proposed: > > > > All of these should work: > > > > print < >EOL > > print << EOL; > > EOL > > print < >EOL # this is the end of the here doc > > People may throw rocks at me for this, but I'd like to suggest that > not only is a comment allowed on the terminator line, but a semicolon > also be allowed. Vis: > > print < EOL; # This should work, too > > Yes, I know that it can be done as: > > print <<"EOL;"; > EOL; > > but (imho) the prior example has high DWIM value, and is keeping with > the spirit of the RFC. I like it... I think I will add this to the next version. Richard -- [EMAIL PROTECTED]
Re: RFC 111 (v2) Here Docs Terminators (Was Whitespace and Here Docs)
On Mon 28 Aug, Bart Lateur wrote: > On Mon, 28 Aug 2000 10:38:42 -0400 (EDT), Eric Roode wrote: > > >People may throw rocks at me for this, but I'd like to suggest that > >not only is a comment allowed on the terminator line, but a semicolon > >also be allowed. Vis: > > > >print < >EOL; # This should work, too > > Let me throw the first rock. I think this is confusing for the reader of > your code. This looks like a statement, not an end-of-doc marker, so > they'll search for the definition of the sub EOL. I will catch the rock as this is getting ever closer to DWIM. > > Next you'll propose that > > print < blah > EOL; print "OK!\n"; > > should work too, and print "OK!\n" as well. > Yes why not, though it might be bad style. > OTOH, what about this... > > print < blah > EOL; > > which makes this a full blown statement (note the missing semicolon in > the first line)... Yes as well. > > Nah! > I think we are likely to disagree... Richard -- [EMAIL PROTECTED]
Re: RFC 162 (v1) Filtering Here Docs
On Mon 28 Aug, Bart Lateur wrote: > On 27 Aug 2000 19:23:51 -, Perl6 RFC Librarian wrote: > > >It only removes whitespace, > >and it measures whitespace with tabs=8. > > My editor is set to tabs=4. Perl's interpretation wouldn't agree with > the visual appearance in my editor. This doesn't sound like a neat > solution. > This is a problem, there may not be a general solution (use tabs qw(4)? for tabs != 8 ?) > Why not disallow merging of tabs and spaces as being equivalent? If you > want to skip a leading tab, but a tab between '<<"' and the EOL marker. > If you want to skip spaces, put spaces in. If you want to skip tabs and > spaces, put that sequence in. Editors and people are inconsistent. I can indent with spaces then when the next lines is autoindented the editor uses tabs. trying to ensure consistent behaviour is like trying to get consistent behaviour on this list... > > The only consequence would be that you'd have to be consistent in what > you put in front of the text lines (and in the whitespace prefix > definition). > This leads back to my original "remove all whitespace". Somehow there is a compromise to extracted from this. -- [EMAIL PROTECTED]
Re: RFC 195 (v1) Retire chop().
On Fri 08 Sep, Eric Roode wrote: > Does anyone EVER use chomp() except shortly after reading a line > of input from a stream? No? > Yes > Perhaps $/ and $\ should become per-filehandle variables, and > there should be some way to set autochomp-on-read per filehandle, > and auto-newline-on-output per filehandle. I can see a small benefit for autochomp-on-read but none whatsoever for auto-newline-on-output (even if you could decide when to send it). Richard -- [EMAIL PROTECTED]
Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)
Michael,
I just noticed your post (I am at work). This is begining to get there (maybe I
should not have split the original
111).
In the prototype you only cover use of " quotes.
if( ($pre_code, $quote_type, $curr_tag, $post_code) = $_ =~
m/(.*)\<\<(")(\w+)"(.*)/ )
It needs to match (.*)<<((["'`])(\w+)\2)|(\w+))(.*) or something like that.
Richard Proctor
Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)
In Michael Schwerns prototype, expansion to treat both semicolons and comments at the end tag is possible by changing /^(\s*)$curr_tag\s*$/ to /^(\s*)$curr_tag\s*(;\s*)?(#.*)?$/ Richard
Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)
This whole debate has got silly. RFC 111 V1 covered both the whitespace on the terminator and the indenting - there was a lot of debate that this was two things - more were in favour of the terminator and there was more debate on the indenting. Therefore I split this into two RFCs leaving RFC111 just dealing with the terminator. RFC 111V3 represents what I believe was rough concenus (ALA IETF meaning) on the terminator issue. (The debate had been quiet for several weeks) Michael Schwern has gone as far as doing a prototype that almost covers it and with the few things I have posted earlier today could be extended to handle all cases. Next comes the issue of the removing whitespace on the left of the content. There are several possibilities, these are now mostly in RFC 162. These are: 1) There is no processing of the input (current state) 2) All whitespace to the left is removed (my original idea) 3) Whitespace equivalent to the first line is removed (not a good solution) 4) Whitespace equivalent to the terminator is removed if possible (ALA Michaels prototype) - this could be workable. 5) Whitespace equivalent to the smallest amount of the content is removed (current RFC 162 preffered solution) When measuring whitespace how does the system treat tabs? (be realistic and dont FLAME) So where do we go from here? A) Do we want one syntax or two? (<
RFC 111
This whole debate has got silly. RFC 111 V1 covered both the whitespace on the terminator and the indenting - there was a lot of debate that this was two things - more were in favour of the terminator and there was more debate on the indenting. Therefore I split this into two RFCs leaving RFC111 just dealing with the terminator. RFC 111V3 represents what I believe was rough concenus (ALA IETF meaning) on the terminator issue. (The debate had been quiet for several weeks) Michael Schwern has gone as far as doing a prototype that almost covers it and with the few things I have posted earlier today could be extended to handle all cases. Next comes the issue of the removing whitespace on the left of the content. There are several possibilities, these are now mostly in RFC 162. These are: 1) There is no processing of the input (current state) 2) All whitespace to the left is removed (my original idea) 3) Whitespace equivalent to the first line is removed (not a good solution) 4) Whitespace equivalent to the terminator is removed if possible (ALA Michaels prototype) - this could be workable. 5) Whitespace equivalent to the smallest amount of the content is removed (current RFC 162 preffered solution) When measuring whitespace how does the system treat tabs? (be realistic and dont FLAME) So where do we go from here? A) Do we want one syntax or two? (<
Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)
On Fri 15 Sep, Nathan Wiger wrote: > Michael G Schwern wrote: > > So indenting the terminator and indenting the text are linked. If you > > do one, you want to do the other. > > As I and many others have said, that's not necessarily true. I like all > my code to line up, braces, parens, and all. It enhances readability, > and is easier to scan. > > Anyways, it seems both your and my needs could be met if we simply added > a <<< operator that does what you want. Otherwise we're forced to choose > between two useful alternatives that are both valid. I could see using > both your and "my" way in many different situations, so we should make > them coexistant, not mutually exclusive. > There are two current RFCs RFC 111 deals with the terminator - I dont think anyone is realy debating that at present. RFC 162 discusses the indenting of heredoc content. There are two possible operators, the existing << and the enhanced <<< There are 5 possible ways of indenting, many of them have no compatibility problems, some might and hence might benefit from the <<<. a) No Indenting (status quo - do whatever the current << does. b) Remove all leading whitespace - Not popular - no longer supported c) Remove whitespace equivalent to the first line - Not popular - no longer supported d) Remove whitespace equialent to the smallest whitespace - a Realistic option e) Remove whitespace equialent to the terminator - a realistic option. Do the following two options satisfy everybody? [no but its worth a try] 1) << removes whitespace equivalent to the terminator (e) this is largely backward complatible as many existing heredocs are unlikely to have white space before the terminator. 2) <<< removes whitespace equivalent to the smallest whitespace (d) or are these the options that will satisfy everybody [no but its worth a try] 1) << Does just what it does now 2) <<< implements (d) or (e) [[there is still the tabs debate however]] Richard -- [EMAIL PROTECTED]
Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)
On Fri 15 Sep, Michael G Schwern wrote: > On Fri, Sep 15, 2000 at 06:38:37PM +0100, Richard Proctor wrote: > > 1) << removes whitespace equivalent to the terminator (e) this is largely > > backward complatible as many existing heredocs are unlikely to have white > > space before the terminator. > > > > 2) <<< removes whitespace equivalent to the smallest whitespace (d) > > > > or are these the options that will satisfy everybody [no but its worth a > > try] > > > > 1) << Does just what it does now > > > > 2) <<< implements (d) or (e) > > > I'd say: > > 1) << does what it does now mod RFC 111 (ie. you can put whitespace in the >terminator, but it doesn't effect anything) I was assuming that the terminators changed ala RFC 111 whatever happens > > 2) <<< does (e). These are equivalent to my second set of options > > 3) distribute a collection of dequote() mutations with perl. As a module presumably > > 4) mention the s/// tricks in the documentation (< Yes. > > [[there is still the tabs debate however]] > > Tabs are easy, don't expand them. Consider them as a literal > character. This assums that the code author is going to use the same > keystrokes to indent their here-doc text as the terminator, about as > safe an assumption as any for tabs. > > Maybe I'm being too simplistic, I don't use tabs anymore. > Yes you are, the problem comes with mixing editors - some use tabs for indented material some dont, some reduce files using tabs etc etc. [I move between too many editors]. Perl should DWIM. I think that treating tabs=8 as the default would work for most people, even those who set tabs at other values as long as they are consistent - a "use tabs 4" could be used by them if they want to get the same behaviour if they mix tabs and spaces. Richard -- [EMAIL PROTECTED]
Re: RFC 283 (v1) C in array context should return a histogram
Simon, > This has been on the Perl 5 to-do list for ages and ages. The idea is > that when you're transliterating a bunch of things, you want to know > how many of each of them matched in your original string. While this may be a fun thing to do - why? what is the application? Richard
Re: RFC 283 (v1) C in array context should return a histogram
Simon, > I think I said in the RFC, didn't I? It's extending the counting use of tr/// > to allow you to count several different letters at once. For instance, letter > frequencies in text is an important metric for linguists, codebreakers and > others; think about how you'd get letter frequency from a string: >(%alphabet) = $string =~ tr/a-z//; > And it's on the Perl 5 wishlist, so it ain't just me that thinks its a worthy idea. So you can use it for code breaking and japhs. It is at best a fun thing. It does not seem to have much to do with tr///, if you want it, why not put it in a module with some meaningful name such as histogram()? How did something like this get in the wish list? Richard
Re: RFC 288 (v1) First-Class CGI Support
On Mon 25 Sep, Perl6 RFC Librarian wrote:
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> First-Class CGI Support
>
> Maintainer: Adam Turoff <[EMAIL PROTECTED]>
>
> To make CGI programming easier, this option/pragma should:
>
> Turn on tainting
What would it do on a platform that does not support Tainting?
> Parse the CGI context, returning CGI variables into %CGI
This is a little vague, will it parse $ENV{'QUERY_STRING'}, look for
content on STDIN controlled by $ENV{'CONTENT_LENGTH'}, Cookies, the command
line? Or all of them. Will it handle multipart input? How will it
handle multiple inputs of the same name? etc etc.
> Offer simple functions to set HTTP headers (e.g. content type, result
> codes)
Will there be access to do more - eg to control caching, cookies etc, will
it be optional?
>
> All of the other features offered by Lincoln Stein's CGI.pm should remain,
> but should not be deeply integrated into Perl6.
>
--
[EMAIL PROTECTED]
Re: Larry's Apocalypse 1
On Fri 06 Apr, Dan Sugalski wrote: > This is, I presume, in addition to any sort of inherent DWIMmery? I don't > see any reason that: > > @foo[1,2] = ; > > shouldn't read just two lines from that filehandle, for example, nor why > Fair enough > @bar = @foo * 12; > > shouldn't assign to @bar all the elements of @foo multiplied by 12. (Though > others might, of course) Reasonable, but what should @bar = @foo x 2; do? Repeat @foo twice or repeat each element twice? (its current behaviour is less than useless, other than for JAPHs) Richard -- [EMAIL PROTECTED]
Re: Larry's Apocalypse 1
On Fri 06 Apr, John Porter wrote: > Richard Proctor wrote: > > but what should > > @bar = @foo x 2; > > do? Repeat @foo twice or repeat each element twice? (its current > > behaviour is less than useless, other than for JAPHs) > > How is one significantly less useful than the other? > Its current behaviour is to assign to $bar[0] the length of @foo repeated twice. DB<1> @foo = (1,2,3) DB<2> @bar = @foo x 2 DB<3> p "@bar" 33 DB<4> p $bar[0] 33 This is what I call less than useless, perhaps you are thinking of, the current behavior of @bar = (@foo) x 2 DB<5> @bar = (@foo) x 2 DB<6> p "@bar" 1 2 3 1 2 3 Which has real application. Richard -- [EMAIL PROTECTED]
Apo2: \Q ambiguity
In Apocalypse 2, \Q is being used for two things, and I believe this may be
ambiguious.
It has the current \Quote meaning admitibly \Q{oute} it is also being
proposed for a null token disambiguate context. As in $foo\Q[bar].
But if it is spliting $foo and {this is in curlies} this will be taken as
\Quoting the content of the curlies.
I think that \Q for quoting and \Q for a null token should be different.
And given that the null token is new this is what should use something new.
It may also be a good idea to allow alternative brackets in \Q{...} in
much the same way as one can use different symbols for s///. If what you
are quoting uses curlies, one might choose angle brackets, or square
brackets.
Richard
--
[EMAIL PROTECTED]
Re: Apoc2 - concerns
On Sat 05 May, John Siracusa wrote: > On 5/5/01 3:28 PM, Larry Wall wrote: > > Well, that's enough brainwracking for the moment. Gloria is making me > > go eat something... > > Bread and water until Apocalypse 33 is done? ;) At one Apocalypse a month, that is a very long time... Would Larry survive for nearly three years on just Bread and water? :-) Richard -- [EMAIL PROTECTED]
A12 Versioning
I am not happy about the versioning proposal. While A12 listed many properties that could apply to a a module such as version, subject, author etc, the versioning declaration class Dog-1.2.1-cpan:JRANDOM; leaves me a little cold. Issues: 1) Why does this only use Version and Author? Suppose there are versions for different oses or that use other particular libraries that are wanted or not? 2) Shouldn't all these properties just be in a hash against the module rather than some having special significance? Others can then be simply added as appropriate. 3) Why is the information positional rather than by keyword property? use Dog :version«1.2.1» :author«JRANDOM» :os«cpm»; 4) What are the expected rules for versioning? While the public CPAN has one set of versioning, other projects have weird versioning rules, with letters and numbers. What would work and why? These are not fully thought through answers, but illustrate some thoughts or the matter. Richard -- Personal [EMAIL PROTECTED]http://www.waveney.org Telecoms [EMAIL PROTECTED] http://www.WaveneyConsulting.com Web services [EMAIL PROTECTED]http://www.wavwebs.com Independent Telecomms Specialist, ATM expert, Web Analyst & Services
Re: The last shall be last (was: The first shall be first)
On Sun 05 Sep, David Green wrote: > On 2004/9/04, [EMAIL PROTECTED] (Jonathan Lang) wrote: > (Nice Subject change, I almost missed it!) > > >Larry Wall wrote: > > > Yow. Presumably "nth" without an argument would mean the last. > > > >If it means the last, why not just use C? > > Conflict with "last LOOP"? Hm, the context should be enough to > distinguish them, no? (Hey, maybe they can be unified somehow -- > "last -1" to skip to the penultimate pass through the loop? =P) > That could be generalised, "next +1" skipping next iteration, "next -1" "redo" this iteration, "first" redo the iteration from the beginning etc. Richard -- Personal [EMAIL PROTECTED]http://www.waveney.org Telecoms [EMAIL PROTECTED] http://www.WaveneyConsulting.com Web services [EMAIL PROTECTED]http://www.wavwebs.com Independent Telecomms Specialist, ATM expert, Web Analyst & Services
Re: Still about subroutines...
On Fri 17 Sep, Larry Wall wrote: > > $?fileWhich file am I in? > $?lineWhich line am I at? > $?package Which package am I in? > @?package Which packages am I in? > $?module Which module am I in? > @?module Which modules am I in? > $?class Which class am I in? > @?class Which classes am I in? > $?roleWhich role am I in? > @?roleWhich roles am I in? > $?grammar Which grammar am I in? > @?grammar Which grammars am I in? > &?sub Which sub am I in? > @?sub Which subs am I in? > $?sub Which sub name am I in? > &?block Which block am I in? > @?block Which blocks am I in? > $?block Which block label am I in? > > Some of those may be sillier than others. But the fact that these all > contain a C is a good visual indication that they're all potentially > generic in meaning when you use them in a macro. I kinda like that. Maybe there are some more... $?perl Which version of perl am I in And relating to the outside world $?osWhich operating system am I operating on I am sure there could be many more, perhaps many (all?) of the special variables could become $? variables for consistency. Richard -- Personal [EMAIL PROTECTED]http://www.waveney.org Telecoms [EMAIL PROTECTED] http://www.WaveneyConsulting.com Web services [EMAIL PROTECTED]http://www.wavwebs.com Independent Telecomms Specialist, ATM expert, Web Analyst & Services
Re: Still about subroutines...
On Fri 17 Sep, Larry Wall wrote: > : $?osWhich operating system am I operating on > > Again, which OS am I compiled on, or at best, which OS does the compiler > think I'm compiling for, in the case of cross-compilation. > Therefore should: $?os Be which operating system it is being compiled on $*os Be which operating system it is being executed on Some of the other special variables may have a similar dual personality. Richard -- Personal [EMAIL PROTECTED]http://www.waveney.org Telecoms [EMAIL PROTECTED] http://www.WaveneyConsulting.com Web services [EMAIL PROTECTED]http://www.wavwebs.com Independent Telecomms Specialist, ATM expert, Web Analyst & Services
Re: What Requires Core Support (app packaging)
On Sun 19 Sep, Jonadab the Unsightly One wrote: > >> Archimedes. It doesn't allow them at all, from what I understand. > > > > It probably doesn't disallow file extensions [per se], but the dot > > Could be. I haven't used it personally. The name should be Risc-OS - the Archimedes is one of the computers that run it. Risc-OS has the concept of filetype, but it is not as part of the name, but a separate property of the files. Having said that, In converting from a filename with an extension from another system, a ".ext" is often converted to a "/ext" as "." is the native directory symbol. Thus in converting between unix style file names and riscos style file names is roughly tr#/.#./# (there are some caveats). Richard (Using Risc-os on an RPC) -- Personal [EMAIL PROTECTED]http://www.waveney.org Telecoms [EMAIL PROTECTED] http://www.WaveneyConsulting.com Web services [EMAIL PROTECTED]http://www.wavwebs.com Independent Telecomms Specialist, ATM expert, Web Analyst & Services
Yet more on angle quotes
How equivalent are << and «? Does use of one idiom imply the closing quote is the same. ie are the following allowed, prohibited or what? <> Just thinking... Richard -- Personal [EMAIL PROTECTED]http://www.waveney.org Telecoms [EMAIL PROTECTED] http://www.WaveneyConsulting.com Web services [EMAIL PROTECTED]http://www.wavwebs.com Independent Telecomms Specialist, ATM expert, Web Analyst & Services
Re: quotemeta
On Wed 16 Mar, Rod Adams wrote: > I vote for axing C in favor of C and C. > Given A05 states that bare scalars match literally, quotemeta is (almost?) obsolete. It can certainly be downgraded. Richard -- Personal [EMAIL PROTECTED]http://www.waveney.org Telecoms [EMAIL PROTECTED] http://www.WaveneyConsulting.com Web services [EMAIL PROTECTED]http://www.wavwebs.com Independent Telecomms Specialist, ATM expert, Web Analyst & Services
Re: 'is' and action at a distance
On Fri 18 May, Damian Conway wrote: > > Ed wrote: > > >> Can 'undef' valued thingys have properties > > Yes. > >> and functions? > > No. > Why not? Richard -- [EMAIL PROTECTED]
Re: [A-Z]+\s*\{
On Sun 20 Jan, Me wrote: > > On Saturday 19 January 2002 22:05, Brent Dax wrote: > > > Is this list of special blocks complete and correct? > > > > > > BEGIN Executes at the beginning of compilation > > > CHECK Executes at the end of compilation > > > INIT Executes at the beginning of run > > > END Executes at the end of run > > > PRE Executes at beginning of block entry > > > POST Executes at end of block entry > > > NEXT Executes on call to next() within current block > > > CATCH Executes on exception within current block > > > KEEP Executes on normal exit of the current block > > > UNDO Executes on "un-normal" exit of the current block > > - LAST > (Per Damian's last (LAST/POST) post.) > > - FIRST? > (Symmetry.) > > - ALWAYS? > (Another plausible addition. Rounds out PRE and POST > with invariant assertions that get checked twice, once at > the time PRE does, once at the time POST does. > Personally I'd leave this out until it became clear, well > past p6.0, whether it was really worth it, but it seems > worth mentioning.). > To complete such a list perhaps there is a case for: NEVER :-) Richard -- Personal Work - Waveney Consulting Mail: [EMAIL PROTECTED] [EMAIL PROTECTED] Web: http://www.waveney.org http://www.WaveneyConsulting.com Independent Telecommunications Consultant, ATM expert, Web Analyst
A5 - A job well done
Larry, Wow, that was a very good demolition and rebuilding of the regex edifice. When the RFCs were being written I spent many hours thinking over some of the issues and writting many of the RFCs on regexes, trying to build on what was in perl5, without changing the existing language use. By allowing change to that starting point he has done a much better job of it. (I was not a novice in this as I had done research in pattern matching at University many many years ago) At the time of the RFCs I was employed and hence had more free time to spend thinking about the design of perl6 than I do at present. (How is it that being unemployed I have LESS free time...) Richard -- Personal [EMAIL PROTECTED]http://www.waveney.org Telecoms [EMAIL PROTECTED] http://www.WaveneyConsulting.com Web services [EMAIL PROTECTED]http://www.wavwebs.com Independent Telecommunications Consultant, ATM expert, Web Analyst & Services
RE: [RFC] Perl6 HyperOperator List
On Wed 30 Oct, Larry Wall wrote: > An earlier message had something like this as a hyper: > > @a = @b[.method]; > > That absolutely won't work, because [.method] is a valid subscript. > In this case it would have to be written > > @a = @b[.]method; > > But the general problem is just about enough to kill the whole [] > idea for hyper. It's really only rescuable if we have a known set of > operators to match against. Then on the basis of the rule of matching > the longest token possible, we can have the hyper interpretation > override any interpretation as a subscript or anonymous array composer. > > For example, [undef] is a vector undef only if C is a member of > that distinguished set of operators. The [] made it look appropriate, if the problem is ambiguity then perhaps the contents of the [] need a prefix to force hyper interpretation if it could be ambiguous. These are special, powerful cases and the clearer they are made the better - minimal huffman coding is not necessary. [+] - hyper meaning is clear [.method] - fix meaning as the subscript [*.method] - for some "*" forces hyper context, all it requires is another 60 mesages to undecide on what "*" should be. Richard -- Personal [EMAIL PROTECTED]http://www.waveney.org Telecoms [EMAIL PROTECTED] http://www.WaveneyConsulting.com Web services [EMAIL PROTECTED]http://www.wavwebs.com Independent Telecomms Specialist, ATM expert, Web Analyst & Services
Re: [RFC] Perl Operator List, TAKE 6
On Fri 01 Nov, Michael Lazzaro wrote: > >(heredocs) - [exact format unknown; probably as perl5] > There are comments by Larry in Appo 2 wrt RFCs 111 and 162. Appo 2: === 111 aaa Here Docs Terminators (Was Whitespace and Here Docs) 162 abb Heredoc Contents RFC 111: Here Docs Terminators (Was Whitespace and Here Docs) Fine. RFC 162: Heredoc contents I think I like option (e) the best: remove whitespace equivalent to the terminator. By default, if it has to dwim, it should dwim assuming that hard tabs are 8 spaces wide. This should not generally pose a problem, since most of the time the tabbing will be consistent throughout anyway, and no dwimming will be necessary. This puts the onus on people using nonstandard tabs to make sure they're consistent so that Perl doesn't have to guess. Any additional mangling can easily be accomplished by a user-defined operator. RFC111: === Perl6 should ignore any whitespace before the terminator of a heredoc on any line. Further it should ignore any whitespace ";"s (and comments) that follow the terminator. Perl should also ignore whitespace between the << and the terminator. Discussion took place on allowing statements following the terminator, but generally these where thought of as a bad idea. So only ";" and comments should occour on the same line. All of these should work: print
Re: Unicode operators [Was: Re: UTF-8 and Unicode FAQ, demos]
This UTF discussion has got silly. I am sitting at a computer that is operating in native Latin-1 and is quite happy - there is no likelyhood that UTF* is ever likely to reach it. The Gillemets are coming through fine, but most of the other heiroglyphs need a lot to be desired. Lets consider the coding comparisons. Chars in the range 128-159 are not defined in Latin-1 (issue 1) and are used differently by windows to Latin-1 (later issues) so should be avoided. Chars in the range 160-191 (which include the gillemot) are coming through fine if encoded by the sender as UTF8. Anything in the range 192-255 is encoded differently and thus should be avoided. Therefore the only addition characters that could be used, that will work under UTF8 and Latin-1 and Windows are: CodeSymbol Comment 160 Non-breaking space (map to normal whitespace) 161 ¡ Could be used 162 ¢ Could be used 163 £ Could be used 164 ¤ Could be used 165 ¥ Could be used 166 ¦ Could be used 167 § Could be used 168 ¨ Could be used thouugh risks confusion with " 169 © Could be used 170 ª Could be used (but I dislike it as it is alphabetic) 171 « May well be used 172 ¬ "Not"? 173 Nonbreaking "-" treat as the same 174 ® Could be used 175 ¯ May cause confusion with _ and - 176 ° Could be used 177 ± Introduces an interesting level of uncertainty? Useable 178 ² To the power of 2 (squaring ? ) Otherwise best avoided 179 ³ Cubing? Otherwise best avoided 180 ´ Too confusing with ' and ` 181 µ Could be used 182 ¶ Could be used 183 · Dot Product? though likely to be confused with . 184 ¸ treat as , 185 ¹ To the power 1? Probably best avoided 186 º Could be used (but I dislike it as it is alphabetic) 187 » May well be used 188 ¼ Could be used 189 ½ Could be used 190 ¾ Could be used 191 ¿ Could be used Richard -- Personal [EMAIL PROTECTED]http://www.waveney.org Telecoms [EMAIL PROTECTED] http://www.WaveneyConsulting.com Web services [EMAIL PROTECTED]http://www.wavwebs.com Independent Telecomms Specialist, ATM expert, Web Analyst & Services
Re: Unicode operators [Was: Re: UTF-8 and Unicode FAQ, demos]
On Tue 05 Nov, Smylers wrote: > Richard Proctor wrote: > > > I am sitting at a computer that is operating in native Latin-1 and is > > quite happy - there is no likelyhood that UTF* is ever likely to reach > > it. > > > > ... Therefore the only addition characters that could be used, that > > will work under UTF8 and Latin-1 and Windows ... > > What about people who don't use Latin-1, perhaps because their native > language uses Latin-2 or some other character set mutually exclusive > with Latin-1? Once you go beyond latin-1 there is nothing common anyway. The Gullimots become T and t with inverted hats under Latin-2, oe and G with an inverted hat under Latin-3, oe and G with a squiggle under it under Latin-4, No meaning and a stylisd K for Latin-5, (cant find latin6), Gullimots under Latin 7, nothing under latin-8. Richard -- Personal [EMAIL PROTECTED]http://www.waveney.org Telecoms [EMAIL PROTECTED] http://www.WaveneyConsulting.com Web services [EMAIL PROTECTED]http://www.wavwebs.com Independent Telecomms Specialist, ATM expert, Web Analyst & Services
Re: This weeks Perl 6 summary
On Wed 06 Nov, Piers Cawley wrote: > miniparrot, a first attempt > If you've been paying attention to the Parrot build process, you'll be > aware that it was always a goal to use a cut down variant of parrot > itself to run the configuration tests. The plan is that this miniparrot > should be buildable with nothing more than an ANSI compliant C > compiler. Should this be called budgie? :-) -- Personal [EMAIL PROTECTED]http://www.waveney.org Telecoms [EMAIL PROTECTED] http://www.WaveneyConsulting.com Web services [EMAIL PROTECTED]http://www.wavwebs.com Independent Telecomms Specialist, ATM expert, Web Analyst & Services
Re: String concatentation operator
On Thu 14 Nov, Michael G Schwern wrote: > On Thu, Nov 14, 2002 at 12:19:47PM +, Andy Wardley wrote: > > Can we overload + in Perl 6 to work as both numeric addition > > and string concatenation, depending on the type of the operand > > on the left? There have been times when I have wondered if string concatination could be done without any operator at all. Simply the placement of two things next to each other as in $foo $bar or $foo$bar would silently concatenate them. But then I feel there are some deep horrors and ambiguities that I have failed to spot... Richard -- Personal [EMAIL PROTECTED]http://www.waveney.org Telecoms [EMAIL PROTECTED] http://www.WaveneyConsulting.com Web services [EMAIL PROTECTED]http://www.wavwebs.com Independent Telecomms Specialist, ATM expert, Web Analyst & Services
Re: In defense of zero-indexed arrays.
On Thu 05 Dec, Michael G Schwern wrote: > So here's your essay topic: > > Explain how having indexes (arrays, substr, etc...) in Perl 6 start at 0 > will benefit most users. Do not invoke legacy. [1] > > [1] ie. "because that's how most other languages do it" or "everyone is > used to it by now" are not valid arguments. Ask any Pascal programmer. :) Many years ago I was involved with a project where all the software people reffered to the hardware as planes 0 and 1 (it was a duplicated system) and the hardware people always used 1 and 2. To avoid confusion we settled on using 0 and 2. Any way of indexing arrays has its proponents. Perl currently has the heavily depreciated $[ to allow playing with this base, changing it has nasty affects at a distance. Long long ago some computer languages did base their arrays at 1 rather than 0. Hopefully they are dead now - it led to confusion and bad practices. But that is a legacy argument. There was an argument when computer languages were close to the hardware, when to index an array you added the index (multiplied by the size of the element) to the base of the array to find what you wanted. This is probably insignificant and not an issue today. To conclude other than a very large legacy argument, there is probably no strong reason to base arrays at 0 rather than 1. I would not want to change. Richard -- Personal [EMAIL PROTECTED]http://www.waveney.org Telecoms [EMAIL PROTECTED] http://www.WaveneyConsulting.com Web services [EMAIL PROTECTED]http://www.wavwebs.com Independent Telecomms Specialist, ATM expert, Web Analyst & Services
Re: right-to-left pipelines
On Wed 11 Dec, Simon Cozens quoted: > No proper program contains an indication which as an operator-applied > occurrence identifies an operator-defining occurrence which as an > indication- applied occurrence identifies an indication-defining occurrence > different from the one identified by the given indication as an > indication-applied occurrence. - Algol 68 Report My father in law (Charles Lindsey) says that para in the Algol 68 Report is not his. Richard -- Personal [EMAIL PROTECTED]http://www.waveney.org Telecoms [EMAIL PROTECTED] http://www.WaveneyConsulting.com Web services [EMAIL PROTECTED]http://www.wavwebs.com Independent Telecomms Specialist, ATM expert, Web Analyst & Services
A6: multi promotion
If one has a simple sub such as factorial:
sub factorial(int $a) {...}
then one subsequently declares the multi form of factorial to pick up the
non-integer form:
multi factorial(num $a) {...}
Does this promote the original declaration of factorial to a multi?
if not what happens?
Richard
--
Personal [EMAIL PROTECTED]http://www.waveney.org
Telecoms [EMAIL PROTECTED] http://www.WaveneyConsulting.com
Web services [EMAIL PROTECTED]http://www.wavwebs.com
Independent Telecomms Specialist, ATM expert, Web Analyst & Services
Re: A6: multi promotion
On Wed 12 Mar, Michael Lazzaro wrote: > > On Tuesday, March 11, 2003, at 12:39 PM, Austin Hastings wrote: > > You want C to tell the compiler to build in multiple dispatch. > > Any invocation of C after C is going to be a penny > > dropped into the great Pachinko game of multimethod-dispatchery. By > > default, if no winning multi appears, the call falls out the bottom and > > winds up invoking the original sub(). > > OK, hmm. What Damian is saying is that, tentatively, it's the > reverse... it calls the sub if theres a sub, then the multi if there's > a multi. So overriding a sub with a multi wouldn't work, but it would > *silently* not work, because you could just never get to the multi > version (well, not without a bit of introspection). Messy > > I agree that the issue of overriding an inherited/preexisting C -- > like one from a CPAN module -- with a set of C implementations > is a useful capability; it would allow you to extend predefined > routines to handle different arguments without getting into OO. But I > sure worry that it makes accidental redefinition of subs invisible in > many cases. > Perhaps it should be possible to explicitly promote (or is it demote?): sub factorial is multi; Richard -- Personal [EMAIL PROTECTED]http://www.waveney.org Telecoms [EMAIL PROTECTED] http://www.WaveneyConsulting.com Web services [EMAIL PROTECTED]http://www.wavwebs.com Independent Telecomms Specialist, ATM expert, Web Analyst & Services
