r30037 - docs/Perl6/Spec
Author: moritz
Date: 2010-03-12 13:27:44 +0100 (Fri, 12 Mar 2010)
New Revision: 30037
Modified:
docs/Perl6/Spec/S03-operators.pod
Log:
[S03] two grammeros
Modified: docs/Perl6/Spec/S03-operators.pod
===
--- docs/Perl6/Spec/S03-operators.pod 2010-03-11 22:06:43 UTC (rev 30036)
+++ docs/Perl6/Spec/S03-operators.pod 2010-03-12 12:27:44 UTC (rev 30037)
@@ -1822,7 +1822,7 @@
actually interested in; any additional list elements are treasured
up lazily to be returned after the C... is done.
-The righthand first value is considered to the endpoint or limit of the
+The righthand first value is considered to be the endpoint or limit of the
series that is to be generated from the lefthand side by the C...
operator itself.
@@ -1856,7 +1856,7 @@
1, 1, { $^a + $^b } ... * # 1,1,2,3,5,8,13,21...
Any means of specifying a function will do, as long as you arrange
-return it as a list value rather than calling it:
+it as a list value rather than calling it:
1, 1, infix:+ ... *# 1,1,2,3,5,8...
1, 1, [+] ... * # same thing
Re: r29976 - docs/Perl6/Spec
On Mar 10, 9:49 am, la...@wall.org (Larry Wall) wrote: Algol68 would have done much better had it been Open Source software... If Algol68 was *GPL* Open-Source, then I could take the Zilog Z80 implementation Algol68C and have a HLL on my TI-84 _Pocket_ Calculator (rather the existing choice of TI-BASIC or asm... sigh): * http://en.wikipedia.org/wiki/TI-84_Plus_series * http://www.80bus.co.uk/publications/magazines/LSG3.pdf - R Anderson Pg52 Using Algol68 on a pocket calculator must then set some kind of record as being the longest long-gestated Bubble Bobble ever: * http://en.wikipedia.org/wiki/Bubble_Bobble Incidentally, I programmed in AlgolW on a Burroughs machine once, long, long ago in a galaxy far away... SNAP. AlgolW was my first HLL. But I suspect you mean a IBM 360. Maybe you can find more details of a Burroughs implementation? (esp source code) c.f. http://www.everything2.com/index.pl?node=Algol%20W The only other AlgolW implementation I know of it is the 2008 translator by Glyn Webster: http://www.jampan.co.nz/~glyn/ NevilleDNZ
Re: r29976 - docs/Perl6/Spec
On Mar 10, 9:49 am, la...@wall.org (Larry Wall) wrote: On Wed, Mar 10, 2010 at 10:10:29AM +1100, Timothy S. Nelson wrote: : Algol 68 is notorious as a failure. Let's hope things are : different here. So they say: http://www.google.com.au/search?q=site:www.cs.utexas.edu/~EWD+algol-68 There may be some similarities with perl6. I speculate that if Algol68 was named something else, then the Algol60 implementers would not have gotten their noses so far out of joint. BTW: notorious as a failure is a good way of describing Algol68 as it was not exactly a failure. For example several Operating Systems were written in Algol68 variants: DRA's Flex, ICL's VME, the Soviet Эльбрус-1 and the Cambridge CAP computer. c.f. http://www.reddit.com/r/programming/comments/bbcoc/ancient_operating_system_written_in_algol68_with/ It google is looking for a Alternately, they probably would have bootstrapped Algol into its own ubiquitous language had the Open Source movement existed back then. History would have been much different. Moot point... to this day it is virtually impossible to get sufficient access to the source code to the classic Algol68 compilers. The only exception being the partial release of Algol68RS (missing the format/transport/io libraries) Incidentally, I programmed in Algol W on a Burroughs machine once, long, long ago in a galaxy far away... Algol W was my first HLL too. There is a Algol-W to C implementation: aw2c: http://www.jampan.co.nz/~glyn/ It is opensource - save for the test suite. I think the original Algol-W compile's source - written in PL/360 has long since been lost. N
r30053 - docs/Perl6/Spec
Author: lwall Date: 2010-03-12 17:52:09 +0100 (Fri, 12 Mar 2010) New Revision: 30053 Modified: docs/Perl6/Spec/S02-bits.pod Log: [S02] document which ops don't autoclose with *, including assignment conjecture a generalization of the closure-calling context that subscripts enforce note that this generalization might allow the autoclosing of some of the current exceptions Modified: docs/Perl6/Spec/S02-bits.pod === --- docs/Perl6/Spec/S02-bits.pod2010-03-12 16:32:43 UTC (rev 30052) +++ docs/Perl6/Spec/S02-bits.pod2010-03-12 16:52:09 UTC (rev 30053) @@ -13,8 +13,8 @@ Created: 10 Aug 2004 -Last Modified: 3 Mar 2010 -Version: 207 +Last Modified: 12 Mar 2010 +Version: 208 This document summarizes Apocalypse 2, which covers small-scale lexical items and typological issues. (These Synopses also contain @@ -1019,6 +1019,31 @@ one of these operators, you'll need to write an explicit closure or do an explicit curry on the operator with C.assuming(). +Operators that are known to return non-closure values with C* include: + +$a = * # just assigns Whatever +0 .. * # means 0 .. Inf +0 ... * # means 0 ... Inf +'a' xx *# means 'a' xx Inf +1,* # means 1,* :) + +[Conjecture: it is possible that, for most of the above operators that +take C* to mean CInf, we could still actually return a closure +that defaults that particular argument to CInf. However, this would +work only if we provide a value list context that forbids closures, +in the sense that it always calls any closure it finds it its list +and replaces the closure in the list with its return value or values, +and then rescans from that point (kinda like a text macro does), in case +the closure returned a list containing a closure. So for example, +the closure returned by C0..* would interpolate a Range object into +the list when called. Alternately, it could return the C0, followed +by another closure that does C1..*. Even the C... operator could +likely be redefined in terms of a closure that regenerates itself, +as long as we figure out some way of remembering the last N values +each time.] + +In any case, array indexes must behave as such a 'value list context', +since you can't directly index an array with anything other than a number. The final element of an array is subscripted as C@a[*-1], which means that when the subscripting operation discovers a CCode:($) object for a subscript, it calls it and supplies an argument indicating
numerics, roles, and naming
So, I've been looking more closely at Perl's native value types and associated roles, and there are a few matters of their naming or availability that I have questions or suggestions on. 1. As a general observation, I note that it is a common pattern for basic Perl 6 value types that a role for the concept is written out as the whole name, such as Boolean or Rational or Integral or String etc, and the primary Perl type composing that is an abbreviation thereof, Bool or Rat or Int or Str etc. 2. There doesn't seem to be a role for complex as there is for integer or rational or real or numeric. So, if the boxed Perl complex number is called Complex and the machine native one is called complex or complex128 or whatever, what would one name the role that is common to all of these? Note that I wouldn't necessarily consider Numeric to be the answer because I would consider Numeric more broad, such as to include anything that might conceivably be called a number, probably user-defined, that isn't representable by a complex. So, is current thinking that Numeric is supposed to fill the role I mentioned, or is it meant to be broader than that, in which case do we need a complex role. If we should have a complex role, then what would we name it? Following the above pattern, you'd think that Complex would be best used as th role name and so something else is needed for the type, either as some abbreviation, or alternately with additions. Conceivably one could have a complex type defined in terms of any combination of the various real or rational or integer types, such as NumComplex or RatComplex (and FatRatComplex) and IntComplex etc. So I suggest making a Complex role and splitting the old Complex type at least into the distinct [Num|Rat|FatRat]Complex types I mentioned. For the integer version, my understanding is that number theory already provides a suitable term, Gaussian integer, which is a complex number whose real and imaginary parts are both integers. So I suggest using Gaussian as the name option for an IntComplex. Or maybe better yet for completion sake, make Gaussian a role and something like Gaus the type or something. Alternately, while we would still need a Complex-specific role, we could possibly avoid a need to explicitly declare some of the composing types if Complex is parameterizable, as AFAIK Rational et al are parameterizable. What do you think? 3. I notice that some roles that are longer forms of type names look like nouns, while others look like adjectives. I suppose that adjectives are what you're going after, and the ones that look like nouns such as Boolean and Rational and Real are also adjectives. On the other hand, lots of roles are surely just nouns, such as Failure and Routine. So a question I have is, given the context, is Integral the best name for that role, or would Integer be better? From some quick searching around, the term integral doesn't seem to be used a lot in literature for the meaning you're ascribing, and integer seems to be much more common, when referring to these things. That is, unless you're specifically going for integral domain as what Integral is meant to cover. Is that it? So is there a specific reason or three that Integral is better than Integer or is it really a wash? Is anyone opposed to renaming Integral to Integer? Besides my inclination to think that some roles are better off looking like nouns when possible, it seems that most literature searches for the term integral bring up calculus operations, such as integration is seemingly a much more commonly used interpretation of the term integral, and so integer may lessen confusion there. Maybe. -- Darren Duncan
Re: numerics, roles, and naming
Follow-up, ... 4. If Integral is better called Integer, or regardless ... Would Numeric be better called Number? Would there by any objection to renaming it such? What are advantages of the former over the latter? Basically, same idea, if we're going more for nouns or adjectives role names. (Note, any replies to this follow-up message should be tacked on as a reply to the initial one.) Thank you. -- Darren Duncan
Re: numerics, roles, and naming
Darren Duncan wrote: 2. There doesn't seem to be a role for complex as there is for integer or rational or real or numeric. So, if the boxed Perl complex number is called Complex and the machine native one is called complex or complex128 or whatever, what would one name the role that is common to all of these? I'm definitely in favor of there being a Complex role - not just for the reasons given above, but also to have a common role that applies to a complex number regardless of the coordinate system that's being used to store the value (e.g. cartesian vs. polar). Both should be able to provide you with the real, imaginary, magnitude, and direction components; but classes based off of the cartesian model should be able to do the former two directly and calculate the latter two, and vice versa. A single role that's agnostic about the coordinate system would allow us to use any of these in a function call. For that purpose, I think that the common, underlying role should be called Complex. Following the above pattern, you'd think that Complex would be best used as th role name and so something else is needed for the type, either as some abbreviation, or alternately with additions. Conceivably one could have a complex type defined in terms of any combination of the various real or rational or integer types, such as NumComplex or RatComplex (and FatRatComplex) and IntComplex etc. For practical purposes, I think that the component types for Complex should be standardized as Real - that is, the Complex role should assume that the components do the Real role. As I indicate above, I think that a more significant distinction should be the coordinate system: cartesian complex numbers are essentially optimized for use with addition and subtraction; polar complex numbers are a more efficient choice for multiplication and division; raising a number to a complex exponent works most efficiently if the exponent is cartesian and the result is polar, and vice versa for logs. And so on. For the integer version, my understanding is that number theory already provides a suitable term, Gaussian integer, which is a complex number whose real and imaginary parts are both integers. So I suggest using Gaussian as the name option for an IntComplex. Or maybe better yet for completion sake, make Gaussian a role and something like Gaus the type or something. Hmm... true enough. I'd rather have Gaussian be to Complex as Integral is to Real: a separate role, not necessarily related in any sort of role composition sense, but serving a similar purpose. Note that Gaussian would not have separate cartesian and polar forms; by definition, it operates off of a cartesian coordinate system. While a polar version could exist in theory, it doesn't in practice; and even if it did, it wouldn't be interchangeable with the cartesian version, the way that they are when the components are Real. OTOH, Gaussian definitely has analogs comparable to the differences between Integral vs. Real, in that Gaussian and Integral have the concept of factors and everything that goes with them (e.g., primes, gcf, lcm, remainders, etc.) Perhaps we need a role to encapsulate that notion, much like we have one that encapsulates the notion of order (e.g., before/after). Or would that turn out to be unnecessary clutter, seeing as how we only have two examples of roles that would compose it (Integral and Gaussian), one of which is a highly technical fringe case? Alternately, while we would still need a Complex-specific role, we could possibly avoid a need to explicitly declare some of the composing types if Complex is parameterizable, as AFAIK Rational et al are parameterizable. I'm fine with Complex being parameterizable, as long as Real is the default parameter. 3. I notice that some roles that are longer forms of type names look like nouns, while others look like adjectives. I suppose that adjectives are what you're going after, and the ones that look like nouns such as Boolean and Rational and Real are also adjectives. On the other hand, lots of roles are surely just nouns, such as Failure and Routine. So a question I have is, given the context, is Integral the best name for that role, or would Integer be better? From a layman's view of things, I keep on finding myself wanting to say Integer rather than Integral. That said, it's not that hard to retrain myself; and I do see some benefit to the notion that role names are adjectives while class names are nouns, as long as it's applied consistently to the standard roles. That said, see below. Still: when I first saw Integral, the first thing that came to mind was a calculus operation, not whole numbers. 4. If Integral is better called Integer, or regardless ... Would Numeric be better called Number? Would there by any objection to renaming it such? What are advantages of the former over the latter? Basically, same idea, if we're going more for nouns or
Re: numerics, roles, and naming
Jon, thanks for your feedback; it was both informative and supportive. Jon Lang wrote: Darren Duncan wrote: 2. There doesn't seem to be a role for complex as there is for integer or rational or real or numeric. So, if the boxed Perl complex number is called Complex and the machine native one is called complex or complex128 or whatever, what would one name the role that is common to all of these? I'm definitely in favor of there being a Complex role - not just for the reasons given above, but also to have a common role that applies to a complex number regardless of the coordinate system that's being used to store the value (e.g. cartesian vs. polar). Both should be able to provide you with the real, imaginary, magnitude, and direction components; but classes based off of the cartesian model should be able to do the former two directly and calculate the latter two, and vice versa. A single role that's agnostic about the coordinate system would allow us to use any of these in a function call. For that purpose, I think that the common, underlying role should be called Complex. I agree 100%. I also foresaw the cartesian vs polar thing, and considered it very important, but I didn't mention it in my post because for some reason I assumed that the existing Complex type already supported both views, or I thought I recalled the Synopsis already talking about it. Anyway, yes, a Complex role *must* include both the cartesian and polar possible-representations (possreps), and then there can be a composing class optimized for each one. Following the above pattern, you'd think that Complex would be best used as th role name and so something else is needed for the type, either as some abbreviation, or alternately with additions. Conceivably one could have a complex type defined in terms of any combination of the various real or rational or integer types, such as NumComplex or RatComplex (and FatRatComplex) and IntComplex etc. For practical purposes, I think that the component types for Complex should be standardized as Real - that is, the Complex role should assume that the components do the Real role. That's reasonable. As I indicate above, I think that a more significant distinction should be the coordinate system: cartesian complex numbers are essentially optimized for use with addition and subtraction; polar complex numbers are a more efficient choice for multiplication and division; raising a number to a complex exponent works most efficiently if the exponent is cartesian and the result is polar, and vice versa for logs. And so on. And now I learned something about complex math. For the integer version, my understanding is that number theory already provides a suitable term, Gaussian integer, which is a complex number whose real and imaginary parts are both integers. So I suggest using Gaussian as the name option for an IntComplex. Or maybe better yet for completion sake, make Gaussian a role and something like Gaus the type or something. Hmm... true enough. I'd rather have Gaussian be to Complex as Integral is to Real: a separate role, not necessarily related in any sort of role composition sense, but serving a similar purpose. Note that Gaussian would not have separate cartesian and polar forms; by definition, it operates off of a cartesian coordinate system. While a polar version could exist in theory, it doesn't in practice; and even if it did, it wouldn't be interchangeable with the cartesian version, the way that they are when the components are Real. Personally I prefer the idea of Int and Rat etc being disjoint as programming language data types, even if they are considered subsets by some conceptions, because then we can just have Int as the one primitive type in terms of which everything else is defined. So it stands to reason in such as system that making Gaussian/Int-Complex types and Real-Complex types disjoint is consistent with the fact that Int does *not* compose the Real role. OTOH, Gaussian definitely has analogs comparable to the differences between Integral vs. Real, in that Gaussian and Integral have the concept of factors and everything that goes with them (e.g., primes, gcf, lcm, remainders, etc.) Perhaps we need a role to encapsulate that notion, much like we have one that encapsulates the notion of order (e.g., before/after). Or would that turn out to be unnecessary clutter, seeing as how we only have two examples of roles that would compose it (Integral and Gaussian), one of which is a highly technical fringe case? The role may still be a good idea, though. See also Boolean, which currently is used by just Bool and Bit (and bit). On a tangent, something else I was wondering or suggesting is whether it would be reasonable for the Boolean role to be composed by anything that supports bitwise operations (I don't mean shifting, but not/and/or/xor/etc) since I believe all those bitwise operations are direct analogies to boolean
