On Mon, Aug 10, 2009 at 2:16 PM, Mark J. Reed wrote:
> I still like the double-bracket idea. I don't much mind the extra
> character; 5 characters total still beats the 7 of HTML/XML.
Agreed. As I said, the biggest potential stumbling block for this
would be the existence of a double-bracket that
Masak's Journal[1] identifies a couple of problems involving the
interaction of POD with block-form classes - one in the article
itself, and another in the comments that follow. The first is that a
mixture of indented block-form classes and non-indented POD is
visually very ugly. The second is th
On Mon, Aug 10, 2009 at 3:36 PM, Darren Duncan wrote:
> Personally, I think that comments should have trailing # as well as leading
> ones, so they are more like strings in that the same character is used to
> mark both ends.
You mean like the following?
q[quoted text]
qq(interpolated quo
smuj wrote:
> smuj wrote:
>> Jon Lang wrote:
>>> ... the biggest potential stumbling block for this
>>> would be the existence of a double-bracket that sees frequent use at
>>> the start of a line. Query: does '<<' count as a double bracket,
Darren Duncan wrote:
> Still, I like the idea of #...# also being supported from the point of
> symmetry with '...' and "..." also being supported, not that this is
> necessary.
This is mutually exclusive with the practice of commenting out a bunch
of lines by prepending them with '#'.
--
Jonath
smuj wrote:
> Jon Lang wrote:
>> Here's a radical notion: use something other than '#' to initiate an
>> inline comment.
>>
> [snippage]
>
> Or maybe just don't allow "embedded" comments unless they are actually
> "embedded",
Ben Morrow wrote:
> However, I would much rather see a general syntax like
>
> (# ... )
> {# ... }
> [# ... ]
>
> with no whitespace allowed between the opening bracket and the #: this
> doesn't seem to conflict with anything. Allowing <# ... > in rules would
> also be nice.
That's rather
smuj wrote:
> Jon Lang wrote:
>> smuj wrote:
>>> Jon Lang wrote:
>>>> Here's a radical notion: use something other than '#' to initiate an
>>>> inline comment.
>>>>
>>> [snippage]
>>>
>>> Or maybe jus
Ben Morrow wrote:
> This appears to be leading to a :comment modifier on quotables, with
> some suitable shortcut. Perhaps 'q#'? Or are we not allowed mixed alpha
> and symbols?
It's probably a bad practice, if possible.
> (I really want to suggest £, just to teach USAnians '#' isn't called
> 'po
jerry gay wrote:
> for the latest spec changes regarding this item, see
> http://perlcabal.org/svn/pugs/revision/?rev=27959.
>
> is everyone equally miserable now? ;)
Already seen it. My latest points still stand, though: #`(...) is
still vulnerable to ambiguity relative to #..., whereas `#(...),
On Sat, Aug 15, 2009 at 7:17 AM, Timothy S. Nelson wrote:
> On Sat, 15 Aug 2009, Austin Hastings wrote:
>
>> This whole thread seems oriented around two points:
>>
>> 1. Strings should not carry the burden of umpty-ump filesystem checking
>> methods.
>>
>> 2. It should be possible to specify a file
Timothy S. Nelson wrote:
> David Green wrote:
>> Jon Lang wrote:
>>> If so, could you give some examples of how such a distinction could be
>>> beneficial, or of how the lack of such a distinction is problematic?
>
> Well, my main thought in this context is
Troels Liebe Bentsen wrote:
> Hey,
>
> Just joined the list, and I too have been thinking about a good path literal
> for Perl 6. Nice to see so many other people are thinking the same :).
Welcome to the list!
> Not knowing where to start in this long thread, I will instead try to show how
> I wo
On Sun, Aug 16, 2009 at 1:26 PM, Damian Conway wrote:
> * This means Pod can be indented; the = is no longer tied to the
> first column. The indentation preceding the opening = (using the
> ($?TABSTOP // 8) rule, as for heredocs) now specifies the zeroth
> column of the Pod block.
Wi
Could we also get "=numbered" and "=term" directives that are
equivalent to "=item :numbered" and "=item :term", respectively, for
use with abbreviated blocks? E.g.:
=numbered First Item
=numbered Second Item
=numbered Third Item
=term First Name
Definition
=term Second Na
On Tue, Aug 11, 2009 at 12:42 PM, Jon Lang wrote:
> jerry gay wrote:
>> for the latest spec changes regarding this item, see
>> http://perlcabal.org/svn/pugs/revision/?rev=27959.
>>
>> is everyone equally miserable now? ;)
>
> Already seen it. My latest point
On Tue, Aug 18, 2009 at 7:03 PM, Mark J. Reed wrote:
> The OS-level chdir() and getcwd() are not thread-safe. The usual
> advice is to ignore them completely in multithreaded programs, in
> favor of absolute paths (or relative paths from a fixed location,
> never calling chdir()). This is part of
On Wed, Aug 19, 2009 at 5:37 AM, Jan Ingvoldstad wrote:
> On Wed, Aug 19, 2009 at 1:54 PM, Moritz Lenz via RT <
> perl6-bugs-follo...@perl.org> wrote:
>
>>
>> Since the discussion came up on #perl6 if this is really the expected
>> behaviour, S09 says:
>>
>> As the end-point of a range, a lone "wha
Damian Conway wrote:
>> When using the code block alias, are the outermost curly braces
>> considered to be part of the ambient code?
>
> Yes. All ambient code is actual code.
OK. Let me propose an alternative (which I expect will be immediately
shot down):
Allow '=begin alias', '=end alias', an
FWIW, the current proposal for aliasing blocks of ambient text is
functional; it just feels a bit kludgey, and I'm a bit bothered by the
fact that you can't alias any ambient text other than a code block.
On Wed, Aug 19, 2009 at 11:29 AM, Damian Conway wrote:
> Jonathan "Dataweaver" Lang proposed:
David Green wrote:
> Jon Lang wrote:
>> Given that it's relatively easy to say "1..^*", I wouldn't mind
>> standardizing this so that '*' always refers to the element just past
>> the last one, at least when dealing with the standard index.
>
'home' should be spelled '~'.
--
Jonathan "Dataweaver" Lang
Martin D Kealey wrote:
> I wonder if this is becoming the new Perl mantra "use lexically scoped
> pragmata".
Larry said it much more succinctly: all's fair if you predeclare.
--
Jonathan "Dataweaver" Lang
Smylers wrote:
> Jon Lang writes:
>> FWIW, the current proposal for aliasing blocks of ambient text is
>> functional; it just feels a bit kludgey,
>
> Why? To me it seems the opposite: what could be more natural for
> delimiting a block of code than braces?
Because
I promised some further thoughts; here they are:
As written, declarator aliasing attaches the alias to a piece of code,
and draws both the name and the alias from that. What about using a
special case of the declarator block for this? That is:
class Database::Handle { #=alias
has IO $
Michael Zedeler wrote:
>> The obvious (default) choice for a step size would be the precision of
>> the more precise of the two values. So 0.0001 in your example above.
>>
>
> Well... maybe. How do you specify the intended precision, then? If I want
> the values from 1 to 2 with step size 0.01, I
Mark J. Reed wrote:
> On Tue, Aug 25, 2009 at 5:58 PM, Jon Lang wrote:
>> Also, I want to second David Green's point: we're not talking "Range"
>> and "Interval" here; we're talking "Range" and "Series".
>
> But a "
Michael Zedeler wrote:
> Proposed changes:
>
> It shouldn't be possible to construct RangeIterators over Str (apart from
> single length strings) or Complex using the Range operator (..).
I'd go one step further with Complex, to say that Range isn't a useful
concept at all so long as "before" and
On Thu, Aug 27, 2009 at 2:59 AM, Jon Lang wrote:
> Michael Zedeler wrote:
>> Jon Lang wrote:
>>> As for Str, I'm not sure that we should go so far as to say that you
>>> _can't_ create RangeIterators over them, so much as to say that the
>>> def
smuj wrote:
> TSa wrote:
>>
>> HaloO,
>>
>> David Green wrote:
>>>
>>> For certain discrete ordered types, like Int, both ways work out the
>>> same, and since Ints are the most common and most obvious use for Ranges,
>>> it's easy to overlook the confusion. The case with strings is a good
>>> exa
On Thu, Aug 27, 2009 at 2:36 PM, Mark J. Reed wrote:
> I think $a <= $^x <= $b is short enough, and lets you choose between <
> and <= on both ends and without having to remember how many dots each
> maps to.
"How many dots"?
Note that there are three sets of comparison operators:
'<' and '<=' n
smuj wrote:
> So you're saying you'd like things to stay exactly as they are at the
> moment!? :-)
Not quite. I'd like to see the effects of context spelled out more
clearly than they are; and I'd like a revision so that '..' numifies
its endpoints while a new 'to' operator doesn't. That is, res
On Thu, Aug 27, 2009 at 2:34 PM, Larry Wall wrote:
> On Thu, Aug 27, 2009 at 02:21:12PM -0700, Jon Lang wrote:
> : 2.5 ~~ 1..5 # true: equivalent to "2.5 ~~ 1 <= $_ <= 5".
>
> Current specced behavior for Range objects.
>
> : 2.5 ~~ @(1..5) # false: eq
On Mon, Aug 31, 2009 at 12:42 AM, TSa wrote:
>
> HaloO,
>
> Jon Lang wrote:
>>
>> '<' and '<=' numify their arguments before comparing them.
>> 'lt' and 'le' stringify their arguments before comparing them.
>&
Damian Conway wrote:
> Raiph elucidated:
>> I was thinking it would be possible to reference (compiler) variables
>> representing eg. the name and sig of a block being parsed, or a block
>> or declaration which has just been parsed, or which is just about to be
>> parsed, and that simply referencin
Damian Conway wrote:
> Jon Lang kept his promise:
>
>> I promised some further thoughts; here they are:
>
> Much appreciated.
You're welcome.
>> As written, declarator aliasing attaches the alias to a piece of code,
>> and draws both the name and the a
Not actually S26; but closely related: should $=POD and .WHY be
read-only? Also, should there be other Pod variables besides $=POD?
If so, which ones?
Back on the subject of S26: should declarator blocks and aliases be
able to introspect the object with which they're associated? That is,
should
On Mon, Sep 21, 2009 at 12:01 PM, wrote:
> @@ -65,9 +65,9 @@
>
> The basic underlying concept is that a Parcel behaves much like a
> list, but it doesn't enforce any context, in a way that no flattening
> -or coercion is made. When you use the Positional API on a Parcel, it
> -will include all t
Darren Duncan wrote:
> These generally look like good changes, but I have a few points on which I'd
> like clarification or to make suggestions.
>
>> +Perl supports generic types through what are called "roles"
>> +which represent capabilities or interfaces. These roles
>> +are generally not used
Darren Duncan wrote:
> Jon Lang wrote:
>> So what about custom delimiters?
>>
>> q:2<1100100101>
>> q:8[57013]
>> q:16~DEADBEEF~
>
> Well, sure, if its useful; the idea is to amalgam numeric and Str syntax.
> However, because a Blob literal pr
On Wed, Sep 30, 2009 at 11:58 PM, wrote:
>
> Author: moritz
> Date: 2009-10-01 08:58:00 +0200 (Thu, 01 Oct 2009)
> New Revision: 28523
>
> Modified:
> docs/Perl6/Spec/S32-setting-library/Numeric.pod
> Log:
> [S32::Num] More thoughts on Inf/NaN Complex, and on comparing Complex and
> Real number
Darren Duncan wrote:
> Jon Lang wrote:
>> I'm not sure that I feel comfortable locking C into
>> rectilinear coordinates as its internal storage method, as there will
>> be cases where the code operates more smoothly if you're using polar
>> coordinates to s
Some further thoughts:
Essentially, this could be done as an extension of the versioning
system. The difference between "possrep" versioning and normal
versioning would lie in the means by which the possrep dimension would
be resolved if not specified. Namely, the compiler would make the
decisio
On Thu, Oct 1, 2009 at 9:53 AM, wrote:
> The Perl 6 equivalent to Perl 5's C is C.
> (Perl 6's C function only evaluates strings, not blocks.)
> -A C block by default has a C block that handles all
> +A C block by default has a C block that handles all fatal
> exceptions by ignoring them. If
yary wrote:
> I'm confused between using ranges to generate a lazy list and using
> them as criteria to match against.
Indeed. It was my understanding that there was a recent change to
Ranges so that they now exist primarily to be used as matching
criteria. If you wish to generate a list, the pr
How do pred and succ work when given Complex values?
More generally: if Complex does Numeric, then Numeric doesn't include
Ordered (or whatever it's called), because Complex doesn't do Ordered.
As such, you can't used Numeric for any function that depends on the
value being Ordered.
On Sun, Oct
Moritz Lenz wrote:
> Jon Lang wrote:
>> typos: s[Nuermic] = "Numeric"
>
> You do have a pugs commit bit, don't you?
A what? AFAICT, I don't have any way of editing the Synopses; all I
can do is to comment on what I find.
--
Jonathan "Dataweaver" Lang
Consider a Range role that is parameterized (i.e., "Range of T" is a
perfectly valid thing to do). According to the spec, the definition of
Range depends on the nature of T:
* If the lower bound is Numeric, certain coercion rules are attempted on the
upper bound; otherwise, the two boundaries mus
Ovid wrote:
> The only way to handle this appears to be renaming one of the x()
> methods and trying to track down all code which relies on it and
> changing it. This essentially violates the problem we're trying to
> solve with traits, er, roles.
>
> In short, under the original traits model, you
David Green wrote:
> Or to look at it the other way around: Since we refer to things by name,
> those names have to be unique everywhere; so let's start out with long,
> "fully-qualified" names everywhere: $dog.Dog::bark(), $tree.Tree::bark(),
> $i.Int::succ, etc. Now everything's fine -- except
David Green wrote:
> Jon Lang wrote:
>> David Green wrote:
>>> On the other hand, $dogwood.Dog::bark cannot be simplified by leaving out
>>> the "Dog::" because then it would be ambiguous.
>>
>> On the gripping hand, if we have a function "tr
Darren Duncan wrote:
> Jon Lang wrote:
>> Here, we need a bit of a clarification: are we talking roles or
>> classes? Real example: Numeric is a role; Num is a class. Both can
>> be used in signatures; but only classes can be used to create objects.
>> That is,
David Green wrote:
> Aha, so the bark:(Dog:) syntax identifies the method by its signature as
> well, thus distinguishing it from the .bark:(Tree:) method. This works fine
> when the sigs can distinguish the invocants, which is very common. However,
> I could have ambiguous methods even including
David Green wrote:
> Jon Lang wrote:
>>
>> This implies that both Logging and Math do Numeric, since the invocant
>> ought to be of a type that the class does.
>
> I would expect that
> role Logging { method log(Numeric $x:) {...} }
> means the invocant is
Raphael Descamps wrote:
> I personally don't understand why we don't have a exclude and alias
> operator in Perl 6 but I have not read all the synopses and don't have
> an overview.
I don't think that it's explicitly spelled out anywhere; but the
reason is fairly straightforward: exclude and alias
In "Aiasing methods in CPAN roles", David Green wrote:
> Jon Lang wrote:
>> David Green wrote:
>>>
>>> I would expect that "role Logging { method log(Numeric $x:) {...} }"
>>> means the invocant is really of type Numeric & Logging, wit
Raphael Descamps wrote:
> In the original traits paper the aliasing is not "deep": to respect the
> flattening property, the semantic of the role must not change, so
> aliasing a recursive method will call the original method. It's a known
> theoretical weakness of the traits paper and "freezing ro
David Green wrote:
> Jon Lang wrote:
>> In "Aiasing methods in CPAN roles", David Green wrote:
>>>
>>> I don't want my special log() method to work only for other types that
>>> explicitly do NumLog; I want it to work for any type that directly &q
I recently attempted to write a sample mutable role that made use of a
number of lvalue methods, and I had a bear of a time getting it to
work. Could we arrange for a more intuitive option to be available?
For example, allow the programmer to pass a writer code block in
through the rw trait, and a
Jonathan Worthington wrote:
> Ovid wrote:
>>
>> I was asking the special case where:
>>
>> 1. A class consumes two (or more) roles
>> 2. Each roles provides a method with an identical signature
>> 3. The methods are not equivalent and neither role can rely on the other's
>> method
>>
>> With that,
TSa wrote:
> Jon Lang wrote:
>>
>> I have some more thoughts on this; but I'm on a time crunch at the
>> moment, and would really like to get some feedback on the above before
>> proceeding further: have I missed anything in my reasoning?
>
> I fully understan
Moritz Lenz wrote:
>> Given the above, if one wants to construct a full-precision rational
>> value in terms of 3 Int values analogous to a mantissa and radix and
>> exponent, what is the best way to write it in Perl 6?
>>
>> For example, say I want the following expression to result in a FatRat
>>
On Thu, Dec 3, 2009 at 6:38 PM, David Green wrote:
> I'm wondering whether we can make use of the contrary sense implied by the
> word "but", and have it apply specifically to cases where something is being
> overridden. In cases where there isn't something to override we could use a
> different
On Wed, Dec 16, 2009 at 2:10 PM, Dave Whipp wrote:
> The definition of the Complex type seems a little weak. A few things:
>
> To get the Cartesian components of the value there are two methods ("re" and
> "im"). In contrast there is just one method "polar" to return the polar
> components of the
Dave Whipp wrote:
> Moritz Lenz wrote:
>>
>> Dave Whipp wrote:
>>>
>>> [cut] Contrast with Rat which has both separate accessors and the "nude"
>>> method (a name that could possibly be improved to avoid adult-content
>>> filters)
>>
>> suggestions welcome.
>
> Attempting to generalize: what we wan
Dave Whipp wrote:
> Jon Lang wrote:
>>
>> my ($num, $denom) = $num.^attr; # $num.WHAT == Ratio;
>> my ($mag, $phase) = Complex::Polar($z).^attr;
>> my ($re, $im) = Complex::Cartesian($z).^attr;
>> my ($x, $y) = $vector.^attr »·« ( [1, 0], [0, 1] );
>
> I
On Sat, Dec 19, 2009 at 1:07 PM, wrote:
> for the most generic non-failure undefined value. The C type,
> derived from C, is also undefined, but excludes C so
> that autothreading may be dispatched using normal multiple dispatch
> -rules. The C type is derived from C but nothing else
> +rule
Perhaps you could create an error function that temporarily sets the
default error message (does perl 6 still have the $! variable?) and
returns false; so:
subset Filename of Str where { $_ ~~ :f or error ( "No such file: '$_'" ) }
Of course, that's a rather narrowly-defined function, as it's
Larry Wall wrote:
> But also note that there are several other ways to predeclare
> types implicitly. The 'use', 'require', and 'need' declarations
> all introduce a module name that is assumed to be a type name.
Just to clarify: it's possible to define a module within a file,
rather than as a fi
John Gabriele wrote:
> Personally, I've always thought that Perl has a very natural feel to
> it, and deserves a doc markup format that's also natural: [Markdown]
> (and [Pandoc]'s Markdown has just the right additions, IMO).
>
> [Markdown]: http://daringfireball.net/projects/markdown/
> [Pandoc]:
Moritz Lenz wrote:
> Please take a look at http://rt.perl.org/rt3/Ticket/Display.html?id=73356:
>
> rakudo: say max(1..5)
> rakudo c05478: OUTPUT«-Inf»
> * masak submits rakudobug for max(1..5)
>
> The weird thing is that it is right, according to the current spec. It says
>
> our multi max( Or
On Mon, Mar 8, 2010 at 12:40 PM, Darren Duncan wrote:
> Starting with the context of this piece of Synopsis 2:
>
> These types do (at least) the following roles:
>
> Class Roles
> = =
> Str Stringy
> Bit Numeric Boolean Integral
> Int Num
Darren Duncan wrote:
> 2. There doesn't seem to be a role for "complex" as there is for "integer"
> or "rational" or "real" or "numeric". So, if the boxed Perl complex number
> is called "Complex" and the machine native one is called "complex" or
> "complex128" or whatever, what would one name th
Ruud H.G. van Tol wrote:
> Did you consider "discrete"?
I think that "Discrete" could work quite well as the role that
encapsulates the ways in which Integer and Gauss are alike. It may
even be genralizable beyond that, although there might be some discord
between theory and practice. (In theory
Darren Duncan wrote:
> I'm inclined to consider a "Discrete" to be broad enough to include Boolean,
> as well as every single enum type in general; it would also include Order,
> say. So I would also then add a more specific something, say
> "DiscreteNumeric".
There are discrete things that are n
Damian Conway wrote:
> I do like the idea of being able to specify the sequence of values of an
> enumeration by using a series of some kind.
>
> And I must say the one that feels most natural is the one that plays on
> the equivalence of underlying equivalence of enums and constants, namely:
>
>
One more idea: could you implement the sort of thing being asked for
by means of a buffer? That is, what's the difference between the
bitset being asked for and a Buf[boolean]? And could those
differences be addressed by composing a Buf[boolean] into a more
appropriate role?
Note also that Perl
> Log:
> [Numeric] Move sqrt to Numeric. Remove incorrect return value type of roots.
> Move cis and unpolar to Real. Add to-radians and from-radians to Numeric.
The return value for roots should have been corrected (to List of
Numeric), not removed.
--
Jonathan "Dataweaver" Lang
Why do I find myself thinking of roles and classes here?
IMHO, we should have a role that represents abstractly a moment in
time. This role should, in and of itself, not be tied to any
particular calendar; its purpose is so that one can write functions
that make reference to instances in time wit
Darren Duncan wrote:
> I think that the most thorough solution is to just take it for granted that
> there are multiple reference timelines/calendars and that in general it is
> impossible to reconcile them with each other.
Taking this to its logical extreme, there might be a few (admittedly
fring
Darren Duncan wrote:
> Larry Wall wrote:
>>
>> Or going the other direction, perhaps we're missing a primitive that
>> can produce a data structure with the type information stripped, and
>> then eqv might be able to determine structural equivalence between
>> two canonicalized values.
>
> Often yo
Jon Lang wrote:
> Right. Still, there are times when duck-typing, flawed as it is,
> might be exactly what is needed to resolve the problem at hand. I
> forget who or in what context, but I vaguely recall someone posting an
> article here that proposed the use of £ in signatures as a
Smylers wrote:
> pugs-comm...@feather.perl6.nl writes:
>
>> Author: lwall
>> Log:
>> [S03] refine hyper dwimminess to be more like APL, with modular semantics
>>
>> + (1,2,3) »+» 1 # 2,4,4,6 rhs dwims to (1 xx *).batch(3)
>
> I'd've expected the output to be 2,3,4; is the 2,4,4,6 cop
wrote:
> +Regardless of whether the dwim is forced or emergent from the shapes
> +of the arrays, once the side to dwim on has been chosen, the dwim
> +semantics on the dwimmy side are always:
> +
> + (@dwimmyside xx *).batch(@otherside.elems)
> +
> +This produces a list the same length as the c
Darren Duncan wrote:
> With the above addition, you have both Buf and Blob roles as well as Buf and
> Blob types.
>
> I think you need to make each of those just a role or a type, and then add
> another named entity which is the counterpart role or type.
>
> For example, as you have Stringy as a ro
Another thing to consider is that Perl 6 is symbol-heavy: that is, keywords
are often symbols (such as &&, <=>, or $_) rather than words. AFAIK, those
symbols are not English, and I would not expect them to change under a
natural language transformation of the setting. And to elaborate on Aaron's
Aaron Sherman wrote:
> Oh bother, I wrote this up last night, but forgot to send it. Here y'all
> go:
>
> I've been testing ".." recently, and it seems, in Rakudo, to behave like
> Perl 5. That is, the magic auto-increment for "a" .. "z" works very
> wonkily,
> given any range that isn't within som
Solomon Foster wrote:
> Ranges haven't been intended to be the "right way" to construct basic
> loops for some time now. That's what the "..." series operator is
> for.
>
> for 1e10 ... 1 -> $i {
> # whatever
> }
>
> is lazy by the spec, and in fact is lazy and fully functional in
>
Approaching this with the notion firmly in mind that infix:<..> is
supposed to be used for matching ranges while infix:<...> should be
used to generate series:
Aaron Sherman wrote:
> Walk with me a bit, and let's explore the concept of intuitive character
> ranges? This was my suggestion, which se
Aaron Sherman wrote:
> So, what's the intention of the range operator, then? Is it just there to
> offer backward compatibility with Perl 5? Is it a vestige that should be
> removed so that we can Huffman ... down to ..?
>
> I'm not trying to be difficult, here, I just never knew that ... could
> o
Mark J. Reed wrote:
> Perhaps the syllabic kana could be the "integer" analogs, and what you
> get when you iterate over the range using ..., while the modifier kana
> would not be generated by the series ア ... ヴ but would be considered
> in the range ア .. ヴ? I wouldn't object to such script-spe
Smylers wrote:
> Jon Lang writes:
>> Approaching this with the notion firmly in mind that infix:<..> is
>> supposed to be used for matching ranges while infix:<...> should be
>> used to generate series:
>>
>> With series, we want C< $LHS ... $RHS >
Aaron Sherman wrote:
> Darren Duncan wrote:
> 3) It seems that there are two competing multi-character approaches and both
>>> seem somewhat valid. Should we use a pragma to toggle behavior between A
>>> and
>>> B:
>>>
>>> A: "aa" .. "bb" contains "az"
>>> B: "aa" .. "bb" contains ONLY "aa", "ab"
When I last reviewed the writeup for the series operators, I noticed two issues:
First, why is the RHS argument a list? You only ever use the first
element of it; so why don't you just reference a single value?
Second, I'm trying to think of a simple and intuitive way to write up
a series expres
On Thu, Jul 22, 2010 at 9:25 AM, Aaron Sherman wrote:
> On Thu, Jul 22, 2010 at 11:41 AM, Moritz Lenz wrote:
>> The difficulty you're running into is that you're trying to use the wrong
>> tool for the job. Just don't use the series operator when it's not easy to
>> use. Perl 6 has other mechanis
On Thu, Jul 22, 2010 at 11:35 AM, Aaron Sherman wrote:
> On Thu, Jul 22, 2010 at 1:13 PM, Jon Lang wrote:
>> Yes, it would be a
>> special tool; but it would be much more in keeping with the "keep
>> simple things easy" philosophy that Perl 6 tends to p
Aaron Sherman wrote:
> As a special case, perhaps you can treat ranges as special and not as simple
> iterators. To be honest, I wasn't thinking about the possibility of such
> special cases, but about iterators in general. You can't generically reverse
> lazy constructs without running afoul of th
Dave Whipp wrote:
> To squint at this slightly, in the context that we already have 0...1e10 as
> a sequence generator, perhaps the semantics of iterating a range should be
> unordered -- that is,
>
> for 0..10 -> $x { ... }
>
> is treated as
>
> for (0...10).pick(*) -> $x { ... }
>
> Then the wh
TSa wrote:
> Swapping the endpoints could mean swapping inside test to outside
> test. The only thing that is needed is to swap from && to ||:
>
> $a .. $b # means $a <= $_ && $_ <= $b if $a < $b
> $b .. $a # means $b <= $_ || $_ <= $a if $a < $b
This is the same sort of discontinuity
Darren Duncan wrote:
> Does "..." also come with the 4 variations of endpoint inclusion/exclusion?
>
> If not, then it should, as I'm sure many times one would want to do this,
> say:
>
> for 0...^$n -> {...}
You can toggle the inclusion/exclusion of the ending condition by
choosing between "..."
201 - 300 of 329 matches
Mail list logo
