r28772 - docs/Perl6/Spec
Author: carlin Date: 2009-10-12 12:11:08 +0200 (Mon, 12 Oct 2009) New Revision: 28772 Modified: docs/Perl6/Spec/S29-functions.pod Log: [Spec/S29-functions.pod] Fixed mistake with 'die'. carlin--, masak++ Modified: docs/Perl6/Spec/S29-functions.pod === --- docs/Perl6/Spec/S29-functions.pod 2009-10-12 09:19:28 UTC (rev 28771) +++ docs/Perl6/Spec/S29-functions.pod 2009-10-12 10:11:08 UTC (rev 28772) @@ -255,7 +255,8 @@ multi die (@LIST) -Prints each element to $*ERR (STDERR) and throws an exception. +Throws a fatal Exception. The default exception handler prints each element of +the list to $*ERR (STDERR). =item fail
Re: r28751 - docs/Perl6/Spec
On Sun, Oct 11, 2009 at 11:47:45AM -0400, Brandon S. Allbery KF8NH wrote: On Oct 11, 2009, at 06:36 , Mark J. Reed wrote: That's not grammatical; you've just created a run-on sentence. Why not leave it as a colon? Or semicolon. I agree comma seems wrong. Colon is correct here because the second phrase defines what we mean in the first phrase. It could also be viewed as a logical consequence, though semantically it's more like a final cause. But in general a colon indicates that we're explaining what we mean in the first part, which is a tighter relationship than the mere juxtaposion of semicolon, which leaves the reader to work out the relationship. Larry
Re: r28597 - docs/Perl6/Spec/S32-setting-library
David Green wrote: On 2009-Oct-4, at 2:07 pm, Moritz Lenz wrote: Michael Zedeler wrote: It doesn't, because succ should always give the next, smallest possible element given some ordering relation. Where's that definition from? The dictionary. =) It would be confusing to have a successor method for something that isn't orderable and discrete. An ordered continuous type like Real could have .inc and .dec; it just happens that in the common case of Ints, .succ and .inc mean the same thing. Complex could have an .inc method, but I don't think there's any especially obvious choice (because .inc probably wants an ordered type). Would it add 1? or 1+i? Better to spell it out explicitly. Well, Real implies ordering (at least to me ;-), I don't think we have a class or role for countability. A Discrete role would be useful, but is Set good enough for that? Sets could be acting as domains for things such as Integers, so we are on two different abstraction levels there (having Integer implement Set would probably never make much sense, but an Integer object can be part of a Set). Integers, strings and other types have a succ and pred method, but you could say that they draw upon a set (acting as their domain) when they decide the successor and predecessor of any given element. In mathematical terms it makes sense, but I am aware that from an implementation perspective, it sounds somewhat odd. It does, however solve some of the current problems that we have with iterating on Ranges and various other things. Also, the domain should define how to compare objects and could provide details about whether the set is finite, countable or uncountable. Does anyone know if there has been any prior discussions of such an approach? I started changing the spec, but decided against it since I have some 10 years of design discussion to catch up on first. Links to prior discussions will be greatly appreciated. Regards, Michael.
Re: r28597 - docs/Perl6/Spec/S32-setting-library
... Also, the domain should define how to compare objects and could provide details about whether the set is finite, countable or uncountable. ... Sounds like a role Domain that provides methods (off the top of my head)- ordering - returns Nil if the domain is unordered, or a method implementing cmp if it is ordered succ, pred- returns Nil if the domain is uncountable, or method implementing next item, prior item if countable. count - returns Inf if it's an infinite domain, or count of objects if finite. What if counting is an expensive operation? perhaps there should also be an is_infinite method that returns true or false. Then the .. operator can accept anything that does Domain where ordering is non-Nil, and the ... operator can add the condition that succ/pred are non-Nil.
