Re: How are unrecognized options to built-in pod block types treated?
On Wed, Aug 4, 2010 at 15:56, Damian Conway dam...@conway.org wrote: Carl proposed: The other path that seems reasonable to me would be to use the same naming scheme as for the block types, i.e. reserve all-upper and all-lower forms (and die if an unrecognized one of this form is encountered), and let the custom ones live in the namespace of mixed-case identifiers. That sounds sane to me as well; the only question is whether that much structure is needed for config options. I did not consider this issue when designing S26, but in considering it now, I think Carl's suggestion is entirely sensible and in line with what I intended. Specifically, I think it would be easiest to be consistent and say that all purely lowercase and all purely uppercase config option names are reserved, and that unrecognized reserved config options generate at least a warning when they are parsed. Mixed-case config options should be freely available to users and the parser should simply accept them without complaint and include them in the internal data structure it builds, whereupon they will be available to user-defined Pod extensions. Damian are there codepoints in unicode that may be either upper-case or lower-case, depending on the charset? if so, then there's ambiguity here, depending on the user's locale. i suspect not, but languages are strange beasts, and i don't know the answer. ~jerry
Re: Radix (base) conversion
On Fri, Jul 23, 2010 at 05:17, Jan Ingvoldstad frett...@gmail.com wrote: Hi. I was fiddling about with a small example of how nice radix adverbials are for conversion: my $x = 6*9; say :13($x); rakudo: 69 ($x = 54 in base 10, but 54 in base 13 is 69 in base 10.) Strangely enough, I cannot find a way — in the spec — of both treating a number as something in base 13 as well as displaying it in base 13. sprintf() has formats for binary, octal and hexadecimal, but there appears no way to use an arbitrary base. As a clarification, see this example form bc(1): obase=13 print What do you get when you multiply six by nine? ; 6*9 What do you get when you multiply six by nine? 42 obase=10 Am I missing something? It is also somewhat confusing that while $x stores the result of the multiplication of 6*9, the adverbial radix conversion treats the variable as a literal and no longer a value. -- Jan perhaps a Rat should be displayed, with the base as denominator? say :13(6 * 9); # 42/13 ~jerry
Re: Radix (base) conversion
On Fri, Jul 23, 2010 at 07:45, Mark J. Reed markjr...@gmail.com wrote: No, 42/13 is 42 over 13, which is 3 + 3/13. Let's not confuse fractions and bases, please. ha! yet another case of crossed wires too early in the morning. sorry for the confusion, i've been making similar apologies all day. too bad i don't drink coffee ~jerry
Re: Command-line args (weekly contribution to P6)
On Wed, May 26, 2010 at 00:53, Moritz Lenz mor...@faui2k3.org wrote: The spec doesn't elaborate on how the short args are specified in the signature of MAIN. I see two possible approaches (that don't contradict): 1) one renames them in the signature, so it would like sub MAIN(:name(:$n)) then $n has two names, 'name' and 'n', and we could consider all one-letter parameter names as short names this is what was intended in the spec. if you can update it to stamp out the ambiguity, that would be most welcome. 2) Iterate over all named parameters and build unambiguous prefixes. If any of them is just one letter short, we consider it a short name. Anz opinions from p6l about it? this method has too much magic. ~jerry
Re: r29129 - docs/Perl6/Spec
On Thu, Nov 19, 2009 at 08:17, Thom Boyer t...@boyers.org wrote: I'm curious about the change from blorst to blast. I quickly figured out that blorst was derived from BLock OR STatement (as S04 used to say: In fact, most of these phasers will take either a block or a statement (known as a Iblorst in the vernacular)). The best that I can figure for blast is BLock And STatement. But using AND seems less correct to me. Furthermore, blast is less likely to google up the results I need. So, what exactly _is_ the derivation of blast? perhaps 'BLock or A STatement' or 'BLock, Alternatively, STatement', or you can simply think of it as misspelled but nicer on the ears than the eyes. ~jerry
Announce: Rakudo Perl 6 development release #21 (Seattle)
On behalf of the Rakudo development team, I'm pleased to announce the September 2009 development release of Rakudo Perl #21 Seattle. Rakudo is an implementation of Perl 6 on the Parrot Virtual Machine [1]. The tarball for the September 2009 release is available from http://github.com/rakudo/rakudo/downloads . Due to the continued rapid pace of Rakudo development and the frequent addition of new Perl 6 features and bugfixes, we recommend building Rakudo from the latest source, available from the main repository at github. More details are available at http://rakudo.org/how-to-get-rakudo. Rakudo Perl follows a monthly release cycle, with each release code named after a Perl Mongers group. September 2009 is code named Seattle for the enthusiasm they have shown for Perl 6 during monthly meetings, and the feedback, encouragement and support given me for the past several years. Since the 2009-08 release, Rakudo Perl builds from an installed Parrot instead of using Parrot's build tree. This release of Rakudo requires Parrot 1.6.0. For the latest information on building and using Rakudo Perl, see the README file section titled Building and invoking Rakudo. (Quick note: the --gen-parrot option still automatically downloads and builds Parrot as before, if you prefer that approach.) Also, unlike previous versions of Rakudo Perl, the perl6 (or perl6.exe) executables only work when invoked from the Rakudo root directory until a make install is performed. Running make install will install Rakudo and its libraries into the Parrot installation that was used to build it, and then the executables will work when invoked from any directory. Some of the specific major changes and improvements occuring with this release include: * Rakudo is now passing 15,497 spectests, an increase of 3,128 passing tests since the August 2009 release. With this release Rakudo is now passing 71.5% of the available spectest suite. * Rakudo now supports contextual variables. * Rakudo now supports the rational (Rat) data type. * Rakudo now supports overloading of many of the builtin operators, many of which are now defined in the core setting. Many have also been improved to be more faithful to the specification with respect to types and coercions. * Substantially improved support for trait handling. Most of the built-in traits are now defined in the core setting. * The %*ENV variable now works properly for modifying the process environment. Since the Perl 6 specification is still in flux, some deprecated features have been removed from Rakudo. Prominently among those are: * '=$handle' is deprecated in favor of '$handle.get' (one line) and '$handle.lines' (all lines). * 'int $obj' is deprecated in favor of '$obj.Int'. The development team thanks all of our contributors and sponsors for making Rakudo Perl possible. If you would like to contribute, see http://rakudo.org/how-to-help , ask on the perl6-compi...@perl.org mailing list, or ask on IRC #perl6 on freenode. The next release of Rakudo (#22) is scheduled for October 22, 2009. A list of the other planned release dates and codenames for 2009 is available in the docs/release_guide.pod file. In general, Rakudo development releases are scheduled to occur two days after each Parrot monthly release. Parrot releases the third Tuesday of each month. Have fun! References: [1] Parrot, http://parrot.org/
Parrot 1.6.0, half-pie Released!
On behalf of the Parrot team, I'm proud to announce Parrot 1.6.0 half-pie. Parrot (http://parrot.org/) is a virtual machine aimed at running all dynamic languages. Parrot 1.6.0 is available on Parrot's FTP site, or follow the download instructions at http://parrot.org/download. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion on the source code repository to get the latest and best Parrot code. Parrot 1.6.0 News: - Functionality + Added a fixed-size structure allocator to the Garbage Collector + Added a lazy mode to the PObj and Fixed-Size memory allocators + Added a profiling runcore, which generates Callgrind-compatible output + Added lexical subsystem opcodes: find_dynamic_lex, store_dynamic_lex + Converted Contexts to garbage-collectable PMC structures + Created a new Context API + Enhanced the PMC allocator to automatically allocate ATTR structures - Performance + Optimized opcodes to cache the current Context for subsequent lookups + Reduced string comparisons in VTABLE_isa - Maintenance and cleanup + Began proper encapsulation of STRING API + Unified all PMC destruction functions + Unified Continuation PMC and Parrot_cont structure + Unified Sub PMC and Parrot_sub structure + Removed PMC_EXT structure + Removed PMC_Sync from PMC + Removed UnionVal from PMC structure - Bugfix + Fixed several stack-walking bugs in Garbage Collector code + Fixed bug when copying a NULL STRING, now returns empty STRING struct - Tests + Converted several Perl5 tests to PIR + Expanded test coverage of NameSpace PMC - Compilers + Made Parrot Compiler Toolkit available in the base install Many thanks to all our contributors for making this possible, and our sponsors for supporting this project. Our next scheduled release is 20 October 2009. Enjoy! ~particle
Re: S26 - The Next Generation
On Wed, Aug 19, 2009 at 11:03, Kyle Hasselbacherkyl...@gmail.com wrote: Perl 5 programmers are sometimes surprised to find that 'perl -c strange.pl' can execute code. Imagine their surprise to find that 'perl6doc' does too. this is why it's spelled 'perl6 --doc', which should give you some hint that you're running the compiler, just as 'perl -c' does, and 'perldoc' doesn't. ~jerry
Re: Logo considerations
On Mon, Mar 23, 2009 at 09:22, Richard Hainsworth rich...@rusrating.ru wrote: Hats off to the designer of the gimel symbol - the associations with anarchy are probably right for perl6. But to be honest, a letter didnt quite inspire me. Since, I dont want to criticize without providing other ideas, here are some thoughts. Logos can contain meaning. I am not sure whether the Camel was chosen for a meaning, or because it was something to put on a book cover. But one could say, it is an animal that goes into a desert where no others can. Sort of going where no one has gone before. There seem to be a lot of animals attached to software things, such as a camel, but also a penguin and a parrot. So how about choosing another animal for perl6? My choice would be a lion, perhaps one lazing in the sun. The meaning that it is lazy, but it has raw power when it needs, and is the king of the jungle. Alternatively, if we stay away from animals, then how about something to do with parallelism, or super-positioning, or even a strange attractor, since perl6 can be strange and yet it is attractive. there have been plenty of good ideas and it's great to see an open discussion on this topic. however, since it hasn't been mentioned before, know that the camel, in relation to perl, is the sole property of o'reilly. this is why tpf doesn't use the camel--instead it uses an onion. i'm interested to see what comes out of this discussion, but a camel isn't an option. ~jerry
Re: r25745 - docs/Perl6/Spec
On Mon, Mar 9, 2009 at 10:16, Patrick R. Michaud pmich...@pobox.com wrote:
On Sun, Mar 08, 2009 at 09:43:17AM +0100, pugs-comm...@feather.perl6.nl
wrote:
=item * ws
Match whitespace between tokens.
=item * space
Match a single whitespace character. Hence C ws is equivalent to C
space+ .
The definitions of ws and space above are incorrect, or at least
misleading. ws matches required whitespace between pairs of word
characters; it's optional whitespace otherwise. The default definition
of ws is something like:
token ws { ?before \w ?after \w ! || \s* }
It's certainly _not_ the case that ws is equivalent to space+ .
To make things a bit quicker for people writing custom versions of
ws (which may need to include comment whitespace), the Parrot
Compiler Toolkit also provides an optimized ww rule that matches
only between a pair of word characters. Then the default definition
of ws becomes
token ws { !ww \s* }
Grammars can change this to things like:
token ws { !ww [ \s+ || '#' \h* \n ]* }
if you need a mnemonic to help you remember what 'ww' means, use 'within word'.
this reminds me that pge's ww may be incorrect in its treatment of
apostrophe. these characters (['-] by default) are word
characters, but i don't think that's been tested, and i don't think
it's been implemented, either.
~jerry
Re: Google's Summer of Code 2009
On Sun, Mar 1, 2009 at 17:26, Hinrik Örn Sigurðsson hinrik@gmail.com wrote: Google has announced this year's Summer of Code[1]. The Perl Foundation accepted one project (mentored by Moritz) related to Perl 6 last year[2]. I was wondering if there are any developers interested in mentoring students on Perl 6-related projects this year. I for one would like to apply (as a student) for some Perl 6 work. 1. http://code.google.com/soc/ 2. http://code.google.com/soc/2008/perl/about.html i'm glad your interest is building, based on last year's successes. this year, the perl foundation will again apply as a mentoring organization for google summer of code. leading the effort will be jonathan leto, one of last year's mentors, stepping up to fill eric wilhelm's role as organization administrator. like last year, tpf will encourage applications for both perl 5 and perl 6 projects, and parrot projects as well (as long as they're perl-related). last year, if i recall correctly, 44 mentors applied for tpf, and 25 student applications were received (of which 16 met the tpf standard for acceptance). google allocated 6 slots to tpf, and 5 projects were completed. this year, i expect more organizations and more students will apply, and i know both fewer organizations and fewer students will be accepted into the program. if the perl foundation is accepted again (i have high hopes), you should know that the perl community is extremely generous. i have no doubt tpf will again see more volunteers show interest in mentoring students than students applicants, and i expect there will be many more project applications than acceptances. stay tuned for more info, as tpf is just starting up the hype machine. until that gets going, you might start looking at last year's projects page [1] for previous ideas, and if you're really serious, you can start working on your proposal. expect this year's standard for acceptance to be similar to last year's, and expect the competition to be greater. ~jerry 1. http://www.perlfoundation.org/perl5/index.cgi?gsoc2008_projects)
Re: RFD: Built-in testing
On Fri, Jan 23, 2009 at 12:37, Dave Whipp d...@dave.whipp.name wrote: I could also imagine writing code that reads from an Sqlite database, and imposes that info onto the test. Whatever mechanism is used, I think we need a language-defined mechanism to supply a stable unique identifier for each test, so that it can be individually tracked and manipulated. Perhaps is only is the wrong way to implement the action-at-a-distance, but it does seem better (IMO) than a preprocessor. i don't understand the drive to have unique test identifiers. we don't have unique identifiers for every code statement, or every bit of documentation. why are tests so important/special/different that each warrants a unique id? that aside, this functionality sounds like it can be encapsulated in a module, if desired. as it stands, i can't see a reason reason it *has to* be made available in the core. as a recap, the discussions larry, patrick, moritz and i (and others, i'm sure) had on this topic long ago led to agreement that the most important characteristics for a portable specification test suite were: ~ the tests should be organized in such a way that it makes it easy to figure out to what bit of spec is under scrutiny (addressed by directory/filename standardization and smartlinks) ~ the test files mustn't be cluttered with code that implementations need ignore (comments are used, which are by default ignored, and can be preprocessed to customize the test for each implementation) ~ the skip/todo markers should be as close to the relevant tests as possible, so they're less likely to fall out-of-sync (the markers are in comments in the test file, directly above the tests) it's my view that spec tests should be easy to maintain for developers of multiple implementations, and uniqueness is an overly burdensome constraint. ~jerry
Re: RFD: Built-in testing
On Thu, Jan 22, 2009 at 09:22, Moritz Lenz mor...@faui2k3.org wrote:
Richard Hainsworth wrote:
But it is interesting to think about the case where a user wants two
different diagnostic test messages (to all the testing gurus out there:
do you actually want such a feature?). It shouldn't be too hard to do;
maybe just :OK('True message', 'False message')?
maybe
$x == $y :ok('message') :nok('failure message')
or
$x == $y
:ok({ .true ?? 'message' !! 'failure message' })
:diag( 'tap comment', :some_tap_propertysome values)
to handle success and failure messages, and set custom diagnostic info
in the tap stream. that is, as long as the result of the comparison is
available in $_ to the :ok adverb.
~jerry
Re: r24846 - docs/Perl6/Spec
On Fri, Jan 9, 2009 at 13:16, Eirik Berg Hanssen eirik-berg.hans...@allverden.no wrote: pugs-comm...@feather.perl6.nl writes: +C--prelude=Perl6-autoloop-no-print. Since eager matching is used, if you +need to pass something like: + ++foo -bar ++foo baz ++/foo ++/foo +you'll end up with + + %+OPTSfoo = '-bar ++foo baz'; That doesn't look very eager to me. it's eager for the match to close, which is the opposite of greedy matching. in perl 5 documentation, it's called non-greedy. for use and explanation of the terminology, see http://perlcabal.org/syn/S05.html#Backtracking_control. ~jerry
Re: r24846 - docs/Perl6/Spec
On Fri, Jan 9, 2009 at 14:26, Eirik Berg Hanssen
eirik-berg.hans...@allverden.no wrote:
jerry gay jerry@gmail.com writes:
On Fri, Jan 9, 2009 at 13:16, Eirik Berg Hanssen
eirik-berg.hans...@allverden.no wrote:
That doesn't look very eager to me.
it's eager for the match to close, which is the opposite of greedy
matching. in perl 5 documentation, it's called non-greedy. for use
and explanation of the terminology, see
http://perlcabal.org/syn/S05.html#Backtracking_control.
~jerry
If that's now the case, that's unfortunately confusing. In other
contexts, eagerness is leftmost (eager for matching to start, if
you like), which is orthogonal to greed:
# Perl Cookbook illustration of eagerness, expanded to demonstrate
# that the non-greedy case is equivalent:
$string = 'good food';
if ($greedy) {
$string =~ s/o*/e/; # 'egood food'
}
else {
$string =~ s/o*?/e/; # 'egood food'
}
Why not stick to non-greedy, if that's what you mean? Surely
that's not ambiguous?
i agree the wording isn't clear here, but it is consistent with the
current design language. i don't want to define something with a
negative, so i purposefully did not use non-greedy. i'll bring it up
at the next design meeting, so the linguists can weigh in.
~jerry
Re: r24711 - docs/Perl6/Spec
On Thu, Jan 1, 2009 at 03:30, Darren Duncan dar...@darrenduncan.net wrote: pugs-comm...@feather.perl6.nl wrote: --name :name --name=value:namevalue --name=spacy value:name«'spacy value'» --name='spacy value':name«'spacy value'» --name=val1,'val 2',etc :name«val1 'val 2' etc» +-n :name +-n=value :namevalue +-n=spacy value :name«'spacy value'» +-n='spacy value' :name«'spacy value'» +-n=val1,'val 2',etc:name«val1 'val 2' etc» --name :name# only if declared Bool --name=value :namevalue # don't care Is that right? Should the right column example not also be shortened to :n ? I thought the single-dash names only allowed a single character in a name on purpose, since multiple chars after a - were multiple options. -- Darren Duncan yes, it's right. options have both long and short names. perhaps you missed the change to the paragraph above: +Assuming C-n is the shortname for C--name, that reads short name (two words) as of r24732. if you want to set Cn to Cvalue, use C--n=value. ~jerry
Re: r24737 - docs/Perl6/Spec
On Fri, Jan 2, 2009 at 09:27, Geoffrey Broadwell ge...@broadwell.org wrote: On Fri, 2009-01-02 at 17:08 +0100, pugs-comm...@feather.perl6.nl wrote: +=head2 Synopsis + + multi sub perl6( +Bool :a($autosplit), +Bool :c($check-syntax), +Bool :$doc, +:e($execute), +:$execute-lax, #TODO fix illegal -e6 syntax. -6? not legal. -x? hrmm +Bool :F($autoloop-split), +Bool :h($help), +:I(@include), +#TODO -M, +Bool :n($autoloop-no-print), +:O($output-format) = 'exe', +:o($output-file) = $*OUT, +Bool :p($autoloop-print), +:S(@search-path), +Bool :T($taint), +Bool :v($version), +Bool :V($verbose-config), + ); I find this a little difficult to skim, because parallel things are not aligned. Aligning on ':' should make things much easier on the eyes: multi sub perl6( Bool :a($autosplit), Bool :c($check-syntax), Bool :$doc, :e($execute), :$execute-lax, Bool :F($autoloop-split), Bool :h($help), :I(@include), #TODO -M, Bool :n($autoloop-no-print), :O($output-format) = 'exe', :o($output-file) = $*OUT, Bool :p($autoloop-print), :S(@search-path), Bool :T($taint), Bool :v($version), Bool :V($verbose-config), ); thanks, done. Ah, that's a bit better. Looking at the above, is $execute-lax supposed to be a boolean, or is it really a generic scalar? It's also not obvious what a boolean named $doc does -- which probably means either that it's not supposed to be a boolean, or it needs a somewhat more descriptive long name (or both). --execute-lax is gone, since -e6 is just an idiomatic shortcut for --execute '6', which is outlined in Synopsis 11. Also, in Perl 5 taint is tri-valued, because it has a warnings-only mode. How will that be supported by Perl 6? well, perl 5 uses two flags for this, and i'm as yet undecided what to do about it.one argument is that i should keep the syntax from perl 5 consistent where possible. another argument is that taint warnings mode is relatively unused (and for development only) so doesn't deserve its own flag. maybe -t goes away, and -T takes a param that defaults to CTaintException but can be set to something like CTaintException does Resumable. Finally, how do the defaults of $output-file and $output-format interact so that the default behavior remains compile-and-execute? Changing the default to compile-to-exe seems unperlish to me i've gotten rid of default values for these options. they're strictly implementation-dependent. the syntax exists to allow rakudo to emit pbc files, and pugs to emit javascript, and i think is flexible enough for other implementations. maybe i'll remove them entirely, since they are implementation-dependent and can be done with ++metasyntax. in any case, the default behavior of perl 6 is unchanged from perl 5, which is compile-and-execute. ~jerry
Re: r24737 - docs/Perl6/Spec
On Fri, Jan 2, 2009 at 11:24, Geoffrey Broadwell ge...@broadwell.org wrote: Thank you for the quick turnaround! On Fri, 2009-01-02 at 10:55 -0800, jerry gay wrote: On Fri, Jan 2, 2009 at 09:27, Geoffrey Broadwell ge...@broadwell.org wrote: It's also not obvious what a boolean named $doc does -- which probably means either that it's not supposed to be a boolean, or it needs a somewhat more descriptive long name (or both). I think this is the only remaining item you had not yet responded to -- er, unless I missed it. 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). the most likely short names, C -d -o -c are all taken by either p5 or p6 command-line. i don't want to use C-d, because that has to do with the debugger in p5, so makes it harder for p6 to catch accidental usage. C--doc probably warrants a short name, since it will be called frequently--i hope, reducing irc traffic :) but i haven't decided on a good name yet. i'm open to suggestions. ~jerry
Re: 6PAN Spec question
On Thu, Dec 18, 2008 at 05:45, Mark Overmeer m...@overmeer.net wrote: * Daniel Ruoso (dan...@ruoso.com) [081218 13:39]: Em Qui, 2008-12-18 às 13:08 +1100, Timothy S. Nelson escreveu: My question is, what sort of information actually belongs in a final version of the 6PAN spec? I'm assuming it will at least include 6PAN Package format (layout, metadata, etc), and I'd suggest that it also include the layout of packages on the 6PAN server. 2) How source packages are uploaded, indexed, mirrored, searched, downloaded etc (6PAN/CPAN6) If you understand my explanation of CPAN6, then you certainly must be ware that 6PAN and CPAN6 have nothing to do with each other. Please do not use them in combination. It is as silly as saying TCP/Linux -- there's a difference? that was never clear to me (but i haven't read any docs). at best, they are incredibly, confusingly, similarly named. ~jerry
Re: Perl6's RE(P)L
On Wed, Dec 17, 2008 at 11:51, Moritz Lenz mor...@faui2k3.org wrote: Since Perl 5 has no REPL, I'm not sure where such a spec would go. S20, maybe, since the debugger is the closest thing? or maybe S19, because it defines the console interface to the rest of the world. Or just pick a not-yet-used number, S34, and have fun with it ;-) since i'm working on S19, i thought i'd speak up here. a spec for the perl 6 repl is not covered under my S19 ian hague grant. therefore, i have no plans to work on a repl spec in the short term. if it is determined that S19 is an appropriate place for the repl spec (it just might be), that shouldn't stop anybody from modifying that document. it's in the pugs repository so the community can easily contribute, after all. ~jerry
Parrot 0.8.0, Pareto Principle released
On behalf of the Parrot team, I'm proud to announce Parrot 0.8.0 Pareto Principle. Parrot (http://parrotcode.org/) is a virtual machine aimed at running all dynamic languages. Parrot 0.8.0 is available via CPAN, or follow the download instructions at http://parrotcode.org/source.html. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion on the source code repository to get the latest and best Parrot code. Parrot 0.8.0 News: - Implementation + float precision expanded to 15 significant digits from 6 + large integers autopromoted in PIR so as not to lose precision + improved precision of complex square root + exception handlers can register types of exceptions they catch - Languages + Cardinal (Ruby) - implemented gather, take, and yield builtins - Range, Time, Math, GC, Kernel classes - many more tests - added a new committer + Markdown : new lightweight markup language - start implementation with PCT/NQP + partcl (Tcl 8.5.4) - Moved to its own repository: http://code.google.com/p/partcl/ + Rakudo (Perl 6) - split() works with regexes - implemented Str.comb - ord() and chr() builtins - improved parsing of literal numbers - support for hyphens and dashes in identifiers - next() on for-loops - fixed floating point constant precision - improved namespace handling, closer to STD.pm model - support for exporting symbols - Compilers + P6object - now generates classes in nested namespaces instead of :: names - supports class creation in caller's HLL namespace + PCT / PGE - now using true nested namespaces instead of :: names - cleaned up HLLCompiler interactive prompts and readline mode - updated to use typed exception handler registration - added initial support for loop control exceptions + PIRC - fixed Heredoc preprocessor - cleaned up Macro preprocessor - many code clean-ups, warning fixes and consting - updated Makefile for easier compilation + IMCC - Added .tailcall syntax to replace .return in tailcall context - Examples + pirric (BASIC) - an old style line numbered Basic interpreter able to use parrot objects - example connecting to mysql via nci - example using classes to write and run an embedded Basic program - Documentation + Book - Added chapters for PCT, PMCs, and Opcodes/Runcores - Expanded and improved formatting in various chapters - Renumbered chapters Many thanks to all our contributors for making this possible, and our sponsors for supporting this project. Our next scheduled release is 18 Nov 2008. Enjoy! ~jerry
Re: Parrot 0.8.0, Pareto Principle released
The undefined warnings are known, and due mainly to the tests not being as carefully written as they should be. I believe there is a ticket in the rt queue, but i'm not able to search it from my phone. If nobody beats me to it, i'll point it out when i arrive at my destination. ~jerry On 10/24/08, Elyse M. Grasso [EMAIL PROTECTED] wrote: On Friday 24 October 2008, jerry gay wrote: On behalf of the Parrot team, I'm proud to announce Parrot 0.8.0 Pareto Principle. Parrot (http://parrotcode.org/) is a virtual machine aimed at running all dynamic languages. After an svn update and rebuild of parrot and rakudo, I ran 'make spectest' in parrot/languages/perl6. Everything passed that wasn't skipped, but the tests threw a lot of warnings: mostly a lot of Use of uninitialized value, but I also saw one Undefined value shifted from empty range. Is this expected behavior? Or is there something wrong with my setup? (Kubuntu 8.04) -- Elyse Grasso http://www.data-raptors.comComputers and Technology http://www.astraltrading.com Divination and Science Fiction http://www.data-raptors.com/global-cgi-bin/cgiwrap/emgrasso/blosxom.cgi WebLog -- Sent from Gmail for mobile | mobile.google.com
Re: [svn:perl6-synopsis] r14574 - doc/trunk/design/syn
On Fri, Aug 8, 2008 at 12:57 PM, Jon Lang [EMAIL PROTECTED] wrote: But are 'twas and -x valid identifiers? IMHO, they should not be. no, indeed they are not, because they don't start with underscore or alpha. that's why they won't work. ~jerry
Re: Catching exceptions with the // operator
On Wed, Aug 6, 2008 at 8:58 AM, Yaakov Belch [EMAIL PROTECTED] wrote:
In a little language that I wrote some time ago, I found it very useful to
let the // operator catch exceptions:
f(x) // g(y) does:
* If f(x) returns a defined value, use this value.
* If f(x) returns an undefined value, use the value of g(x) instead.
* If f(x) throws an exception, catch and keep it in $!, use the value of g(x)
* But don't catch exceptions of g(x).
Similarly, f(x) // g(y) // h(z) catches exceptions of f(x) and of g(y)
but not of h(z).
I would like to suggest the same semantics for perl6.
Let me explain why this is useful and why I think this is the right thing:
First of all, it provides a very light-weight exception handling using
well-known ideoms like:
$file_content=read_file($filename) // $default_value;
compute_statistics($data) // write_log_message(stats failed: $!);
With the proposed change, these ideoms work whether the functions throw
exceptions or not.
But why should this be the right thing? Obviously, // is the fallback
or redundancy operator: Don't despair if the first computation doesn't
produce a usable result --- we have another way of getting the job done.
In this context, and exception conveys the same message as an undefined
value: The first step failed. You need to fall back to some other
alternative or give up! As the second expression provides exactly this
other alternative, there is no need to jump out of the normal processing
order anymore.
i don't think this will work for perl 6. since perl 6 has resumeable
exceptions (like Cwarn), the meaning of the C// operator could be
ambiguous. given the following statement,
my $bill = ack() // thpp() // ppt();
with perl 6's current semantics, if Cack(), throws a resumable
exception that is handled in the current scope or an outer scope,
execution will resume before C// and the definedness of the result
from Cack() will be tested in order to determine whether or not to
call Cthpp().
using your semantics, if a resumable exception is thrown in Cack(),
C// will cause Cthpp() to be invoked immediately, discarding any
possible defined result from Cack(). also, the question arises that
if Cthpp() doesn't handle the type of exception thrown, should
Cppt() be called immediately, or only if Cthpp() returns an
undefined result? seems to me it would try to handle the exception
thrown by Cack(). so how do i signify that my exception has been
handled, and that i can now assign a default value to C$bill?
in my mind, this strays too far from the meaning of C// and adds
ambiguity that makes the operator unusable. perhaps there's room for
an operator that gives some sugar for
my $bill = try { ack() CATCH { thpp() } };
but to me that code is concise enough that it doesn't warrant syntactic relief.
~jerry
Re: step size of nums
2008/7/10 TSa [EMAIL PROTECTED]: HaloO, Larry Wall wrote: Well, maybe 0 .. 10-ε or some such. This ε there is what I have as the .step method of nums in the thread The Inf type. That is $min..^$max is the same as $min..($max-$max.step). For Ints the .step is always 1. For Nums it depends on the number, that is the spacing of Nums is non-uniform but discrete like Ints. That is what I call non-uniform Ints in contrast to Rats which are dense and their operations ++ and -- are undefined unless one wants to jump through the diagonalized Rats with skipped duplicates: 1++ - 1/2, 1/2++ - 1/3, 1/3++ - 2/3, 2/3++ - 1/4, 1/4++ - 3/4, etc. So, does it make sense to define ++ and -- for nums as $x++ meaning $x += $x.step? Or should these operators floor the value to an Int and step the result? my $x = 3.14; $x++; say $x; # num 4.14 or int 4? $x = 3.14159265358979323846e20; $x++; say $x; # int 314159265358979323847 # or int 31415926535897931 # or num 3.141592653589794e20 for 64bit float? The last two options above are because $x.step == 1e5. The exact value would need a float with 22 digits mantissa, i.e. a quad precision. least surprise (to me) says ++ always increments by 1 for numeric types. if you want to increment by ε, by all means create ε++ and ε-- ops. ~jerry
Parrot 0.6.1 Bird of Paradise Released
Aloha! On behalf of the Parrot team, I'm proud to announce Parrot 0.6.1 Bird of Paradise. Parrot (http://parrotcode.org/) is a virtual machine aimed at running all dynamic languages. Parrot 0.6.1 can be obtained via CPAN (soon), or follow the download instructions at http://parrotcode.org/source.html. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion or SVK on the source code repository to get the latest and best Parrot code. Parrot 0.6.1 News: - Specification + drafted pdd29_compiler_tools.pod + updated pdd28_character_sets.pod draft + updated pdd19_pir.pod draft - Languages + c99: added independent C pre-processor + HQ9+: reimplemented with PCT + Lua: . reimplementation with PCT, using PAST and POST . behavior aligned wih 5.1.3 + Rakudo: . implemented basic I/O, including '$*IN', '$*OUT', '$*ERR', 'prefix:=' . implemented simple typing and runtime type checking . added basic multi-method dispatch . expanded named argument handling, including Pair and colonpairs . added 'Whatever' and 'Capture' classes . implemented 'handles' trait verb . added 'loop' statement . implemented 'given', 'when', 'for', 'while', 'until' statement modifiers . implemented Hash methods '.keys' and '.values' . fixed bug to get '.WHAT' working correctly . initial implementation of 'eval' - Compilers + NQP: . created a bootstrapped build, see 'make boot' . added 'infix:', 'infix:=', 'infix:', 'infix:=' relational operators . added 'postfix:++', 'postfix:--' operators + PCT: . added methods specifying default behaviors in PAST, reducing repeated code . improved symbol table lookup + PGE: . removed deprecated code including: P6Regex, P6Grammar, PAST-pm - Miscellaneous + notable speedups during compilation and execution of parrot and HLLs + pdb (the parrot debugger) can now catch parrot exceptions + better detection of glibc and gettext during configuration + various bugfixes, code cleanups, deprecations, and coding standard fixes Mahalo to all our contributors for making this possible, and our sponsors for supporting this project. Enjoy! ~jerry
Re: Nomenclature Question - BEGIN etc.
On Wed, Apr 9, 2008 at 10:31 PM, John M. Dlugosz [EMAIL PROTECTED] wrote: Consider the words that may be used to introduce a block for a special purpose, like BEGIN END INIT CATCH etc. What do you call those? They are not even special named blocks because that is not the block name (that already means something). syntactically speaking, http://svn.pugscode.org/pugs/src/perl6/STD.pm groups them in statement_control, just like 'if' and 'for'. semantically speaking, i don't have a clever or unique name for them, other than what larry has already come up with. ~jerry
Re: failure notice
On Thu, Apr 10, 2008 at 11:23 AM, Larry Wall [EMAIL PROTECTED] wrote: On a larger question, I'm wondering if it's time to slush/freeze the Synopses as historical documents and put all spec effort into the new form (presumably as a wiki that knows how to serialize into a document). I don't think we have the bandwidth to maintain multiple standard documents. Well, okay, *I* don't have the bandwidth... from the perspective of a language implementor, i believe that formalization may be a benefit in the long term. however, it will cause some short-term disruption with which i'd greatly appreciate help. specifically, the spec test suite employs the use of smartlinks, which are pod-like tags used to relate a set of tests to specific locations in the synopses. modification of the spec format will require modification of the spec test suite, and the coverage/reporting tools (e.g. smartlinks.pl.) also, modification of the spec file type from .pod to .odf will certainly add to the complexity of any tool migration. as multiple implementations of the spec are now maturing, these tools have become more important to judging the progress of any implementation. also, as manager for the parrot and perl 6 projects under the perl foundation umbrella for google summer of code (GSoC), i'd like to note that there's a chance we'll have a student working on a project to improve the perl 6 test suite. i expect this student to make good use of today's existing tools, like smartlinks.pl, in the course of his project. reformatting the spec documents will likely implement this effort, and may lead to a failed project where the student will not be compensated. i certainly don't want to see that happen. i'll know more about whether or not this project has been accepted in the coming week. i hope that the hackathons during the upcoming conference season will be a place where folks can help us improve the spec test suite, and that a spec document format change today will be disruptive. i'd love to see folks helping out with migration to a new documentation format, as well, but i think it's easier if we keep the current documents up-to-date until the migration is considered complete. i believe that if we put effort into migrating to a new format, while keeping the current spec pod format as canon, and later (post-GSoC) marking the current spec documents as historical, it will allow time for implementation, documentation, and testing projects to move forward during the traditionally busy summer months. ~jerry
Parrot 0.4.16 Released
On behalf of the Parrot team, I'm proud to announce Parrot 0.4.16, A Farewell to Alex. Parrot (http://parrotcode.org/) is a virtual machine aimed at running all dynamic languages. Parrot 0.4.16 can be obtained via CPAN (soon), or follow the download instructions at http://parrotcode.org/source.html. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion or SVK on the source code repository to get the latest and best Parrot code. Parrot 0.4.16 News: - Implementation: + Performed code review on every PMC + Modified PMC code generation to use Storable, reducing compile times + Added a makefile target to generate test coverage data of C sources - Languages: + NQP: added lists, for loops, operators, comparison and multiplicative operators + Announced Kea-CL, Kea Common Lisp, an ANSI Common Lisp implementation The repository is available at https://rgrjr.dyndns.org/svn/kea-cl/trunk/ - Documentation + PDD17 PMCs - draft approved, the design is complete + Added more PIR tutorials, see examples/tutorial/00_README.pod - Miscellaneous: + Many bugfixes, enhancements, documentation, and coding standard updates + Deprecated PMC constants and other crufty syntax, see DEPRECATED.pod + Improved icc compiler compatibility for error line reporting Thanks to all our contributors for making this possible, and our sponsors for supporting this project. Enjoy! ~jerry
Re: [svn:perl6-synopsis] r14449 - doc/trunk/design/syn
On 9/6/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: @@ -1254,6 +1273,17 @@ =item * +A leading C? indicates a positive zero-width assertion, and like C! +merely reparses the rest of the assertion recursively as if the C? +were not there. In addition to forcing zero-width, it also suppresses +any named capture: + +alpha # match a letter and capture in $alpha ++alpha# match a letter, don't capture +?alpha# much null before a letter, don't capture + +=item * + A leading C~~ indicates a recursive call back into some or all of the current rule. An optional argument indicates which subpattern to re-use, and if provided must resolve to a single subpattern. s/much/match/
Re: Web Module (Was: Perl6 new features)
On 6/22/07, Chas Owens [EMAIL PROTECTED] wrote: Most of the time the policy is enacted by lower-case-l lazy sysadmins who can't be bothered to type perl -MCPAN -e install Foo::Bar My normal route around them is to install the module into the home directory of the user who is going to run the script, but I have had difficulty with this before when it comes time to move to production: Where is the code review for that code?. My answer of where is the code review for that (often open source) database install you just did? doesn't tend to hold the weight I wish it did. For some reason binary blobs make some types of sysadmins feel all fuzzy and warm inside. so use the parrot back end and compile all the modules to bytecode. oh, and you can merge the foreign module bytecode with the bytecode for your application, so it's all one big happy binary file. in fact, parrot will even provide a way to compile bytecode to a native executable which contains parrot itself. there, now you've got a proper binary with *zero* external requirements in the production environment--it doesn't even need to have parrot installed. at that point, i'd be surprised if the release engineers or sysadmins even notice. ~jerry
Re: Synopsis 26
On 3/18/07, Thom Boyer [EMAIL PROTECTED] wrote: I never could find the Pod-to-XHTML'd version of S26 -- the document attached to that email was S26.pod6, not S26.xhtml. I don't want to bug Damian, because obviously he has enough of life happening, as it were. But is the XHTML'd version of S26 available anywhere? I haven't been able to find it, and I don't read POD as well as all you perl veterans =thom -- alas, the pod parser has not yet been released. the only file format of S26 is the canon, written by damian in perl 6 pod format, (or pod6, or whatever it's called.) ~jerry
Re: [svn:perl6-synopsis] r13516 - doc/trunk/design/syn
On 1/7/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
+Matching against a CGrammar object will call the Ctop method
+defined in the grammar. The Ctop method may either be a rule
+itself, or may call the actual top rule automatically. How the
+CGrammar determines the top rule is up to the grammar, but normal
+Perl 6 grammars will default to setting top to the first rule in the
+original base grammar. Derived grammars then inherit this idea of
+the top rule. This may be overridden in either the base grammar or a
+derived grammer by explicitly naming a rule top, or defining your
+own top method to call some other rule.
Matching against a CSignature does not actually bind any variables,
but only tests to see if the signature Icould bind. To really bind
top--an all lowercase reserved word? it just doesn't stand out. all
grammars i've seen and written so far have used all lower-case rule
names.
if you're going to explicitly set a top rule, like a main sub, make it
all uppercase.
grammar DerivedGrammar is BaseGrammar;
rule TOP { ... }
that makes it more clear that something is special about that rule..
~jerry
Re: Don't tell me what I can't do!
On 10/2/06, Jonathan Lang [EMAIL PROTECTED] wrote: I'm not used to programming styles where a programmer intentionally and explicitly forbids the use of otherwise perfectly legal code. Is there really a market for this sort of thing? use strict;
Re: Don't tell me what I can't do!
On 10/2/06, Aaron Sherman [EMAIL PROTECTED] wrote: Jonathan Lang wrote: I'm not used to programming styles where a programmer intentionally and explicitly forbids the use of otherwise perfectly legal code. Is there really a market for this sort of thing? use strict; you're so twelve hours ago... :) http://groups.google.com/group/perl.perl6.language/tree/browse_frm/thread/56eeca9620d8c054/7f1d0eae0add6e96?rnum=1_done=%2Fgroup%2Fperl.perl6.language%2Fbrowse_frm%2Fthread%2F56eeca9620d8c054%2F7f1d0eae0add6e96%3Ftvc%3D1%26#doc_fef40e484e8b3acf or http://xrl.us/r2nz ~jerry
Re: Nested statement modifiers.
On 9/1/06, Trey Harris [EMAIL PROTECTED] wrote: In a message dated Fri, 1 Sep 2006, Paul Seamons writes: I'm not sure if I have seen this requested or discussed. This was definitively rejected by Larry in 2002: http://www.nntp.perl.org/group/perl.perl6.language/9343 He has not revisited the issue in the several times it has come up since. perhaps a sentence to that effect belongs in S04, which has no mention of nested statement modifiers, for or against. ~jerry
Re: Naming the method form of s///
On 8/31/06, Luke Palmer [EMAIL PROTECTED] wrote: On 8/31/06, Juerd [EMAIL PROTECTED] wrote: Still, though, How would you specify :g? It doesn't make a lot of sense on rx// -- just like you can't use it with qr// in Perl 5. It is a good point that it doesn't belong on the regex. Perhaps: $foo.subst(/bar/, baz, :g) That seems to work, though the weight is at the front again. Oh. $foo.subst(:g, /bar/, baz) i seem to recall $foo.subst(/:g bar/, baz) is valid syntax already. ~jerry
Re: clarifying the spec for 'ref'
On 8/25/06, Trey Harris [EMAIL PROTECTED] wrote: In a message dated Fri, 25 Aug 2006, Mark J. Reed writes: I think the justification for Luke's POV is the number of operations each class provides. But my perspective agrees with Juerd - subclasses can remove functionality as well as adding it, and I definitely view constant as an add-on modifier, not a default that has to be overridden. Can someone suggest some reading I can do to understand how that works? I can't wrap my head around the idea of subclasses removing functionality. perhaps trey meant subclasses can add constraints as well as functionality instead of subclasses can remove functionality as well as adding it. just a guess. ~jerry
designing a test suite for multiple implementations
recently, perl 6 development has taken the form of a multi-method dispatch. that is, multiple implementations are under active development. this includes pugs (in haskell,) v6 (in perl5,) v6-Compiler (in perl6,) and perl6 (on parrot.) hopefully, each of these returns the same result, a working[1] perl6 implementation. it makes sense for these implementations to share perl6 tests written from the perl6 specification. it is also important for this to happen, as it will help solidify the specification, allow implementations to check results against each other, share new and corrected tests easily, and be the canonical reference for answering questions about the spec. it is also important that only perl6 specification tests be shared; implementation-specific tests belong solely with the implementation.. few have ever created a test suite of this magnitude before--i certainly haven't, and don't expect anyone will do it alone. the overarching question i have is: how is an test suite targeted for multiple implementations designed, developed, managed, and controlled? i believe we can quickly address the developed question with the word organically. tests will be added, changed, or removed as needed. organization of tests in the suite will change over time as refactoring of any large body of tests or code is inevitable. this is the simple, practical solution we usually expect when working with perl. as for controlled, i expect restricted access to the test repository, as a protected body of tests is important to more people as soon as multiple implemenations are using it. providing a method of submitting and applying patches will allow anyone the ability to propose a new test for inclusion. for managed, i have a few ideas. currently, the suite lives in the pugs repo. this is a fine first approximation, but i believe it will soon be time to move this suite[3]. the question is, should it be moved into their own repository, or into the repo of the official perl6 implementation (if such a beast will indeed exist,) or should it live in some other place i haven't thought of yet? the options here are limited, and i believe straightforward. it should be easy to come to an agreement and take action. i've left the designed question for last, because i think it's the most difficult. perl6 test suite has already taken steps towards targeting multiple implementations. the suite has been designed with a set of sanity tests, which are required to pass successfully in order to run the perl6 Test module, which is written in perl6. this allows the remainder of the suite's test files to be written in perl6, making their representation independent of implementation. all the perl6 implementations i've mentioned above use this test suite, and pass some subset of the tests. this is a big win, and has allowed newer implementations to grow quickly as the course has already been laid. but unsolved problems remain. perl has a long history of testing. there are widely held beliefs on how to design and develop test suites. simple rules, like keeping like tests together, using good test descriptions, testing components in isolation, performing integrated tests, and marking tests as todo() or skip() when not working as expected. this last testing rule i mentioned becomes somewhat problematic when designing a test suite for use by multiple perl6 implementations. it is obvious that some implementations of perl6 will not pass all tests, and will need to mark certain tests as todo() and skip() in order to run the suite successfully. this is further complicated by the fact that perl6 is designed to be executed in multiple platforms. therefore, a test may succeed for a particular subset of implementations on a particular subset of platforms per implementation, but fail elsewhere. so, what should todo() information would look like, and where it should go? it's a tough problem, because there's a lot of pain, and it has to be shared somehow. if it's decided we are testing the specification, we should design implementation-independent tests. from this, it follows that implementation details (like todo()) should not exist in the test. instead, todo() info would be contained in a config file, or in a test harness, or by some other implementation-specific method. this is not ideal, since changes to the shared test suite may invalidate the todo() information in a particular implementation as test numbers or descriptions change. keeping todo info directly with the test means a particular implementation has this information with the test (as is currently best practice,) but it has it's downsides as well. test files become crowded with todo() statements and conditional logic for implementation- and platform-dependent todo()s. each time a new implementation is updated, the shared test suite will be modified, requiring (imo) unnecessary test suite changes. i should point out that implementation-specific tests must exist, but they must not be in a
Re: designing a test suite for multiple implementations
On 8/11/06, Larry Wall [EMAIL PROTECTED] wrote: Just to avoid repeating some of the discussion, here's a link to #perl6: http://colabti.de/irclogger/irclogger_log/perl6?date=2006-08-07,Monsel=110#l193 The discussion goes on and off for most of the rest of the page, so you probably want to search for and highlight todo if you're using firefox. thanks for the link, i didn't know #perl6 was logged. for those of you who may not know, on that channel i'm known as [particle]. Anyway, we thrashed the internal/external question pretty hard, and the rough consensus was to leave todos with the tests for now, but move to a todo() function that is easy to isolate, visually if nothing else. My own take on it is that we can just define the official tests to be the parts outside of todo() calls for now. that take seems to me like a particularly interesting form of blindness. however, it is a blindness that we (perl6 language implementors) would all share. using this definition, it seems we the blind should all be able to eventually describe this official elephant. But Jerry raises a lot of good questions that need to be answered over the long haul. Certainly by the time we have a real 6.0 we'll need to have worked out the policy and polity issues. For now, my gut feeling is that we'll need at least four times as many tests as we have so far, and rapid test development is best served by exercising the least amount of control. Trying to lock it down too early will simply stall the process for most of the million monkeys who are currently writing tests. Version control is our best friend here, at least for now. Trouble tickets are probably premature unless they're *very* lightweight. true, my questions are mainly long haul. i agree that control to the test repo should not *yet* be limited, so we can maintain our (seemingly quickening) pace of perl6 development. i don't intend to fix what isn't broken. the timely questions are those related to design, and implementation thereof. it is here where i hope suggestions like darren's (thanks!) and those from others with test design experience can lend a hand. ~jerry
Re: S04 - forbidden coding-style
On 7/25/06, Thomas Wittek [EMAIL PROTECTED] wrote: Bearing that in mind, would the eye-socket-burning return $foo IF $something; really be so bad? Operators/reserved words should be lowercase. Period. ;) I think that this would heavily break consistency, annoying new users. perhaps this can be enabled with a pragma? i suggest Cuse PERL; ~jerry :)
Re: A note for test writers
On 7/15/06, Leopold Toetsch [EMAIL PROTECTED] wrote: Folks, Please always verify test results, don't use the Parrot output of the test as the expected output. If you are implementing a new feature, write the *test first*. Thanks, leo PS from r13305: @@ -1324,7 +1324,7 @@ set P2, 300 # .Integer set P3, 246.246 # .Float div P2, P2, P3 - eq P2, 1, EQ4 + .fp_eq( P2, 1.218293, EQ4) 300 / 246.246 just isn't 1 exactly i'm pretty sure this was intended for p6i, not p6l, so i'm forwarding it there. ~jerry
Re: grammar: difference between rule, token and regex
On 6/2/06, Rene Hangstrup Møller [EMAIL PROTECTED] wrote: Hi I am toying around with Parrot and the compiler tools. The documenation of Perl 6 grammars that I have been able to find only describe rule. But the grammars in Parrot 0.4.4 for punie and APL use rule, token and regex elements. Can someone please clarify the difference between these three types, and when you should use one or the other? i'm forwarding this to p6l, as it's a language question and probably best asked there. that said, the regex/token/rule change is a recent one, and is documented in S05 (http://dev.perl.org/perl6/doc/design/syn/S05.html) in particular, see the Regexes really are regexes now section, which describes the differences. also, there are some recent threads on p6l with regard to this topic, which you may find enlightening. you can find these via google groups, or some other nntp archive. ~jerry
[PATCH] S02 - add grammar / rule info to sigil list
i noticed a few things missing from the list of sigils. patch inline below. ~jerry Index: design/syn/S02.pod === --- design/syn/S02.pod (revision 9154) +++ design/syn/S02.pod (working copy) @@ -494,8 +494,8 @@ $ scalar @ ordered array % unordered hash (associative array) - code -:: package/module/class/role/subset/enum/type + code/rule/token/regex +:: package/module/class/role/subset/enum/type/grammar @@ multislice view of @ Within a declaration, the C sigil also declares the visibility of the
the 'postfix:::' operator
that's postfix ::, as mentioned in the Names section of S02. snip There is no longer any special package hash such as %Foo::. Just subscript the package object itself as a hash object, the key of which is the variable name, including any sigil. The package object can be derived from a type name by use of the :: postfix operator: MyType::$foo snip i don't see it anywhere in S03. probably should be, if it indeed exists, method postfix. ~jerry
Re: S05: Interpolated hashes?
On 4/24/06, Larry Wall [EMAIL PROTECTED] wrote:
If you want to reset to before the key for some reason, you can always
set .pos to $KEY.beg, or whatever the name of the method is. Hmm,
that looks like it's unspecced.
BEGIN
.beg looks over-huffmanized to me. .begin is more natural to
english-speaking programmers, who have been using begin and end for
decades. if .beg will be used as .end's pair, i suggest this be kept
consistent, and BEGIN{} blocks be renamed as well.
BEGging the compiler to execute a block first is a mnemonic device,
but it doesn't work with the first example.
END
~jerry
