Outlaw the "\ddd" notation
Hi, there~ Perl 5 uses the "\ddd" notation to index characters by octal numbers (e.g. \187 and \13). Now that Perl 6 has the shiny new \o and \o[] notations, we probably need to outlaw the legacy stuff explicitly in S02 since we have the assumption that everything not mentioned in the Synopses is assumed to stay the same as in Perl 5. Therefore, in Perl 6, "\187" eq '187' will hold. BTW, Audrey also thinks it's necessary to add a snippet to S02. :=) Cheers, Agent
[patch] do EXPR
Hello~
Here is a snippet from the Pugs test suite:
{
my $ret = eval 'do 42';
ok(!$ret, 'do EXPR should not work', :todo);
# XXX or should it? Feels weird...
}
which motivated me to create the following patch for S04:
Index: D:/projects/Perl6-Syn/S04.pod
===
--- D:/projects/Perl6-Syn/S04.pod (revision 10955)
+++ D:/projects/Perl6-Syn/S04.pod (working copy)
@@ -349,8 +349,9 @@
$x = do if $a { $b } else { $c };
-This construct only allows you to prefix a statement. If you want to
-continue the expression after the statement you must use the curly form.
+This construct only allows you to prefix I statement (or an expression).
+If you want to continue the expression after the statement you must use the
+curly form.
Since C is defined as going in front of a statement, it follows
that it can always be followed by a statement label. This is particularly
Cheers,
Agent
Re: ===, =:=, ~~, eq and == revisited (blame ajs!) -- Explained
David Green writes: > I guess my problem is that [1,2] *feels* like it should === [1,2]. > You can explain that there's this mutable object stuff going on, and I > can follow that (sort of...), but it seems like an implementation > detail leaking out. The currently defined behaviour seems intuitive to me, from a starting point of Perl 5. The difference between: my $new = [EMAIL PROTECTED]; and: my $new = [EMAIL PROTECTED]; is that the second one is a copy; square brackets always create a new anonymous array rather than merely refering to an existing one, and that's the same thing that's happening here. Think of square brackets as meaning something like Array->new and each one is obviously distinct. > And I feel this way because [1,2] looks like it should be platonically > unique. I'd say that C< (1, 2) > looks like that. But C< [1, 2] > looks like it's its own thing that won't be equal to another one. Smylers
Re: ===, =:=, ~~, eq and == revisited (blame ajs!) -- Explained
David Green writes: > On 8/13/06, Smylers wrote: > > > Please could the proponets of the various behaviours being discussed > > here share a few more concrete examples ... > > OK, Thanks for that. In summary, if I've understood you correctly, it's that: =:= two aliases to the same actual variable === one variable contains a copy of the other's actual contents eqv both contain contents which represent the same thing but may have come from different sources And that being true at one level implies being true for the above levels. Yes? > === > Example: Suppose I have some employee objects, and I employ two John > Smiths. They have the same name, work in the same department, and by > stunning coincidence everything my class knows about them just > happens to be the same. Except that they wouldn't. Because each one would have a separate payroll number, or some artificial thing invented just for the sake of being different. So this example doesn't sound plausible to me. > But they're still different objects (the payroll system definitely > needs to produce two cheques, although since they earn the same > salary, it doesn't matter which one of them gets which cheque); so > $john1 !=== $john2, and I can tell them apart. And why on earth would you be making such a comparison? If you have a list of employees who need cheques then you just iterate through them and process them in turn; you wouldn't be comparing an arbitrary pair of them. So I now understand what this operator does. But I'm still struggling to fathom where I would ever have a use for it. Smylers
[svn:perl6-synopsis] r10969 - doc/trunk/design/syn
Author: larry Date: Tue Aug 15 08:40:59 2006 New Revision: 10969 Modified: doc/trunk/design/syn/S02.pod Log: Explicitly outlawed \123 and the like. Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podTue Aug 15 08:40:59 2006 @@ -12,9 +12,9 @@ Maintainer: Larry Wall <[EMAIL PROTECTED]> Date: 10 Aug 2004 - Last Modified: 14 Aug 2006 + Last Modified: 15 Aug 2006 Number: 2 - Version: 64 + Version: 65 This document summarizes Apocalypse 2, which covers small-scale lexical items and typological issues. (These Synopses also contain @@ -1365,11 +1365,25 @@ =item * -Characters indexed by hex, octal, and decimal numbers can be interpolated -into strings using either C<"\x123"> (with C<\o> and C<\d> behaving -respectively) or using square brackets: C<"\x[123]">. Multiple -characters may be specified within any of the bracketed forms by -separating the numbers with comma: C<"\x[41,42,43]">. +Characters indexed by hex numbers can be interpolated into strings +by introducing with C<"\x">, followed by either a bare hex number +(C<"\x263a">) or a hex number in square brackets (C<"\x[263a]">). +Similarly, C<"\o12"> and C<"\o[12]"> interpolate octals, while +C<"\d1234"> and C<"\d[1234]"> interpolate decimals--but generally +you should be using hex in the world of Unicode. Multiple characters +may be specified within any of the bracketed forms by separating the +numbers with comma: C<"\x[41,42,43]">. You must use the bracketed +form to disambiguate if the unbracketed form would "eat" too many +characters, because all of the unbracketed forms eat as many characters +as they think look like digits in the radix specified. None of these +notations work in normal Perl code. They work only in interpolations +and regexes and the like. + +The old C<\123> form is now illegal, as is the C<\0123> form. +Only C<\0> remains, and then only if the next character is not in +the range C<'0'..'7'>. Octal characters must use C<\o> notation. +Note also that backreferences are no longer represented by C<\1> +and the like--see S06. =item *
[svn:perl6-synopsis] r10970 - doc/trunk/design/syn
Author: larry Date: Tue Aug 15 08:41:37 2006 New Revision: 10970 Modified: doc/trunk/design/syn/S02.pod Log: typo Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podTue Aug 15 08:41:37 2006 @@ -1383,7 +1383,7 @@ Only C<\0> remains, and then only if the next character is not in the range C<'0'..'7'>. Octal characters must use C<\o> notation. Note also that backreferences are no longer represented by C<\1> -and the like--see S06. +and the like--see S05. =item *
[svn:perl6-synopsis] r10971 - doc/trunk/design/syn
Author: larry
Date: Tue Aug 15 08:52:46 2006
New Revision: 10971
Modified:
doc/trunk/design/syn/S04.pod
Log:
Clarifications on C with bare expression.
Modified: doc/trunk/design/syn/S04.pod
==
--- doc/trunk/design/syn/S04.pod(original)
+++ doc/trunk/design/syn/S04.podTue Aug 15 08:52:46 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 19 Aug 2004
- Last Modified: 14 Aug 2006
+ Last Modified: 15 Aug 2006
Number: 4
- Version: 34
+ Version: 35
This document summarizes Apocalypse 4, which covers the block and
statement syntax of Perl.
@@ -349,8 +349,15 @@
$x = do if $a { $b } else { $c };
-This construct only allows you to prefix a statement. If you want to
-continue the expression after the statement you must use the curly form.
+This construct only allows you to attach a single statement to the end
+of an expression. If you want to continue the expression after the
+statement, or if you want to attach multiple statements. you must use
+the curly form. Since a bare expression may be used as a statement,
+you may use C on an expression, but its only effect is to function
+as an unmatched left parenthesis, much like the C<$> operator in
+Haskell. That is, precedence decisions do not cross a C boundary.
+Conjectural: a C may be used within a subexpression, but only if
+terminated by an unmatched right bracket of some kind.
Since C is defined as going in front of a statement, it follows
that it can always be followed by a statement label. This is particularly
Re: ===, =:=, ~~, eq and == revisited (blame ajs!) -- Explained
David Green schreef: > === > ...is equality-of-contents, basically meaning that the things you're > comparing contain the same [...] values. How about strings; are normalized copies used with the === ? http://www.unicode.org/faq/normalization.html http://www.unicode.org/notes/tn5/ -- Affijn, Ruud "Gewoon is een tijger."
Re: ===, =:=, ~~, eq and == revisited (blame ajs!) -- Explained
On 8/14/06, Smylers wrote: David Green writes: Thanks for that. In summary, if I've understood you correctly, it's that: =:= two aliases to the same actual variable === one variable contains a copy of the other's actual contents eqv both contain contents which represent the same thing but may have come from different sources And that being true at one level implies being true for the above levels. Yes? Right. (Where the ordering for "above" means =:= implies ===, and === implies eqv, but not in the other direction, of course.) > === Example: Suppose I have some employee objects, and I employ two John Smiths. They have the same name, work in the same department, and by stunning coincidence everything my class knows about them just happens to be the same. Except that they wouldn't. Because each one would have a separate payroll number, or some artificial thing invented just for the sake of being different. So this example doesn't sound plausible to me. Well, I didn't say it was a *good* payroll system! OK, it's a silly contrived example; maybe my objects should have represented the reticulated flanges I have in stock, since one piece of inventory is the same as any other. Except I wouldn't really create an object for each one, I'd just have a single group-object that contained a $num_available counter (Anyone cleverer than I should feel free to jump in with a better example.) So I now understand what this operator does. But I'm still struggling to fathom where I would ever have a use for it. Maybe you wouldn't -- eqv is what most of us will use most of the time, I expect (being the ordinary everyday parallel to == and eq). But since it is possible to use variables both by value and by reference, there still needs to be a way to work with and compare both of them when you want to do fancy advanced stuff. -David
=== and array-refs
On 8/14/06, Smylers wrote:
David Green writes:
I guess my problem is that [1,2] *feels* like it should === [1,2].
You can explain that there's this mutable object stuff going on, and I
can follow that (sort of...), but it seems like an implementation
detail leaking out.
The currently defined behaviour seems intuitive to me, from a
starting point of Perl 5.
But is Perl 5 the best place to start? It's something many of us are
used to, but that doesn't mean it's the best solution conceptually,
even if it was the most reasonable way to implement it in P5.
The reason I think it's an implementation wart is that an array --
thought of as a single, self-contained lump -- is different from a
reference or pointer to some other variable. Old versions of Perl
always eagerly exploded arrays, so there was no way to refer to an
array as a whole; put two arrays together and P5 (or P4, etc.) thinks
it's just one big array or list.
Then when references were introduced, "array-refs" provided a way to
encapsulate arrays so we could work with them as single lumps. It's
not the most elegant solution, but being able to nest data structures
at all was a tremendous benefit, and it was backwards-compatible.
P6 doesn't have to be that backwards-compatible -- it already isn't.
P6 more naturally treats arrays as lumps; this may or may not be
*implemented* using references as in P5, but it doesn't have to -- or
at least, it doesn't have to *look* as though that's how it's doing
it. Conceptually, an array consisting only of constant literals,
like (1,2,3), isn't referring to anything, so it doesn't need to
behave that way.
The difference between:
my $new = [EMAIL PROTECTED];
and:
my $new = [EMAIL PROTECTED];
is that the second one is a copy; square brackets always create a
new anonymous array rather than merely refering to an existing one,
and that's the same thing that's happening here. Think of square
brackets as meaning something like Array->new and each one is
obviously distinct.
I agree that [EMAIL PROTECTED] should be distinct from [EMAIL PROTECTED] -- in the former
case, we're deliberately taking a reference to the @orig variable.
What I don't like is that [EMAIL PROTECTED] is distinct from [EMAIL PROTECTED] -- sure,
I'm doing something similar to Array->new(1,2) followed by another
Array->new(1,2), but I still want them to be the same, just as I want
Str->new("foo") to be the same as Str->new("foo"). They're just
constants, they should compare equally regardless of how I created
them. (And arrays should work a lot like strings, because at some
conceptual level, a string is an array [of characters].)
> And I feel this way because [1,2] looks like it should be platonically
unique.
I'd say that C< (1, 2) > looks like that. But C< [1, 2] > looks
like it's its own thing that won't be equal to another one.
Except [1,2] can look like (1,2) in P6 because it automatically
refs/derefs stuff so that things Just Work. That's good, because you
shouldn't have to be referencing arrays yourself (hence my point
above about an array conceptually being a single lump). But if we're
going to hide the [implementational] distinction in some places, we
should hide it everywhere.
Actually, my point isn't even about arrays per se; that's just the
implementation/practical side of it. You can refer to a scalar
constant too:
perl -e 'print \1, \1'
SCALAR(0x8104980)SCALAR(0x810806c)
They're different because the *references* are different, but I don't
care about that. A reference to a constant value is kind of
pointless, because the value isn't going to change. References to
*variables* are useful, because you never know what value that
variable might have, and refs give you a pointer to the current value
of the variable at any time.
The fact that it's even possible to take a reference to a literal is
kind of funny, really; but since in P5 you had to be explicit about
(de)referencing, it didn't hurt, and you could maybe even find some
cute ways to take advantage of it (such as an easy way to get unique
IDs out of the str/numification of a ref?). P6 just lets you gloss
over certain ref/deref distinctions that in a perfect world wouldn't
have existed in the first place.
Leibniz's "identity of indiscernibles" is a perfectly practical
principle to pursue in programming. Now [EMAIL PROTECTED] may be discernible
from [EMAIL PROTECTED] or [1, @orig] from [1, @other], but \1 is completely the
same as \1 in all ways -- all ways except for being able to get a
representation of its memory location. And that's not anything about
"1", that's a bit of metadata about the reference itself -- something
that definitely is based on the implementation.
(I can imagine some other implementation where in a ridiculous
attempt to optimise for minimal memory footprint, everything with a
value of 1 points to the same address. When I say "$a=1; $a++", $a
Re: === and array-refs
It seems to me that there is some confusion being given in this
thread and the most recent parts of its predecessor (which can lead
to FUD in the wrong hands), so I'll briefly try to clear it up, as I
would like to think I understand the issues.
At 2:51 PM -0600 8/15/06, David Green wrote:
On 8/14/06, Smylers wrote:
David Green writes:
I guess my problem is that [1,2] *feels* like it should === [1,2].
You can explain that there's this mutable object stuff going on, and I
can follow that (sort of...), but it seems like an implementation
detail leaking out.
There are no implementation details leaking out, but rather we are
just dealing with the declared interface behaviour of different types
and operators.
I agree that [EMAIL PROTECTED] should be distinct from [EMAIL PROTECTED] -- in the former
case, we're deliberately taking a reference to the @orig variable.
What I don't like is that [EMAIL PROTECTED] is distinct from [EMAIL PROTECTED] -- sure,
I'm doing something similar to Array->new(1,2) followed by another
Array->new(1,2), but I still want them to be the same, just as I
want Str->new("foo") to be the same as Str->new("foo"). They're
just constants, they should compare equally regardless of how I
created them. (And arrays should work a lot like strings, because
at some conceptual level, a string is an array [of characters].)
You are right, but we have both Seq and Array types, so depending
which one you use, you want either the === or eqv operators to do
what you want. There is no reason that === should say 2 Array are
equal; we have eqv for that, or use 2 Seq instead of 2 Array if you
want === to return true on the same values.
So, (1,2) always === and eqv (1,2), but [1,2] only eqv [1,2] and
[1,2] generally !=== [1,2].
First of all, in Perl 6, there are no separate "arrays" and "array
refs"; we simply have the 'Array' type, which is treated as a lump on
its own.
More generally, there are no "reference" types in Perl 6. We do have
a concept of multiple symbols being aliases for the same container,
and they only come to be that way if they are explicitly aliased,
such as with "$a := $b"; only in those cases, the operator =:=, which
sees if 2 symbols represent the same container, would return true.
If you create 2 values separately and don't explicitly alias them
like that, =:= will return false, even if the 2 containers have
appearances of the same value.
Both the === and eqv operators test the actual values of 2
containers, but that their semantics differ in regards to mutable
containers. Given an immutable container/type, such as a number or
Str or Seq, both will always return true if the values are the same.
With a mutable container, such as an Array, only eqv will return true
if the value is the same, and === will return false for 2 containers
having the same value.
The difference between === and eqv is that, if you have 2 symbols, $a
and $b, and $a === $b returns true, then that result is guaranteed to
be eternal if you don't assign to either symbol afterwards. For a
mutable type like an Array, === returns false on 2 containers because
it can't guarantee that someone else holding another symbol for
either container won't change its content, and so $a or $b could
change after we made the === test, without us causing that to happen,
and so for mutable types, === only returns true for 2 aliases,
because that is the most it can guarantee that they will be the same.
By contrast, eqv does not make the eternal guarantee, and works only
on snapshots, so eqv can safely deep-compare mutable types like
Arrays, since even if one of them changes afterwards, it doesn't
matter, since eqv only guaranteed them equal for that point in time
when it executed.
It is important for some applications to distinguish whether the
result of an equivalence test will be valid eternally or not, and
hence we have multiple analagous types and multiple equality tests,
where pairwise they distinguish eternally vs snapshot. We can say
exactly what we mean, and it is unambiguous, which is a GOOD thing.
-- Darren Duncan
