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"

=== 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: ===, =:=, ~~, 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

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

Iteration Again (was «Re: Angle quotes and pointy brackets»)

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Brent 'Dax' Royal-Gordon) wrote: >I'm going to pull a Larry and think out >loud for a minute here. Note that I speak authoritatively here, Noted. Or not. =) >Treating it like an array is wrong. >On the other hand, what if a filehandle *is* an

Re: Angle quotes and pointy brackets

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Smylers) wrote: >David Green writes: >> I'm not even sure what those double-quotation marks are doing -- [...] >Look back at how Larry defined the guillemets: [...] >So the double-quotes in there are "shell-like

Re: specifying the key Type for a Hash

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Larry Wall) wrote: >S9 talk about it. We current have things like: >my Cat %pet is shape(Str); >and parameters to types are in square brackets, so it's more like: >my %pet is Hash[:shape(Str) :returns(Cat)]; I still prefer "shaped", for

Re: iteration (was Re: Angle quotes and pointy brackets)

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Matt Diephouse) wrote: >What I mean is that Perl takes an array and makes an iterator out of it. >Sure, you probably don't think about it like that, but the behavior is >the same (who says arrays need to iterate starting at element zero?). I prob

Re: specifying the key Type for a Hash

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Larry Wall) wrote: >Maybe type parameters are just subscripts? [...] >my Fight %fight does key{Dog;Cat}; I like that. >But if English-like is the criterion that'd still read better as >my Fight %fight has key{Dog;Cat}; I like that even

Re: iteration (was Re: Angle quotes and pointy brackets)

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Matt Diephouse) wrote: >On Sat, 04 Dec 2004 08:59:24 -0700, David Green <[EMAIL PROTECTED]> wrote: >C signifies a role named "Iterate". Roles are sort of a >mix of interfaces and mixins (as I understand it --

Re: specifying the key Type for a Hash

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Smylers) wrote: >No! Avoid synonyms. They're initially tempting, because then everybody >gets to pick the one he/she wants to use, but then it turns out you need >to learn all of them so as to read other people's code, and that's worse >than no

Re: pull & put (Was: Angle quotes and pointy brackets)

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Luke Palmer) wrote: >But what we'd really like to do is: given the user knows what push/pop >do, what would they *guess* to mean shift (I tend to think that this >is a very good technique for naming). >And, well, I'm thinking pull. So it's a t

Re: specifying the key Type for a Hash

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Luke Palmer) wrote: >David Green writes: > > In article <[EMAIL PROTECTED]>, > > [EMAIL PROTECTED] (Larry Wall) wrote: > > >Maybe type parameters are just subscripts? [...] > > >my Fight %figh

Pleasing some of the people all of the time

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Larry Wall) wrote: >On Mon, Dec 06, 2004 at 03:11:15AM -0700, David Green wrote: >[snip] >: I like that. >: I like that even better. [etc.] >Um. You're so very...easy to please... I guess I'm okay with that...

Re: Dimension of slices; scalars versus 1-element arrays?

OK, so at issue is the difference between an element of an array ($p5[1]) and a slice (that might contain only one element, @p5[1]), only generalised to n dimensions. (A problem which didn't exist in P5 because there were no higher dimensions!) And we don't want @B[4; 0..6] to reduce to a 1-

Re: Dimension of slices; scalars versus 1-element arrays?

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (David Green) wrote: >I can imagine "table context" being reasonably popular. [...] >(Taking a scalar and returning a list is less common, but I can >imagine a 2-D version of 'split' that turns a string into

Re: Junctive puzzles.

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Luke Palmer) wrote: >Well, we see the same kind of thing with standard interval arithmetic: >[...] It didn't bother me that junctions weren't ordered transitively. (Ordering had better work transitively for ordinary numbers, but junctions aren'

Re: push with lazy lists

On 7/12/04, Austin Hastings wrote: --- Larry Wall <[EMAIL PROTECTED]> wrote: The hard part being to pick a random number in [0,Inf) uniformly. :-) Half of all numbers in [0, Inf) are in the range [Inf/2, Inf). Which collapses to the range [Inf, Inf). Returning Inf seems to satisfy the uniform dist

Re: The .bytes/.codepoints/.graphemes methods

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Larry Wall) wrote: >On Tue, Jun 29, 2004 at 10:52:34AM -0500, Jonathan Scott Duff wrote: >: :u0 # use bytes (. is byte) >: :u1 # level 1 support (. is codepoint) >: :u2 # level 1 support (.

Re: Why do users need FileHandles?

Luke Palmer <[EMAIL PROTECTED]> wrote on July 22, 2004: Even more philosophical is "what is core?" I believe the standard definition is "Anything I want to use goes in the core; anything everyone else wants goes wherever there's room left over." ... So making it "go in the core" may just mean th

Re: Why do users need FileHandles?^H^H^H^H^HCore modules?

On 7/23/04, Luke Palmer wrote: Not necessarily. Glop, on which I'm doing a presentation at OSCON (have to plug it sometime ;-), "Game Language on Perl, you say? Goodness, what's that??" Sorry. Got tired of English. =) There's a lot of stuff like that. Way too much to include in a distribution.

Re: String interpolation

On 7/21/04, Brent 'Dax' Royal-Gordon wrote: >Amen. Please don't steal unnecessary metacharacters in qq() >strings--although I still think we should keep it, @ causes a lot of >problems. That's why my suggestion would be to use a character that already has a special meaning in double-quoted st

Re: Synopsis 2 draft 1

