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
[svn:perl6-synopsis] r14571 - doc/trunk/design/syn
Author: audreyt Date: Tue Aug 5 02:38:33 2008 New Revision: 14571 Modified: doc/trunk/design/syn/S02.pod Log: * S02: A few more C... an C... blocks, Contributed by John M. Dlugosz++. Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podTue Aug 5 02:38:33 2008 @@ -12,9 +12,9 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 10 Aug 2004 - Last Modified: 25 Jul 2008 + Last Modified: 5 Aug 2008 Number: 2 - Version: 133 + Version: 134 This document summarizes Apocalypse 2, which covers small-scale lexical items and typological issues. (These Synopses also contain @@ -1415,7 +1415,7 @@ There is a need to distinguish list assignment from list binding. List assignment works much like it does in Perl 5, copying the values. There's a new C:= binding operator that lets you bind -names to Array and Hash objects without copying, in the same way +names to CArray and CHash objects without copying, in the same way as subroutine arguments are bound to formal parameters. See S06 for more about binding. @@ -1544,7 +1544,7 @@ =item * -In numeric context (i.e. when cast into CInt or CNum), a Hash object +In numeric context (i.e. when cast into CInt or CNum), a CHash object becomes the number of pairs contained in the hash. In a boolean context, a Hash object is true if there are any pairs in the hash. In either case, any intrinsic iterator would be reset. (If hashes do carry an intrinsic @@ -1807,7 +1807,7 @@ it starts in the current dynamic scope and from there scans outward through all dynamic scopes until it finds a contextual variable of that name in that context's lexical scope. -(Use of C$+FOO is equivalent to CONTEXT::$FOO or $CONTEXT::FOO.) +(Use of C$+FOO is equivalent to C CONTEXT::$FOO or C $CONTEXT::FOO .) If after scanning all the lexical scopes of each dynamic scope, there is no variable of that name, it looks in the C* package. If there is no variable in the C* package and the variable is @@ -1921,7 +1921,7 @@ C$?FILE and C$?LINE are your current file and line number, for instance. C? is not a shortcut for a package name like C* is. Instead of C$?OUTER::SUB you probably want to write C OUTER::$?SUB . -Within code that is being run during the compile, such as BEGIN blocks, or +Within code that is being run during the compile, such as CBEGIN blocks, or macro bodies, or constant initializers, the compiler variables must be referred to as (for instance) C COMPILING::$?LINE if the bare C$?LINE would be taken to be the value during the compilation of the currently running
Class Name Question
In S12, So when you say Dog, you're referring to both a package and a protoobject, that latter of which points to the actual object representing the class via HOW. Does that mean that the object referred to by Dog does both roles? In that case the latter is confusing wording. Or does it mean that the compiler returns one of two different objects depending on context? In addition to the listop! So, how does it know which is wanted? E.g. my $x = Dog; # the undefined Dog my $y = ::Dog; # the package but that means other wording is wrong, in that :: in rvalue context is not a no-op exactly. If, on the other hand, Dog is always a listop that in the 0-ary case returns the protoobject, the protoobject can be defined to also do the Abstraction role, or perhaps, Ah! mix in the Package as a property. my ::z ::= Dog; Dog::func1(); z::func1(); # same thing In that case, the first line works because the object is the undefined dog but the package object, so there is an implicit conversion to Package. The middle line might work by knowing the context of a qualified name, so either the compiler knows this specifically or can handle anything in the symbol table that can be implicitly converted to an Abstraction. --John
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 should've been more explicit. While I don't really have a problem with replacing Code with Callable (except the latter is more wordy, so why not replace Callable with Code...), the issue is that your S02.pod edits indicates that a variable foo must always be bound to a Routine object. However, variable with the sigil can be bound to a Block as well, so replacing Code with Routine at line 1487 and 1512 doesn't quite work. :-) Cheers, Audrey
syntax question: method close is export ()
Does that mean that traits can come before the signature? Or should it be
corrected to
method close () is export { ... }
?
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 http://www.dlugosz.com/Perl6/offerings/ so they don't get lost, until someone with authority wants to diff them. I'm diffing them (slowly), and have committed your stylistic edits to S02.pod. Thanks! 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. Cheers, Audrey
Re: Edits to submit - Routine/Callable
Audrey Tang audreyt-at-audreyt.org |Perl 6| wrote: 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 should've been more explicit. While I don't really have a problem with replacing Code with Callable (except the latter is more wordy, so why not replace Callable with Code...), 1) nobody cared enough to discuss it for a couple weeks, and I decided that's one reason why this is moving so slowly...better to =do= already. See earlier post on Callable/Code. 2) Callable is mentioned in S02 as the role that goes with variables, and that is latest most official statement from Larry. Uses of Code for that role (eqv to variable) is relic from before roles. Why not use Code instead of Callable? I think Larry wanted those key sigil roles to have names that are adjectives. In any case, they form a nice matched set. the issue is that your S02.pod edits indicates that a variable foo must always be bound to a Routine object. However, variable with the sigil can be bound to a Block as well, so replacing Code with Routine at line 1487 and 1512 doesn't quite work. :-) I must have made a mistake; that should have been Callable. Callable is synonomous with the sigil. Cheers, Audrey
Re: new article, A Romp Through Infinity
HaloO, John M. Dlugosz wrote: Please let me know if you see any coding errors, and of course any feedback is welcome. Firstly, shouldn't there also be infinite strings? E.g. 'ab' x Inf is a regularly infinite string and ~pi as well. Other classes might have elaborate notions of infinity. The Complex e.g. might have an angle associated to an Inf. Secondly, you only have a single Inf constant and its negation. But there should be a multitude of infinities. E.g. a code fragment my Int $a = random(0..1) 0.5 ?? 3 !! Inf; my Int $b = $a + 1; say yes if $b $a; should always print yes. That is we continue counting after Inf such that we have transfinite ordinals. 0, 1, 2, ..., Inf, Inf+1, Inf+2, ..., Inf*2, Inf*2+1, ... The implementation is strait forward as an array of coefficients of the Inf powers with Inf**0 == 1 being the finite Ints. The sign bit goes separate from the magnitude. That is you can do the usual Int arithmetic in the ranges Inf..^Inf*2 and -Inf*2^..-Inf except that Inf has no predecessor and -Inf no successor. Well, and we lose commutativity of + and *. I.e. 1 + $a != $a + 1 if $a is transfinite. I'm not sure if such a concept of interesting values of infinity is overly useful, though. In TeX e.g. there are infinitely stretchable spacings of different infinitudes so that they overwrite each other. Or take a stereographic projection near the point opposite of the center of projection where you can usefully clip instead of getting into funny folding of values into the valid range. Also I think we can have finite conceptual infinities for types like int32 and num64. In the latter case we also have infinitely small values and infinities like sqrt(2). In short everything that falls out of the finite range of these types and is captured in Int or Num. BTW, with an infinite precision Num I see no need for the Rat type! Regards, TSa. -- The unavoidable price of reliability is simplicity -- C.A.R. Hoare Simplicity does not precede complexity, but follows it. -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: A few multiple dispatch questions
HaloO,
Jonathan Worthington wrote:
Does the veto take place once the multiple dispatch has given us a
candidate and we try to bind the parameters to the signature, or as part
of the multiple dispatch? For example, supposing I declare:
multi foo(Int $a;; Num $b) { ... } # 1
multi foo(Int $a;; Str $b) { ... } # 2
multi foo(Int $a;; Num $b, Num $c) { ... } # 3
What happens with these?
I would expect that since all parameters are required that
they never show up in the same candidate set that is considered
by the dispatcher to find the most specific.
foo(2, RandomThing.new); # Ambiguous dispatch error
Assuming that the second parameter is incompatible to Num and Str
you should get a can't dispatch error---no ambiguity at all.
foo(2, 2.5); # Ambiguous dispatch error, or 1 because 2 vetos?
I must admit that I've never grasped that veto business. But why
should it be necessary here?
foo(1, 2.5, 3.4); # Ambiguous dispatch error, or 3 because only one with
arity match?
Yeah, only #3 in the applicable method set.
Regards, TSa.
--
The unavoidable price of reliability is simplicity -- C.A.R. Hoare
Simplicity does not precede complexity, but follows it. -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: A few multiple dispatch questions
On Tue, Aug 05, 2008 at 06:17:30PM +0200, Jonathan Worthington wrote:
Hi,
I am currently reviewing bits of the spec surrounding multiple dispatch
and, of course, have a question or two (I'll probably have some more
later, as the dust settles in my head).
1) The spec says:
--
A proto also adds an implicit multi to all routines of
the same short name within its scope, unless they have an explicit modifier.
--
If you write:
proto sub foo(:$thing) { ... }
sub foo(Int $x) { ... }
only sub foo() { ... }
Does this give some kind of error, because you've declared something
with 'only', but it clearly can't be the only one because we also have a
proto in there?
I'd consider it an error.
2) If I write:
multi sub foo(Int $blah) { ... } # 1
proto sub foo(:$blah) is thingy { ... } # 2
multi sub foo() { ... } # 3
Does #1 get the thingy trait, or not because it was declared before the
proto was? I'm clear that #3 gets it...
I think a proto cannot be expected to work retroactively. In fact, I
think it's probably an error to declare a proto after a non-proto in the
same scope.
3) The spec says:
--
A parameter list may have at most one double semicolon; parameters after
it are
never considered for multiple dispatch (except of course that they can
still
veto if their number or types mismatch).
--
Does the veto take place once the multiple dispatch has given us a
candidate and we try to bind the parameters to the signature, or as part
of the multiple dispatch? For example, supposing I declare:
multi foo(Int $a;; Num $b) { ... } # 1
multi foo(Int $a;; Str $b) { ... } # 2
multi foo(Int $a;; Num $b, Num $c) { ... } # 3
What happens with these?
foo(2, RandomThing.new); # Ambiguous dispatch error
foo(2, 2.5); # Ambiguous dispatch error, or 1 because 2 vetos?
foo(1, 2.5, 3.4); # Ambiguous dispatch error, or 3 because only one with
arity match?
Basically, what I'm getting at is, are all of these multi-methods
ambiguous because they all have the same long name, and just because
binding fails doesn't make us return into the multiple dispatch
algorithm? (This is what I'm kinda expecting and would mean every one of
these fails. But I just want to check that is what was meant by the
wording.)
I believe veto is giving the wrong idea here as something that
happens after the fact. What's the term for only allowing acceptable
candidates to put their names on the ballot? Anyway, as TSa surmises,
the ballot is vetted or stacked in advance--only those candidates
that *could* bind are considered to be part of the candidate set.
In the abstract, candidates that cannot match never get their names
on the ballot, though of course an implementation might choose to
determine this lazily as long as it preserves the same semantics.
Alternately, even if the list of valid candidates is determined
eagerly, if the candidate list construction is memoized based on the
typeshape of the Capture, it will generally not have to be redone
until you see a different typeshape (where the meaning of different
may depend on how specific the signatures are, and in particular on
whether any of the signatures rely on subset constraints (including
individual values, which are just degenerate subsets)).
Larry
Re: A few multiple dispatch questions
On Tuesday 05 August 2008 12:01:29 Larry Wall wrote: I believe veto is giving the wrong idea here as something that happens after the fact. What's the term for only allowing acceptable candidates to put their names on the ballot? disenfranchise -- c
Re: A few multiple dispatch questions
On Tuesday 05 August 2008 15:25:47 Bob Rogers wrote: On Tuesday 05 August 2008 12:01:29 Larry Wall wrote: I believe veto is giving the wrong idea here as something that happens after the fact. What's the term for only allowing acceptable candidates to put their names on the ballot? disenfranchise In the context of balloting, that applies to voters; the equivalent word for candidates is qualify (or disqualify). My state has closed primaries; same effect. -- c
