Persistance of superpositions?
Damian Conway
> 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:
letters: !any [0, 1, 2]
digits: !all
- 0
- 1
- 2
names: !one ["Brian", "Ingy", "Mr Inline"]
sane: !none
- "Larry"
- "Damian"
- "Brian"
...
Damian
Brian Ingerson
> I was wondering...
>
> How persistant are superpositions? How pervasive are they?
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
...
Cheers, Brian
Buddha Buck
How persistant are superpositions? How pervasive are they?
I mean, will the following 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 {
$state = $ndaTable{$state}{$input};
last unless $state;
}
print "Input string $instring has more than 3 letters and 2 digits\m"
unless $state;
Brian Ingerson
> On 29/10/02 16:05 -0500, Buddha Buck wrote:
> > I was wondering...
> >
> > How persistant are superpositions? How pervasive are they?
>
> 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]
letters: !super [a, b, c]
even!
Cheers, Brian
Damian Conway
> 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 C<err> 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 ;-)
Brian Ingerson
> 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 C<any> and friends were operations, not types.
Oops.
YAML type-URIs are made up of a type-family with an optional format:
and:
!int
is shorthand for:
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
Michael Lazzaro
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
Larry Wall
: > @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 C<x>.
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
Luke Palmer
> From: Larry Wall <la...@wall.org>
>
> 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
Piers Cawley
> 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? :-)
Piers is waiting for the thread to die down with some conclusions,
which he will then present as a masterful summary. Piers is also
running late with the summary for last week due to badness with laptop
power supplies and overarching laziness. It'll *maybe* be out for
Thursday.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Damian Conway
>>Not quite. You also need to discriminate the *type* of the superposition:
>
>
> Oh right. I was thinking that C<any> 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