Re: Another adverb on operator question

Perhaps I'm missing something; but why couldn't you say '[lt]:lc $a, $b, $c'? That is, I see the "reducing meta-operator" as a way of taking a list-associative infix operator and treating it as a function call, albeit one with a funny name. As such, you should be able to do things with a reduced

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

But are 'twas and -x valid identifiers? IMHO, they should not be. -- Jonathan "Dataweaver" Lang

Re: Differential Subscripts

On Fri, Aug 8, 2008 at 7:41 PM, John M. Dlugosz <[EMAIL PROTECTED]> wrote: > How is @array[*-2] supposed to be implemented? > > S09 > // reported again 8-Aug-2008 > > Is this magic known to the parser at a low level, or is it possible to > define your own postcircumfix operators that interact with

Re: Multiple Return Values - details fleshed out

John M. Dlugosz wrote: > I wrote to clarify and > extrapolate from what is written in the Synopses. A few comments: 1. I was under the impression that identifiers couldn't end with - or '. 2. While list context won't work with named return values, "h

Re: The False Cognate problem and what Roles are still missing

On Wed, Aug 20, 2008 at 3:16 PM, Aristotle Pagaltzis <[EMAIL PROTECTED]> wrote: > Hi $Larry et al, > > I brought this up as a question at YAPC::EU and found to my > surprise that no one seems to have thought of it yet. This is > the mail I said I'd write. (And apologies, Larry. :-) ) > > Consider t

Re: adverbial form of Pairs notation question

TSa wrote: > Ahh, I see. Thanks for the hint. It's actually comma that builds lists. > So we could go with () for undef and require (1,) and (,) for the single > element and empty list respectively. But then +(1,2,3,()) == 4. Actually, note that both infix:<,> and circumfix:<[ ]> can be used to bu

Re: Should $.foo attributes without "is rw" be writable from within the class

Daniel Ruoso wrote: > TSa wrote: >> May I pose three more questions? >> >> 1. I guess that even using $!A::bar in methods of B is an >> access violation, right? I.e. A needs to trust B for that >> to be allowed. > > Yes > >> 2. The object has to carry $!A::bar and $!B::bar separately, right

Re: Should $.foo attributes without "is rw" be writable from within the class

Daniel Ruoso wrote: > Jon Lang wrote: >> Note that this ought only be true of class inheritance; with role >> composition, there should only be one $!bar in the class, no matter >> how many roles define it. > > er... what does that mean exactly? Unless something has

Re: XPath grammars (Was: Re: globs and trees in Perl6)

For tree-oriented pattern matching syntax, I'd recommend for inspiration the RELAX NG Compact Syntax, rather than XPath. Technically, RELAX NG is an XML schema validation language; but the basic principle that it uses is to describe a tree-oriented pattern, and to consider the document to be valid

Re: globs and rules and trees, oh my! (was: Re: XPath grammars (Was: Re: globs and trees in Perl6))

Timothy S. Nelson wrote: >> note to treematching folks: it is envisaged that signatures in >> a rule will match nodes in a tree >> >>My question is, how is this expected to work? Can someone give an >> example? > >I'm assuming that this relates to Jon Lang's comment about using >

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

<[EMAIL PROTECTED]> wrote: > Log: > Add missing series operator, mostly for readability. Is there a way for the continuing function to access its index as well as, or instead of, the values of one or more preceding terms? And/or to access elements by counting forward from the start rather than ba

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

Larry Wall wrote: > On Sun, Oct 05, 2008 at 08:19:42PM -0700, Jon Lang wrote: > : <[EMAIL PROTECTED]> wrote: > : > Log: > : > Add missing series operator, mostly for readability. > : > : Is there a way for the continuing function to access its index as well > : as,

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

"also" seems to be the junctive equivalent of "andthen". Should there be a junctive equivalent of "orelse"? -- Jonathan "Dataweaver" Lang

Re: Are eqv and === junction aware?

