Re: Quick question: (...) vs [...]

John M. Dlugosz 提到: What is the difference between (1,2,3) and [1,2,3] ? One is a List and one is an Array; you cannot push into a list, but you can into an array. my @a := (1,2,3); my @b := [1,2,3]; @a.push(4); # fails @b.push(4); # works Cheers, Audrey

Re: Edits to submit

Audrey Tang 提到: However, in S02 you removed the Code class and replaced it with Routine, but that does not really work; for example, a bare block is a Code, but it cannot be a Routine since it can't be wrapped in place, and caller() would bypass it when considering caller frames. I shou

Re: syntax question: "method close is export ()"

John M. Dlugosz 提到: Does that mean that traits can come before the signature? Or should it be corrected to method close () is export { ... } It's a simple typo. Thanks, fixed in r14572. Cheers, Audrey

Re: Edits to submit

John M. Dlugosz 提到: I've edited several of the S??.pod files,but I have not heard back from the owner ($Larry, whose name is on the top of the file) about accepting merging or rejecting my changes. I've posted the files to so they don't get lost, unti

Re: Conceptual questions about Objects

John M. Dlugosz wrote: Seriously, Does this mean that the access of private attributes from trusted classes is a "different form"? And that's why you need the qualified syntax when I think it should not be necessary in all cases? Or should that passage really say "not in non-trusted classes, incl

Re: Conceptual questions about Objects

John M. Dlugosz wrote: OK, trust is not implicit on derived classes. Is that because there is no rule that says it is, or is there a mention of that somewhere in the official docs? There is. S12 Line 561: Every I declaration also declares a corresponding private I storage location, and the e

Re: Conceptual questions about Objects

John M. Dlugosz wrote: That seems to be saying that using the method-call form is preferred, as it abstracts whether it is a real hard attribute or not. Er, it is not so. The $.foo notation is good not only for calling accessors, but also as a way to specify context when calling oneself's met

Re: Conceptual questions about Objects

