Modular versions and APIs

Discussions about module versions have touched on questions of how to distinguish or specify interfaces/APIs a few times, but I haven't seen much detail, so I thought I'd post some musings on the subject. At its simplest, I want to add some functionality to my program by using some module; and

Re: handling undef better

On 12/16/05, Darren Duncan wrote: The root question of the matter is, what does "undef" mean to you? To me it means nothing. (I'm so callous.) The fact is, that in any normal program, using an undefined value as if it were a defined one is a bug. Normally there will be a point where such

Re: Junctions again (was Re: binding arguments)

On 1/4/06, Luke Palmer wrote: The other thing that is deeply disturbing to me, but apparently not to many other people, is that I could have a working, well-typed program with explicit annotations. I don't think it disturbs me... but that might just be because I don't really understand it.

Re: The definition of 'say'

On 2/8/06, Larry Wall wrote: > From: Damian Conway <[EMAIL PROTECTED]> > I've now been using C (via Perl6::Say) for some time -- testing our collective intuition on this -- and it turns out that b. isn't the least surprising. At least, not to me. In fact, I am regularly (and annoyingly) >

Re: Smart match table

On 2/8/06, Mike Guy wrote: I obviously missed that when it went past on p5p. Surely that should read Any Code()predicate(value) match if $b->($a) meaning that $a satisfies the predicate implemented by the code $b? Ignoring $a seems a completely stupid thing to do. Well, t

Re: s29 and Complex numbers

On 2/23/06, Jonathan Lang wrote: (Another possibility would be to return a list of every possible result when in list context, with the result that you'd get in scalar context being element zero of the list. This even has its uses wrt sqrt(Num), providing a two-element list of the positive an

Re: comment scope

e Comments::Boxchars" line first. #==# # -David Green # #==#

Spaced Out (Was Re: [svn:perl6-synopsis] r8573 - doc/trunk/design/syn)

On 4/6/06, Larry Wall wrote: On Thu, Apr 06, 2006 at 10:18:48PM +0800, Audrey Tang wrote: : TSa wrote: : > And a self($_.bar) is pretty much useless. In other words : > wrongly huffmanized. : : FWIW, I agree with both points. I agree with those points too, but not necessarily the conclusion. S

Re: Easy Str === Str question: what is a reference type

On 7/12/06, Aaron Sherman wrote: There's a problem here, from my point of view. I'll take it one assumption at a time: * $whatever.as.id ~~ $whateverelse.as.id is true if and only if $whatever := $whateverelse at some point in the past, either explicitly, or through some so

Re: ===, =:=, ~~, eq and == revisited (blame ajs!) -- Explained

On 7/13/06, Yuval Kogman wrote: So, Larry assisted by Audrey explained the purpose of === vs eqv vs =:=. It makes sense now, but I still feel that as far as ergonomics go this is not perfect. I think I understand it... (my only quibble with the syntax is that === and eqv look like spin-offs o

Re: naming of the Str type

On 8/8/06, Darren Duncan wrote: At 5:25 PM -0700 8/8/06, Darren Duncan wrote: I'm wondering if it would not be inappropriate to change the name Str to something more descriptive of its content within the historical or current wider context. ... I have evolved my thoughts to accept that Str i

Re: ===, =:=, ~~, eq and == revisited (blame ajs!) -- Explained

On 8/13/06, Smylers wrote: Please could the proponets of the various behaviours being discussed here share a few more concrete examples which start by explaning a scenario in which there is a desire to do something, preferably one that Perl 5 coders can identify with, and then show how on

Re: ===, =:=, ~~, eq and == revisited (blame ajs!) -- Explained

Way back on 7/14/06, Larry Wall wrote: On Thu, Jul 13, 2006 at 10:19:24PM -0600, David Green wrote: [...] No, === is also deep. It's only shallower (or potentially shallower) in the sense that it treats any mutable object node as a leaf node rather than changing to "snapshot"

Re: ===, =:=, ~~, eq and == revisited (blame ajs!) -- Explained

On 8/14/06, Smylers wrote: David Green writes: Thanks for that. In summary, if I've understood you correctly, it's that: =:= two aliases to the same actual variable === one variable contains a copy of the other's actual contents eqv both contain contents which represent

=== and array-refs

On 8/14/06, Smylers wrote: David Green writes: I guess my problem is that [1,2] *feels* like it should === [1,2]. You can explain that there's this mutable object stuff going on, and I can follow that (sort of...), but it seems like an implementation detail leaking out. The curr

Re: === and array-refs

On 8/16/06, Dr.Ruud wrote: I also wondered why a "simple" array (for example containing only value type objects) whould not C<===> its copy. But with .SKID that must be easy to handle. That's what I was wondering that started off this thread. I understand (more or less, I think), why it *does

Re: === and array-refs

On 8/16/06, Charles Bailey wrote: This is where the "eternal" part starts to confuse me (not picking on your wording, but on the semantics). I'll pick on the wording (wording should always be picked on -- not to be pedantic (OK, I like to be pedantic, but that's not the *only* reason!), but b

Re: === and array-refs

On 8/15/06, Darren Duncan wrote: At 2:51 PM -0600 8/15/06, David Green wrote: [...] You are right, but we have both Seq and Array types, so depending which one you use, you want either the === or eqv operators to do what you want. There is no reason that === should say 2 Array are equal; we

Re: === and array-refs

On 8/16/06, David Green wrote: $a=[1, 2, [EMAIL PROTECTED]; $c=[1, 2, [EMAIL PROTECTED]; $d=[1, 2, [EMAIL PROTECTED]; $a =:= $c; #false, different variables $a === $c; #true, same elements make up $a and $c $a eqv $c; #true, same elements

Re: === and array-refs

On 8/17/06, Darren Duncan wrote: At 11:16 PM -0600 8/16/06, David Green wrote: I just want [1,2] to be === to [1,2], or [1,2, [EMAIL PROTECTED] to be equal to [1,2, [EMAIL PROTECTED] but !=== [1,2, [EMAIL PROTECTED] -- eqv won't work in the latter case (regardless of Seq vs. Array -- I d

Re: Numerification of Order:: constants

On 8/17/06, Reed, Mark (TBS) wrote: S03, lines 418-420: "[cmp] always returns C, C, or C (which numerify to -1, 0, or +1)." Shouldn't Order::Increase numerify to +1 and Order::Decrease to -1? In which case it would be clearer to put them in respective order above... Maybe you could view it e

Re: === and array-refs

On 8/16/06, David Green wrote: $a=[1, 2, [EMAIL PROTECTED]; $c=[1, 2, [EMAIL PROTECTED]; $d=[1, 2, [EMAIL PROTECTED]; $a =:= $c; #false, different variables $a === $c; #true, same elements make up $a and $c $a eqv $c; #true, same elements

Re: META vs meta

On 9/11/06, Larry Wall wrote: Only that I'm thinking of renaming all the meta-ish methods to use interrogative pronouns: .META-> .HOW .SKID-> .WHO .PKG -> .WHAT .VAR -> .WHERE .WHO and .WHAT strike me as better being swapped. Maybe... or some such. Not s

Negative array subscripts

On 1/30/07, [EMAIL PROTECTED] wrote in "[svn:perl6-synopsis] r13549 - doc/trunk/design/syn": +It has become the custom to use negative subscripts to indicate counting +from the end of an array. This is still supported, but only for unshaped +arrays: +For shaped arrays you must explicitly refer t

Re: Negative array subscripts

On 2/5/07, David Green wrote: Then we wouldn't need * to count backwards, although it's still useful to allow us to count past the end of an array. There are all sorts of variations on this scheme, such as whether * is the last element or the one after that, etc., or whether 0 sho

Re: [S09] "Whatever" indices and shaped arrays

On 2/24/07, Jonathan Lang wrote: In effect, using * as an array of indices gives us the ordinals notation that has been requested on occasion: '*[0]' means 'first element', '*[1]' means 'second element', '*[-1]' means 'last element', '*[0..2]' means 'first three elements', and so on - and this

Re: [S09] "Whatever" indices and shaped arrays

On 2/27/07, Jonathan Lang wrote: David Green wrote: So I end up back at one of Larry's older ideas, which basically is: [] for counting, {} for keys. What if you want to mix the two? "I want the third element of row 5". In my proposal, that would be "@array[5, *[2]]

Re: [S09] "Whatever" indices and shaped arrays

On 3/7/07, Jonathan Lang wrote: Looks good to me. As well, the fact that @x[-1] doesn't refer to the element immediately before @x[0] is awkward, as is the fact that @x[*-1] doesn't refer to the element immediately before @x[*+0]. IMHO, it would be cleaner to have @x[n] count forward and

Whatevereversing Ranges

On 2/28/07, [EMAIL PROTECTED] wrote: Ranges are not autoreversing: C<2..1> is always a null range. I assume the reason for not having ranges automatically go in either direction is that it would make it easier for subtle bugs to creep in when either end is smaller (or bigger) than you expecte

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

On 3/8/07, Smylers wrote: In Perl 5 if you rely on a feature (or bugfix) from a particular version of a module you can specify that version and the code will continue to work with future versions -- which is a reasonably pragmatic approach, effectively saying "until proven otherwise I'll presu

Module versions (was "Re: [svn:perl6-synopsis] r14317 - doc/trunk/design/syn")

On 3/8/07, Larry Wall wrote: Perl 6 is specced to keep all the old versions of modules around in the library (unless the new version claims to emulate the old version). Oh, good! So how does a module say that it emulates another version? (Or perhaps another module altogether...) Does "does"

Re: request new Mapping|Hash operators

On 3/16/07, Darren Duncan wrote: On Wed, 7 Mar 2007, Smylers wrote: >[...] Perl is a better language than SQL, in general, [...] Likewise, we shouldn't have to write in SQL, or in pseudo-Perl-SQL, but just write in Perl. A database is supposed to be a base for *data*, after all. I'd love to

Re: request new Mapping|Hash operators

On 3/18/07, Darren Duncan wrote: On Sun, 18 Mar 2007, Aaron Crane wrote: > That's easy even in Perl 5. This modifies %hash in-place: > my @values = delete @[EMAIL PROTECTED]; > @[EMAIL PROTECTED] = @values; [...] If %hash contained keys a,b,c and @old_names was a and @new_names was b

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

On 5/29/07, Larry Wall wrote: Note that "any" is considered a singular noun in English, I started to say, "Except when it means 'all'", but when used that way, it still would mean "all" in the singular sense. But it gives me an excuse to point out that "any" can be ambiguous in English; it'

Re: Referring to source code within Perldoc

On 6/21/07, brian d foy wrote: Couldn't most of this be figured out by making Pod6 extensible (or whatever the right term is). Pod6 would be more of the syntax and basic operation, but other people could have custom directives that their Pod6 translators and formatters could then use. Yeah, t

Re: Referring to source code within Perldoc: the new A<> code

On 6/21/07, Smylers wrote: Please can you explain the reasoning for choosing antecedent, rather than successor? I assume because it's easier for someone to refer to something that was just written in the preceding line(s) than something that hasn't been written yet. Of course, documentation

Re: documentation standards (was "[svn:perl6-synopsis] r14421 - doc/trunk/design/syn")

On 6/21/07, Smylers wrote: Mark Overmeer writes: > The boundary between freedom and anacharchy is faint. Indeed. And I'd much rather we err on the side of anarchy. I'd much rather we didn't err at all! Just because something isn't "perfect" doesn't mean it's an error, or that it's not worth

Re: documentation standards (was "[svn:perl6-synopsis] r14421 - doc/trunk/design/syn")

On 6/22/07, Smylers wrote: David Green writes: Well, clutter like "Blah: none" seems to me to be more the fault of the doc-formatter for not hiding lines like that. It's more the repetition in the lines you snipped that I really object to: Ah. (That was sneaky of me.) I

Re: Documenting Perl6 part 2

On 7/14/07, Mark Overmeer wrote: [...] I sincerely hope that the summerizor is wrong: . in the last week, the main people who are not happy with what I've done have put out a document indicated what they'd like. I'm digesting that and I'm going to try to explain how it can be made to fit

Re: Pair notation for number radix

On 10/6/07, brian d foy wrote: That looks like it might mean that these are corresponding forms: 8 => 377:8<377>:8(377) Now, if I can do that, what happens to the pair form in a hash composer when I want the key of '8' and the value of :10<377>? What happened to the suggestion of us

The Core of the Matter (was "Re: xml and perl 6")

On 11/29/07, Luke Palmer wrote: I think you are falling into a classic builtin trap. [...] Please, you, everyone, forget about the word "core". It is an implementation detail. Yes! Though it's a natural mistake because people assume that The CORE(TM) in Perl6 means something similar to the

Standards bearers (was "Re: xml and perl 6")

On 11/29/07, James Fuller wrote: but by making some fundamental xml processing available by the core (like file access, regex, and a host of other fundamental bits n bobs), u do promote a common and systematic approach to working with XML in all perl modules. As everyone else and his dog has

Re: xml and perl 6

On 11/29/07, James Fuller wrote: well, if my previous posts didn't attract flames this post certainly will ;) Nah, this is getting into the interesting language part! (Technically, it should be perl6+xml-language... but then the goal of perl6 is to be infinitely flexible, so I guess it is

Re: what should be the default extension?

On 1/7/08, Trey Harris wrote: In a message dated Mon, 7 Jan 2008, Richard Hainsworth writes: May I suggest the following extension to the 'use ' pragma, viz. use in Oh please, no. The entire point of the wording currently in the synopsis is so that we can have platform-independent locatio

Re: pluralization idea that keeps bugging me

On 2008-Jan-26, at 9:58 am, Larry Wall wrote: My first thought is that this is such a common idiom that we ought to have some syntactic sugar for it: say "Received $m message\s." I've always wanted a magic-S (and I don't think the anglocentrism matters, because Perl is already pretty angl

Re: pluralization idea that keeps bugging me

On 2008-Jan-31, at 2:38 am, Mark Overmeer wrote: * David Green ([EMAIL PROTECTED]) [080131 08:48]: I've always wanted a magic-S (and I don't think the anglocentrism matters In "the good old days" all computer OSes were anglo-centric. They are not like that anymore

Re: Musings on operator overloading (was: File-Fu overloading)

On 2008-Feb-24, at 2:28 pm, Jonathan Lang wrote: { use text; if $a > "49" { say $a } } ...with the result being the same as Perl5's 'if $a gt "49" { say $a }' (so if $a equals '5', it says '5'). Am I following you? If so, I'm not seeing what's so exciting about the concept; The whole poi

Re: Musings on operator overloading

On 2008-Mar-19, at 1:40 pm, Mark J. Reed wrote: On Wed, Mar 19, 2008 at 1:01 PM, Larry Wall <[EMAIL PROTECTED]> wrote: The use of + in Python or << in C++ is, I think, primarily the violation of a *linguistic* principle, not a mathematical principle. Maybe it's just 'cause I cut my teeth on BA

Re: Idea: infer types of constants

On 2008-Apr-13, at 4:07 am, John M. Dlugosz wrote: I'm thinking that 'constant' is more special than other variables, and that the formal description of strong typing and static types should say that the compiler =will= implicitly get the type for $pi rather than making it Any. Except if c

Re: What does 'eqv' do exactly?

On 2008-May-3, at 5:12 pm, John M. Dlugosz wrote: Jon Lang dataweaver-at-gmail.com |Perl 6| wrote: My own understanding of it is that "snapshot semantics" involves looking at an immutable copy of an object (a "snapshot" of it) instead of looking at the object itself. That said, my understa

Re: nested 'our' subs - senseless?

On 2008-May-3, at 5:04 pm, John M. Dlugosz wrote: What does this mean? our sub outer () { ... our sub inner () { ... } } inner; # defined? I think this should be illegal. Nested named subs makes sense for 'my', with the rules of visibility matching the ability to clone the closure

Re: nested 'our' subs - senseless?

On 2008-May-6, at 6:07 am, TSa wrote: Just to ensure that I get the our behavior right, consider sub foo { our $inner = 3; } sub bar { our $inner = 4; # redeclaration error? } say $inner; Does this print 3 even when foo was never called? No, it throws an error

Re: ordinal access to autosorted hashes

On 2008-May-27, at 8:32 pm, Jon Lang wrote: [...] Would it be reasonable to allow hashes to use .[] syntax as something of a shortcut for ".iterator in list context", thus allowing autosorted hashes to partake of the same sort of dual cardinal/ordinal lookup capabilities that lists with user-defi

Huffman encoding (was Re: treatment of "isa" and inheritance)

On 2008-Apr-30, at 1:29 pm, Brandon S. Allbery KF8NH wrote: On Apr 30, 2008, at 15:14 , Jon Lang wrote: On a side note, I'd like to make a request of the Perl 6 community with regard to coding style: could we please have adverbal names that are, well, adverbs? "is :strict Dog" brings to my mind

Re: assignable mutators (S06/Lvalue subroutines)

On 2008-May-27, at 9:40 am, Dave Whipp wrote: TSa wrote: method inch { yield $inch = $.mm * 25.4; self.mm = $inch / 25.4; } Would you regard that as elegant? That looks functionally incorrect to my eyes: if the caller resumes at the time of the "yield" s

Re: ordinal access to autosorted hashes

On 2008-Jun-1, at 11:20 am, Jon Lang wrote: David Green wrote: I thought it already did, but apparently it's something that we discussed that didn't actually make it into S09. I agree that .[] should apply to hashes just as .{} can apply to arrays. The hashes don't ev

Re: assignable mutators (S06/Lvalue subroutines)

On 2008-Jun-1, at 1:50 pm, Jon Lang wrote: David Green wrote: [...] assignment should work like passing args when used on a function. Then you can easily do whatever you want with it. [...] If a routine is rw, you may optionally define a single "slurpy scalar" (e.g., '*

Re: assignable mutators (S06/Lvalue subroutines)

On 2008-Jun-2, at 3:30 pm, Jon Lang wrote: sub foo($value?) is rw($value) { ... } Or something to that general effect. The parameter in question must be optional and cannot have a default value, so that a test of whether or not the parameter is actually there can be used to determine whe

Re: Multiple Return Values - details fleshed out

On 2008-Aug-9, John M. Dlugosz wrote to clarify and extrapolate from what is written in the Synopses: Third, list assignment will handle assignment to a literal pair by accessing the names of the items inside the Capture. So list assignment beh

Re: Why no "is ro"? (Re: Subroutine parameter with trait and default.)

On 2008-Sep-23, at 2:32 pm, Michael G Schwern wrote: My other thought is that since parameters are read-only by default it's not thought you'd have to write it much so clarity wins out over brevity, the flip side of Huffamn encoding. But that doesn't work out so good for normal variable de

Re: Split with negative limits, and other weirdnesses

On 2008-Sep-23, at 8:38 am, TSa wrote: Moritz Lenz wrote: In Perl 5 a negative limit means "unlimited", which we don't have to do because we have the Whatever star. I like the notion of negative numbers as the other end of infinity. I think positive values and zero make sense. But I don't

Re: Why no "is ro"? (Re: Subroutine parameter with trait and default.)

On 2008-Sep-23, at 5:27 pm, Michael G Schwern wrote: David Green wrote: Happily, brevity often aids clarity. The rest of the time, it should be up to one's editor; any editor worth its salt ought to easily auto-complete "ro" into "readonly". Eeep! The "your

Signatures and matching (was "Re: XPath grammars (Was: Re: globs and trees in Perl6)")

On 2008-Oct-2, at 6:15 pm, Timothy S. Nelson wrote: The guys on IRC convinced me that the way to go might be something like a grammar, but that does trees and tree transformations instead of a text input stream. See the IRC log for details :). [...] note to treematching folks: it is envisag

Re: Signatures and matching (was "Re: XPath grammars (Was: Re: globs and trees in Perl6)")

On 2008-Oct-22, at 10:03 am, TSa wrote: David Green wrote: One thing I would like signatures to be able to do, though, is assign parameters by type. Much like a rule can look for identifiable objects like a or , it would be very useful to look for parameters by their type or class rather

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

On 2008-Dec-2, at 12:33 pm, Geoffrey Broadwell wrote: On Tue, 2008-12-02 at 08:50 +0100, Carl Mäsak wrote: Darren (>): How does one write anonymous value literals of those types? Why is the latter method [conversion] insufficient for your needs? Efficiency reasons, among others. Surely the

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

On 2008-Dec-3, at 12:38 pm, Mark J. Reed wrote: Overall, the goal is to ensure that by the end of the loop the program is in the state of having just called doSomething(), whether the loop runs or not - while also ensuring that the program is in that state at the top of each loop iteration.

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

On 2008-Dec-3, at 10:18 am, TSa wrote: Darren Duncan wrote: Strong typing in Perl means that Perl is conveniently and reliably keeping track of this user-intended interpretation of the data, so it is easy for any piece of code to act on it in a reasonable way. Strong typing lets user code

Re: why infix::(Int, Int --> Rat)

On 2008-Dec-4, at 9:42 am, TSa wrote: I remember the state of affairs being that [div] returns an Int Something more explicit like "idiv" was suggested for integral division. Personally, I'm happy not to have anything special provided for it, on the grounds that having to say, e.g. "floor(

Equality of values and types (was Re: how to write literals of some Perl 6 types?)

On 2008-Dec-4, at 4:41 pm, Leon Timmermans wrote: On Thu, Dec 4, 2008 at 6:34 PM, TSa <[EMAIL PROTECTED]> wrote: And how about 'Num 1.0 === Complex(1,0) === Int 1'? IMHO the spec on === is quite clear: "two values are never equivalent unless they are of exactly the same type." I guess the

Re: why infix::(Int, Int --> Rat)

On 2008-Dec-4, at 3:08 pm, Mark J. Reed wrote: Using "div" instead of "/" should make it pretty clear that you're disposing of the remainder. I misremembered div vs. idiv, but how standard is it? I know "div" commonly means int division, but not always. On the one hand, some things you j

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

On 2008-Dec-4, at 9:09 am, Aristotle Pagaltzis wrote: And while it does seems like a closure trait, that seems somewhat problematic in that the order of evaluation is weird when compared to other closure traits, which I suppose is what led you to declare the “coy” solution as the most natura

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

On 2008-Dec-5, at 7:43 am, David Green wrote: Now the condition is in the middle and is syntactically separate. (It's still not up front, but if the first block is really long, you can always... add a comment!) Well, you don't need a comment -- why not allow the condition to co

Re: r24325 - docs/Perl6/Spec

On 2008-Dec-14, at 11:21 am, Moritz Lenz wrote: Uri Guttman wrote: how is sort ordering specified? Currently it is not specified, it defaults to infix:. If you can suggest a non-confusing way to specify both a transformation closure and a comparison method, please go ahead. how does it k

Re: What does a Pair numify to?

On 2008-Dec-15, at 4:18 pm, Jon Lang wrote: If you've got a list of Pairs, you use a sorting algorithm that's designed for sorting Pairs (which probably sorts by key first, then uses the values to break ties). Agreed. If you've got a list that has a mixture of Pairs and non-Pairs, I think

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

On 2008-Dec-6, at 7:37 am, Aristotle Pagaltzis wrote: Funnily enough, I think you’re onto something here that you didn’t even notice: [...] if we had a NOTFIRST (which would run before ENTER just as FIRST does, but on *every* iteration *except* the first), then we could trivially attain the

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

On 2008-Dec-16, at 6:21 pm, Timothy S. Nelson wrote: Or, instead of having a new block, just add the iterator indicator to the NEXT block, and get rid of ENTER and LEAVE. That way, you'd have this sequence: - FIRST {} - NEXT 0 {} # Replaces ENTER - NEXT 1..* {} # Does NOTF

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

On 2008-Dec-17, at 5:15 pm, Aristotle Pagaltzis wrote: The way Template Toolkit solves this is far better: the loop body gets access to an iterator object which can be queried for the count of iterations so far and whether this is the first or last iteration. Well, I prefer a built-in counter l

Re: Temporal and purity (was: Re: IO, Trees, and Time/Date)

On 2009-Feb-19, at 4:39 pm, Martin Kealey wrote: 2. "Date isa Instant" works sensibly: anywhere that expects an Instant, you can give it a Date. (Assuming we all agree that dates start at midnight, but then we *are* talking specifically Gregorian dates.) I don't like dates just starting at

Re: Temporal revisited

On 2009-Feb-19, at 11:26 am, Dave Rolsky wrote: What I want to see in Perl 6 is a set of very minimal roles that can be used to provide a simply object from gmtime() and localtime(). These objects should not handle locales, proper Olson timezones, string parsing, user-defined formatting, or

Re: r25445 - docs/Perl6/Spec/S32-setting-library

On 2009-Feb-20, at 11:17 am, Larry Wall wrote: Certainly, we'll be depending on the type system to keep these things straight. I'm not suggesting the user use bare Nums as anything other than naive durations for APIs such as sleep(). If we have some units to make suitable objects, we can say

Re: Temporal revisited

On 2009-Feb-20, at 7:17 am, Dave Rolsky wrote: Define really basic math. [...] you could say "all math is done in terms of seconds", but then there's literally no way to "add 1 month". Oh, I meant only adding or subtracting seconds (as mentioned elsewhere); adding a month is certainly advanc

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

On 2009-Feb-23, at 10:09 am, TSa wrote: I also think that time and numbers in general should be treated in a fuzzy way by smart match. My thought is to have == take a :within adverb, at least for imprecise types like Num, that could be used to specify how close values need to come in order

min= (from "Rakudo Built-ins Can Now Be Written In Perl 6")

On 2009-Feb-23, Jonathan Worthington posted to Rakudo.org: Applied a patch from bacek++ to get "min= and "max=" working ("$foo min= 100" will assign 100 to $foo if it's smaller than what is in $foo). Nice -- except I first read that backwards, i.e. even though it follows straight from the

Re: min= (from "Rakudo Built-ins Can Now Be Written In Perl 6")

Feb 24, 2009 at 11:16 AM, Ruud H.G. van Tol > wrote: David Green wrote: my $foo is limited(100..200); $foo = 5; # really does $foo = 100 Where does that MySQ smell come from? Why not undef (or NaN)? How about Failing instead of any of the above? Silently replac

Re: Masak's S29 list

On 2009-Feb-26, at 7:46 pm, Timothy S. Nelson wrote: # Object has .print and .say. [...] My question is, would we be better off having the string conversion routine for arrays worry about the input/output record/field separators, rather than the IO object? The downside I can see is that

Re: Recursive Runtime Role Reapplication Really Rebounds

On 2009-Mar-9, at 3:32 am, Ovid wrote: Since you cache resultsets if they've not changed, you could easily have the XML and YAML roles getting reapplied at runtime multiple times. Could this issue be mitigated with temp variables? { temp $resultset does Role::Serializable::YAML; pr

Re: a junction or not

On 2009-Mar-17, at 2:16 am, Jon Lang wrote: $choice.perl will return the same thing that the following would: any($choice.eigenstates.«perl) That is, it would return a Junction of Str, not a Str. So the question is how to get something that returns an expression to the effect of: 'any('

Re: deciphering infix:

On 2009-Mar-26, at 10:50 pm, Patrick R. Michaud wrote: But what to do with something like C< 3 cmp '3' >, or any infix: where the operands are of differing types? Do we constrain C to only work on similarly-typed operands (in which case my sort above would fail), or am I overlooking somethi

Re: New CPAN

On 2009-May-30, at 6:56 am, Andrew Whitworth wrote: I'm not saying we *can't* create a general repository for all sorts of nonsense, I'm saying that we *shouldn't*. "Holiday photos" is just a whimsical example. The problem is that it's hard enough keeping up with what "Perl6" is today, let a

Re: New CPAN

On 2009-May-30, at 12:06 pm, David Green wrote: ...what "Perl6" is today, let alone what it will be tomorrow. Actually, we do kind of know what Perl will look like a decade from now, because P6 is deliberately extensible enough that we may never need a Perl 7. But that simply

Re: renaming or adding some operators

On 2009-May-29, at 7:53 pm, Darren Duncan wrote: Thirdly, there are I'm sure a number of other aliases that could be added to other ops, such as ≤ and ≥ for <= and >=, and ≠ for one of the inequality operators, although that last one would probably make more sense if = was the equality test

Re: Reusing code: "Everything but the kitchen sink"

On 2009-Jul-7, at 5:28 am, Jonathan Worthington wrote: The spec is right in that you need to write a method in the class that decides what to do. This will look something like: method fuse() { self.Bomb::fuse() } That makes sense for using the combined role on its own, but can we still

Huffman's Log: svndate r27485

On 2009-Jul-8, at 3:41 pm, pugs-comm...@feather.perl6.nl wrote: =item log + our Num multi method log ( Num $x: Num $base = Num::e ) is export Logarithm of base C<$base>, default Natural. Calling with C<$x == 0> is an error. It occurs to me that "log" is a pretty short name for a function I

Re: YAPC::EU and Perl 6 Roles

On 2009-Jul-8, at 1:49 pm, Ovid wrote: That being said, roles also have two competing uses (though they don't conflict as badly). As units of behavior, they provide the functionality your code needs. However, they can also serve as an interface. Maybe there are Interfaces, which are, we

Re: Reusing code: "Everything but the kitchen sink"

On 2009-Jul-10, at 4:37 pm, Jon Lang wrote: This is one of the distinctions between role composition and class inheritance. With class inheritance, the full tree of inherited classes is publicly accessible; with role composition, the methods of the combined role are the only ones that are m

Re: RFC: overriding methods declared by roles (Was: Re: Reusing code: "Everything but the kitchen sink")

On 2009-Jul-12, at 12:43 pm, Daniel Ruoso wrote: role R1 { method foo() {...} # degenerates to interface } Just wondering: since merely declaring an interface will be common enough, should we be able to say simply "method foo;" inside a role, and drop the {...}? class Bla does R2 { m

Re: Rukudo-Star => Rakudo-lite?

On 2009-Aug-9, at 6:30 am, Richard Hainsworth wrote: Its just that */star/whatever doesnt convey [to me] the fact that its a sub-set of of Perl6. I like "*"... it has more personality than "lite". (Or even "light".) Though since it's a subset, we could always call it "Rakudo ⊂"! On 2009-

Re: Embedded comments: two proposed solutions to the comment-whole-lines problem

On 2009-Aug-11, at 1:38 pm, raiph mellor wrote: For a quick backgrounder, Larry had talked of reserving backtick for use as a user defined operator [1], Mark had suggested its use as a (tightly bound) comment [2], and James et al had suggested using it to declare units [3]. I'd like to see unit

Re: Filename literals

On 2009-Aug-13, at 10:25 am, Hinrik Örn Sigurðsson wrote: I've read a couple of posts about file test operators, where some have suggested making filenames special, either as a subtype of Str or something else entirely. That way Str wouldn't have all these file test methods, which is good because

Files and IO and all

On 2009-Aug-14, at 4:34 am, David Green wrote: There's a lot of scope for a nice, friendly, high-level IO view; perhaps we need an IO-working group to assemble knowledge about what is and isn't possible with different filesystems and design an interface around it all. I

  1   2   >