Larry Wall wrote: > eqv and === autothread just like any other comparisons. If you really > want to compare the contents of two junctions, you have to use the > results of some magical .eigenmumble method to return the contents > as a non-junction. Possibly stringification will be sufficient, if

Re: [perl #60732] Hash indexes shouldn't work on array refs

On Mon, Nov 24, 2008 at 7:19 AM, Rafael Garcia-Suarez <[EMAIL PROTECTED]> wrote: > Moritz Lenz wrote in perl.perl6.compiler : >> jerry gay wrote: >>> On Fri, Nov 21, 2008 at 10:43, via RT Moritz Lenz >>> <[EMAIL PROTECTED]> wrote: # New Ticket Created by Moritz Lenz # Please include the

Re: Support for ensuring invariants from one loop iteration to the next?

Aristotle Pagaltzis wrote: > * Bruce Gray <[EMAIL PROTECTED]> [2008-12-03 18:20]: >> In Perl 5 or Perl 6, why not move the grep() into the while()? > > Because it's only a figurative example and you're supposed to > consider the general problem, not nitpick the specific example… But how is that no

Re: Support for ensuring invariants from one loop iteration to the next?

Mark J. Reed wrote: > Mark J. Reed wrote: >> loop >> { >> doSomething(); >> last unless someCondition(); >> doSomethingElse(); >> } > > That is, of course, merely the while(1) version from Aristotle's > original message rewritten with Perl 6's loop keyword. As I said, I'm > OK with that, per

Re: how to write literals of some Perl 6 types?

Darren Duncan wrote: > Now, with some basic types, I know how to do it, examples: > > Bool # Bool::True Please forgive my ignorance; but are there any cases where 'Bool::True' can be spelled more concisely as 'True'? Otherwise, this approach seems awfully cluttered. -- Jonathan "Dataweaver

Re: Roles and IO?

Leon Timmermans wrote: > What I propose is using role composition for *everything*. Most > importantly that includes the roles Readable and Writable, but also > things like Seekable, Mapable, Pollable, Statable, Ownable, Buffered > (does Readable), Socket, Acceptable (does Pollable), and more. > >

Re: List.end - last item and last index mixing

Moritz Lenz wrote: > From S29: > > : =item end > : > : our Any method end (@array: ) is export > : > : Returns the final subscript of the first dimension; for a one-dimensional > : array this simply the index of the final element. For fixed dimensions > : this is the declared maximum subscript.

Re: Roles and IO?

Leon Timmermans wrote: > I assumed a new role makes a new interface. In other words, that a > type that happens to do Pollable, Mappable, Statable and Ownable > wouldn't automatically do File in that case. If I was wrong my abuse > of subset wouldn't be necessary. Otherwise, maybe there should be a

Re: What does a Pair numify to?

Mark Biggar wrote: > The only use case I can think of is sorting a list of pairs; > should it default to sort by key or value? But this isn't a case of numifying a Pair, or of stringifying it - or of coercing it at all. If you've got a list of Pairs, you use a sorting algorithm that's designed f

Re: What does a Pair numify to?

On Mon, Dec 15, 2008 at 10:26 PM, Larry Wall wrote: > On Mon, Dec 15, 2008 at 04:43:51PM -0700, David Green wrote: >> I can't really think of a great example where you'd want to numify a >> pair, but I would expect printing one to produce something like "a => >> 23" (especially since that's what a

Re: What does a Pair numify to?

TSa wrote: > I see no problem as long as say gets a pair as argument. Then it can > print the key and value separated with a tab. More problematic are > string concatenations of the form > > say "the pair is: " ~ (foo => $bar); > > which need to be written so that say sees the pair > > say "the

Re: What does a Pair numify to?

Moritz Lenz wrote: > Off the top of my head, see S06 for the gory details: > > my $pair = a => 'b'; > > named(a => 'b'); > named(:a); > named(|$pair); > > positional((a => 'b')); > positional((:a)); > positional($pair); As you say: the gory details, emphasis on gory. But if that's the way of thin

Re: Support for ensuring invariants from one loop iteration to the next?

How do you compute '*'? That is, how do you know how many more iterations you have to go before you're done? Should you really be handling this sort of thing through an "iteration count" mechanism? How do you keep track of which iteration you're on? Is it another detail that needs to be handled

Re: Support for ensuring invariants from one loop iteration to the next?

Aristotle Pagaltzis wrote: > And it says exactly what it's supposed to say in the absolutely > most straightforward manner possible. The order of execution is > crystal clear, the intent behind the loop completely explicit. If it works for you, great! Personally, it doesn't strike me as being as

Re: Support for ensuring invariants from one loop iteration to the next?

not telling you that you're wrong; TIMTOWTDI. I'm telling you that it's a matter of taste. On Fri, Dec 19, 2008 at 5:52 AM, Aristotle Pagaltzis wrote: > * Jon Lang [2008-12-19 03:50]: >> Personally, it doesn't strike me as being as straightforward >> as put

Re: returning one or several values from a routine

Daniel Ruoso wrote: > > Hi, > > As smop and mildew now support ControlExceptionReturn (see > v6/mildew/t/return_function.t), an important question raised: > > sub plural { return 1,2 } > sub singular { return 1 } > my @a = plural(); > my $b = plural(); > my @c = singular(); > my $d = singular

Re: returning one or several values from a routine

Daniel Ruoso wrote: > I've just realized we were missing some spots, so remaking the list of > possibilities > > my $a = sub s1 { return a => 1 } > my $b = sub s2 { return a => 1, b => 2 } > my $c = sub s3 { return 1, 2, 3, a => 1, b => 2 } > my $d = sub s4 { return 1 } > my $e = sub s5 { retu

Re: returning one or several values from a routine

Daniel Ruoso wrote: > Hmm... I think that takes the discussion to another level, and the > question is: > > "what does a capture returns when coerced to a context it doesn't > provide a value for?" > > The easy answer would be undef, empty array and empty hash, but that > doesn't DWIM at all. > >

Re: returning one or several values from a routine

TSa wrote: > Jon Lang wrote: >> item($x) # Dwimmey use of item context. > > IIRC this is the same as $$x, right? Or does that > extract the invocant slot without dwimmery? Umm... good question. This is a rather nasty paradox: on the one hand, we want to be able to stac

Re: returning one or several values from a routine

Dave Whipp wrote: > Daniel Ruoso wrote: >> Hmm... I think that takes the discussion to another level, and the >> question is: >> >> "what does a capture returns when coerced to a context it doesn't >> provide a value for?" > > I'd like to take one step further, and ask what it is that introduced >

Writing to an iterator

I was just reading through S07, and it occurred to me that if one wanted to, one could handle stacks and queues as iterators, rather than by push/pop/shift/unshift of a list. All you'd have to do would be to create a stack or queue class with a private list attribute and methods for reading from a

Re: r24819 - docs/Perl6/Spec

Darren Duncan wrote: > pugs-comm...@feather.perl6.nl wrote: >> >> Log: >> [S02] clarify that Pairs and Mappings are mutable in value, but not in key > > >> >> KeyHash Perl hash that autodeletes values matching default >> KeySet KeyHash of Bool (does Set in list/array context) >>

Re: Extending classes in a lexical scope?

Ovid wrote: > Is it possible to modify the core Perl6Array class like that (without extra > keywords)? If so, is it possible for each programmer to make such a change > so that it's lexically scoped? AFAIK, it is not possible to modify a core class; however, I believe that it _is_ possible to d

Re: Not a bug?

On Mon, Jan 12, 2009 at 2:15 AM, Carl Mäsak wrote: > Ovid (>): >> $ perl6 -e 'my $foo = "foo";say "{" ~ $foo ~ "}"' >> ~ foo ~ > > Easy solution: only use double quotes when you want to interpolate. :) > > This is not really an option when running 'perl6 -e' under bash, though. $ perl6 -e 'my

Re: Not a bug?

On Mon, Jan 12, 2009 at 1:08 PM, Larry Wall wrote: > On Mon, Jan 12, 2009 at 03:43:47AM -0800, Jon Lang wrote: > : On Mon, Jan 12, 2009 at 2:15 AM, Carl Mäsak wrote: > : > Ovid (>): > : >> $ perl6 -e 'my $foo = "foo";say "{" ~ $foo ~ "}&

Re: Extending classes in a lexical scope?

Ovid wrote: > Actually, I'd prefer to go much further than this: > > use Core 'MyCore'; > > And have that override core classes lexically. > > That solves the "but I want it MY way" issue that many Perl and Ruby > programmers have, but they don't shoot anyone else in the foot. Since 'use' import

Re: Extending classes in a lexical scope?

Ovid wrote: > - Original Message > >> From: Jon Lang > >> > Actually, I'd prefer to go much further than this: >> > >> > use Core 'MyCore'; >> > >> > And have that override core classes lexically. >

Re: design of the Prelude (was Re: Rakudo leaving the Parrot nest)

Forgive my ignorance, but what is a Prelude? -- Jonathan "Dataweaver" Lang

Re: design of the Prelude (was Re: Rakudo leaving the Parrot nest)

On Thu, Jan 15, 2009 at 6:45 PM, Jonathan Scott Duff wrote: > On Thu, Jan 15, 2009 at 8:31 PM, Jon Lang wrote: >> >> Forgive my ignorance, but what is a Prelude? >> >> -- >> Jonathan "Dataweaver" Lang > > The stuff you load (and execute)

Re: Operator sleuthing...

Mark Lentczner wrote: > STD has sym<;> as both an infix operator ( --> Sequencer), and as a > terminator. > ?? Which is it? Since I think most people think of it as a statement > terminator, I plan on leaving it off the chart. It is both. Examples where it is used as an infix operator include:

Re: r25060 - docs/Perl6/Spec src/perl6

On Tue, Jan 27, 2009 at 9:43 AM, wrote: > +=head2 Reversed comparison operators > + > +Any infix comparison operator returning type C may be transformed > into its reversed sense > +by prefixing with C<->. > + > +-cmp > +-leg > +-<=> > + > +To avoid confusion with the C<-=> operator,

Re: r25060 - docs/Perl6/Spec src/perl6

Larry Wall wrote: > Jon Lang wrote: > : If there are only a handful of operators to which the new > : meta-operator can be applied, why do it as a meta-operator at all? > > As a metaoperator it automatically extends to user-defined comparison > operators, but I admit that'

Re: r25102 - docs/Perl6/Spec

Larry Wall wrote: > So I'm open to suggestions for what we ought to call that envelope > if we don't call it the prelude or the perlude. Locale is bad, > environs is bad, context is bad...the wrapper? But we have dynamic > wrappers already, so that's bad. Maybe the setting, like a jewel? > That

Re: r25200 - docs/Perl6/Spec t/spec

wrote: > -=item --autoloop-split, -F *expression* > +=item --autoloop-delim, -F *expression* > > Pattern to split on (used with -a). Substitutes an expression for the > default > split function, which is C<{split ' '}>. Accepts unicode strings (as long as Should the default pattern be ' ', o

Re: r25200 - docs/Perl6/Spec t/spec

On Thu, Feb 5, 2009 at 9:21 AM, Larry Wall wrote: > On Thu, Feb 05, 2009 at 07:47:01AM -0800, Dave Whipp wrote: >> Jon Lang wrote: >>>> Pattern to split on (used with -a). Substitutes an expression for the >>>> default >>>> split function, which is

Re: 2 questions: Implementations and Roles

Timothy S. Nelson wrote: >Also, is there a simple way to know when I should be using a class > vs. a role? If you plan on creating objects with it, use a class. If you plan on creating classes with it, use a role. -- Jonathan "Dataweaver" Lang

Re: References to parts of declared packages

On Wed, Feb 11, 2009 at 12:15 PM, Jonathan Worthington wrote: > Hi, > > If we declared, for example: > > role A::B {}; > > Then what should a reference to A be here? At the moment, Rakudo treats it > as a post-declared listop, however I suspect we should be doing something a > bit smarter? If so,

Re: References to parts of declared packages

Carl Mäsak wrote: >> * A should be treated as a post-declared package. > > Whatever this means, it sounds preferable. :) It means that you can define package A without ever declaring it, by declaring all of its contents using such statements as 'role A::B ', 'sub A::Foo', and so on. -- Jonathan

S03: how many metaoperators?

With the addition of the reversing metaoperator, the claim that there are six metaoperators (made in the second paragraph of the meta operators section) is no longer true. Likewise, the reduction operator is no longer the fourth metaoperator (as stated in the first sentence of the reduction operat

S06: named arguments and long names

Are required named parameters (e.g., ':$foo!') considered to be part of the long name provided by a signature? (S06 seems to indicate that they aren't.) Either way, can their status with respect to the long name be changed? That is, if they aren't included in the long name, can they be added to

Re: References to parts of declared packages

TSa wrote: > Does that imply that packages behave like C++ namespaces? That is > a package can be inserted into several times: > > package A > { > class Foo {...} > } > # later elsewhere > package A > { > class Bar {...} > } > > I would think that this is just different sy

Synopsis for Signatures?

At present, signatures appear to serve at least three rather diverse purposes in Perl 6: * parameter lists for routines (can also be used to specify what a given routine returns; explored in detail in S06). * variable declaration (see "declarators" in S03). * parametric roles (currently only addre

Re: References to parts of declared packages

Larry Wall wrote: > Jon Lang wrote: > : Well, we _do_ have a mechanism in place for adding to an existing > : class (e.g., "class Foo is also { ... }"), and classes are a special > : case of modules; so I don't see why you shouldn't be able to do > : likewise wi

Re: References to parts of declared packages

Larry Wall wrote: > Jon Lang wrote: > : And with package versioning, you may not need an "is instead" > : equivalent: if you want to "redefine" a package, just create a newer > : version of it in a tighter lexical scope than the original package was > : in.

infectious traits and pure functions

In reading over the Debugging draft (i.e., the future S20), I ran across the concept of the infectious trait - that is, a trait that doesn't just get applied to the thing to which it is explicitly applied; rather, it tends to spread to whatever else that thing comes in contact with. "Taint" is the

Re: infectious traits and pure functions

Darren Duncan wrote: > There are ways to get what you want if you're willing to trade for more > restrictiveness in the relevant contexts. > > If we have a way of marking types/values and routines somehow as being pure, > in the types case marking it as consisting of just immutable values, and in >

Re: infectious traits and pure functions

Martin D Kealey wrote: > On Mon, 16 Feb 2009, Jon Lang wrote: >> if there's any doubt about the matter (e.g., conclusively proving or >> disproving purity would be NP-complete or a halting problem), then > > Deciding whether you have a halting problem IS a halting problem

Re: Comparing inexact values (was "Re: Temporal changes")

Larry Wall wrote: > So it might be better as a (very tight?) operator, regardless of > the spelling: > >    $x ~~ $y within $epsilon I like this: it's readable and intuitive. As well, it leaves ± available for use in its mathematical sense. > For what it's worth, ± does happen to be in Latin-1,

Re: Comparing inexact values (was "Re: Temporal changes")

Daniel Ruoso wrote: > What about... > >  if $x ~~ [..] $x ± $epsilon {...} > > That would mean that $x ± $epsilon in list context returned each value, > where in scalar context returned a junction, so the reduction operator > could do its job... (I'm assuming that you meant something like "if $y ~

Re: Comparing inexact values (was "Re: Temporal changes")

TSa wrote: > Larry Wall wrote: >> So it might be better as a (very tight?) operator, regardless of >> the spelling: >> >>     $x ~~ $y within $epsilon > > This is a pretty add-on to smartmatch but I still think > we are wasting a valueable slot in the smartmatch table > by making numeric $x ~~ $y s

Re: Comparing inexact values (was "Re: Temporal changes")

On Tue, Feb 24, 2009 at 1:39 PM, Daniel Ruoso wrote: > Em Ter, 2009-02-24 às 13:34 -0800, Jon Lang escreveu: >> Daniel Ruoso wrote: >> >  if $y ~~ [..] $x ± $epsilon {...} >> Junctions should not return individual values in list context, > > It is not the junction th

Re: Comparing inexact values (was "Re: Temporal changes")

Doug McNutt wrote: > Thinking about what I actually do. . . > > A near equal test of a float ought to be a fractional error based on the > current value of the float. > > $x  tested for between $a*(1.0 + $errorfraction) and $a*(1.0 - > $errorfraction) > > If you're dealing with propagation of error

S14 markup

Someone should go through the Parametric Roles section and properly indent the code blocks. They're not rendering properly at http://perlcabal.org/syn/S14.html -- Jonathan "Dataweaver" Lang

Re: Synopsis for Signatures?

On Fri, Feb 13, 2009 at 11:49 AM, Larry Wall wrote: > On Fri, Feb 13, 2009 at 10:24:14AM -0800, Jon Lang wrote: > : Given that signatures have grown well beyond their origins as > : subroutine parameter lists, and given that signatures have their own > : syntax, perhaps they should

Re: Comparing inexact values (was "Re: Temporal changes")

Mark J. Reed wrote: > I do quite like the magical postfix %, but I wonder how far it should > go beyond ±: > > $x += 5%;   # becomes $x += ($x * .05)?  Or maybe $x *= 1.05  ? > $x * 5%;   # becomes $x * .05 ? If it works with ±, it ought to work with + and -. Rule of thumb: if there's no easy way

Re: Comparing inexact values (was "Re: Temporal changes")

TSa wrote: > HaloO, > > Jon Lang wrote: >> >>   �...@a[50%] # accesses the middle item in the list, since Whatever is >> set to the length of the list. > > I don't understand what you mean with setting Whatever. Whatever is > a type that mostly be

Re: Comparing inexact values (was "Re: Temporal changes")

Daniel Ruoso wrote: > Em Qui, 2009-02-26 às 17:01 +0100, TSa escreveu: >>      $y.error = 0.001; >>      $x ~~ $y; > > Looking at this I just started wondering... why wouldn't that be made > with: > >  my $y = 10 but Imprecise(5%); >  $x ~~ $y; That's not bad; I like it. -- Jonathan "Dataweaver"

Re: Comparing inexact values (was "Re: Temporal changes")

Jon Lang wrote: > TSa wrote: >> Jon Lang wrote: >>> >>>   �...@a[50%] # accesses the middle item in the list, since Whatever is >>> set to the length of the list. >> >> I don't understand what you mean with setting Whatever. Whatever is &

Re: Comparing inexact values (was "Re: Temporal changes")

Martin D Kealey wrote: > On Thu, 26 Feb 2009, Jon Lang wrote: >> asin is not the inverse function of sin, although it's probably as close >> as you can get.  And even there, some sort of compiler optimization could >> potentially be done, replacing the composition of asin

Re: Range and continuous intervals

Darren Duncan wrote: > I don't know if this was previously discussed and dismissed but ... > > Inspired by some recent discussion in the "comparing inexact values" thread > plus some temporal discussion and some older thoughts ... > > I was thinking that Perl 6 ought to have a generic interval type

Re: r25626 - docs/Perl6/Spec

Let me see if I'm grasping the concept here: by default, all functions are British in the sense that they always do things the British way no matter where they are in the world:their behavior is determined by the culture in which they were raised. In contrast, lifted code "goes native" and does th

Re: r25626 - docs/Perl6/Spec

> +Note that in each piec of lifted code there are references to Typo: s/piec/piece/ -- Jonathan "Dataweaver" Lang -- Jonathan "Dataweaver" Lang

Re: Range and continuous intervals

On Fri, Feb 27, 2009 at 1:19 AM, Darren Duncan wrote: > Jon, I like all of your stated ideas in general.  I also don't care about > the postfix %; that was just a concept example pulled from the inexact > comparison thread.  The idea of using zero is also appropriate conceptually > with shades of

pod variables?

Under the section about twigils in S02, "$=var" is described as a "pod variable". I'm not finding any other references to pod variables; what are tey, and how are they used? (In particular, I'm wondering if they're a fossil; if they aren't, I'd expect further information about them to be in S26.)

Re: Range and continuous intervals

Darren Duncan wrote: > In reply to Jon Lang, > > What I'm proposing here in the general case, is a generic collection type, > "Interval" say, that can represent a discontinuous interval of an ordered > type.  A simple way of defining such a type is that it is a &qu

Re: Range and continuous intervals

Thomas Sandlaß wrote: > The benefit of a dedicated Interval type comes from supporting set > operations (&), (|) etc. which are still unmentioned in S03. Have set operations been implemented in either Rakudo or Pugs? > BTW, > what does (1..^5).max return? I think it should be 4 because this > is

Re: new Capture behavior (Was: Re: r25685 - docs/Perl6/Spec)

Daniel Ruoso wrote: > Daniel Ruoso escreveu: >> What really got me confused is that I don't see what problem this change >> solves, since it doesn't seem that a signature that expects an invocant >> (i.e.: cares about invocant) will accept a call without an invocant, so >> "method foo($b,$c) is exp

Re: new Capture behavior (Was: Re: r25685 - docs/Perl6/Spec)

Darren Duncan wrote: > Here's a question: > > Say I had an N-adic routine where in OO terms the invocant is one of the N > terms, and which of those is the invocant doesn't matter, and what we really > want to have is the invocant automatically being a member of the input list. How about allowing

Re: new Capture behavior (Was: Re: r25685 - docs/Perl6/Spec)

OK; let me get a quick clarification here. How does: say "Hello, World!"; differ from: "Hello, World!".say; or: say $*OUT: "Hello, World!"; in terms of dispatching? And more generally, would there be a reasonable way to write a single routine (i.e., implementation) that could be

Re: r25807 - docs/Perl6/Spec

> +To declare an item that is parsed as a simple term, you must use the > +form C<< term: >>, or some other form of constant declaration such > +as an enum declaration.  Such a term never looks for its arguments, > +is never considered a list prefix operator, and may not work with > +subsequent par

Re: r25807 - docs/Perl6/Spec

On Sat, Mar 14, 2009 at 7:29 AM, Larry Wall wrote: > : So if I were to say: > : > :     rand $n: > : > : is the compiler smart enough to notice that trailing colon and > : recognize this as an indirect method call rather than two adjacent > : terms? > > No, currently under STD you get: > >    Obso

Re: a junction or not

This isn't the first (or second, or third, or fourth...) time that I've seen complications arise with regard to junctions. Every time, the confusion arises when some variation of the question "is it a junction?" is raised. Ultimately, this is because Perl is trying it's darnedest to treat Junctio

Re: Regex syntax

Moritz Lenz wrote: > I noticed that in larger grammars (like STD.pm and many PGE grammars in > the parrot repo) string literals are always quoted for clarity > > regex foo { > 'literal' > } > > Since I think this is a good idea, we could just as well enforce that, and > drop the <...> ar

Re: Musings on operator overloading

Larry Wall wrote: > So here's another question in the same vein. How would mathematicians > read these (assuming Perl has a factorial postfix operator): > > 1 + a(x)**2! > 1 + a(x)²! The "1 + ..." portion is not in dispute: in both cases, everything to the right of the addition sign get

Re: Musings on operator overloading

Larry Wall wrote: > Now, I think I know how to make the parser use precedence on either > a prefix or a postfix to get the desired effect (but perhaps not going > both directions simulatenously). But that leads me to a slightly > different parsing question, which comes from the asymmetry of po

Re: Musings on operator overloading

TSa wrote: > Jon Lang wrote: > > all unary operators, be > > they prefix or postfix, should be evaluated before any binary operator > > is. > > Note that I see ** more as a parametric postscript then a real binary. > That is $x**$y sort of means $x(**$y). That

Re: Musings on operator overloading

On Wed, Mar 26, 2008 at 12:03 PM, Larry Wall <[EMAIL PROTECTED]> wrote: > On Wed, Mar 26, 2008 at 11:00:09AM -0700, Jon Lang wrote: > > : all unary operators, be they prefix or postfix, should be evaluated > : before any binary operator is. > > And leaving the pool of v

Re: Musings on operator overloading

Mark J. Reed wrote: > Jon Lang wrote: > > Those don't strike me as being unary operators; they strike me as > > being function calls that have left out the parentheses. > > At least through Perl5, 'tain't no difference between those two in Perl land. True

Re: Musings on operator overloading

Thom Boyer wrote: > But the main point I was trying to make is just that I didn't see the > necessity of positing > > 1,2,3\say > > when (if I understand correctly) you could write that as simply as > > 1,2,3 say Nope. This is the same situation as the aforementioned '++' example, in

postfix and postcircumfix

In "Question on your last change to S02", Larry Wall wrote: > (By the way, you'll note the utility of being able to talk about a > postfix by saying .[], which is one of the reasons we allow the optional > dot there. :) Can I take this as an indication that the rules for postcircumfix operators

Re: First look: Advanced Polymorphism whitepaper

John M. Dlugosz wrote: > Here is a first look at the ideas I've worked up concerning the Perl 6 type > system. It's an overview of the issues and usage of higher-order types in > comparison with traditional subtyping subclasses. > > http://www.dlugosz.com/Perl6/ Very interesting, if puzzling, re

Re: First look: Advanced Polymorphism whitepaper

TSa wrote: > The use of £ in > > sub foo (£ pointlike ::PointType $p1, PointType $p2 --> PointType) > > is that of *structural* subtyping. Here FoxPoint is found to be > pointlike. In that I would propose again to take the 'like' operator > from JavaScript 2. Doing that the role should be bet

Re: First look: Advanced Polymorphism whitepaper

chromatic wrote: > Jon Lang wrote: > > Ah; that clears things up considerably. If I understand you > > correctly, John is using '£' to mean "use Duck Typing here". _That_, > > I can definitely see uses for. As well, spelling it as 'like'

Re: First look: Advanced Polymorphism whitepaper

John M. Dlugosz wrote: > TSa wrote: > > Jon Lang wrote: > > > I'm having some difficulty understanding the business with £. I > > > _think_ that you're saying that £ sort of acts as a prefix operator > > > that changes the meaning of the type with w

Re: treatment of "isa" and inheritance

Brandon S. Allbery KF8NH wrote: > TSa wrote: > > I totally agree! Using 'isa' pulls in the type checker. Do we have the > > same option for 'does' e.g. 'doesa'? Or is type checking always implied > > in role composition? Note that the class can override a role's methods > > at will. > > It occurs

Re: OK, ::?CLASS not virtual

John M. Dlugosz wrote: > And you can use CLASS in a role also, confidant that it will be looked up > according to the normal rules when the class is composed using that role, > just like any other symbol that is not found when the role is defined. > Using ::?CLASS in a role is an error (unless you

Re: First look: Advanced Polymorphism whitepaper

On Wed, Apr 30, 2008 at 9:58 PM, Brandon S. Allbery KF8NH <[EMAIL PROTECTED]> wrote: > > On May 1, 2008, at 0:53 , chromatic wrote: > > > > correctness sense. Sadly, both trees and dogs bark.) > > > > Hm, no. One's a noun, the other's a verb. Given the linguistic > orientation of Perl6, it see

  1   2   3   4   >