Re: Logo considerations
Timothy S. Nelson wrote [on p6l]: On Tue, 24 Mar 2009, Timothy S. Nelson wrote: On Mon, 23 Mar 2009, Richard Hainsworth wrote: 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. Ok, I've attached a logo mockup of lazy, (supposedly) parallel lions that are strangely attracted to each other. Think of this logo mockup as a wiki -- feel free to hack on it, especially if you can get the lions to be hubristically superpositioned while also remaining parallel and attracted. Or, if we made the magnetic lines of force hexagonal (inspired by Conrad Schneiker), and superpositioned (ie. superimposed) the whole thing over the Parrot logo, that would be kinda cool. Although if we keep going like this, the logo will look like a Graeme Base picture. If you're going for sciencey or mathey illustrations, then I think its important to include something that speaks quantum physics in there, since quantum superpositions aka Junctions are one of the big central user features that Perl 6 provides which is relatively new to languages in general. For example, one particularly iconic illustration is the cat in the sealed box with poison and a Geiger counter, aka Schrödinger's cat. Or rather than images of an alive and dead cat superimposed, you could have images of other mutually exclusive things superimposed. And depending on what things you choose, then those items can pull multiple-duty as other symbols (a boon to a logo); eg, those 2 lions, depending how you look at it, could be either powerful/lazy, or alive/dead. Mind you, you don't want to go too far away such that it isn't easy to perceive the quantum interpretation without being told it is there. On a related matter, remember that when going for a logo you don't want to make it *too* complicated. With symbols, often less is more. And also we probably want something that will work scaled up or down. It should certainly look good as black and white line-art. I know they are more examples, but some things I saw suggested looked a bit too complicated. On the other hand, arguably the gimel is too simple. But I'm sure something good can be worked out. -- Darren Duncan
Re: Logo considerations
On Tue, 24 Mar 2009, Timothy S. Nelson wrote: On Mon, 23 Mar 2009, Richard Hainsworth wrote: 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. Is there a way we can also show it to be impatient and hubristic? :) 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. Ok, I've attached a logo mockup of lazy, (supposedly) parallel lions that are strangely attracted to each other. Think of this logo mockup as a wiki -- feel free to hack on it, especially if you can get the lions to be hubristically superpositioned while also remaining parallel and attracted. Or, if we made the magnetic lines of force hexagonal (inspired by Conrad Schneiker), and superpositioned (ie. superimposed) the whole thing over the Parrot logo, that would be kinda cool. Although if we keep going like this, the logo will look like a Graeme Base picture. :) - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y- -END GEEK CODE BLOCK-
Re: Logo considerations
On Mon, 23 Mar 2009, Richard Hainsworth wrote: 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. Is there a way we can also show it to be impatient and hubristic? :) 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. Ok, I've attached a logo mockup of lazy, (supposedly) parallel lions that are strangely attracted to each other. Think of this logo mockup as a wiki -- feel free to hack on it, especially if you can get the lions to be hubristically superpositioned while also remaining parallel and attracted. HTH, - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y- -END GEEK CODE BLOCK- <>
Re: Logo considerations
On Mon, Mar 23, 2009 at 09:22, Richard Hainsworth 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: r25902 - docs/Perl6/Spec
pugs-comm...@feather.perl6.nl wrote: > Author: lwall > Date: 2009-03-19 01:43:53 +0100 (Thu, 19 Mar 2009) > New Revision: 25902 > > Modified: >docs/Perl6/Spec/S05-regex.pod > Log: > [S05] define .caps and .chunks methods on match objects > > > Modified: docs/Perl6/Spec/S05-regex.pod > === [...] > @@ -2547,6 +2547,9 @@ > $/.chars # $/.to - $/.from > $/.orig # the original match string > $/.Str # substr($/.orig, $/.from, $/.chars) > +$/.ast # the abstract result associated with this node > +$/.caps # sequential captures > +$/.chunks # sequential tokenization > > Within the regex the current match state C<$¢> also provides > > @@ -2558,6 +2561,18 @@ > > =item * > > +As described above, a C in list context returns its positional > +captures. However, sometimes you'd rather get a flat list of tokens in > +the order they occur in the text. The C<.caps> method returns a list > +of every captured item, regardless of how it was otherwise bound into > +named or numbered captures. The C<.chunks> method returns the captures > +as well as all the interleaved "noise" between the captures. [Conjecture: > +we could also have C<.deepcaps> and C<.deepchunks> that recursively expand > +any capture containing submatches. Presumably each returned chunk would > +come equipped with some method to discover its "pedigree" in the parse tree.] Could you elaborate on the "items" you are talking about? simple strings for non-captures and Match objects for captures? Or pairs of the form $name => $capture or $number => $capture for captures? (Either way is fine by me, I just want to know how to write the tests ;-) Cheers, Moritz
r25970 - docs/Perl6/Spec
Author: lwall Date: 2009-03-23 02:27:32 +0100 (Mon, 23 Mar 2009) New Revision: 25970 Modified: docs/Perl6/Spec/S05-regex.pod Log: clarifications to .caps and .chunks requested by moritz++ Modified: docs/Perl6/Spec/S05-regex.pod === --- docs/Perl6/Spec/S05-regex.pod 2009-03-23 00:41:38 UTC (rev 25969) +++ docs/Perl6/Spec/S05-regex.pod 2009-03-23 01:27:32 UTC (rev 25970) @@ -14,9 +14,9 @@ Maintainer: Patrick Michaud and Larry Wall Date: 24 Jun 2002 - Last Modified: 18 Mar 2009 + Last Modified: 22 Mar 2009 Number: 5 - Version: 93 + Version: 94 This document summarizes Apocalypse 5, which is about the new regex syntax. We now try to call them I rather than "regular @@ -2562,15 +2562,35 @@ =item * As described above, a C in list context returns its positional -captures. However, sometimes you'd rather get a flat list of tokens in -the order they occur in the text. The C<.caps> method returns a list -of every captured item, regardless of how it was otherwise bound into -named or numbered captures. The C<.chunks> method returns the captures -as well as all the interleaved "noise" between the captures. [Conjecture: -we could also have C<.deepcaps> and C<.deepchunks> that recursively expand -any capture containing submatches. Presumably each returned chunk would -come equipped with some method to discover its "pedigree" in the parse tree.] +captures. However, sometimes you'd rather get a flat list of tokens +in the order they occur in the text. The C<.caps> method returns +a list of every capture in order, regardless of how it was otherwise +bound into named or numbered captures. (Other than order, there is +no new information here; all the elements of the list are the very +same C objects that bound elsewhere.) The bindings are actually +returned as key/value pairs where the key is the name or number under which +the match object was bound, and the value is the match object itself. +In addition to returning those captured C objects, the +C<.chunks> method also returns all the interleaved "noise" between +the captures. As with C<.caps>, the list elements are in the order +they were originally in the text. The interleaved bits are also returned +returned as pairs, where the key is '~' and the value +is a simple C object containing only the string, even if unbound +subrules such as C<.ws> were called to traverse the text in the first +place. Calling C<.ast> on such a C object always returns a C. + +A warning will be issued if either C<.caps> or C<.chunks> discovers +that it has overlapping bindings. In the absence of such overlap, +C<.chunks> guarantees to map every part of its matched string (between +C<.from> and C<.to>) to exactly one element of its returned matches, +so coverage is complete. + +[Conjecture: we could also have C<.deepcaps> and C<.deepchunks> that +recursively expand any capture containing submatches. Presumably the +keys of such returned chunks would indicate the "pedigree" of bindings +in the parse tree.] + =item * All match attempts--successful or not--against any regex, subrule, or
r25969 - docs/Perl6/Spec
Author: lwall Date: 2009-03-23 01:41:38 +0100 (Mon, 23 Mar 2009) New Revision: 25969 Modified: docs/Perl6/Spec/S02-bits.pod Log: clarify (we hope) how the top-level lexical, package, and dynamic scopes interact Modified: docs/Perl6/Spec/S02-bits.pod === --- docs/Perl6/Spec/S02-bits.pod2009-03-22 21:17:38 UTC (rev 25968) +++ docs/Perl6/Spec/S02-bits.pod2009-03-23 00:41:38 UTC (rev 25969) @@ -12,9 +12,9 @@ Maintainer: Larry Wall Date: 10 Aug 2004 - Last Modified: 18 Mar 2009 + Last Modified: 22 Mar 2009 Number: 2 - Version: 160 + Version: 161 This document summarizes Apocalypse 2, which covers small-scale lexical items and typological issues. (These Synopses also contain @@ -1866,6 +1866,47 @@ code that is executing the eval.) In more traditional terms, the normal program is functioning as the "prelude" of the eval. +So the outermost lexical scopes nest like this, traversed via C: + +CORE <= SETTING < UNIT < (your_block_here) + +The outermost packages scopes nest like this, traversed via C: + +GLOBAL < (your_package_here) + +You main program starts up in the C package and the C +lexical scope. Whenever anything is declared with "our" semantics, it +inserts a name into both the current package and the current lexical +scope. (And "my" semantics only insert into the current lexical +scope.) Note that the standard setting, C, is a lexical scope, +not a package; the various items that are defined within (or imported +into) C are *not* in C, which is pretty much empty when +your program starts compiling, and mostly only contains things you +either put there yourself, or some other module put there because +you used that module. In general things defined within (or imported +into) C should only be declared or imported with "my" semantics. +All Perl code can see C anyway as the outermost lexical scope, +so there's no need to also put such things into C. + +The C package itself is rooted at C. +The C package is rooted at C. You will note +that C is not the parent of C. However, searching +up the dynamic stack for context variables will look in all nested +dynamic scopes (mapped automatically to each call's lexical scope, +not package scope) out to C; once all the dynamic scopes are +exhausted, it also looks in the C package and then in the +C package, so C<$*OUT> typically finds the process's standard +output handle. + +Any context variable declared with C in the user's main program +(specifically, the part compiled with C as the current package) +is accessible (by virtue of being in C) as a context variable +even if not directly in the dynamic call chain. Note that context +vars do *not* look in C for anything. (They I look in +C if you're running under a setting distinct from C, +if that setting defines a dynamic scope outside your main program, +such as for the C<-n> or C<-p> switch.) + =item * You may interpolate a string into a package or variable name using
Logo considerations
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. Richard
r25966 - docs/Perl6/Spec
Author: moritz
Date: 2009-03-22 21:58:27 +0100 (Sun, 22 Mar 2009)
New Revision: 25966
Modified:
docs/Perl6/Spec/S14-roles-and-parametric-types.pod
Log:
[S14] use named arguments to .new() in an example
Modified: docs/Perl6/Spec/S14-roles-and-parametric-types.pod
===
--- docs/Perl6/Spec/S14-roles-and-parametric-types.pod 2009-03-22 20:03:56 UTC
(rev 25965)
+++ docs/Perl6/Spec/S14-roles-and-parametric-types.pod 2009-03-22 20:58:27 UTC
(rev 25966)
@@ -98,7 +98,7 @@
Roles may have attributes:
role Pet {
-has $.collar = Collar.new(Tag.new);
+has $.collar = Collar.new(tag => Tag.new);
method id () { return $.collar.tag }
method lose_collar () { undefine $.collar }
}
