Re: Custom object constructors
Kevan Benson wrote: That said, I submit that it's a very confusing part of the language as defined currently, and I haven't seen a very thorough explanation of the purpose of each method in the chain the instantiates a new object. S12 touches upon them slightly, but not in enough detail that I was able to work out where I should be adding code to appropriately make alternate constructors. I've tried to explain that here: http://perlgeek.de/blog-en/perl-6/object-construction-and-initialization.html (If anybody thinks part of this is worthy backporting to the specs, feel free). Cheers, Moritz
Re: Synopsis 02: Range objects [recap]
Timothy S. Nelson wrote: I think a Complex range only makes sense if you provide 4 endpoints, not 2, but I haven't been following the conversation, so I'll leave it up to the Complex number experts :). (start-angle, start-length) :by(angle-step, length-factor) -- Ruud
Re: versioning same-auth forks/branches
On 2009-Aug-26, at 3:54 pm, Darren Duncan wrote: The question I have is what to do when a single same authority wants to release multiple forks or branches of the same module, each presumably targeting a different use case, and the version numbers for each fork/branch are not supposed to be interrelated. We could allow arbitrary components in the name; that would give people as much latitude as they want in making up names and splitting them into pieces that are presumably meaningful to a human. Archives like CPAN could either use the whole name as identification (as long as the full thing is unique), or they could pick particular pieces that they will pay attention to (e.g. name + auth + vers) and ignore the rest. Conventions for other components might evolve over time (e.g. a standard meaning for :branch might become customary); the main use is for documentation and classifying modules so people can search for them, etc.Perl shouldn't care what the name is, long or short, other than having a unique way to identify each module. (We could even have an ID separate from the name, but if the names weren't unique that would be confusing for people too, so I don't see any reason not to keep the long name for that purpose.) Flagging stable vs. dev releases could be done via a designated component in the long name; or it could be a trait on the module (e.g. is statusbeta, is statusdev, etc.). Either way, the info is available so you can instruct Perl not to use any alpha modules, or so on. -David
Re: Synopsis 02: Range objects [recap]
Jon Lang wrote: 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 after are undefined. Agreed. I should have written that as part of the proposal as well. 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 default step algorithm is defined only for single-character strings, and fails if you give it anything else. In particular, the programmer should be allowed to enable Str-based RangeIterators by explicitly supplying his own step algorithm. That is: 'aa' .. 'zz' # Error in list context: default stepper rejects multi-character endpoints 'aa' .. 'zz' :by(stepper) # custom stepper overrides default concerns The difference between this and the triple dot-operator is that we provide an upper bound (and are forced to use the :by-adverb). Is it worth the while? Next open question: What about Ranges using different types in each endpoint? 1.5 .. 10 :by(0.5) (Rat .. Int) 0 .. 7 Should they be coerced - and in that case to what? If we don't coerce them, what should be returned? This is only a half-formed thought at the moment, so please bear with me: maybe Ranges should extend the triptych that exists with comparison operators. That is, you have before and after, lt and gt, and and ; you also have cmp, leg, and =. Perhaps .. should be treated as the numeric operator, and equivalent Str and generic operators should be supplied separately. I'd be inclined to spell the generic Range operator - the one corresponding to before/after/cmp - as to. I'm not sure how the Str-based one ought to be spelled. With .., there should be automatic coercion of both endpoints to numbers, just as there is with and . With to, there should be no coercion at all, just like before after, and cmp. And just like .. should nummify, the to operator should stringify? Sounds nice. Regards, Michael.
Re: Synopsis 02: Range objects
Karl Brodowsky wrote: Michael Zedeler schrieb: 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 guess that writing 1.00 .. 2.00 won't be sufficient. Trying to work out the step size by looking at the precision of things that are double or floats doesn't really sound so feasible, since there are a lot of holes in the actual representation, so 1.0001 may become 1.0, yielding very different results. That is a general problem of floats. We tend to write them in decimal notation, but internally they use a representation which is binary. And it is absolutely not obvious what the precision of 1.0001 might be. There could be a data type like LongDecimal in Ruby or BigDecimal in Java, that actually has a knowlegde of its precision and whose numbers are fractions with a power of 10 as the denominator. But for floats I would only see the interval as reasonably clear. Even a step of 1 is coming with some problems, because an increment of 1 does not have any effect on floating point numbers like 1.03e300 or so. Yes. Exactly my point. By the way, do we want to warn if someone writes 1e300 .. 1e301 :by(1) given that the number implementation yields 1e300 + 1 == 1e300? Regards, Michael.
Re: Synopsis 02: Range objects
Shouldn't it autopromote to Bignum at that point? On 8/27/09, Michael Zedeler mich...@zedeler.dk wrote: Karl Brodowsky wrote: Michael Zedeler schrieb: 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 guess that writing 1.00 .. 2.00 won't be sufficient. Trying to work out the step size by looking at the precision of things that are double or floats doesn't really sound so feasible, since there are a lot of holes in the actual representation, so 1.0001 may become 1.0, yielding very different results. That is a general problem of floats. We tend to write them in decimal notation, but internally they use a representation which is binary. And it is absolutely not obvious what the precision of 1.0001 might be. There could be a data type like LongDecimal in Ruby or BigDecimal in Java, that actually has a knowlegde of its precision and whose numbers are fractions with a power of 10 as the denominator. But for floats I would only see the interval as reasonably clear. Even a step of 1 is coming with some problems, because an increment of 1 does not have any effect on floating point numbers like 1.03e300 or so. Yes. Exactly my point. By the way, do we want to warn if someone writes 1e300 .. 1e301 :by(1) given that the number implementation yields 1e300 + 1 == 1e300? Regards, Michael. -- Sent from my mobile device Mark J. Reed markjr...@gmail.com
Re: Synopsis 02: Range objects [recap]
On Thu, Aug 27, 2009 at 2:59 AM, Jon Langdatawea...@gmail.com 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 default step algorithm is defined only for single-character strings, and fails if you give it anything else. In particular, the programmer should be allowed to enable Str-based RangeIterators by explicitly supplying his own step algorithm. That is: 'aa' .. 'zz' # Error in list context: default stepper rejects multi-character endpoints 'aa' .. 'zz' :by(stepper) # custom stepper overrides default concerns The difference between this and the triple dot-operator is that we provide an upper bound (and are forced to use the :by-adverb). Is it worth the while? It _does_ give you an upper bound, which ... doesn't do. This is only a half-formed thought at the moment, so please bear with me: maybe Ranges should extend the triptych that exists with comparison operators. That is, you have before and after, lt and gt, and and ; you also have cmp, leg, and =. Perhaps .. should be treated as the numeric operator, and equivalent Str and generic operators should be supplied separately. I'd be inclined to spell the generic Range operator - the one corresponding to before/after/cmp - as to. I'm not sure how the Str-based one ought to be spelled. With .., there should be automatic coercion of both endpoints to numbers, just as there is with and . With to, there should be no coercion at all, just like before after, and cmp. And just like .. should nummify, the to operator should stringify? Sounds nice. No. Technically, there should be three versions: a generic version that does no coercion; the version that nummifies; and the version that stringifies. I can only think of two names to use; so unless someone else can come up with a viable third name, we have to do without one of the three. The one that stringifies is the most expendible, since one can always explicitly stringify when no coercion is implicitly done, but there's no way _not_ to stringify if it _is_ implicitly done. And stringified ranges aren't nearly as important to have as numified ones are. -- Jonathan Dataweaver Lang -- Jonathan Dataweaver Lang
Re: Synopsis 02: Range objects
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 example: it really doesn't make sense that a value not produced by a range nevertheless lies between its endpoints. Why not have a separate Interval type? I see no problem when a Range matches for values which are not produced by a RangeIterator. I expect 2.5 ~~ 1..5 to be true even though 2.5 is not in 1,2,3,4,5. The same applies for 'aaa' ~~ 'aa'..'az'. I find this quite natural. Note that order is not a prerequisite for a notion of range and range iteration. I think of ranges more like set and set iteration. I'm going to post my take on the complex case elsewhere in this thread. Regards, TSa. -- The unavoidable price of reliability is simplicity -- C.A.R. Hoare Simplicity does not precede complexity, but follows it. -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: Synopsis 02: Range objects
HaloO, Michael Zedeler wrote: James Cloos wrote: Michael Complex .. Complex - undef, exception or some other bad thing. Complex .. Complex should have a defined meaning in p6. A definition which is easy to compute would be the set of points contained by the square which has opposite corners at the two specified points. We should not think of complex ranges as areas. The thing used in complex analysis is the path along which you integrate. OTOH circles are the two dimensional equivalents of intervals. But is that useful? Complex numbers are mostly for mathematics, so I guess we have to look in that domain for a good use case. In that domain there is no natural ordering of complex numbers, and without some ordering, you may be able to decide what should be in the list to return, but not which order to use. I have stated elsewhere that order is not necessary. A notion of distance suffices. The direction of iteration is well defined by the complex step size. I believe that anything we put into Perl 6 should have obvious use cases and fall natural into place in the domain that the construct in question belongs to. This means we have to come up with a design (there currently is no specification of Complex .. Complex), some kind of use case to as justification and finally a validation that ensures that the design is consistent with other things in the language. The complex case should result in the numeric case when given real numbers as bounds and step size. So my proposal for complex range iteration is to use complex addition to generate the next candidate and complex distance to check whether it is closer to the endpoint or not. The only drawback I see is that 1.2 .. 5 then iterates up to 5.2 not 4.2 as in the order based approach. But I don't consider this a bad outcome because the endpoint isn't hit in both cases and 5.2 is closer ;) Applying the above metric procedure to complex range matches is however a bit more problematic because the direction from start to end is not necessarily the same as that given by the step size. Since the step size should be ignored in real matches we should do so in the complex case as well and check whether the number in question lies on the line from start to end. Problem is how accurate this check shall be. IOW, what is the line width of the range? I would add an eps parameter to the range creating operator with a default around 1e-10. This would be useful for real ranges with excluded ends as well. Actually this parameter should be a relative error not an absolute one. Another idea is to make matches succeed in the intersection of the two circles around the endpoints through the other endpoint. E.g. then 2+i ~~ 1..3 is true and 2+2i ~~ 1..3 is false. This works for reals such that 1..3 is the intersection of -1..3 and 1..5 which are the one dimensional circles of radius 2 around 1 and 3 respectively. Note that this metric definition of interval can be generalized to vector spaces of arbitrary dimension where one intersects hyperspheres around two points. One can also generalise to non-euclidean metrics, of course. Perhaps even a string distance function might work. Regards, TSa. -- The unavoidable price of reliability is simplicity -- C.A.R. Hoare Simplicity does not precede complexity, but follows it. -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
1.23 becomes Rat (Re: Synopsis 02: Range objects)
Larry Wall wrote: Another note, it's likely that numeric literals such as 1.23 will turn into Rats rather than Nums, at least up to some precision that is pragmatically determined. Doing these as Rat would avoid a lot of the precision issues that floating point arithmetic has all the time. It will actually work perfectly well with addition, because the denominator is always a small power of 10, so that is true for the sum as well. Multiplying might be an issue, because the denominator becomes a large power of 10, but I think that that can be handled pretty well, unless the multiplication is really performed to an extent that the result uses significant amounts of memory. But as soon as division is occuring, these rational numbers tend to develop denominators that are not powers of 10 any more. Combining this with some multiplications and additions this may result in huge numerators and denominators that are somewhat expensive to handle. So what would happen after such a long calculation: - would the Rats somehow know that they are all derived from Rats that were just used instead of floats because of being within a pragmatically determined precision? Then the result of * or / could just as pragmatically become a floating point number? - would the Rats grow really huge numerators and denominators, making it expensive to work with them? - would the first division have to deal with the conversion from Rat to floating point? - or should there be a new numeric type similar to Rat that is always having powers of 10 as denominator (like BigDecimal in Java or LongDecimal for Ruby or decimal in C# or so)? Even in this last case the division is not really easy to define, because the exact result cannot generelly be expressed with a denomonator that is a power of 10. This can be resolved by: - requires additional rounding information (so writing something like a.divide(b, 10, ROUND_UP) or so instead of a/b - implicitely find the number of significant digits by using partial derivatives of f(x,y)=x/y - express the result as some kind of rational number - express the result as some kind of floating point number. Regards Karl
Re: Synopsis 02: Range objects
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 example: it really doesn't make sense that a value not produced by a range nevertheless lies between its endpoints. Why not have a separate Interval type? I see no problem when a Range matches for values which are not produced by a RangeIterator. I expect 2.5 ~~ 1..5 to be true even though 2.5 is not in 1,2,3,4,5. I suspect that the double meaning of Ranges is going to confuse some people and bite others. If things stay as they are, I hope that the use of :by will be flagged as a syntax error if used in literal Range smart matching. Of course, that doesn't help the unsuspecting when variables are being used, ala 2.5 ~~ $myrange. (For the record, 2.5 ~~ '!'..5 is also true on my system, although I don't know why! I certainly wouldn't expect it though :) The same applies for 'aaa' ~~ 'aa'..'az'. I find this quite natural. Not sure if you're saying that's something you'd like or if you think that that's something already there. It doesn't match for me using recent(ish) Rakudo. Of course, that could just be me! :) I'd personally prefer it if Ranges just did lists, including when smart matching, but had an interval method or such like for explicit matching against the endpoints, e.g. 2.5 ~~ interval(1..5) # or 2.5 ~~ $myrange.interval I'm new in town though, so I'll happily admit that I don't know the full implications of such a change. Having context-insensitive Ranges DWIM's better to me, but DWIMery, like beauty, is clearly in the eye of the beholder! :) Cheers, -- smuj
Re: Synopsis 02: Range objects
Given how easy chained relational ops make explicit range checking with endpoints, e.g. $a = $x = $b Imd be perfectly happy with a Range smartmatching only the elements that you get out of the RangeIterator. On 8/27/09, smuj s...@iol.ie 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 example: it really doesn't make sense that a value not produced by a range nevertheless lies between its endpoints. Why not have a separate Interval type? I see no problem when a Range matches for values which are not produced by a RangeIterator. I expect 2.5 ~~ 1..5 to be true even though 2.5 is not in 1,2,3,4,5. I suspect that the double meaning of Ranges is going to confuse some people and bite others. If things stay as they are, I hope that the use of :by will be flagged as a syntax error if used in literal Range smart matching. Of course, that doesn't help the unsuspecting when variables are being used, ala 2.5 ~~ $myrange. (For the record, 2.5 ~~ '!'..5 is also true on my system, although I don't know why! I certainly wouldn't expect it though :) The same applies for 'aaa' ~~ 'aa'..'az'. I find this quite natural. Not sure if you're saying that's something you'd like or if you think that that's something already there. It doesn't match for me using recent(ish) Rakudo. Of course, that could just be me! :) I'd personally prefer it if Ranges just did lists, including when smart matching, but had an interval method or such like for explicit matching against the endpoints, e.g. 2.5 ~~ interval(1..5) # or 2.5 ~~ $myrange.interval I'm new in town though, so I'll happily admit that I don't know the full implications of such a change. Having context-insensitive Ranges DWIM's better to me, but DWIMery, like beauty, is clearly in the eye of the beholder! :) Cheers, -- smuj -- Sent from my mobile device Mark J. Reed markjr...@gmail.com
Re: Synopsis 02: Range objects
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 example: it really doesn't make sense that a value not produced by a range nevertheless lies between its endpoints. Why not have a separate Interval type? I see no problem when a Range matches for values which are not produced by a RangeIterator. I expect 2.5 ~~ 1..5 to be true even though 2.5 is not in 1,2,3,4,5. I suspect that the double meaning of Ranges is going to confuse some people and bite others. If things stay as they are, I hope that the use of :by will be flagged as a syntax error if used in literal Range smart matching. Of course, that doesn't help the unsuspecting when variables are being used, ala 2.5 ~~ $myrange. Another possibility is that literal Range smartmatching works as is in the absence of :by (that is, with a Range), but becomes a set membership test in its presence (i.e., with a RangeIterator). Or not; see below. (For the record, 2.5 ~~ '!'..5 is also true on my system, although I don't know why! I certainly wouldn't expect it though :) One explanation would be that it's comparing the String 2.5 to the String-terminated Range !..5. Since 2 falls between ! and 5, so does 2.5. The same applies for 'aaa' ~~ 'aa'..'az'. I find this quite natural. Not sure if you're saying that's something you'd like or if you think that that's something already there. It doesn't match for me using recent(ish) Rakudo. Of course, that could just be me! :) I'd personally prefer it if Ranges just did lists, including when smart matching, but had an interval method or such like for explicit matching against the endpoints, e.g. 2.5 ~~ interval(1..5) # or 2.5 ~~ $myrange.interval I don't like the Huffman encoding: does $x come after $a and before $b? is a common test, and so should be short. I'd rather require you to force it into list context if your goal is to test for set membership. In fact, that might be a clean way of handling its dual nature: in item context, it behaves as a Range object; in list context, it behaves as the RangeIterator. So: 2.5 ~~ 1..5 # true: equivalent to 2.5 ~~ 1 = $_ = 5. 2.5 ~~ @(1..5) # false: equivalent to 2.5 ~~ (1, 2, 3, 4, 5). Incidently, this first example is why I think that Range is intimately related to the various order-related operators, and in particular before and after: its most common use outside of generating sequential lists is to provide a shorthand for $min before $_ before $max and similar range-testing expressions. -- Jonathan Dataweaver Lang
Re: Synopsis 02: Range objects
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. But I do like your list context for list behavior idea. I would support that happily. On 8/27/09, Jon Lang datawea...@gmail.com wrote: 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 example: it really doesn't make sense that a value not produced by a range nevertheless lies between its endpoints. Why not have a separate Interval type? I see no problem when a Range matches for values which are not produced by a RangeIterator. I expect 2.5 ~~ 1..5 to be true even though 2.5 is not in 1,2,3,4,5. I suspect that the double meaning of Ranges is going to confuse some people and bite others. If things stay as they are, I hope that the use of :by will be flagged as a syntax error if used in literal Range smart matching. Of course, that doesn't help the unsuspecting when variables are being used, ala 2.5 ~~ $myrange. Another possibility is that literal Range smartmatching works as is in the absence of :by (that is, with a Range), but becomes a set membership test in its presence (i.e., with a RangeIterator). Or not; see below. (For the record, 2.5 ~~ '!'..5 is also true on my system, although I don't know why! I certainly wouldn't expect it though :) One explanation would be that it's comparing the String 2.5 to the String-terminated Range !..5. Since 2 falls between ! and 5, so does 2.5. The same applies for 'aaa' ~~ 'aa'..'az'. I find this quite natural. Not sure if you're saying that's something you'd like or if you think that that's something already there. It doesn't match for me using recent(ish) Rakudo. Of course, that could just be me! :) I'd personally prefer it if Ranges just did lists, including when smart matching, but had an interval method or such like for explicit matching against the endpoints, e.g. 2.5 ~~ interval(1..5) # or 2.5 ~~ $myrange.interval I don't like the Huffman encoding: does $x come after $a and before $b? is a common test, and so should be short. I'd rather require you to force it into list context if your goal is to test for set membership. In fact, that might be a clean way of handling its dual nature: in item context, it behaves as a Range object; in list context, it behaves as the RangeIterator. So: 2.5 ~~ 1..5 # true: equivalent to 2.5 ~~ 1 = $_ = 5. 2.5 ~~ @(1..5) # false: equivalent to 2.5 ~~ (1, 2, 3, 4, 5). Incidently, this first example is why I think that Range is intimately related to the various order-related operators, and in particular before and after: its most common use outside of generating sequential lists is to provide a shorthand for $min before $_ before $max and similar range-testing expressions. -- Jonathan Dataweaver Lang -- Sent from my mobile device Mark J. Reed markjr...@gmail.com
Re: Synopsis 02: Range objects
Jon Lang wrote: smuj wrote: I'd personally prefer it if Ranges just did lists, including when smart matching, but had an interval method or such like for explicit matching against the endpoints, e.g. 2.5 ~~ interval(1..5) # or 2.5 ~~ $myrange.interval I don't like the Huffman encoding: does $x come after $a and before $b? is a common test, and so should be short. I'd rather require you to force it into list context if your goal is to test for set membership. In fact, that might be a clean way of handling its dual nature: in item context, it behaves as a Range object; in list context, it behaves as the RangeIterator. So: 2.5 ~~ 1..5 # true: equivalent to 2.5 ~~ 1 = $_ = 5. 2.5 ~~ @(1..5) # false: equivalent to 2.5 ~~ (1, 2, 3, 4, 5). Incidently, this first example is why I think that Range is intimately related to the various order-related operators, and in particular before and after: its most common use outside of generating sequential lists is to provide a shorthand for $min before $_ before $max and similar range-testing expressions. So you're saying you'd like things to stay exactly as they are at the moment!? :-) -- smuj
Re: Synopsis 02: Range objects
On Thu, Aug 27, 2009 at 2:36 PM, Mark J. Reedmarkjr...@gmail.com 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 '=' numify their arguments before comparing them. 'lt' and 'le' stringify their arguments before comparing them. 'before' compares its arguments without any coercion. Note that there's no equivalent to '='. I'm unclear as to which of these cases '..' is currently like, if any; it may be an unholy hybrid of all three. But for the sake of argument, I'll assume that it's currently like '' and '='. $a ~~ 1..5 # $a ~~ 1 = $_ = 5 $a ~~ 1^..5 # $a ~~ 1 $_ = 5 $a ~~ 1..^5 # $a ~~ 1 = $_ 5 $a ~~ 1^..^5 # $a ~~ 1 $_ 5 What's so hard about that? And if '..' is like 'before', it can do things that can't easily be done otherwise: $a ~~ 1..5 # 1 before $_ before 5 || $_ === 1 | 5 -- Jonathan Dataweaver Lang
Re: Synopsis 02: Range objects
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, restrict '..' to cases when you're defining a range of numbers, and use 'to' to handle all other cases. It might also be nice to have a stringifying version; perhaps 'be', using the same everything's an acronym naming convention used by other stringifying operators (e.g., 'lt' is less than, 'le' is 'less than or equal to', 'leg' is less than, equal to, greater than) - in this case, 'be' would be 'beginning to end'. At the very least, this would avoid the inevitable questions about why there isn't a stringifying version. :) That said, it may not be good for much more than that. -- Jonathan Dataweaver Lang
Re: Synopsis 02: Range objects
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: equivalent to 2.5 ~~ (1, 2, 3, 4, 5). Not by current rules; which say the left side matches the list 1..5 as a whole. We don't do implicit junctifying of lists anymore, and haven't for several years. Which points to the correct Perl 6 utterance for that: 2.5 ~~ any(1..5)# false Wherein, as you suggest, the 1..5 in list context does in fact iterate the range to produce individual values. Larry
Re: Synopsis 02: Range objects
On Thu, Aug 27, 2009 at 2:34 PM, Larry Wallla...@wall.org 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: equivalent to 2.5 ~~ (1, 2, 3, 4, 5). Not by current rules; which say the left side matches the list 1..5 as a whole. We don't do implicit junctifying of lists anymore, and haven't for several years. Which points to the correct Perl 6 utterance for that: 2.5 ~~ any(1..5) # false Wherein, as you suggest, the 1..5 in list context does in fact iterate the range to produce individual values. You're right, of course. I keep getting tripped up on those details... -- Jonathan Dataweaver Lang
Re: Synopsis 02: Range objects
On Aug 27, 2009, at 17:48 , Jon Lang wrote: On Thu, Aug 27, 2009 at 2:36 PM, Mark J. Reedmarkjr...@gmail.com 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? .. vs. ... operators, I presume. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part
