Re: r29931 - docs/Perl6/Spec
On Sat, Mar 13, 2010 at 08:53:02PM -0800, Darren Duncan wrote: : 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
Re: r29931 - docs/Perl6/Spec
I think I found a Synopsis fossil, in light of revision 29931, but wanted to be sure ... pugs-comm...@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. 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. 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
Re: continuation markers for long literals (was Re: r29931 - docs/Perl6/Spec)
Larry Wall wrote: 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
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 : : >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
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 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 3, 2010 at 6:26 PM, Darren Duncan 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 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
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)
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 = :8<55084\ 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)
Doesn't unspace work for this? On Wednesday, March 3, 2010, Darren Duncan wrote: > 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. > > > > 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
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. 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
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 I 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 values: +Decimal fractions not using "e" notation are also treated as literal C 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 and C 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. (C<<