Re: Persistance of superpositions?
Date: Tue, 29 Oct 2002 15:57:56 -0800 (PST) From: Larry Wall [EMAIL PROTECTED] That's not a problem with builtins, but what about sub foo (); sub prefix:foo ($x); @a = [foo][1,2,3,4,5]; So how is this interpreted? Such syntactic ambiguity isn't nice. Should we go with the hyper interpretation, and say use: [foo].[1,2,3,4,5] For the other way. Wait... but that's no good! That's an infinite lookahead situation (is our parser one that cares?): [$foo.baz.bar.assuming(a = 1, b = 2, d = 4)] ^^ term? operator? i don't know. keep on parsing Oh! Operator! I think this ambiguity is prevalent enough to sit with the coder, considering other cases. How are we going to deal with this? Luke
Re: Persistance of superpositions?
Brian Ingerson wrote: Not quite. You also need to discriminate the *type* of the superposition: Oh right. I was thinking that Cany and friends were operations, not types. Oops. YAML type-URIs are made up of a type-family with an optional format: !domain.com/type#format and: !int is shorthand for: !yaml.org/int#dec So I'm wondering if any|all|one|none can be formats of !super? I guess so. But they're not really formats, so much as distinct types. And if so, should there be a default format? No. # !yaml.org/any letters: !any [a, b, c] Good. # !yaml.org/super#all digits: !super#all - 0 - 1 - 2 Bad. # !perl.yaml.org/one (Perl specific types) names: !perl/one [Brian, Ingy, Mr Inline] # (Yes, this dwims :) Ugly. (And it would probably have to be !perl6/one) # !perl.yaml.org/super-none (longer type name, no format) sane: !perl/super-none - Larry - Damian - Brian ... Urk. It might be more forward thinking to allow any|all|one|none into the yaml.org type repository. That's my view. Danmian
Re: Persistance of superpositions?
Buddha Buck wrote:
I was wondering...
How persistant are superpositions? How pervasive are they?
As I mentioned in a recent post, would expect them to be all-pervasive
and fully propagating.
I mean, will the following work?
I would certainly hope so! (modulo the syntax snafu)
In fact, it's hard to see how we could define superpositions sensibly and
yet have it could *not* work.
$letters = any('a'..'z');
$digits = any('0'..'9');
$ndaTable = {
start = { $letters = 'OneLetter',
$digits = 'OneDigit' }
OneLetter = { $letters = 'TwoLetter',
$digits = 'OneLetter'},
TwoLetter = { $letters = 'TriLetter,
$digits = 'TwoLetter'},
TriLetter = { $digits = 'TriLetter'),
OneDigit = { $letters = 'OneDigit',
$digits = 'TwoDigit'},
TwoDigit = { $letters = 'TwoDigit'}
}
for split(//,$instring) - $input {
That's a high-precdence Cerr there, partner. You meant:
for split(/null/,$instring) - $input {
$state = $ndaTable{$state}{$input};
last unless $state;
}
print Input string $instring has more than 3 letters and 2 digits\m
unless $state;
Damian
PS: Is anyone collecting these examples. It would make writing that perl.com
article much easier for me ;-)
Re: Persistance of superpositions?
On Tuesday, October 29, 2002, at 01:50 PM, Damian Conway wrote: PS: Is anyone collecting these examples. It would make writing that perl.com article much easier for me ;-) But of course! Piers is summarizing this entire thread -- right, Piers? :-) Aaron Crane wrote: x [+]= y; I guess that's OK looking, tho either is fine with me. However, I think we now need to vectorpause and hear from the eigenLarry (that is, let the superpositions of Larry collapse to a discrete state), before we superget ourselves too worked up on our eigensolution, here. EigenMikeL
Re: Persistance of superpositions?
On 30/10/02 08:36 +1100, Damian Conway wrote: Brian Ingerson wrote: Speaking of persistence, I just realized I'll need to start thinking about YAML serializations of superpositions. My first cut at it would be: --- letters: !super [0, 1, 2] digits: !super - 0 - 1 - 2 ... Not quite. You also need to discriminate the *type* of the superposition: Oh right. I was thinking that Cany and friends were operations, not types. Oops. YAML type-URIs are made up of a type-family with an optional format: !domain.com/type#format and: !int is shorthand for: !yaml.org/int#dec So I'm wondering if any|all|one|none can be formats of !super? And if so, should there be a default format? letters: !any [0, 1, 2] digits: !all - 0 - 1 - 2 names: !one [Brian, Ingy, Mr Inline] sane: !none - Larry - Damian - Brian ... Here are some options: --- # !yaml.org/any letters: !any [a, b, c] # !yaml.org/super#all digits: !super#all - 0 - 1 - 2 # !perl.yaml.org/one (Perl specific types) names: !perl/one [Brian, Ingy, Mr Inline] # (Yes, this dwims :) # !perl.yaml.org/super-none (longer type name, no format) sane: !perl/super-none - Larry - Damian - Brian ... It might be more forward thinking to allow any|all|one|none into the yaml.org type repository. !perl/glob is staying right where it is, thank you ;) Cheers, Brian
Re: Persistance of superpositions?
On Tue, 29 Oct 2002, Michael Lazzaro wrote:
:x [+]= y;
:
: I guess that's OK looking, tho either is fine with me.
My only syntactic quibble with [+] is that it's officially ambiguous
when it's a unary operator:
a = [+]b
could also be the start of
a = [+1, +2, +3]
Or worse:
sub x;
a = [x]b;
Except there isn't a unary Cx.
But I don't think that's a real problem. The other potential problem
is that we might get a bit of visual interference with real subscripts like
a[1.. :2] [+] b[1]
But that's probably okay. Another trouble spot is
a = [-][1,2,3,4,5];
That's not a problem with builtins, but what about
sub foo ();
sub prefix:foo ($x);
a = [foo][1,2,3,4,5];
And how soon till someone asks for
a = {$_ * 2}[1,2,3,4,5];
I kinda like the possibility of distinction between [+]= and [+=],
even if there isn't one really.
my Dog a [.]= new;
is also a bit clever.
As for getting back to ^ with xor, that's also pretty okay by me.
Oh, another thing in favor of [+] is that it's also a good place
to require a space before an infix
: However, I think we now need to vectorpause and hear from the
: eigenLarry (that is, let the superpositions of Larry collapse to a
: discrete state), before we superget ourselves too worked up on our
: eigensolution, here.
I like eigenstates about as much as Damian likes X.
Larry