John M. Dlugosz wrote: A method can refer to private attributes etc. in other objects than self. This is unlike Smalltalk and like C++. Which objects? Obviously, those that _have_ them in the first place. Correct, though those classes also has to trust the calling class: class MyClass { has $!

Re: S09 editorial fixes

Thom Boyer 提到: Audrey Tang wrote: $code = { "a" => 1, $b, $c ==> print }; The examples above are from L. According to those rules, that last assignment to $code seems to be a hash, not code. Or does the C<< ==> >> mean that the contents aren't a

Re: S09 editorial fixes

Nicholas Clark 提到: So if the semicolon is replaced with a comma, like this, my @x := [{1+1}, {2+2}]; the {} acts as a hash constructor, and @x is [{2 => undef}, {4 => undef}] ? No, {} acts as a closure constructor, and @x contains two closures that returns 2 and 4 respectively when calle

Re: S09 editorial fixes

Larry Wall 提到: > I was originally thinking just loop modifiers, but I suppose > > { say $^x } if foo(); > > also can be made to make some kind of sense, in the same way that > > if foo() -> $x { say $x } > > is supposed to work. Right. I've committed the clarification (as a new section

Re: S09 editorial fixes

Larry Wall 提到: Yes, unless we decide we need something like that for list comprehensions. Maybe looping modifiers allow placeholders in what would otherwise be an error... Sure. How about this: " Use of a placeholder parameter in statement-level blocks triggers a syntax error, because the pa

Re: S09 editorial fixes

John M. Dlugosz 提到: > I just finished another pass on S09, and in this posting I note > editorial issues with the file that can easily be corrected. This is as > opposed to subjects for deep discussion, which I'll save for later and > individual posts. > > = on Mixing subscripts > "Within a C<

Re: S09 editorial fixes

John M. Dlugosz 提到: > But about your answer, "automatically called with no arguments". Isn't > that what a bare closure normally does anyway? Say, I introduced extra > {} just for scoping or naming the block, where a statement is expected. > > foo; > bar; > { my $temp= foo; bar(temp); } #forget a

Re: S09 editorial fixes

Audrey Tang 提到: > John M. Dlugosz 提到: > >> = on Parallelized parameters and autothreading >> >> use autoindex; >> do { @c[$^i, $^j, $^k, $^l] = @a[$^i, $^j] * @b[$^k, $^l] }; >> >> Shouldn't those be semicolons? Ditto for subsequent exampl

Re: S09 editorial fixes

John M. Dlugosz 提到: > = on Parallelized parameters and autothreading > > use autoindex; > do { @c[$^i, $^j, $^k, $^l] = @a[$^i, $^j] * @b[$^k, $^l] }; > > Shouldn't those be semicolons? Ditto for subsequent examples. > Also, what does the "do" do? I think it is only meaningful if there

Re: "our" methods?

John M. Dlugosz 提到: > In S29, there are definitions like >our Capture method shape (@array: ) is export > But in S12 there is no mention as to what an "our" method is. It states that > "my" is used to make private methods, and "^" to make class methods. > I think this is a doc relic and shoul

Re: Generalizing ?? !!

在 Jun 11, 2007 5:10 AM 時，Jonathan Lang 寫到： A variation of chaining associativity gets used, with the "chaining rule" being '$v1 op1 $v2 // $v1 op2 $v3' instead of '$v1 op1 $v2 && $v2 op2 $v3', as is the case for comparison chaining. But wouldn't that make: True ?? undef !! Moose; evaluate

Re: .perl, nested arrays, parens and a bug with .perl after hyperop

在 May 21, 2007 8:45 AM 時，Juerd Waalboer 寫到： Steffen Schwigon skribis 2007-05-21 1:28 (+0200): That's ARRAY := ARRAY there, so the following should dwym: my @foo := [ 1, 2, 3 ]; However, this does not work with pugs, so I don't know if I am wrong, or pugs is wrong. Pugs is wrong an

Re: Packed array status?

2007/2/27, Geoffrey Broadwell <[EMAIL PROTECTED]>: > > 7. Packed arrays with access to raw data pointer to give to API > > Is it possible to point us to some use cases of such packed arrays, > especially the raw data pointer API part? Are you looking for Perl code that creates such packed array

Re: Packed array status?

2007/2/27, Geoffrey Broadwell <[EMAIL PROTECTED]>: As a simpler case than a full 3D engine port, I have some OpenGL benchmarks in Perl 5 that I can port -- these have much reduced requirements. Principly, they need: 1. Basic math and string operators (not grammars) 2. Basic looping and simple

Re: recent changes

在 Feb 9, 2007 5:17 AM 時，Larry Wall 寫到： Questions and feedback welcome, but please don't follow up to this message--start a new thread for a new topic. Bear in mind that this is completely untested code, still fairly buggy and incomplete. Not even pugs can parse it (yet). Note: After some typo

Re: mmd-draft.txt

在 Oct 26, 2006 10:26 AM 時，TSa 寫到： I figure that http://svn.openfoundry.org/pugs/docs/notes/multi_method_dispatch/ mmd-draft.txt hasn't made it into S06 yet. So what is the current state of affairs? The original plan was to have Larry review it in Brazil and check it in along with an implem

[ANNOUNCE] Pugs 6.2.13 released!

After nearly four months of development and 3400+ commits, I'm very glad to announce that Pugs 6.2.13 is now available: http://pugs.blogs.com/dist/Perl6-Pugs-6.2.13.tar.gz SIZE: 6839270 SHA1: b06b8434c64e9bb5e3ab482282fbae0a6ba69218 Motivated by increasing use of Pugs in production,

Re: Nested statement modifiers.

在 Oct 4, 2006 10:17 AM 時，Damian Conway 寫到： Audrey asked: However, I wonder if this is too strict. Disallowing "while" and "until" after a do block is fine (and can be coded directly in those two statement modifier macros), but is there a reason to disallow other modifiers? Well, for a start

Re: Nested statement modifiers.

在 Oct 4, 2006 7:46 AM 時，Damian Conway 寫到： [Apologies for the last post. Gmail got a little eager. Here's what I meant to send...] Juerd wrote: Which can also be written as: do { do { say 1 if 1 } if 1 } if 1; Sorry, no it can't. From S4 (http://dev.perl.org/perl6/doc/design/syn/ S04

Re: Motivation for /+/ set Array not Match?

在 Sep 28, 2006 3:03 AM 時，Carl Mäsak 寫到： Audrey (>): Indeed... Though what I'm wondering is, is there a hidden implementation cost or design cost of making /+/ always behave such that $.from returns something, compared to the current treatment with the workaround you suggested? Has this

Re: Motivation for /+/ set Array not Match?

在 Sep 22, 2006 10:36 PM 時，Patrick R. Michaud 寫到： Out of curiosity, why not: / bar bar $:=(+)/ and then one can easily look at $.from and $.to, as well as get to the arrayed elements? (There are other possibilities as well.) I'm not arguing in favor of or against the proposal, just point

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

在 Sep 24, 2006 12:21 AM 時，Audrey Tang 寫到： 在 Sep 23, 2006 8:36 PM 時，Markus Laire 寫到： On 9/23/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: @args = [EMAIL PROTECTED],1,2,3; -push [,] @args;# same as push @foo,1,2,3 +push [,] @args;# same as push(@foo: 1,2,

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

在 Sep 23, 2006 8:36 PM 時，Markus Laire 寫到： On 9/23/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: @args = [EMAIL PROTECTED],1,2,3; -push [,] @args;# same as push @foo,1,2,3 +push [,] @args;# same as push(@foo: 1,2,3) I don't quite understand this. Shouldn't C<[,] @args

Motivation for /+/ set Array not Match?

From S05: If a subrule appears two (or more) times in any branch of a lexical scope (i.e. twice within the same subpattern and alternation), or if the subrule is quantified anywhere within a given scope, then its corresponding hash entry is always assigned an array of C objects rather than a sing

Re: Unpacking tree node parameters

在 Sep 4, 2006 2:11 AM 時，Gaal Yahas 寫到： Unless I'm mistaken, this doesn't cast back to subroutine signature land very well: sub f1 (Dog ($fido, $spot)) { ... } sub f2 (Dog $ ($fido, $spot)) { ... } sub f3 (Dog :($fido, $spot)) { ... } Correct. Unless Audrey's latest S

Re: single named param

在 Sep 12, 2006 6:59 PM 時，Gaal Yahas 寫到： What invocant is constructed in this signature then? method foo ($just_a_named_param) Is the signature for &foo really the same as that of bar? sub bar ($just_a_named_param) As Larry said, they shouldn't be the same; the first one is &f

Re: single named param

2006/9/12, Gaal Yahas <[EMAIL PROTECTED]>: Does this mean a single named parameter called $x, or a default invocant and a single required positional named $x? "A default invocant" prolly doesn't make sense there... There's nothing to "default" to. :-) Audrey

Reduced assignment operator?

Consider these cases: [=] $x, $y, $z; [+=] $a, $b, $c; S03 is currently inconsistent. It first says these are not supported: The final metaoperator in Perl 6 is the reduction operator. Any infix operator (except for non-associating operators and assignment operators) can be surrounded

Re: multi method dispatching of optional arguments (further refined)

2006/9/4, Ph. Marek <[EMAIL PROTECTED]>: On Sunday 03 September 2006 14:25, Mark Stosberg wrote: > Luke Palmer wrote: > > On 9/3/06, Mark Stosberg <[EMAIL PROTECTED]> wrote: > >> Note that the variant /with/ the parameter can be considered an exact > >> match, but but the variant /without/ it can

Re: Naming the method form of s///

2006/9/1, Juerd <[EMAIL PROTECTED]>: Luke Palmer skribis 2006-08-31 15:48 (-0600): > > I don't think using a method (even if called "s") is good huffman > > coding. My expectation is that copying substitution will be used much - > > perhaps even more than mutating substitution! > And so a method

Re: Same-named arguments

2006/8/26, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: So what's the rationale behind the latest changes? I thought p6 consistently regarded the sigil as part of the name; seems like that should go for named parameters, too. In fact, sigils would seem to be a good way to distinguish named parameters

Re: === and array-refs

在 2006/8/18 上午 3:31 時，Ben Morrow 寫到： Just to make sure I've got all this straight: =:= compares names === compares containers eqv compares values =:= evaluates both sides as lvalue -- that's VAR() -- and compare them with ===. === evaluates both sides as rvalue and, for containe

Re: designing a test suite for multiple implementations

在 2006/8/12 下午 6:15 時，Nicholas Clark 寫到： There's nothing technical stopping the Perl 6 tests being on svn.perl.org, but in a different svn repository from the current repositories, is there? Well, technically yes, except that SVK doesn't support svn:external yet. Setting a svn:external pro

Re: designing a test suite for multiple implementations

在 2006/8/12 上午 3:01 時，jerry gay 寫到： for "managed," i have a few ideas. currently, the suite lives in the pugs repo. this is a fine first approximation, but i believe it will soon be time to move this suite (it doesn't make sense to keep the "official" tests in a non-official repo in the long ter

Re: underscores in the core lib

在 2006/8/11 下午 2:35 時，Luke Palmer 寫到： I think that standard functions ought not to have underscores *most of the time*, because their presence indicates something that could be better named or is miscategorized. However, for methods, especially "advanced" or introspective methods, I think longe

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

在 2006/8/11 下午 3:00 時，Luke Palmer 寫到： On 8/11/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Some object types can behave as value types. Every object can produce a "safe key identifier" (C for short) that uniquely identifies the -object for hashing and other value-base comparisons.

Re: Array Definitions

在 2006/8/2 下午 2:48 時，Arthur Ramos Jr. 寫到： I'm new to the mailing lists. I've just started reading all the Apocalypse and Exegeses with the goal of becoming involved in some manner. Try reading the Synopses first. :-) The Apocalypses and Exegesis are no longer updated, and has diverged co

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

在 2006/7/28 上午 7:54 時，Aaron Crane 寫到： The motivation for s/environmental/contextual/ is clear: avoiding a term that's already used for something else. But, on the same grounds, I'm not sure that "contextual" is the right term, and especially not Ccontext> -- Perl already has contexts, and

Re: Patch for S03

在 2006/7/23 上午 7:33 時，Agent Zhang 寫到： Hello, everyone~ Here's my patch for S03. Thanks, applied (and the previous one on S02 too)! Audrey PGP.sig Description: This is a digitally signed message part

Re: Patch for S02

在 2006/7/19 下午 10:16 時，Agent Zhang 寫到： I found some nits while copying Perl 6 Synopsis 2 by hand. The patch created by my TortoiseSVN for S02 has been pasted at the end of the mail. Thanks, applied as r10314. Audrey PGP.sig Description: This is a digitally signed message part

Re: namespaces, a single colon to separate HLL prefix?

在 2006/7/6 上午 3:30 時，Allison Randal 寫到： Quick question, is there a syntax specified in Perl 6 for referring to namespaces from other languages? I'm reviewing the namespaces PDD and want to update this snippet: -- IMPLEMENTATION EXAMPLES: Suppose a Perl program were to import some Tcl m

Re: S04

在 2006/7/1 下午 6:08 時，Tom Allison 寫到： I picked this up at the YAPC and made some markups on it. Apologies that it is not in a diff format, but that's going to come with practice. ... is there a file attachment somewhere? :-) I got stuck on some of the intended behaviors and prohibited

Re: Pm's YAPC::NA talk online

在 2006/6/27 下午 4:41 時，Patrick R. Michaud 寫到： For any who may be interested, my talk slides for "Perl 6 Compiler Status and the Parrot Compiler Toolkit" (presented today at YAPC::NA) are available at http://www.pmichaud.com/2006/pres/yapc-perl6/slide.html That was a wonderful talk. Thank

Re: lexical lookup and OUTER::

在 2006/6/24 上午 8:41 時，Patrick R. Michaud 寫到： because later in the scope $x may be declared, so it's safer to just put OUTER right there. I don't think $x can be declared later in the scope. According to S04, If you've referred to $x prior to the first declaration, and the compiler

Re: About default options ':ratchet' and ':sigspace' on rules

在 2006/6/3 下午 3:03 時，Shu-Chun Weng 寫到： I'll then rewrite most of my rules into tokens. And about the definition of , the "engine" I mentioned is Pugs::Complier::Rule, so that if what PGE does is considered the "correct" way, I will change the behavior of P::C::Rule. Yes, please do. :-) By

Re: ACID transactions for in-memory data structures

Rob Kinyon wrote: > I'm pretty sure it wouldn't be very feasible to do this natively in > P5. But, would it be possible to do it natively in P6? As in, > supported within the interpreter vs. through some sort of overloading. Look at "is atomic" in S17draft, and Software Transaction Memory in gener

Re: A rule by any other name...

Ruud H.G. van Tol wrote: > Are all or some of the following equivalent to ? > > U+00A0 No-Break Space > U+202F Narow No-Break Space > U+FEFF Zero Width No-Break Space > U+2060 Word Joiner No. A05 makes it explicit is just \x20, and S05 also says that it matches one "space char", wh

Re: A rule by any other name...

Patrick R. Michaud wrote: >> - is a single character of obligatory whitespace Hmm, it's literal ' ' (that is, \x20), not "whitespace" in general, right? For "obligatory whitespace" we have \s. > This one has bugged me since the day I first saw it implemented > in PGE. We _already_ have \s, , a

Re: A rule by any other name...

Allison Randal wrote: > More importantly, whitespace skipping isn't a very significant option in > grammars in general, so creating two keywords that distinguish between > skipping and no skipping is linguistically infelicitous. It's like > creating two different words for "shirts with horizontal s

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

[EMAIL PROTECTED] wrote: > Is my ($foo, *, $bar) = 1..3 legal perl6? my ($foo, undef, $bar) = > 1..3; is valid perl5, but AFAIK that is completely undocumented. (It's > quite useful from time to time Most likely yes, as lvalue * can just act as a /dev/null. > -- now if only my (@rest, $almost,

Re: A shorter long dot

Austin Hastings wrote: > Or, to put it another way: what hard problem is it that you guys are > actively avoiding, that you've spent a week talking about making > substantial changes to the language in order to facilitate lining up > method names? That's a very good point too. Initially it's just

Re: A shorter long dot

Damian Conway wrote: > Juerd wrote: >>> and propose ".:" as a solution > >> $xyzzy.:foo(); >> $fooz. :foo(); >> $foo. :foo(); > > This would make the enormous semantic difference between: > >foo. :bar() > > and: > >foo :bar() > > depend on a visual difference of

Re: =$fh vs *$fh

Larry Wall wrote: > On the other hand, -<> makes a pretty pathetic fish operator. So for > the sake of argument, let's keep it =<> for the moment. But ignoring the > tail leads us to the head end of the fish. What do we do about $ARGS? > We could say this: > > =$fh : *$fh :: =<> : *<> > >

Re: Capture Object: why no verb?

Dave Whipp wrote: > Also, I'm a bit confused By the idea that the invocant is obtained by a > scalar dereference, because I know that arrays and hashes can be > invocants, too. E.g. @a.pop. So, If I do: > > my $args = \(@a:); > my $b = $$args; # @a as a scalar > my @c = @$args; # empty l

=$fh vs *$fh

During my S03 cleanup today, I noticed that because *$fh and **$fh interpolates into the current argument list, it's always the same as =$fh under list context. So I wrote this paragraph: [Conjectural: File handles interpolates its lines into positional arguments (e.g. to C>), so we can make C<=$

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

Patrick R. Michaud wrote: > Two other ideas (from a short walk)... how about something along > the lines of "phrase" or "sequence"? Parsec use the word "lexeme" to mean exactly the same thing... Audrey signature.asc Description: OpenPGP digital signature

The "parse" composer

[EMAIL PROTECTED] wrote: > +=item * > + > +Just as C has variants, so does the C declarator. > +In particular, there are two special variants for use in grammars: > +C and C. After a brief discussion on #perl6 with pmichaud and Juerd, it seems that a verb "parse" at the same space as "sub"/"method

Re: Capture Object: why no verb?

Dave Whipp wrote: > Perhaps I'm not fully groking the abstraction of the capture-object, but > it seems to me that there should be a slot in it for the method. For > dispatch, all three things are needed (invocant, method, args); so if > you're going to put two of them in one object, then maybe the

Capturing the Captures.

As promised yesterday, today gaal and I entered a gobby Q/A session, producing the first document under the Perl6::FAQ tree, on the newly coined Capture objects (previously known as Arguments) objects: http://svn.openfoundry.org/pugs/docs/Perl6/FAQ/Capture.pod A HTMLized version is also avail

Re: placeholder vs. lexical variables

Dan Kogai wrote: > I found this when I was playing w/ pugs. > > pugs> { $^x }.(42) > 42 > pugs> { my $z; $^x }.(42) > *** Undeclared variable: "$^x" > at line 1, column 10-14 > > So far as I see s06, there's nothing wrong w/ the statement above. I > just want to make sure this is not a perl

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

TSa wrote: > Note that a prominent, typical foo actually reads: > > self .bar; > > And a self($_.bar) is pretty much useless. In other words > wrongly huffmanized. FWIW, I agree with both points. Some more points: * I think both "say(.meth)" or ".meth.say" are more succinct/readable than "sa

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

Uri Guttman wrote: > one of these days when i have tuits of large circumference, i will do a > nit pass over as much of the A/E/S as i can handle before my brain > explodes. having done tech editing for perl books is good training for > this. in fact it would be a good idea to have several such pas

Re: S06 Splicing clarification

Brad Bowman wrote: > and against the spirit of the "my $COMPILING::x" in earlier versions of > S06. > Regardless of the "not a block" status of a q:code, I think that it's > lexicals should only be visible within the q:code by default. If this > is the intention of the above phrase the it should b

Re: A proposition for streamlining Perl 6 development

Yuval Kogman wrote: > What I do think is that there is something in the middle of these > two big questions, and they are: > > * How will the Perl 6 compiler be designed (parts, etc) That... was what Pugs Apocrypha was meant to contain, with PA02 being a design overview, and PA03 onward doc

Re: A proposition for streamlining Perl 6 development

On 2/8/06, Yuval Kogman <[EMAIL PROTECTED]> wrote: > If Audrey is willing, I think a correct new direction for pugs is to > try and separate the parts even more - the prelude is a mess right > now, many of it's part are duplicated across the backends, the > standard library that is mashed into the

Re: overloading the variable declaration process

On 2/6/06, Darren Duncan <[EMAIL PROTECTED]> wrote: > Speaking briefly, I would like it if Perl 6 provided a way for a > class (or role, or meta-class, etc) to declare that all variables > declared to be of that type are automatically/implicitly set to a > particular value at declaration time, so t

\c[NAMED UNICODE CHARACTER]?

Is it possible to have it as part of Synopsis 02? It's mentioned variously in A05, E05 and E07 (where it permits a \c[2026] form, but should be spelled \d[2026] nowadays), but is not currently part of any Synopses. Audrey

Re: Conversion oneliner t-shirt

On 1/27/06, Juerd <[EMAIL PROTECTED]> wrote: > Because of the favourable response to the prototype I wore during the > post-euroscon Amsterdam.pm meeting, and because Cafepress finally has > black shirts, it is now available for everyone who wants one. > > http://www.cafepress.com/perl6 After some

Re: Parrot and PGE will save the day (was Re: "as if" [Was: Selective reuse of storage in &bless.] )

On 1/21/06, Rob Kinyon <[EMAIL PROTECTED]> wrote: > I'm making a few assumptions here: > 1) Since PGE isn't part of Perl6 (because it's written in PIR), it > can be used as the parser/lexer/etc. for any language, not just Perl6. Rules, like regexes, are essentially language neutral. So that's

perl6-language@perl.org

On 1/21/06, Larry Wall <[EMAIL PROTECTED]> wrote: > But maybe all this is already possible in the current setup, if > > role ObjectFakeHash does Hash {...} > role Object does ObjectFakeHash {...} > class Hash does Hash {...} Yes, I think that's the way to go, as well as :coerce for exp

perl6-language@perl.org

Stevan Little wrote: >> I realize one of Stevan's objections is "But if you use a Hash, does your >> object automatically support the .keys method and .kv and so on?" to >> which I >> reply "No, of course not. That's silly. It just uses the Hash for >> *storage*." >> Is that your objection to ble

Re: Class methods vs. Instance methods

Rob Kinyon wrote: > "Any practical programming language with structural subtyping will > probably let you create and use aliases for type names (so you don't > have to write the full form everywhere). However, the underlying type > system will only consider the structure of the type when doing its

Re: Class methods vs. Instance methods

On 1/19/06, Matt Fowles <[EMAIL PROTECTED]> wrote: > Could you provide a concrete example of the advantage of this approach > please? Failing that can you try and expand on your gut feeling a > bit? May or may not be of use, but Larry's view sounds a bit like reconcilling the (again considered ir

Re: Indeterminate forms for the Num type.

Audrey Tang wrote: > That seems to follow from the standard (ruby, ocaml, mzscheme currently > does that), but some may also argue for NaN bothways (ghc, js) or an > exception bothways (perl5, python). Er, wait, ghc also raises an exception for (div 0 0), because it distinguishes int

Re: Indeterminate forms for the Num type.

Luke Palmer wrote: > I believe we've been through this before. We go with a standard, > probably IEEE, horridly mathematically unappealing though it may be. > It will be easier to implement and it will be more predictable, both > because most other language follow standards, too. "The good thing

Re: Indeterminate forms for the Num type.

Doug McNutt wrote: >> - - Specify them to return some definite value. > Only on a machine that doesn't do it in hardware or in some special perl > function that's unlikely. This question arises as different platform answer things differently for the native calculation of eg. 1**Inf. > >> At this

Indeterminate forms for the Num type.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Assuming "num" uses the underlying floating point semantic (which may turn 0/0 into NaN without raising exception), what should the default "Num" do on these forms? 0/0 0*Inf Inf/Inf Inf-Inf 0**0 Inf**0

The old "$x will not stay shared" thing.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm almost sure this had been covered before, but I failed to find a reference in either the archives or in synopses, so here goes again: sub f ($x) { sub g ($y) { $x + $y }; g($x); } f(10); # 20? Currently in Pugs, &g is built at