Re: Mailing list archive and index

2006-10-05 Thread Darren Duncan
At 5:45 PM -0400 10/4/06, Aaron Sherman wrote: I'm noodling around with the idea of creating an archive and index of all of the messages to the mailing list over the years for purposes of quickly finding all of the messages that have definitive information on a given topic. Simply searching on

Re: Don't tell me what I can't do!

2006-10-05 Thread jesse
On Wed, Oct 04, 2006 at 12:43:04PM -0700, chromatic wrote: On Wednesday 04 October 2006 12:09, jesse wrote: Perhaps I'm misunderstanding what you mean by person writing the program and person writing the libraries. In fact, I've _gotta_ be.  I'd like to be able to put my strictures in

Re: Don't tell me what I can't do!

2006-10-05 Thread jesse
On Wed, Oct 04, 2006 at 01:04:45PM -0700, chromatic wrote: On Wednesday 04 October 2006 12:48, jesse wrote: Ok. So, I think what you're saying is that it's not a matter of don't let people write libraries that add strictures to code that uses those modules but a matter of perl should

Re: class interface of roles

2006-10-05 Thread TSa
HaloO, Brad Bowman wrote: Sam Vilain wrote: This will be the same as requiring that a class implements a method, except the method's name is infix:==(::T $self: T $other) or some such. Sure. The point is, how does a role designer mix in the x and y coordinate attributes *and* augment the

Re: RFC: multi assertions/prototypes: a step toward programming by contract

2006-10-05 Thread TSa
HaloO, Larry Wall wrote: Basically, all types do Package whenever they need an associated namespace. Great! This is how I imagined things to be. And the reason why the :: sigil is also the separator of namespaces. And most of the Package role is simply: method postfix::: () { return

[svn:perl6-synopsis] r12736 - doc/trunk/design/syn

2006-10-05 Thread larry
Author: larry Date: Thu Oct 5 11:16:58 2006 New Revision: 12736 Modified: doc/trunk/design/syn/S04.pod Log: Removed hash composers from line-ending curly rule entirely. Now a parsefail. Modified: doc/trunk/design/syn/S04.pod

[svn:perl6-synopsis] r12737 - doc/trunk/design/syn

2006-10-05 Thread larry
Author: larry Date: Thu Oct 5 11:42:26 2006 New Revision: 12737 Modified: doc/trunk/design/syn/S04.pod Log: Bad dates... Modified: doc/trunk/design/syn/S04.pod == --- doc/trunk/design/syn/S04.pod(original)

if-else and statement-ending blocks?

2006-10-05 Thread Markus Laire
S04 says: A line ending with a closing brace }, followed by nothing but whitespace or comments, will terminate a statement if an end of statement can occur there. That is, these two statements are equivalent: my $x = sub { 3 } my $x = sub { 3 }; Does this mean that if $foo == 123 {

Re: Don't tell me what I can't do!

2006-10-05 Thread Jonathan Lang
chromatic wrote: jesse wrote: Ok. So, I think what you're saying is that it's not a matter of don't let people write libraries that add strictures to code that uses those modules but a matter of perl should always give you enough rope to turn off any stricture imposed on you by external

import collisions

2006-10-05 Thread Jonathan Lang
What if I import two modules, both of which export a 'foo' method? IMHO, it would be nice if this sort of situation was resolved in a manner similar to how role composition occurs: call such a conflict a fatal error, and provide an easy technique for eliminating such conflicts. One such

Hash composers and code blocks

2006-10-05 Thread Aaron Sherman
S04 now reads: == However, a hash composer may never occur at the end of a line. If the parser sees anything that looks like a hash composer at the end of the line, it fails with closing hash curly may not terminate line or some such. my $hash = { 1 = { 2 = 3, 4 = 5 }, #

Re: import collisions

2006-10-05 Thread Aaron Sherman
Jonathan Lang wrote: What if I import two modules, both of which export a 'foo' method? That's always fine unless they have exactly the same signature. In general, that's not going to happen because the first parameter is created from the invocant. Thus: use HTML4; use

Re: Hash composers and code blocks

2006-10-05 Thread Aaron Sherman
Aaron Sherman wrote: Proposal: A sigil followed by [...] is always a composer for that type. %[...]- Hash. Unicode: ⦃...⦄ @[...]- Array. Unicode: [...] ... I left out ::, which is probably a mistake. Part of the elegance of this, IMHO, is that it behaves the same for all

Re: Hash composers and code blocks

2006-10-05 Thread Mark J. Reed
On 10/5/06, Aaron Sherman [EMAIL PROTECTED] wrote: Proposal: A sigil followed by [...] is always a composer for that type. %[...] - Hash. Unicode: ⦃...⦄ @[...] - Array. Unicode: [...] ? - Seq. Unicode: ⎣...⎤ [...] - Code. Unicode: ⦕...⦖ |[...] -

Re: Hash composers and code blocks

2006-10-05 Thread Aaron Sherman
Mark J. Reed wrote: On 10/5/06, Aaron Sherman [EMAIL PROTECTED] wrote: Proposal: A sigil followed by [...] is always a composer for that type. %[...] - Hash. Unicode: ⦃...⦄ @[...] - Array. Unicode: [...] ? - Seq. Unicode: ⎣...⎤ [...] - Code. Unicode:

Updated: Re: Hash composers and code blocks

2006-10-05 Thread Aaron Sherman
Aaron Sherman wrote: (updated based on followup conversations) Proposal: A sigil followed by [...] is always a composer for that type. %[...]- Hash. @[...]- Array. [...]- Code. |[...]- Capture. Identical to \(...). $[...]- Scalar. Like item(...), but