On 8/14/04, [EMAIL PROTECTED] (Larry Wall) wrote: >To get a Perlish representation of any data value, use the C<.repr> >method. This will put quotes around strings, square brackets around >list values, curlies around hash values, etc., such that standard >Perl could reparse the result. XXX .rep

Re: Synopsis 2 draft 1 -- each and every

On 8/15/04, [EMAIL PROTECTED] (David Wheeler) wrote: >On Aug 14, 2004, at 5:52 PM, Larry Wall wrote: >>for all $*IN # all() is junction >>for each $*IN # each method wants closure if we follow Ruby >>for next $*IN # next $foo is a loop exit > >Hmm. Maybe the problem is that we shoul

Re: Synopsis 2 draft 1 -- each and every

On 8/19/04, [EMAIL PROTECTED] (David Green) wrote: > >On Aug 14, 2004, at 5:52 PM, Larry Wall wrote: > > >>for all $*IN # all() is junction > >>for each $*IN # each method wants closure if we follow Ruby > >>for next $*IN # next $foo is a loop ex

Re: Synopsis 2 draft 1 -- each and every

On 8/19/04, [EMAIL PROTECTED] (Luke Palmer) wrote: >David Green writes: > > Hang on -- should we be saying "for each $foo" or "for $foo.each" > > anyway? We don't say "for @foo.each"; the iteration is implicit. So > > I'm thinking i

Re: Synopsis 2 draft 1 -- each and every

On 8/19/04, [EMAIL PROTECTED] (Larry Wall) wrote: >It's hard to come up with an English word that means "next" in scalar >context but "all" in list context. I never know whether to name my arrays singular or plural, either. =) But couldn't there be Two Ways To Do It? One "singular" name and on

Re: Synopsis 2 draft 1 -- each and every

On 8/20/04, [EMAIL PROTECTED] (Luke Palmer) wrote: >So all the laziness goes into the array implementation. But you don't >even need to write your iterator fancily. If you just write your scalar >version of postcircumfix:<>, Perl will do the rest. So if you use an iterator in list context, Perl

Progressively Overhauling Documentation

In <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Aaron Sherman) wrote: >This bit of POD made me think about POD's lack of tabular formatting, a >common idiom in technical documentation. I know POD is still in the >wings, as it were, but I wanted to say this before I forget /me flings coffee cup

Re: Progressively Overhauling Documentation

On 8/23/04, [EMAIL PROTECTED] (Rod Adams) wrote: >What if we add C attribute that the execution compiler would >discard, but POD compilers (and debuggers) could make use of? I >believe that would even allow a particularly stringent corporate >policy to create a flavor of 'strict' which required

The first shall be first (was "Re: parameter contexts (was: Synopsis 9 draft 1)")

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Larry Wall) wrote: >I'm still thinking A is the first one and Z is the last one. Someone >talk me out of it quick. Just think of all the trouble it would cause in the summaries: 'Meanwhile, in perl6-language, there was much discussion about Z.

Re: The first shall be first (was "Re: parameter contexts (was: Synopsis 9 draft 1)")

On 2004/9/04, [EMAIL PROTECTED] (Larry Wall) wrote: >Yow. Presumably "nth" without an argument would mean the last. So >@ints[1st..nth] >means >@ints[*] Yeah, I was thinking something like that. And if the arg is an actual array, maybe it returns the max dimension(s)? I think you'd ge

Re: The last shall be last (was: The first shall be first)

On 2004/9/04, [EMAIL PROTECTED] (Jonathan Lang) wrote: (Nice Subject change, I almost missed it!) >Larry Wall wrote: > > Yow. Presumably "nth" without an argument would mean the last. > >If it means the last, why not just use C? Conflict with "last LOOP"? Hm, the context should be enough to d

Re: The first shall be first (was "Re: parameter contexts (was: Synopsis 9 draft 1)")

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Luke Palmer) wrote: >sub wn($n) { $n ?? wn($n-1)+1 :: $w } >$w2 = 0... + wn«0...; >assert($w2 == $w*2); >Just think of the possibilities! :-) Hm. Needs more Unicode. =) >Seriously though, putting 1st, 2nd, nth, etc. in the langua

Re: The last shall be last (was: The first shall be first)

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Jonathan Lang) wrote: >No problem here, especially if C<0th> and C are synonyms - that is, >make "..., -4th, -3rd, -2nd, -1st, 0th, 1st, 2nd, 3rd, 4th, ..." be the >underlying mechanism, and define C and C as synonyms for >C<0th> and C<1st>. Ye

Ordinals, Hashes, and Arrays, oh my

On 2004/9/06, Larry Wall wrote: >Another possibility is that .[] always forces the "normal" view of an >array as 0-based, and if you want non-0-based arrays you have to use >the .{} interface instead, on the assumption that strange subscripts >are more like hash keys than ranges of integers. That

Re: Ordinals, Hashes, and Arrays, oh my

On 2004/9/10, [EMAIL PROTECTED] (David Green) wrote: >If we consider a generic "data structure" type (which may or may not be >optimised under the hood for integral indices), then why shouldn't {} be >the "index-by-name" interface, and [] the "index-by-or

Re: perl6's new name?

It’s far from obvious that playing with the name is likely to make things significantly better. Perl 6 has been P6 longer than Perl 5 had been P5 — or Perl Anything — at the time it was conceived. That’s not to say nothing should be done about it, but as some people have pointed out in the Githu

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

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

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

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

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

  1   2   3   >