r29930 - docs/Perl6/Spec
Author: masak
Date: 2010-03-03 15:16:22 +0100 (Wed, 03 Mar 2010)
New Revision: 29930
Modified:
docs/Perl6/Spec/S03-operators.pod
Log:
[S03] typo, discovered by particle++
Modified: docs/Perl6/Spec/S03-operators.pod
===
--- docs/Perl6/Spec/S03-operators.pod 2010-03-03 07:37:31 UTC (rev 29929)
+++ docs/Perl6/Spec/S03-operators.pod 2010-03-03 14:16:22 UTC (rev 29930)
@@ -2617,7 +2617,7 @@
when all(:r,:w,:x)
The pair forms are useful only for boolean tests because the method's
-value is evaluated as a boolen, so the
+value is evaluated as a Bool, so the
method form must be used for any numeric-based tests:
if stat($filename).s 1024 {...}
r29931 - docs/Perl6/Spec
Author: lwall
Date: 2010-03-03 18:34:04 +0100 (Wed, 03 Mar 2010)
New Revision: 29931
Modified:
docs/Perl6/Spec/S02-bits.pod
Log:
[S02] remove 1/2 and +2-3i literal forms, now rely on angle dwimmery for
literals,
or constant folding otherwise.
Modified: docs/Perl6/Spec/S02-bits.pod
===
--- docs/Perl6/Spec/S02-bits.pod2010-03-03 14:16:22 UTC (rev 29930)
+++ docs/Perl6/Spec/S02-bits.pod2010-03-03 17:34:04 UTC (rev 29931)
@@ -13,8 +13,8 @@
Created: 10 Aug 2004
-Last Modified: 27 Feb 2010
-Version: 206
+Last Modified: 3 Mar 2010
+Version: 207
This document summarizes Apocalypse 2, which covers small-scale
lexical items and typological issues. (These Synopses also contain
@@ -133,7 +133,7 @@
=item *
-Except within a string literal, a C# character always introduces a comment in
+Except within a quote literal, a C# character always introduces a comment in
Perl 6. There are two forms of comment based on C#. Embedded
comments require the C# to be followed by a backtick (C`) plus one
or more opening bracketing characters.
@@ -3013,25 +3013,27 @@
=item *
Rational literals are indicated by separating two integer literals
-(in any radix) with a slash. Whitespace is not allowed on either
-side of the slash:
+(in any radix) with a slash, and enclosing the whole in angles:
-1/2 # one half literal Rat
-1 / 2 # 1 divided by 2 (also produces a Rat by constant folding)
+1/2 # one half literal Rat
-Note that this essentially overrides precedence to produce a term, so:
+Whitespace is not allowed on either side of the slash or it will
+be split under normal quote-words semantics:
-1/2 * 3/4
+ 1 / 2# ('1', '/', '2')
+ 1/2 # okay, same as 1/2
-means
+Because of constant folding, you may often get away with leaving
+out the angles:
-(1 / 2) * (3 / 4)
+1/2 # 1 divided by 2
-rather than
+However, in that case you have to pay attention to precedence and
associativity.
+The following does Inot cube C2/3:
-((1 / 2) * 3) / 4
+2/3**3 # 2/(3**3), not (2/3)**3
-Decimal fractions not using e notation are also stored as CRat values:
+Decimal fractions not using e notation are also treated as literal CRat
values:
6.02e23.WHAT # Num
1.23456.WHAT # Rat
@@ -3040,15 +3042,19 @@
=item *
Complex literals are similarly indicated by writing an addition or subtraction
of
-two real numbers without spaces:
+two real numbers (again, without spaces around the operators) inside angles:
-5.2+1e42i
-3-1i
+5.2+1e42i
+ -3-1i
As with rational literals, constant folding would produce the same
complex number, but this form parses as a single term, ignoring
surrounding precedence.
+(Note that these are not actually special syntactic forms: both
+rational and complex literal forms fall out naturally from the semantic
+rules of qw quotes described below.)
+
=item *
Characters indexed by hex numbers can be interpolated into strings
@@ -3143,11 +3149,13 @@
The purpose of this would be to facilitate compile-time analysis of
multi-method dispatch, when the user prefers angle notation as the
most readable way to represent a list of numbers, which it often is.
+The form with a single value serves as the literal form of numbers
+such as CRat and CComplex that would otherwise have to be constructed.
It also gives us a reasonable way of visually isolating any known
literal format as a single syntactic unit:
-1+2i.polar
-(-1+2i).polar # same, but less clearly a literal
+(-1+2i).polar # same, but only by constant folding
The degenerate case C is disallowed as a probable attempt to
do IO in the style of Perl 5; that is now written Clines(). (C
continuation markers for long literals (was Re: r29931 - docs/Perl6/Spec)
pugs-comm...@feather.perl6.nl wrote: Modified: docs/Perl6/Spec/S02-bits.pod Log: [S02] remove 1/2 and +2-3i literal forms, now rely on angle dwimmery for literals, or constant folding otherwise. snip I find this an interesting change, and I can see how it would simplify some things, even though I would miss the old behavior. But this reminds me of what I see as a tangential issue, which I want to raise. How would Perl 6 support someone wanting to write a numeric literal that is so long that they would want to split it over multiple source code lines, such as a very long integer that takes a few hundred or thousand characters to write, or an X/Y rational composed of 2 such integers, but they want to keep their source code under the 80 chars per line mark. I'm not currently aware that Perl 6 provides some kind of continuation marker that one could put between pieces of such a literal, so that they could split those pieces otherwise with whitespace but then the parser would treat the code as if said whitespace wasn't there, but I think Perl 6 should have this. It would need to work both outside any quoting constructs as well as inside any angle dwimmery. On one hand I would think the mnemonics of ~, which are stitching things together, would work great for a continuation marker, but that ~ seems to already be established in Perl 6 as indicating a string data context, such that it is used for casting things into Str or catenating 2 strings. However, I will use ~ below for the sake of illustration. my $some_pi = 3.141592653589793238462643383279 ~ 5028841971693993751058209749445923078164 ~ 0628620899862803482534211706798214808651 ~ 3282306647093844609550582231725359408128; my $a_rat = 48111745028410270193 ~ 8521105559/64462294895493038196 ~ 442881097566593344612847564823; As a slight extension to this, one should be able to use that same continuation character between 2 consecutive string literals so that they are parsed as if they were one string literal, so that one could also split those over source code lines, without the vaguarities of source code line endings affecting the value of the string like a here-doc or literal line breaks would. I grant that this could be redundant with regular constant folding of the already defined ~ operator, but using the continuation marker instead for this could spare concern about precedence issues same as 1/2 does versus 1/2 after today's changes. my $a_string = 'hello this world' ~ ' how are you today'; Now I think in the wider world some precedent exists for using the logical-not character ¬ as a continuation marker, but that isn't an ASCII symbol and we would want something ASCII for the continuation marker. Also I think using the backslash for such a marker would be a bad idea. While this isn't an operator per se, if it had to be put in the precedence table, I would think it would have the highest possible precedence; it would be eliminated during one of the earliest parsing phases, during tokenization I believe, and then all the other parsing rules would come into effect following that elimination, except for the big one that any literal continuation chars inside a quoted string are taken as normal characters as usual. So can we please have this continuation marker thing, and what do you think it should look like? Thank you in advance. -- Darren Duncan
Re: continuation markers for long literals (was Re: r29931 - docs/Perl6/Spec)
Mark J. Reed wrote: Doesn't unspace work for this? It would seem that S02 says otherwise: Although we say that the unspace hides the whitespace from the parser, it does not hide whitespace from the lexer. As a result, unspace is not allowed within a token. So, assuming that an integer literal at least, and maybe also an angle dwimmery, is a single token, then that wouldn't work. If unspace did the job, I should be able to say this: my $foo = 3.1415926535897\ 93238462643383279; or: my $foo = 3.1415926535897\ 93238462643383279; and it would be interpreted the same ways as if I said: my $foo = 3.141592653589793238462643383279; Now I think there are good reasons for unspace not being allowed in a token, in which case we'd need some other syntax for the continuation marker that I want. As for supporting long rational literals expressed as X/Y, I can live with being required to say (136\ 5634/42442\ 555) and depend on constant folding rather than 136\ 5634/42442\ 555 doing the same, if that would make things easier. However, the likes of this needs to work: my $bar = :855084\ 4222\ 7677; ... same as this does: my $baz = 564345\ 242432; Thank you. -- Darren Duncan
Re: continuation markers for long literals (was Re: r29931 - docs/Perl6/Spec)
Surely this is not a common-enough requirement to warrant a special syntax. At 80-columns, you can represent integers up to ninety-nine quinvigintillion, nine hundred ninety-nine quattuorvigintillion, nine hundred ninety-nine trevigintillion, nine hundred ninety-nine duovigintillion, nine hundred ninety-nine unvigintillion, nine hundred ninety-nine vigintillion, nine hundred ninety-nine novemdecillion, nine hundred ninety-nine octodecillion, nine hundred ninety-nine septendecillion, nine hundred ninety-nine sexdecillion, nine hundred ninety- nine quindecillion, nine hundred ninety-nine quattuordecillion, nine hundred ninety-nine tredecillion, nine hundred ninety-nine duodecillion, nine hundred ninety-nine undecillion, nine hundred ninety-nine decillion, nine hundred ninety-nine nonillion, nine hundred ninety-nine octillion, nine hundred ninety-nine septillion, nine hundred ninety-nine sextillion, nine hundred ninety-nine quintillion, nine hundred ninety- nine quadrillion, nine hundred ninety-nine trillion, nine hundred ninety- nine billion, nine hundred ninety-nine million, nine hundred ninety-nine thousand, and nine hundred ninety-nine. Surely that's enough for the vast majority of users, isn't it? And if you *do* need anything bigger (perhaps to represent the burgeoning U.S. national debt) then there's always some variation on: my $debt = +( 123456789012345678901234567890123456789012345678901234 ~ 567890123456789012345678901234567890123456789012345678 ~ 901234567890123456789012345678901 ); or even: my $debt = +( 123_456_789_012_345_678_901_234_567_890_123_456_789_012_345_678_901_234 ~ 567_890_123_456_789_012_345_678_901_234_567_890_123_456_789_012_345_678 ~ 901_234_567_890_123_456_789_012_345_678_901 ); if you like to group your thousands for better readability. With adequate constant folding, both of those are still compile-time constants. Damian
Re: continuation markers for long literals (was Re: r29931 - docs/Perl6/Spec)
On Wed, Mar 3, 2010 at 6:26 PM, Darren Duncan dar...@darrenduncan.net wrote:
Mark J. Reed wrote:
Doesn't unspace work for this?
It would seem that S02 says otherwise:
Although we say that the unspace hides the whitespace from the parser, it
does not hide whitespace from the lexer. As a result, unspace is not
allowed within a token.
D'oh, indeed. Never mind.
On Wed, Mar 3, 2010 at 7:00 PM, Damian Conway dam...@conway.org wrote:
At 80-columns, you can represent integers up to ninety-nine
quinvigintillion, [...]
Assuming the short scale. On the long scale, that's ninety-nine
tredecillion, nine hundred ninety-nine thousand nine hundred
ninety-nine duodecillion, etc. :)
there's always some variation on:
my $debt = +(
123456789012345678901234567890123456789012345678901234
~ 567890123456789012345678901234567890123456789012345678
~ 901234567890123456789012345678901
);
Serviceable, but feels a bit hackish. Reminds me of faking P5 qw in
PHP by using split(' ', 'words like this'). But with a reasonably
intelligent compiler, as you say, at least it still compiles to a
literal.
I note that Rakudo alpha turns the above into Inf, which seems apropos. :)
--
Mark J. Reed markjr...@gmail.com
Re: continuation markers for long literals (was Re: r29931 - docs/Perl6/Spec)
Damian Conway wrote: Surely this is not a common-enough requirement to warrant a special syntax. At 80-columns, you can represent integers up to snip Surely that's enough for the vast majority of users, isn't it? Well, 80 columns was an example, albeit the most common, but the principle idea was to support writing code that fit into very narrow spaces (such as may result from having the 80-col constraint plus a whole bunch of code indent levels) while being able to keep the code easily readable and nicely formatted. I also figured that this would be a fairly simple thing to do. Part of the idea was that one could also wrap any long identifiers as well to fit in a narrow space. Now, granted that expressing every thing which might become long as a string literal could probably work, it seemed somewhat inelegant, though maybe the problem is uncommon enough that this is an acceptable sacrifice. And if you *do* need anything bigger (perhaps to represent the burgeoning U.S. national debt) then there's always some variation on: my $debt = +( 123456789012345678901234567890123456789012345678901234 ~ 567890123456789012345678901234567890123456789012345678 ~ 901234567890123456789012345678901 ); or even: my $debt = +( 123_456_789_012_345_678_901_234_567_890_123_456_789_012_345_678_901_234 ~ 567_890_123_456_789_012_345_678_901_234_567_890_123_456_789_012_345_678 ~ 901_234_567_890_123_456_789_012_345_678_901 ); if you like to group your thousands for better readability. With adequate constant folding, both of those are still compile-time constants. That sounds half-reasonable, though it would seem to me that you'd have to quote each piece of the number to make it work right if you were using anything other than base 10. And we're assuming that +(...) isn't producing a Num instead of an Int or Rat as the case may be, as if the rules for +(...) were the same as the parser's rules for what kind of number it makes. So if we leave things as is, then hopefully the examples you raised will be commonly supported as compile-time constants in Perl 6 implementations. -- Darren Duncan
Re: continuation markers for long literals (was Re: r29931 - docs/Perl6/Spec)
On Wed, Mar 03, 2010 at 05:39:58PM -0800, Darren Duncan wrote: : Damian Conway wrote: : Surely this is not a common-enough requirement to warrant a special : syntax. : : At 80-columns, you can represent integers up to : snip : Surely that's enough for the vast majority of users, isn't it? : : Well, 80 columns was an example, albeit the most common, but the : principle idea was to support writing code that fit into very narrow : spaces (such as may result from having the 80-col constraint plus a : whole bunch of code indent levels) while being able to keep the code : easily readable and nicely formatted. Dealing with antediluvian displays sounds like a good spot for that ancient technology, the preprocessor, : I also figured that this would be a fairly simple thing to do. Well, it will be simple, once we have macros; in fact, textual macros can be regarded simply as scoped preprocessors, with all the rights, privileges, and responsibilities pertaining thereto. I think macros will provide enough language support for this sort of hard things should be possible escape hatch. And remember you can always override the grammar if you have special reasons for doing so. That's what Perl 6 is all about. It's not about foreseeing every possible twinge of misgiving that anyone may come to feel in the next 100 years... Sure, we're trying to create a gigantic sweet spot in Perl 6, but Willy Wonka knows you can't have the whole world, and if you could, you can't have it now. :) Larry
