r29931 - docs/Perl6/Spec
pugs-c...@feather.perl6.nl
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.pod 2010-03-03 14:16:22 UTC (rev 29930)
+++ docs/Perl6/Spec/S02-bits.pod 2010-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 I<not> cube C<2/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 C<Rat> values:
+Decimal fractions not using "e" notation are also treated as literal C<Rat> 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 C<Rat> and C<Complex> 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 C<lines()>. (C<<
Darren Duncan
> 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.
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
Mark J. Reed
--
Mark J. Reed <mark...@gmail.com>
Darren Duncan
> 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 = :8<55084\ 4222\ 7677>;
... same as this does:
my $baz = 564345\ 242432;
Thank you.
-- Darren Duncan
Damian Conway
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
Mark J. Reed
> 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. :)
Darren Duncan
> Surely this is not a common-enough requirement to warrant a special
> syntax.
>
> At 80-columns, you can represent integers up to
> 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
Larry Wall
: 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
Darren Duncan
> 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. :)
FYI,
As a follow-up, this Perl 6 discussion has inspired me to apply some of these
ideas to my Muldis D language (PTMD_STD dialect), so then there should be an
earlier example of the concept I proposed.
The feature that I went and specced out today, and named "unspace" after its
Perl 6 inspiration, basically is a token consisting of a pair of backslashes
separated by whitespace. Currently this token can be placed in the middle of
either a numeric or a stringy literal (including quoted formats of identifiers),
and in the latter case *inside* the quotes.
Examples:
$bar := 7;55084\ \4222\ \7677 # an integer expressed in octal #
$some_pi := 3.141592653589793238462643383279\
\5028841971693993751058209749445923078164\
\0628620899862803482534211706798214808651\
\3282306647093844609550582231725359408128
$a_rat := 48111745028410270193\
\8521105559 / 64462294895493038196\
\442881097566593344612847564823
$a_string := 'hello this world\
\ how are you today'
$a_string := 'hello this world'
~ ' how are you today'
Those, except the last, are direct translations of the pseudo-Perl-6 I gave
earlier in the thread.
Note that since Muldis D's use of backslashes differs in some ways from how Perl
6 uses them (backslashes are only otherwise used for spelling escaped
characters), the above syntax doesn't conflict with anything there.
One detail unlike Perl 6's unspace is that I put a backslash at both ends of the
stuff to ignore, so when used for the above purpose the code isn't end-weighted
and a human can parse what's going on faster. Also, my version of unspace is
simpler in that you don't put any comments in it.
Now if naming my concept "unspace" may confuse people, as it is partially like
that of Perl 6 but partly not, I could name it something else, but that name
seemed the best for now, because it is all about letting a programmer put some
whitespace in their code which the parser would then treat as if it wasn't there
at all.
-- Darren Duncan
Darren Duncan
sure ...
pugs-c...@feather.perl6.nl wrote:
> 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.
<snip>
> 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.
<snip>
Basically, I found this line in Synopsis 2, in the section talking about unspace:
1+3\ i;
So the question is about whether this example should be kept as still valid code
or whether it is now invalid and a fossil?
I suspect it *is* still valid, at least if this by itself:
3i
... is a valid literal denoting <0+3i>, but wanted to check.
-- Darren Duncan
Larry Wall
: Basically, I found this line in Synopsis 2, in the section talking about unspace:
:
: 1+3\ i;
:
: So the question is about whether this example should be kept as
: still valid code or whether it is now invalid and a fossil?
:
: I suspect it *is* still valid, at least if this by itself:
:
: 3i
:
: ... is a valid literal denoting <0+3i>, but wanted to check.
Yes, both of those are still valid. Thanks.
In fact, the \ is required if you want to use a variable:
$foo + $bar\i
Well, I suppose you could also write that as:
$foo + ($bar)i
but that could be construed as clunkier. Or at least more typing.
Larry