Re: Wh<[ie]>ther Infix Superposition ops

[Markus Laire]

On 29 Oct 2002 at 5:45, Piers Cawley wrote:

> Whilst I don't wish to get Medieval on your collective donkey I must
> say that I'm really not sure of the utility of the proposed infix
> superposition ops. I'm a big fan of any/all/one/none, I just think
> that
> 
> one(any($a, $b, $c), all($d, $e, $f))
> 
> Is a good deal more intention revealing than the superficially
> appealing than
> 
> ($a & $b & $c) ^ ( $d | $e | $f )
> 
> which takes rather more decoding. And if you *do* want to use such
> operators, surely you could just do 
> 
> use ops ':superpositions';
> 
> in an appropriate lexical scope. Am I missing something?

In this case I find the latter to be easier to decode and more 
appealing. There are less chars and paretheses are seen much more 
easily. The 'one(...)' especially seems to be superficial, as it's 
just 'this or that' operation in this case, and so single operator 
fits perfectly.

Also the idea of allways using 'function' style for something so 
basic like superpositions doesn't appeal to me. Of course this might 
just be that I'm too used to use strange mathematical symbols. 
(Nobody ever understood my solutions in high-school...)

-- 
Markus Laire 'malaire' <[EMAIL PROTECTED]>

Re: Wh<[ie]>ther Infix Superposition ops

[Piers Cawley]

"Markus Laire" <[EMAIL PROTECTED]> writes:
> On 29 Oct 2002 at 5:45, Piers Cawley wrote:
>
>> Whilst I don't wish to get Medieval on your collective donkey I must
>> say that I'm really not sure of the utility of the proposed infix
>> superposition ops. I'm a big fan of any/all/one/none, I just think
>> that
>> 
>> one(any($a, $b, $c), all($d, $e, $f))
>> 
>> Is a good deal more intention revealing than the superficially
>> appealing than
>> 
>> ($a & $b & $c) ^ ( $d | $e | $f )
>> 
>> which takes rather more decoding. And if you *do* want to use such
>> operators, surely you could just do 
>> 
>> use ops ':superpositions';
>> 
>> in an appropriate lexical scope. Am I missing something?
>
> In this case I find the latter to be easier to decode and more 
> appealing. There are less chars and paretheses are seen much more 
> easily. The 'one(...)' especially seems to be superficial, as it's 
> just 'this or that' operation in this case, and so single operator 
> fits perfectly.
>
> Also the idea of allways using 'function' style for something so 
> basic like superpositions doesn't appeal to me. Of course this might 
> just be that I'm too used to use strange mathematical symbols. 
> (Nobody ever understood my solutions in high-school...)

But they *aren't* 'strange mathematical symbols', they're well
understood symbols in algol style programming languages, and they mean
'bitwise logic'. I'm not agin the using the operators to mean
'superposition builder', but I do think there's a case for having to
introduce them in a lexical scope with an appropriate USE statement.

-- 
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?

Re: Wh<[ie]>ther Infix Superposition ops

[Luke Palmer]

> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> From: Piers Cawley <[EMAIL PROTECTED]>
> Date: Tue, 29 Oct 2002 05:45:01 +
> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
> 
> Whilst I don't wish to get Medieval on your collective donkey I must
> say that I'm really not sure of the utility of the proposed infix
> superposition ops. I'm a big fan of any/all/one/none, I just think
> that
> 
> one(any($a, $b, $c), all($d, $e, $f))
> 
> Is a good deal more intention revealing than the superficially
> appealing than
> 
> ($a & $b & $c) ^ ( $d | $e | $f )
> 
> which takes rather more decoding. And if you *do* want to use such
> operators, surely you could just do 
> 
> use ops ':superpositions';
> 
> in an appropriate lexical scope. Am I missing something?

Uh huh.  This:

   if $x == 1 | 3 | 6 { print "Small triangular" }

I imagine it will not take long for these to sink in to people's
brains, and become used in very clever (and readable) ways.

If you read | as "or," and & as "and," instead of trying to translate
them to "any" and "all," things get very nice.

Plus, a scripting (or, in the case of P6, high level) language with
such small bitwise ops gives me the shivers.  C, sure, they're common.
Perl, no, not usually.  I was even dissatisfied with them in C++,
which is a high- low-level language.

Luke

Re: Perl6 Operator List, Take 3

[Juanma Barranquero]

On Mon, 28 Oct 2002 13:09:37 -0800 (PST), Larry Wall <[EMAIL PROTECTED]> wrote:

> How do your read $a ! $b ! $c?

"Neither $a nor $b nor $c".

What? Aren't you able to see this invisible "neither" operator just at
the front? ;-)


   /L/e/k/t/u

Re: perl6 operator precedence table

[Adam D. Lopresto]

This is exactly what I wanted .= for.

@array .= splice(2,0,$element);   # in-place, @array = @array.splice
@new = @array.splice(2,0,$element);

$sentence .= lcfirst;

The semantics are pretty clear, then it's just up to the compiler to optimize
it for in-place.  Perhaps functions could override the default 

method splice (...) {  #general function for making a new string

method splice (...) is inplace { #overloading to optimize for in-place

but that might be going a bit too far.

> I would, however, point out that other methods could
> potentially have modify-in-place and a copy-and-modify
> variants:
> 
>   @array.splice(2,0,$element);  # in-place
>   @new = @array.splice(2,0,$element);   # on copy
> 
>   $str.chomp;   # in-place
>   $new = $str.chomp;# on copy
> 
>   $str.lcfirst; # in-place
>   $new = $str.lcfirst;  # on copy
> 
>   @array.map({ %trans{$^a} });  # in-place
>   @new = @array.map({ %trans{$^a} });   # on copy
> 
> So we might want to look for a more general solution.
> 
> Unfortunately, one can't just generalize and use
> void/non-void context to determine the correct behaviour,
> since in-place matches and substitutions still need to
> return their match object:
> 
>   $matched = $str.replace(/foo/ -> { 'bar' });  # in-place
>   $newstr  = $str.replace(/foo/ -> { 'bar' });  # on copy
> 
> One could perhaps change the verb to a participle:
> 
>   @array.splice(2,0,$element);   # in-place
>   @new = @array.spliced(2,0,$element);   # on copy
> 
>   $str.chomp;# in-place
>   $new = $str.chomped;   # on copy
> 
>   $str.lcfirst;  # in-place
>   $new = $str.lcfirsted; # on copy
> 
>   @array.map({ %trans{$^a} });   # in-place
>   @new = @array.mapped({ %trans{$^a} }); # on copy
> 
>   $matched = $str.replace(/foo/ -> { 'bar' });   # in-place
>   $newstr  = $str.replaced(/foo/ -> { 'bar' });  # on copy
> 
> but I doubt that would be well accepted. ;-)
> 
> Or one could define a copy-the-invoke method call operator (say, C<+.>):
> 
>   @array.splice(2,0,$element);   # in-place
>   @new = @array+.splice(2,0,$element);   # on copy
> 
>   $str.chomp;# in-place
>   $new = $str+.chomp;# on copy
> 
>   $str.lcfirst;  # in-place
>   $new = $str+.lcfirst;  # on copy
> 
>   @array.map({ %trans{$^a} });   # in-place
>   @new = @array+.map({ %trans{$^a} });   # on copy
> 
>   $matched = $str.replace(/foo/ -> { 'bar' });   # in-place
>   $newstr  = $str+.replace(/foo/ -> { 'bar' });  # on copy
> 
> 
> > In typical topical string usage, that leaves us with
> > 
> > if .subst/a/b/  {...}
> > $result = .where/a/b/
> > 
> > That's quite livable, though the second is a bit odd, English-wise.
> > We could even keep around
> > 
> > s/a/b/
> > 
> > as a shorthand for .subst/a/b/.
> 
> Oh, I definitely think so!
> 
> 
> > And maybe even add
> > 
> > w/a/b/
> > 
> > as a synonym for .where/a/b/.
> 
> Hm. *s*ubstitute and *w*eplace. ;-)
> 
> Damian
> 

-- 
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/

I just want a plate and a fork and a bunny...

Re: perl6 operator precedence table

[Martin D Kealey]

On Tue, 29 Oct 2002, Damian Conway wrote:

> Or one could define a copy-the-invoke method call operator (say, C<+.>):

As a rule I prefer to see "safe" operations have short names and
"dangergous" operations with longer ones.  In this context that means "copy"  
gets the short name and "in place" gets the longer one.

So we should define that methods where possible return new values rather
than acting in-place, but define an apply-assignment operator (say C<.=>) to
use when you want to act in-place.  Of course, the methods can be made aware
of this so that they can optimise where appropriate.

  $str .= chomp;  # store result in-place
  $new = $old . chomp;# return resultant value

  $str .= lcfirst;# store result in-place
  $new = $old . lcfirst;  # return resultant value

  $str .= replace( /foo/ -> {'bar'} );
  $new = $old . replace( /foo/ => { 'bar' } );

Unfortunately that sits badly with things that "return" two non-scalars
(such as "splice" resulting in an portion excised and a remainder) because
it means that this assignment operator doesn't return the "resulting value"  
the way that other assignment operators do.

Also having the in-place version return something different from the copy 
version would be non-obvious to neophites, but that's a problem no matter 
what notation is used.

  @excised = @array .= splice($position,$count,@insertions);

vs

  @excised = @array . slice($position,$count);
  @unexcised = @array . splice($position,$count,@insertions);

So, in

  @a = @b .= grep {/foo/};

should @a be the elements that I contain "foo" or those that I?

-Martin

Re: Wh<[ie]>ther Infix Superposition ops

[Piers Cawley]

Luke Palmer <[EMAIL PROTECTED]> writes:

>> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
>> From: Piers Cawley <[EMAIL PROTECTED]>
>> Date: Tue, 29 Oct 2002 05:45:01 +
>> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
>> 
>> Whilst I don't wish to get Medieval on your collective donkey I must
>> say that I'm really not sure of the utility of the proposed infix
>> superposition ops. I'm a big fan of any/all/one/none, I just think
>> that
>> 
>> one(any($a, $b, $c), all($d, $e, $f))
>> 
>> Is a good deal more intention revealing than the superficially
>> appealing than
>> 
>> ($a & $b & $c) ^ ( $d | $e | $f )
>> 
>> which takes rather more decoding. And if you *do* want to use such
>> operators, surely you could just do 
>> 
>> use ops ':superpositions';
>> 
>> in an appropriate lexical scope. Am I missing something?
>
> Uh huh.  This:
>
>if $x == 1 | 3 | 6 { print "Small triangular" }
>
> I imagine it will not take long for these to sink in to people's
> brains, and become used in very clever (and readable) ways.

So, if that's the way you're going to be using | in your code, just do
C at the top of your file, in the same way
as you do C now. Or wrap it up in a policy file and do
C. 

> If you read | as "or," and & as "and," instead of trying to translate
> them to "any" and "all," things get very nice.

Again, I'm not denying the usefulness, just worried that we're jumping
through an awful lot of more or less ugly and complex syntactic hoops
to get this particular chunk of behaviour into perl 6, when you could,
instead, allow the behaviour to be pragma selectable without bending
the rest of the syntax to accommodate.

> Plus, a scripting (or, in the case of P6, high level) language with
> such small bitwise ops gives me the shivers.  C, sure, they're common.
> Perl, no, not usually.  I was even dissatisfied with them in C++,
> which is a high- low-level language.

Catch is, they're there now and useful, especially when you start
dealing with the outside world (C  anyone?) 

-- 
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?

Re: Wh<[ie]>ther Infix Superposition ops

[Luke Palmer]

> Cc: [EMAIL PROTECTED]
> From: Piers Cawley <[EMAIL PROTECTED]>
> Date: Tue, 29 Oct 2002 09:36:12 +
> 
> Luke Palmer <[EMAIL PROTECTED]> writes:
> 
> >> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> >> From: Piers Cawley <[EMAIL PROTECTED]>
> >> Date: Tue, 29 Oct 2002 05:45:01 +
> >> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
> >> 
> >> Whilst I don't wish to get Medieval on your collective donkey I must
> >> say that I'm really not sure of the utility of the proposed infix
> >> superposition ops. I'm a big fan of any/all/one/none, I just think
> >> that
> >> 
> >> one(any($a, $b, $c), all($d, $e, $f))
> >> 
> >> Is a good deal more intention revealing than the superficially
> >> appealing than
> >> 
> >> ($a & $b & $c) ^ ( $d | $e | $f )
> >> 
> >> which takes rather more decoding. And if you *do* want to use such
> >> operators, surely you could just do 
> >> 
> >> use ops ':superpositions';
> >> 
> >> in an appropriate lexical scope. Am I missing something?
> >
> > Uh huh.  This:
> >
> >if $x == 1 | 3 | 6 { print "Small triangular" }
> >
> > I imagine it will not take long for these to sink in to people's
> > brains, and become used in very clever (and readable) ways.
> 
> So, if that's the way you're going to be using | in your code, just do
> C at the top of your file, in the same way
> as you do C now. Or wrap it up in a policy file and do
> C. 

Heh, I don't C... or C.  :)

As far as frequency goes, though, I think C would
would be more needed.  I mean I'm not sure of that: I'm using a sample
size of 1.  But that's my best guess.

You have a point.  The larger programs will make use of the
superpositions, and the smaller ones will make use of the bitwises.
Better to make the bigger programs use pragmas, and the little ones be
one-linerable.  But who knows, superpositions could often be useful in
scripts, too:

 find | perl -nle 'print join "\n", (s+\.++ | s/~$//).states'

Ok, that was a terrible example.  But you know what I mean

> > Plus, a scripting (or, in the case of P6, high level) language with
> > such small bitwise ops gives me the shivers.  C, sure, they're common.
> > Perl, no, not usually.  I was even dissatisfied with them in C++,
> > which is a high- low-level language.
> 
> Catch is, they're there now and useful, especially when you start
> dealing with the outside world (C  anyone?) 

Hopefully there won't be a need for that C stuff.  The I/O
system better be good enough to allow me to specify those flags
without "jumping through syntactc hoops" in terms of those ugly C
constants.

Plus, who says C and C can't just be constants, and
C   a superposition of them.  It could mean the same
thing :)

Additionally, bitwise ops sure are useful... in a small amout of code.
Three or four lines per program.  That's why we're not getting rid of
them, just making them longer.  Superpositions will turn out to be
unimaginably handy, possibly used in 10% or 15% of the code, so they
get shorter names.

In my mind, Perl is stepping away from being a direct derivative of C;
rather, a derivative of Perl.  And it doesn't seem that the bitwise
ops are used enough anymore to get a single character.  If they get a
single character, surely =~ (~~) should have one.

Luke

Re: Wh<[ie]>ther Infix Superposition ops

[Simon Cozens]

[EMAIL PROTECTED] (Markus Laire) writes:
> In this case I find the latter to be easier to decode and more 
> appealing. There are less chars and paretheses are seen much more 
> easily.

Ack, I guess that means we need a one character DWIM operator.
Although "..." comes pretty close, I suppose.

> something so basic like superpositions

Now I'm just scared.

-- 
I knew that a goodly number of train operating companies had
introduced quiet coaches, but I was still a little concerned
to find that my tickets were prominently marked NOT READING.
- Geraint Jones

Re: Wh<[ie]>ther Infix Superposition ops

[Austin Hastings]

--- Piers Cawley <[EMAIL PROTECTED]> wrote:
> >> 
> >> one(any($a, $b, $c), all($d, $e, $f))
> >> 
> >> Is a good deal more intention revealing than the superficially
> >> appealing than
> >> 
> >> ($a & $b & $c) ^ ( $d | $e | $f )

Would it be practical/meaningful to say

$result = bitwise ($a & $b & $c) ^ ($d | $e | $f);
$result = superpose ($a & $b & $c) ^ ($d | $e | $f);

And allow a use operation to select defaulting behavior? (With an
appropriate warning if the code used one of these operators without
specifying the use directive, even though  is the default?)

[ But it's crucial not to require more quotes and stuff. Just change
the mode for the remainder of the subexpression. ]

=Austin


__
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/

Re: Wh<[ie]>ther Infix Superposition ops

[Jonathan Scott Duff]

On Tue, Oct 29, 2002 at 03:06:51AM -0700, Luke Palmer wrote:
> Superpositions will turn out to be unimaginably handy, possibly used
> in 10% or 15% of the code, so they get shorter names.

Statements like this bother me.  Not because I don't think it might be
true, but because it's in future tense. If someone (named Damian :-)
wrote a superposition synopsis that showed the many and varied uses of
superpositions in contexts that ordinary programmers can relate to, it
would bother me less when people make claims about the usefulness of
superpositions.

I mean, if superpositions are so useful, who's using them now?  How many
modules on CPAN require them? Why hasn't the word spread like
wildfire about them such that your average sysadmin is using them in
his code? I don't know of anyone using superpositions casually or in
production code.

> In my mind, Perl is stepping away from being a direct derivative of C;
> rather, a derivative of Perl.  And it doesn't seem that the bitwise
> ops are used enough anymore to get a single character.  If they get a
> single character, surely =~ (~~) should have one.

I agree.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: Wh<[ie]>ther Infix Superposition ops

[Simon Cozens]

[EMAIL PROTECTED] (Jonathan Scott Duff) writes:
> Statements like this bother me.  Not because I don't think it might be
> true, but because it's in future tense. If someone (named Damian :-)
> wrote a superposition synopsis that showed the many and varied uses of
> superpositions in contexts that ordinary programmers can relate to, it
> would bother me less when people make claims about the usefulness of
> superpositions.

I'll take one of those for perl.com!
 
> I mean, if superpositions are so useful, who's using them now?  How many
> modules on CPAN require them? Why hasn't the word spread like
> wildfire about them such that your average sysadmin is using them in
> his code? I don't know of anyone using superpositions casually or in
> production code.

I was very tempted to use a superposition in production code, but realised
a grep of an array did the same job.

-- 
Oh dear. I've just realised that my fvwm config lasted longer than my
marriage, in that case.
- Anonymous

Re: Wh<[ie]>ther Infix Superposition ops

[Jonathan Scott Duff]

On Tue, Oct 29, 2002 at 10:13:39AM +0200, Markus Laire wrote:
> Also the idea of allways using 'function' style for something so 
> basic like superpositions doesn't appeal to me. 

Superpositions are "basic" in a fabric-of-the-universe kind of way, but
they are hardly basic in the everyone-learns-them-in-grade-school kind
of way. I think the latter is more important for huffman coding of
operators for the unwashed masses. But I'm willing change my mind if we
start teaching everyone superpositions in grade school :-)

Or if someone can show that they aren't really something new and
amazing, but something old and comfortable but with a funny name and
more power.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: Wh<[ie]>ther Infix Superposition ops

[Piers Cawley]

Simon Cozens <[EMAIL PROTECTED]> writes:

> [EMAIL PROTECTED] (Jonathan Scott Duff) writes:
>> Statements like this bother me.  Not because I don't think it might be
>> true, but because it's in future tense. If someone (named Damian :-)
>> wrote a superposition synopsis that showed the many and varied uses of
>> superpositions in contexts that ordinary programmers can relate to, it
>> would bother me less when people make claims about the usefulness of
>> superpositions.
>
> I'll take one of those for perl.com!

I keep meaning to look into nondeterministic algorithms to see if you
can use Superpositions to get them working...

-- 
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?

Re: Wh<[ie]>ther Infix Superposition ops

[Dan Sugalski]

At 11:22 AM -0600 10/29/02, Jonathan Scott Duff wrote:

On Tue, Oct 29, 2002 at 10:13:39AM +0200, Markus Laire wrote:

 Also the idea of allways using 'function' style for something so
 basic like superpositions doesn't appeal to me.


Superpositions are "basic" in a fabric-of-the-universe kind of way, but
they are hardly basic in the everyone-learns-them-in-grade-school kind
of way. I think the latter is more important for huffman coding of
operators for the unwashed masses. But I'm willing change my mind if we
start teaching everyone superpositions in grade school :-)


Perhaps the best thing to do is to define a word operator for 
superpositions and, if they later become really popular, snag some 
generally-available* extended character to represent the operators.


*Generally available meaning in all of the Shift-JIS, Big5, and 
Unicode sets, assuming there are some that aren't Kanji
--
Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Wh<[ie]>ther Infix Superposition ops

[Larry Wall]

On Tue, 29 Oct 2002, Austin Hastings wrote:
: --- Piers Cawley <[EMAIL PROTECTED]> wrote:
: > >> 
: > >> one(any($a, $b, $c), all($d, $e, $f))
: > >> 
: > >> Is a good deal more intention revealing than the superficially
: > >> appealing than
: > >> 
: > >> ($a & $b & $c) ^ ( $d | $e | $f )

First I would like to point out that the & and | are backwards there
from the original.  & means all(), and | means any().

: Would it be practical/meaningful to say
: 
: $result = bitwise ($a & $b & $c) ^ ($d | $e | $f);
: $result = superpose ($a & $b & $c) ^ ($d | $e | $f);
: 
: And allow a use operation to select defaulting behavior? (With an
: appropriate warning if the code used one of these operators without
: specifying the use directive, even though  is the default?)

All other things being equal, I think people will find modal operators
more confusing than if we just make separate operators.

That being said, I'm still wondering whether we can finesse it.  Damian's
default any() semantics in numeric context select a random element.  If
we made that not the default, we could have an alternate default semantics
in numeric (or, at least, integer) context.  So suppose we introduce for
the "pick one" semantics an explicit verb named, oddly enough, pick().

my int $foo = pick( 1 | 2 | 4 );# $foo gets (1,2,4)[rand 3]
my int $bar = 1 | 2 | 4;# $bar gets 7

People can be scared if they like, but I am also of the opinion that
superpositions are more "basic" than bitops, at least in a sense.
My reasoning for that is that they don't commit to an interpretation
prematurely.  A 1 | 2 | 4 means "a 1, a 2, or a 4", nothing more.
You can make other things out of a superposition depending on the
context.  Damian already made them mean two different things in numeric
vs string context.  We could possibly make them mean more things.

So I wonder about whether, in

$result = superpose ($a & $b & $c) ^ ($d | $e | $f);

the "superpose" is really a no-op.  If you go on to say

my int $foo = pick( $result );  # random element filling "contract"
my int $bar = $result;  # bitwise

then the superposition would collapses as specified.

There is one little difficulty with this approach, though.  It would
have to retroactively change the meaning of non-powers-of-two.  That is,
if you say

$mask = 7;
$somebits = 1 | 2;
my int $foo = $somebits & $mask;

then at the point of wave-function collapse, the 7 from $mask has to
be re-interpreted as a 1|2|4.  Maybe that's okay, and maybe it isn't.
>From a transactional view of QM, it's probably fine, since that view
allows for sending information back through time to entangled partners.
It's also fine from a tagmemics point of view, I think, since context
can change the meaning of both nouns and verbs.

Actually, I suppose that in contrast to int context, num context
could pick() by default.  And str context could do strbitops.
Or it could do the currently specified str default of listing out
the whole shebang.  That's probably more user-friendly when you print
out error messages, so I expect stringwise bitop collapse would have
to be requested explicitly.  Or we need to have a bitstring type, or
some such.  There are other places where distinguishing data strings
from human-readable strings would be useful.

Larry

Re: Wh<[ie]>ther Infix Superposition ops

[Larry Wall]

On Tue, 29 Oct 2002, Dan Sugalski wrote:
: Perhaps the best thing to do is to define a word operator for 
: superpositions and, if they later become really popular, snag some 
: generally-available* extended character to represent the operators.

Sorry, I believe in the transactional model of QM, and the future
has already reached back in time and grabbed | and &.   :-)

: *Generally available meaning in all of the Shift-JIS, Big5, and 
: Unicode sets, assuming there are some that aren't Kanji

I believe & and | already satisfy that particular constraint.  :-)

So does X, for that matter.

Now, we'd be in real trouble if we'd picked \ for xor, since that's
the yen sign in Japanese.

Larry

Re: Wh<[ie]>ther Infix Superposition ops

[Larry Wall]

On Tue, 29 Oct 2002, Jonathan Scott Duff wrote:
: On Tue, Oct 29, 2002 at 10:13:39AM +0200, Markus Laire wrote:
: > Also the idea of allways using 'function' style for something so 
: > basic like superpositions doesn't appeal to me. 
: 
: Superpositions are "basic" in a fabric-of-the-universe kind of way, but
: they are hardly basic in the everyone-learns-them-in-grade-school kind
: of way. I think the latter is more important for huffman coding of
: operators for the unwashed masses. But I'm willing change my mind if we
: start teaching everyone superpositions in grade school :-)

That won't happen, because they don't *have* to be taught in grade
school.  You learn any() and all() as part of language before you
ever get to grade school.  What kindergartener can't understand a
logically entangled list of nouns?

I want a tricycle or a video game or a teddy bear for Christmas.
I want a tricycle and a video game and a teddy bear for Christmas.

That's no different from:

$self.want($tricycle | $video_game | $teddy_bear);
$self.want($tricycle & $video_game & $teddy_bear);

Logically entangle nouns *are* more basic than grade school.  Kids are
even sophisticated enough to disambiguate "xor" from "or" by context,
despite the fact that English has no "xor" operator:

Which do you want?  A popsicle or a Mickey Mouse hat?

That's something like:

$you.pick($popsicle X $hat);

: Or if someone can show that they aren't really something new and
: amazing, but something old and comfortable but with a funny name and
: more power.

Well, "quantum superpositions" really is a very funny name.  I've been
reducing that to "super" lately, but even that's misleading, because
it's hard to think of something "super" as basic.  I prefer to think
of them as logically related nouns like we use all the time in English.
Logic for nouns rather than verbs.  Something a toddler can understand.

So I would look favorably on finding a replacement for "superposition".

Larry

Re: Wh<[ie]>ther Infix Superposition ops

[Michael Lazzaro]

On Tuesday, October 29, 2002, at 09:08  AM, Jonathan Scott Duff wrote:

Statements like this bother me.  Not because I don't think it might be
true, but because it's in future tense. If someone (named Damian :-)
wrote a superposition synopsis that showed the many and varied uses of
superpositions in contexts that ordinary programmers can relate to, it
would bother me less when people make claims about the usefulness of
superpositions.


I think superpositions will, indeed, be extensively used, but I don't 
think they'll be called "superpositions" by most of the people that use 
them.  They're typically used more like "set operations".  Something as 
basic as

	if any($x,$y,$z) > 10  # if ($x | $y | $z) > 10

is pretty useful, even in simple code.  As is

 my $n = (1..100) | "don't care";

The collapsification to a discrete value would, I imagine, be typically 
used to select a random entry from a set.

	my $r = any(@set);
	print $r;  # assuming this _does_ collapse

And I'm *really* looking forward to having union/intersection 
operations, because it solves lots of the typical Cookbook recipes for 
lists and hashes as one-liners.

This is why I am nervous about introducing terms like eigenbunny, etc., 
into the general vocabulary of the language.  It attempts to make it 
sound harder than it is, I think -- there are plenty of uses for these 
operators outside the "collapsing" dynamics they allow.  If we focus 
first on an explanation that does not take directly from quantum 
mechanics, but rather sort of ...slide... into the QM meanings after 
explaining the more easily understood "set" meanings, I think it will 
be quite quickly adopted by newbies.

MikeL

Re: Wh<[ie]>ther Infix Superposition ops

[Simon Cozens]

[EMAIL PROTECTED] (Larry Wall) writes:
> So I would look favorably on finding a replacement for "superposition".

Predicate calculus? :) Seriously, I see no problem with calling them 
"set operators".

-- 
For true believers, LORD would be K\textsc{nuth} in TeX, and
L\textsc{amport} in LaTeX. Atheists prefer \phantom{LORD}. Agnostics
may need to use the ifthen package.
 - Chris Boyd, comp.text.tex

RE: Wh<[ie]>ther Infix Superposition ops

[Garrett Goebel]

From: Simon Cozens [mailto:simon@;ermine.ox.ac.uk]
> [EMAIL PROTECTED] (Larry Wall) writes:
> > So I would look favorably on finding a replacement for 
> > "superposition".
> 
> Predicate calculus? :) Seriously, I see no problem with
> calling them "set operators".

Great minds think alike. Or in this case even me ;)  I was just describing
superpositions as set operations to one of our developers... 

I'm left wondering what the relationship between Perl6 and relational
databases will be. Where one will leave off and the other will begin.

--
Garrett Goebel
IS Development Specialist

ScriptPro   Direct: 913.403.5261
5828 Reeds Road   Main: 913.384.1008
Mission, KS 66202  Fax: 913.384.2180
www.scriptpro.com  [EMAIL PROTECTED]

Re: Perl6 Operator List, TAKE 4

[Michael Lazzaro]

On Monday, October 28, 2002, at 01:25  PM, Michael Lazzaro wrote:

Again, I'm wondering if we're going about this wrong way -- perhaps we 
need to go to more effort to save ^ as xor, and use something 
different for hypers, like h<+> or h[+] or `+ or ~+ or ~~+, etc?

OK, I'm calling "Warnock's" on this one.  Is this just so far-fetched 
that nobody's touching it with a ten foot pole, or am I missing 
something, or ?

I know this was dealt with many months ago, but that was before we 
changed ~ to stringify, making the xor situation worse.  Isn't there 
any way to keep ^, since we've just stated that the super meaning "one" 
($a ^ $b ^ $c) is actually a worthwhile concept?  (Yes, we would also 
need to think about altering { $^a op $^b }  in the same way.)

I'll shut up now on this one.  But nobody's taking the bait, eh?

MikeL

Re: Wh<[ie]>ther Infix Superposition ops

[Dan Sugalski]

At 10:02 AM -0800 10/29/02, Larry Wall wrote:

On Tue, 29 Oct 2002, Dan Sugalski wrote:
: Perhaps the best thing to do is to define a word operator for
: superpositions and, if they later become really popular, snag some
: generally-available* extended character to represent the operators.

Sorry, I believe in the transactional model of QM, and the future
has already reached back in time and grabbed | and &.   :-)


Well, I suppose when people use them as bitwise operators they won't 
be any more confusingly wrong then they often are now...

: *Generally available meaning in all of the Shift-JIS, Big5, and
: Unicode sets, assuming there are some that aren't Kanji

I believe & and | already satisfy that particular constraint.  :-)

So does X, for that matter.


I was thinking more of the double-vertical bar or one of the stars. I 
admit I'm really not sure that the quantum operations will be used 
enough to warrant blowing people's expectations of bitwise 
operations, even if the bitwise operations aren't used that much. Not 
my call, though--it's all assembly as far as I'm concerned. :)
--
Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Wh<[ie]>ther Infix Superposition ops

[Brian Ingerson]

On 29/10/02 09:58 -0800, Larry Wall wrote:
> On Tue, 29 Oct 2002, Jonathan Scott Duff wrote:
> : On Tue, Oct 29, 2002 at 10:13:39AM +0200, Markus Laire wrote:
> 
> So I would look favorably on finding a replacement for "superposition".

How about "christmasgift" or "gift"? 

You don't know what it is until you open it. It could be any, all or none of
what you expected.

How about "envelope"? (noun)

Or better yet "pocket". What has it gots in its pocketses my precious?

To keep that QM feel you could call it a "hotpocket".

Cheers, Brian

Re: Wh<[ie]>ther Infix Superposition ops

[Jonathan Scott Duff]

On Tue, Oct 29, 2002 at 10:22:36AM -0800, Michael Lazzaro wrote:
> This is why I am nervous about introducing terms like eigenbunny, etc., 
> into the general vocabulary of the language.  It attempts to make it 
> sound harder than it is, I think -- there are plenty of uses for these 
> operators outside the "collapsing" dynamics they allow.  

I like the eigen- prefix. It adds to the unique flavor of perl jargon 
(where else will you see the term "sigil" bandied about?). If we called
yadda*3 "gedanken code" that wouldn't bother me either. :-)

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: Wh<[ie]>ther Infix Superposition ops

[Jonathan Scott Duff]

On Tue, Oct 29, 2002 at 11:12:28AM -0800, Brian Ingerson wrote:
> On 29/10/02 09:58 -0800, Larry Wall wrote:
> > On Tue, 29 Oct 2002, Jonathan Scott Duff wrote:
> > : On Tue, Oct 29, 2002 at 10:13:39AM +0200, Markus Laire wrote:
> > 
> > So I would look favorably on finding a replacement for "superposition".
> 
> How about "christmasgift" or "gift"? 
> 
> You don't know what it is until you open it. It could be any, all or none of
> what you expected.

Then we should definitely call it "cat"  ;-)

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Perl6 Operator List, Damian's take

[Damian Conway]

Oh boy, I just *hate* the idea of C for xor.
Hate it, hate it, hate it! Yuck, yuck, yuck!

But I do like Michael's idea of using C<@> as the hyperoperator marker
(the array connotation works well, I think). The only problem is that
we end up with too many C<@>'s in most expressions:

	$count = @a + @b;
	@sums  = @a @+ @b;


My personal favorite solution is to use square brackets (for their dual
array and indexing connotations, and because they highlight the operator
so nicely):

	$count = @a + @b;
	@sums  = @a [+] @b;


I also think that binary C as a none-ary superposition compositor is
a mistake. And that C and C would be even bigger ones. That's
because something like:

	if $x ! $y ! $z { ... }
or:
	if $x !! $y !! $z { ... }

is surreptitiously negative. Specifically, it's that missing "neither"
in from of the first operand that niggles. I'd much rather people had
to write one of these:

	if !($x || $y || $z) { ... }

	unless $x || $y || $z { ... }


With that in mind, by freeing up C<^> to resume its original xorish duties,
we get:


	unary (prefix) operators:
	
	  ! - force to bool context, negate
	
	  ~ - force to string context
	
	  +^- force to numeric context, complement
	  ~^- force to string context, complement
	
	
	hyperoperators:
	
	  [op] - around any unary/binary operator, "vectorizes" the operator
	
	binary operators:
	
	  ~ - string concatenation
	  ~=- string append
	
	  &&||^^//  - boolean operations
	  &&=   ||=   ^^=   //=
	  and   orxor   err
	
	  +&+|+^<<>>- bitwise operations
	  +&=   +|=   +^=   <<=   >>=
	
	  ~&~|~^- charwise operations
	  ~&=   ~|=   ~^=
	
	  ?&?|?^- [maybe] C-like bool operations
	  ?&=   ?|=   ?^=   - (result is always just 1 or 0)
	
	   & | ^- superpositional operations
	   &=|=^=   - conjunctive, disjunctive, exclusive
	  all   any   one   none- conjunctive, disjunctive, exclusive, dismissive

  ~~  !~- smart match, smart non-match


Damian

Re: Wh<[ie]>ther Infix Superposition ops

[David Wheeler]

On Tuesday, October 29, 2002, at 09:58  AM, Larry Wall wrote:


  What kindergartener can't understand a
logically entangled list of nouns?

I want a tricycle or a video game or a teddy bear for Christmas.
I want a tricycle and a video game and a teddy bear for Christmas.

That's no different from:

$self.want($tricycle | $video_game | $teddy_bear);
$self.want($tricycle & $video_game & $teddy_bear);


I think that this (and the remainder of your message) is a beautiful 
demonstration of the utility of the superposition operators. I notice 
that the naysayers suddenly quieted down after this message.

So I would look favorably on finding a replacement for "superposition".


Well, I like "set operators," too, but what's the grammatical term for 
the above "logically entangled list of nouns"?

Regards,

David

--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/  Yahoo!: dew7e
   Jabber: [EMAIL PROTECTED]

Re: Wh<[ie]>ther Infix Superposition ops

[Austin Hastings]

I think this may be in response to an earlier message of yours looking
for a replacement for "superposition." But I recall getting a Dilbert
calendar for Xmas some years back with a cover featuring the PHB saying
"I'm not indecisive - I'm flexible!"

Thus, flexops. And flexpressions (flexprs, for short). With
operator:flexible|, operator:flexible&, and operator:flexible^.

And 

  $result = flexible ($a & $b & $c) ^ ($d | $e | $f);

instead of
 
  $result = bitwise ($a & $b & $c) ^ ($d | $e | $f);

(Of course, flexprs are the default, so you won't need to specify that.
See below.)

--- Larry Wall <[EMAIL PROTECTED]> wrote:
> On Tue, 29 Oct 2002, Austin Hastings wrote:
> : --- Piers Cawley <[EMAIL PROTECTED]> wrote:
> : > >> 
> : > >> one(any($a, $b, $c), all($d, $e, $f))
> : > >> 
> : > >> Is a good deal more intention revealing than the superficially
> : > >> appealing than
> : > >> 
> : > >> ($a & $b & $c) ^ ( $d | $e | $f )
> 
> First I would like to point out that the & and | are backwards there
> from the original.  & means all(), and | means any().

Which implies, since no one else has pointed this out, that
 is not as clear as .

(FYI: The little <>'s around -style descriptors is shorthand for some
sort of Saturday afternoon "Kung Fu Theatre" combat pose. As in, "Your
 is no match for my . My sister will be
avenged!")

> 
> : Would it be practical/meaningful to say
> : 
> : $result = bitwise ($a & $b & $c) ^ ($d | $e | $f);
> : $result = superpose ($a & $b & $c) ^ ($d | $e | $f);
> : 
> : And allow a use operation to select defaulting behavior? (With an
> : appropriate warning if the code used one of these operators without
> : specifying the use directive, even though  is the
> default?)
> 
> All other things being equal, I think people will find modal
> operators
> more confusing than if we just make separate operators.

To quote Rene Descartes, "I think not! (poof!)"

>From what everyone has chipped in thus far, the discussion is between
the "conservatives" who feel that since everyone knows 'C', we should
keep the 'C' operator semantics when possible, and the "avant garde"
who feel that "bitops are dead, long live flexops!"

Frankly, I have a hard time imagining a perl program where bitops are
generally useful. (In functions, yes. But will they permeate the
code?)On the other hand, flexops may well be. So I propose that we give
the "nervous" types a way to clearly specify both, and provide a
default (). 

There's no going back, of course. But the ability to give warnings on
unspecific ops and the ability to override the default should satisfy
the conservatives long enough to get them addicted to qrack..

> That being said, I'm still wondering whether we can finesse it. 
> Damian's
> default any() semantics in numeric context select a random element. 
> If
> we made that not the default, we could have an alternate default
> semantics
> in numeric (or, at least, integer) context.  So suppose we introduce
> for
> the "pick one" semantics an explicit verb named, oddly enough,
> pick().
> 
> my int $foo = pick( 1 | 2 | 4 );  # $foo gets (1,2,4)[rand 3]
> my int $bar = 1 | 2 | 4;  # $bar gets 7

It seems to me that flexible results are more like NaN than anything
else. Once they go into an expression, they corrupt the expression.

my $var = 1 | 3;
print $var * 2 - 1;

Should print something like:

ANY-SCALAR(1|5)

Or perhaps it should give a warning:

"Doubleplusungood: Eigenbunny at line 3. Scalar expected." 

> People can be scared if they like, but I am also of the opinion that
> superpositions are more "basic" than bitops, at least in a sense.
> My reasoning for that is that they don't commit to an interpretation
> prematurely.  A 1 | 2 | 4 means "a 1, a 2, or a 4", nothing more.
> You can make other things out of a superposition depending on the
> context.  Damian already made them mean two different things in
> numeric
> vs string context.  

Can I say 

bitwise $str ^~^= 16:20 x ...;  # Each chr in $str xor= shift;

to change case? Or is one ^ enough? (Admittedly an ASCII hack, but ..)

> So I wonder about whether, in
> 
> $result = superpose ($a & $b & $c) ^ ($d | $e | $f);
> 
> the "superpose" is really a no-op.  

I don't think so. Or at least, if it is, I'm not sure how to deal with
it. Because I fear trying to mix "eval" and whatever parser magic is
implied below. And if you don't do that, then there's property-creation
going on which will upscrew the optimizer, I think. (See next para
below.)

> If you go on to say
> 
> my int $foo = pick( $result );# random element filling
> "contract"
> my int $bar = $result;# bitwise
> 
> then the superposition would collapses as specified.


What do you do for actions at a distance. That is, you say my int $foo
= (3 | 4); here, and return $foo, and store it away in a hash, and some
time later, possibly in a different module written months earlier, take
that value OUT of that hash (or, worse, read it

Re: Perl6 Operator List, Damian's take

[Michael Lazzaro]

On Tuesday, October 29, 2002, at 11:21  AM, Damian Conway wrote:

My personal favorite solution is to use square brackets (for their dual
array and indexing connotations, and because they highlight the 
operator
so nicely):

	$count = @a + @b;
	@sums  = @a [+] @b;

Any ideas on what

	{ $^a op $^b }

would become?

MikeL

Re: Perl6 Operator List, Damian's take

[Uri Guttman]

> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:

  DC> Oh boy, I just *hate* the idea of C for xor.
  DC> Hate it, hate it, hate it! Yuck, yuck, yuck!

tell us how you _really_ feel! :-)

  DC> My personal favorite solution is to use square brackets (for their dual
  DC> array and indexing connotations, and because they highlight the operator
  DC> so nicely):

  DC>   $count = @a + @b;
  DC>   @sums  = @a [+] @b;

  DC> [op] - around any unary/binary operator, "vectorizes" the operator

that is actually very neat IMO. it does read well and makes sense too.


  DC>   unary (prefix) operators:

  DC> ! - force to bool context, negate

  DC> ~ - force to string context

  DC> +^- force to numeric context, complement
  DC> ~^- force to string context, complement

what is a string complement? bitwise? i take it the numeric is one's
complement.

  DC>   binary operators:

  DC> ~ - string concatenation
  DC> ~=- string append

what happens to _?

  DC> &&||^^//  - boolean operations
  DC> &&=   ||=   ^^=   //=
  DC> and   orxor   err

  DC> +&+|+^<<>>- bitwise operations
  DC> +&=   +|=   +^=   <<=   >>=

i would add the word integer there. they do bitwise math on the integer
part of a scalar value.

  DC> ~&~|~^- charwise operations
  DC> ~&=   ~|=   ~^=

and these do bitwise operations but on the string part of a
scalar. charwise isn't the best name for that.


  DC> ?&?|?^- [maybe] C-like bool operations
  DC> ?&=   ?|=   ?^=   - (result is always just 1 or 0)

hmm.

  DC>~~  !~- smart match, smart non-match

is that also bind for tr///?

uri

-- 
Uri Guttman  --  [EMAIL PROTECTED]   http://www.stemsystems.com
- Stem and Perl Development, Systems Architecture, Design and Coding 
Search or Offer Perl Jobs    http://jobs.perl.org

Re: Perlmasons. Be the first on your block to join...

[Austin Hastings]

Can we have a secret handshake, too? Will we be blamed for the secret
features of the new US dollar bill? 

"You know that eye-in-the-pyramid looking thingy? Well, notice what
character on the COMPUTER KEYBOARD that looks like? It's not by
coincidence that many of the programmers at the Treasury Dept. are
PERLMASONS! IT'S A CONSPIRACY!!!"

And it's mostly Bavarian (German)-sounding. Better and better.

I'd prefer to be the Gnomes of Zurich, but I suppose I can play a
Discordian. 

Markoff Cheney


--- Jonathan Scott Duff <[EMAIL PROTECTED]> wrote:
> I like the eigen- prefix. It adds to the unique flavor of perl jargon
> (where else will you see the term "sigil" bandied about?). If we
> called yadda*3 "gedanken code" that wouldn't bother me either. :-)


__
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/

Re: Perl6 Operator List, Damian's take

[Damian Conway]

Michael Lazzaro wrote:


Any ideas on what

{ $^a op $^b }

would become?


It would be unchanged. Placeholders have nothing to do with hyperoperators.
And never have had.

Damian

Re: Perl6 Operator List, Damian's take

[Luke Palmer]

> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Date: Tue, 29 Oct 2002 11:36:20 -0800
> Cc: [EMAIL PROTECTED]
> From: Michael Lazzaro <[EMAIL PROTECTED]>
> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
> 
> 
> On Tuesday, October 29, 2002, at 11:21  AM, Damian Conway wrote:
> > My personal favorite solution is to use square brackets (for their dual
> > array and indexing connotations, and because they highlight the 
> > operator
> > so nicely):
> >
> > $count = @a + @b;
> > @sums  = @a [+] @b;
> 
> Any ideas on what
> 
>   { $^a op $^b }
> 
> would become?

Hmm... I was thinking something along the lines of:

   { $^a op $^b }

[i.e.  this change doesn't make any difference]

Luke

Re: Wh<[ie]>ther Infix Superposition ops

[Dan Sugalski]

At 10:22 AM -0800 10/29/02, Michael Lazzaro wrote:

This is why I am nervous about introducing terms like eigenbunny, etc.


Oh, I dunno, I kind of like it. Of course, now my kids want 
eigenbunny slippers... (Though the trouble with those is they may or 
may not be keeping your feet warm--you can never tell)
--
Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Perl6 Operator List, Damian's take

[Damian Conway]

Uri Guttman wrote:


what is a string complement? bitwise? i take it the numeric is one's
complement.


String complement treats the value as a string then bitwise complements every
bit of each character.

Integer complement treats the value as a int then bitwise complements every
bit.



  DC> 	  ~ - string concatenation
  DC> 	  ~=- string append

what happens to _?


Someone hasn't been playing along at home! ;-)
We're contemplating reshuffling the ops to eliminate it.



  DC> 	  +&+|+^<<>>- bitwise operations
  DC> 	  +&=   +|=   +^=   <<=   >>=

i would add the word integer there. they do bitwise math on the integer
part of a scalar value.


Good point. Thanks.



  DC>~~  !~- smart match, smart non-match

is that also bind for tr///?


That's still being discussed at the moment.

Damian

Re: Wh<[ie]>ther Infix Superposition ops

[Miko O'Sullivan]

At 10:22 AM -0800 10/29/02, Michael Lazzaro wrote:
> This is why I am nervous about introducing terms like eigenbunny, etc.

Beats the heck out of "thingy".  I had to read that chapter three times
before I realized that Randal hadn't just forgotten the real word.

I still feel uncomfortable saying it in the office.

-Miko

Re: Wh<[ie]>ther Infix Superposition ops

[Damian Conway]

Simon Cozens wrote:


In this case I find the latter to be easier to decode and more 
appealing. There are less chars and paretheses are seen much more 
easily.
 
Ack, I guess that means we need a one character DWIM operator.
Although "..." comes pretty close, I suppose.

Great minds think alike.

Acme::DWIM 
gave Perl5ers exactly that, 18 months ago. ;-)

Damian

Re: Perl6 Operator List, Damian's take

[Michael Lazzaro]

On Tuesday, October 29, 2002, at 11:47  AM, Luke Palmer wrote:

[i.e.  this change doesn't make any difference]


Doh!  You're right, of course.  For some reason I was thinking a long 
while back that it would be confusing to have

	{ $^a op $^b }

if ^ went back to meaning xor.  But there's the sigils there, so never 
mind.  The problem was imaginary.

MikeL

vector vs. hyper

[Uri Guttman]

damian's syntax table and his use of the term vectorizing made me wonder
why we call his [op] thing a hyperoperator? the word hyper i assume came
from hyperdimensional. but calling [] the vectorizing (or just vectored)
op variant makes much more sense.

@sum = @a [+] @b ;

that reads as vector add @a and @b

@sum [+]= @c ;

vector add @c into @sum.

@sum [+]= $c ;

vector add assign $d to all of @sum.


vector just has more history with this sort of operation. also damian's
choice of [] makes it look like a vector thingy.

so i will table a motion to rename hyper to vector and hope it doesn't
get warnocked.

uri

-- 
Uri Guttman  --  [EMAIL PROTECTED]   http://www.stemsystems.com
- Stem and Perl Development, Systems Architecture, Design and Coding 
Search or Offer Perl Jobs    http://jobs.perl.org

Re: Wh<[ie]>ther Infix Superposition ops

[Jonathan Scott Duff]

On Tue, Oct 29, 2002 at 11:26:56AM -0800, David Wheeler wrote:
> Well, I like "set operators," too, but what's the grammatical term for 
> the above "logically entangled list of nouns"?

I'd call them "ents" if not for Austin Hastings' more sensible 
"flexops" (unless someone wants to take a stab at relating
superpositions to tree people :-)

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: Perl6 Operator List, Take 3

[Damian Conway]

Scott Duff wrote:


Actually, I think we need a universal method on scalars that
gives the eigenstates of that value. It might be C<$val.eigenstates>
or maybe just C<$val.states>. The method would work on non-superimposed
values as well, in which cases it would just return a list containing
the value itself.


Sure, but I'd leave the name "eigenstates" just so the casual
programmer knows they're dealing with something from another
universe if they happen to run across it :-)


But they're *not*, that's the point. This stuff just ain't that hard.
It's just set theory with a few interesting behaviour variations
that make it act more like natural English.

Much more on this in the next few posts.

Damian

Re: Wh<[ie]>ther Infix Superposition ops

[Damian Conway]

Piers Cawley wrote:


Whilst I don't wish to get Medieval on your collective donkey I must
say that I'm really not sure of the utility of the proposed infix
superposition ops. I'm a big fan of any/all/one/none, I just think
that

one(any($a, $b, $c), all($d, $e, $f))

Is a good deal more intention revealing than the superficially
appealing than

($a & $b & $c) ^ ( $d | $e | $f )


I very much doubt that most people will write either of those.
I suspect it will be quite unusual to see nested superpositions
in code. Most folks are going to be using them for simple but
very common checks like:

	if ( $start & $finish < 0 } {
		($finish,$start) = [-]($start,$finish);		# hyper negate
	}

	if ( $start | $finish < 0 ) {
		print "Bad index\n" and die;
	}

	given $start {
		when 1|3|5|7|9   { print "That's odd...\n" }
		when 2|4|6|8|10  { print "Even so...\n" }
		default  { print "Taking off shoes...\n" }
	}

	my $seen = $start | $finish;
	for <> -> $next {
		print $next unless $next == $seen;
		$seen |= $next;
	}
		



which takes rather more decoding. And if you *do* want to use such
operators, surely you could just do 

use ops ':superpositions';

in an appropriate lexical scope. Am I missing something?

Yes. That superpositions are going to be so widely used once people
catch on, that users going to curse us every time they have to
write C at the start of every scope.

;-)

Damian

Re: Wh<[ie]>ther Infix Superposition ops

[Damian Conway]

>>If someone (named Damian :-)

wrote a superposition synopsis that showed the many and varied uses of
superpositions in contexts that ordinary programmers can relate to, it
would bother me less when people make claims about the usefulness of
superpositions.


I'll take one of those for perl.com!


And I'll certainly write one, when/if it's appropriate.

Hint: we may need an Apocalypse N.5 and a corresponding Exegesis N.5
to deal with superpositions, since they don't really fit into the
existing chapter structure of the Camel.

Hmmm, I guess that, since superpositions are both value and operators,
that should be "Exegesis any(2,3)" ;-)



I was very tempted to use a superposition in production code, but realised
a grep of an array did the same job.


Sure. TMTOWTDI. And under the current Q::S implementation, C
almost certainly did it faster too.

But for simple cases, I suspect that using a built-in Perl 6 superposition:

	if  any(@values) % 2  { print "That's odd...\n" }

is more maintainable (and probably faster) than C:

	if  grep { $_ % 2} @values  { print "That's odd...\n" }

Damian

Re: Perl6 Operator List, Damian's take

[Dave Mitchell]

On Wed, Oct 30, 2002 at 06:51:14AM +1100, Damian Conway wrote:
> String complement treats the value as a string then bitwise complements every
> bit of each character.

Is that the complement of the codepoint or the individual bytes?
(I'm thinking utf8 here).

-- 
Nothing ventured, nothing lost.

Re: vector vs. hyper

[Dave Mitchell]

On Tue, Oct 29, 2002 at 02:55:57PM -0500, Uri Guttman wrote:
> 
> damian's syntax table and his use of the term vectorizing made me wonder
> why we call his [op] thing a hyperoperator? the word hyper i assume came
> from hyperdimensional. but calling [] the vectorizing (or just vectored)
> op variant makes much more sense.

I vote for 'vector' too. I also really like the [] idea.

-- 
print+qq&$}$"$/$s$,$*${$}$g$s$@$.$q$,$:$.$q$^$,$@$*$~$;$.$q$m&if+map{m,^\d{0\,},,${$::{$'}}=chr($"+=$&||1)}q&10m22,42}6:17*2~2.3@3;^2$g3q/s"&=~m*\d\*.*g

Re: Wh<[ie]>ther Infix Superposition ops

[fearcadi]

Brian Ingerson writes:
 > On 29/10/02 09:58 -0800, Larry Wall wrote:
 > > On Tue, 29 Oct 2002, Jonathan Scott Duff wrote:
 > > : On Tue, Oct 29, 2002 at 10:13:39AM +0200, Markus Laire wrote:
 > > 
 > > So I would look favorably on finding a replacement for "superposition".
 > 
 > How about "christmasgift" or "gift"? 
 > 
 > You don't know what it is until you open it. It could be any, all or none of
 > what you expected.
 > 
 > How about "envelope"? (noun)
 > 
 > Or better yet "pocket". What has it gots in its pocketses my precious?
 > 
 > To keep that QM feel you could call it a "hotpocket".
 > 
 > Cheers, Brian
 > 
 > 


maybe something containing "parallel" since that is what they are
doing : put those things in parallel universes and let them go. 
( as opposed to seqential thinking in "Classical" language ) 

 parallel 
 parallel_ ??? # do not know english enouth to come with something here

or maybe taking analogu from 

do { ... }  # immediate code
sub{ ... }  # deferred code 

1 or 2   immediate choice  
1 | 2   choice is deferred 

so 

deferred logic  

arcadi 

Re: Wh<[ie]>ther Infix Superposition op

[Damian Conway]

Larry...

> would look favorably on finding a replacement for "superposition".

any(
	"multivalue",
	"multival",
	"opval"=> "andval"|"orval"|"xorval"|"nandval",
	"opval"=> "andval"|"orval"|"exval"|"nonval",
	"opval"=> "allval"|"anyval"|"oneval"|"noneval",
	"set"  => "andset"|"orset"|"xorset"|"nandset",
	"set"  => "andset"|"orset"|"exset"|"nonset",
	"set"  => "allset"|"anyset"|"oneset"|"noneset",
	"junction" => "conjunction"|"disjunction"|"exclusion"|"rejection",
	"junctive" => "conjunctive"|"disjunctive"|"exclusive"|"dismissive",
)

Damian

Re: Wh<[ie]>ther Infix Superposition ops

[Damian Conway]

David Wheeler wrote:


Well, I like "set operators," too, but what's the grammatical term for 
the above "logically entangled list of nouns"?

"Superposition".

Damian

Re: Wh<[ie]>ther Infix Superposition ops

[John Siracusa]

On 10/29/02 3:13 PM, Damian Conway wrote:
> I suspect it will be quite unusual to see nested superpositions
> in code. Most folks are going to be using them for simple but
> very common checks like:
> 
> [...]
>
> my $seen = $start | $finish;
> for <> -> $next {
> print $next unless $next == $seen;
> $seen |= $next;
> }

I just spent 2 minutes staring at that last example until I finally
understood it.  While I agree that there are many common uses for this
stuff, not all common uses are "simple", IMO.

I think my hang-up mostly had to do with all the existing "knowledge" I have
about how "|" and "|=", and even "==" are "supposed" to work.  Had the
example used the English versions of the operators, I would have gotten it
instantly:

my $seen = any($start, $finish);

for <> -> $next
{
  print $next  unless $next == $seen;
  $seen = any($seen, $next);
}

(Okay, maybe I would have gotten stuck for a moment on the "$next == $seen"
part, but that's about it :)

Anyway, I think this is just a long-winded way of expressing my support for
an article explaining set operators (or "cat-bunny slippers" or whatever :)
and all their wonderful uses.  And I also think the English versions of the
operators are much easier to understand, at least initially, if only due to
the  historical baggage of |, &, and friends.

-John

Re: Wh<[ie]>ther Infix Superposition ops

[fearcadi]

Jonathan Scott Duff writes:
 > On Tue, Oct 29, 2002 at 11:12:28AM -0800, Brian Ingerson wrote:
 > > On 29/10/02 09:58 -0800, Larry Wall wrote:
 > > > On Tue, 29 Oct 2002, Jonathan Scott Duff wrote:
 > > > : On Tue, Oct 29, 2002 at 10:13:39AM +0200, Markus Laire wrote:
 > > > 
 > > > So I would look favorably on finding a replacement for "superposition".
 > > 
 > > How about "christmasgift" or "gift"? 
 > > 
 > > You don't know what it is until you open it. It could be any, all or none of
 > > what you expected.
 > 
 > Then we should definitely call it "cat"  ;-)
 > 
 > -Scott
 > -- 
 > Jonathan Scott Duff
 > [EMAIL PROTECTED]
 > 
 > 


maybe explicitely "Shroedinger cat" this make it ( for all those for
whom "superposition" tell little ) 
at the same more personal, christmas-gift-like, ( who is shroedinger ?) 
and equally informative . 

aracdi

Persistance of superpositions?

[Buddha Buck]

I was wondering...

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;

Re: Wh<[ie]>ther Infix Superposition ops

[Austin Hastings]

I confess, I don't get it. To me, it appears to iterate over the input,
printing unique values except that two values ($start, $finish) are
considered to have already been encountered.

If that's all, then okay. But does it somehow skip all entries
before/after the delimiter?

Also, in a related vein, how do flexen and rexen interact?

That is, what happens if I try to match a flexpr? Do I get flexprs in
all the match variables, or what?

=Austin


--- John Siracusa <[EMAIL PROTECTED]> wrote:
> On 10/29/02 3:13 PM, Damian Conway wrote:
> > I suspect it will be quite unusual to see nested superpositions
> > in code. Most folks are going to be using them for simple but
> > very common checks like:
> > 
> > [...]
> >
> > my $seen = $start | $finish;
> > for <> -> $next {
> > print $next unless $next == $seen;
> > $seen |= $next;
> > }
> 
> I just spent 2 minutes staring at that last example until I finally
> understood it.  While I agree that there are many common uses for
> this
> stuff, not all common uses are "simple", IMO.
> 
> I think my hang-up mostly had to do with all the existing "knowledge"
> I have
> about how "|" and "|=", and even "==" are "supposed" to work.  Had
> the
> example used the English versions of the operators, I would have
> gotten it
> instantly:
> 
> my $seen = any($start, $finish);
> 
> for <> -> $next
> {
>   print $next  unless $next == $seen;
>   $seen = any($seen, $next);
> }
> 
> (Okay, maybe I would have gotten stuck for a moment on the "$next ==
> $seen"
> part, but that's about it :)
> 
> Anyway, I think this is just a long-winded way of expressing my
> support for
> an article explaining set operators (or "cat-bunny slippers" or
> whatever :)
> and all their wonderful uses.  And I also think the English versions
> of the
> operators are much easier to understand, at least initially, if only
> due to
> the  historical baggage of |, &, and friends.
> 
> -John
> 


__
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/

Re: Perl6 Operator List, Damian's take

[fearcadi]

Michael Lazzaro writes:
 > 
 > Any ideas on what
 > 
 >  { $^a op $^b }
 > 
 > would become?
 > 
 > MikeL

maybe 

{ $_a op $_b } 
{ _  op  _   } 

and we have simple ( ? ) rules to distinguish it from "space-eater" _ 

   *   _  surrounded by spaces is placeholder if term is expected
   *   _postfixop  "carriage-returns" and binds  the operator to
  previous term
   *  term_  eats to the next word but leaves zerowidth word boundary
   *  explicitely named placeholders in 
{ $_a op $_b } 
  will have to begin with _ : $_a , $_b ( as before with ^ ) 
  to remind that they are placeholders : named _ ; 

I cannot quite see if that is totally consistent .

aracadi


 

Re: Wh<[ie]>ther Infix Superposition ops

[Damian Conway]

Larry wrote:


All other things being equal, I think people will find modal operators
more confusing than if we just make separate operators.


Agreed.



That being said, I'm still wondering whether we can finesse it.


We can get close. But that might actually be counterproductive.


> Damian's default any() semantics in numeric context select a random element.

And I'd like to change that please! If superpositions are fundamental to the
language, we can integrate them properly with the language. So instead of:

	@array[1|2|3]

randomly selecting element 1 or 2 or 3, this expression would return

	any( @array[1,2,3] )

thereby propagating the superpositional nature of the index.

Note that we already do that anyway for certain numeric contexts. That is,
the numeric contexts of the arguments to:

	1|2 * 3|4

don't randomly select, they propagate the superposition.

So I think that superpositions normally just propagate superpositionality
on *all* operations, but also have the following methods:

	$superposition.states()  # return eigenstates
	$superposition.pick()# select one state at random
	$superposition.serialize()   # convert to a string representation

And since superpositions *do* defer evaluation of boolean expressions, there's
no technical reason why we couldn't have a:

	$superposition.intbits() # evaluate superposition as integer bit ops
	$superposition.strbits() # evaluate superposition as string bit ops

Then we make functions like C and C call those methods automatically
when passed a superposition where they're expecting a bitset. That would allow:

	my $in  = sysopen $infile,  O_RDONLY;
	my $out = sysopen $outfile, O_WRONLY | O_APPEND | O_CREAT;
	for <$in> {
		my ($x, $y, $z) = split;
		my $res = $x | $y & $z;
		print $out: $res.intbits(), "\n";
	}
	chmod S_IRWXU|S_IRGRP|S_IXGRP|S_IROTH|S_IXOTH, $outfile;

And, apart from remembering to bitify on output, the finesse is complete.

Better still, we could mandate that you *can't* print a raw superposition;
that you *have* to call C<.intbits()> or C<.strbits()> or C<.serialize()> first.
That would catch the mistake of:

	my $in  = sysopen $infile,  O_RDONLY;
	my $out = sysopen $outfile, O_WRONLY | O_APPEND | O_CREAT;
	for <$in> {
		my ($x, $y, $z) = split;
		my $res = $x | $y & $z;
		print $out: $res, "\n";		# OOPS!
	}
	chmod S_IRWXU|S_IRGRP|S_IXGRP|S_IROTH|S_IXOTH, $outfile;


Damian

Re: Persistance of superpositions?

[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]
digits: !super
  - 0
  - 1
  - 2
...

Cheers, Brian

Re: Wh<[ie]>ther Infix Superposition ops

[Damian Conway]

Austin Hastings wrote:


I confess, I don't get it. 

Yes, you did. :-)



To me, it appears to iterate over the input,
printing unique values except that two values ($start, $finish) are
considered to have already been encountered.

If that's all, then okay. 

Okay then. That's all.



But does it somehow skip all entries
before/after the delimiter?


No. For that you'd want:

	my $seen = $start & $finish;
	for <> -> $next {
		print $next if $next != $seen && $start < $next < $finish;
		$seen &= $next;
	}

Damian

Re: Wh<[ie]>ther Infix Superposition ops

[Brian Ingerson]

On 29/10/02 14:47 -0500, Dan Sugalski wrote:
> At 10:22 AM -0800 10/29/02, Michael Lazzaro wrote:
> >This is why I am nervous about introducing terms like eigenbunny, etc.
> 
> Oh, I dunno, I kind of like it. Of course, now my kids want 
> eigenbunny slippers... (Though the trouble with those is they may or 
> may not be keeping your feet warm--you can never tell)

Oh! I just remembered the ultimate word for a container. It's "cozy", of
course!

Every eigenbunny needs a supercozy!

Cheers, Brian

Re: Persistance of superpositions?

[Damian Conway]

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:

  letters: !any [0, 1, 2]
  digits: !all
- 0
- 1
- 2
  names: !one ["Brian", "Ingy", "Mr Inline"]
  sane: !none
- "Larry"
- "Damian"
- "Brian"
  ...


Damian
	

Re: Persistance of superpositions?

[Brian Ingerson]

On 29/10/02 13:26 -0800, Brian Ingerson wrote:
> 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

Re: Wh<[ie]>ther Infix Superposition ops

[Damian Conway]

Brian Ingerson wrote:


Oh! I just remembered the ultimate word for a container. It's "cozy", of
course!

Every eigenbunny needs a supercozy!


The plural of which is, presumable, "supercozens".

Now *I'm* really scared!

;-)

Damian

Re: Perl6 Operator List, Damian's take

[Aaron Crane]

Damian Conway writes:
> My personal favorite solution is to use square brackets (for their dual
> array and indexing connotations, and because they highlight the operator
> so nicely):
> 
>   $count = @a + @b;
>   @sums  = @a [+] @b;

Mmm, yummy.  I do have a question though (and apologies if I've merely
missed the answer).  We've got two productive operation-formation rules: one
saying "add a final = to operate-and-assign", and the other saying "wrap in
[] to vectorise".  But no-one's said which order they apply in.  That is,
which of these should I type:

  @x [+]= @y;
  @x [+=] @y;

Of course, the rule ordering didn't matter with the "add a leading ^ to
hype" rule.

I think I prefer the first one, by the way -- it strikes me as more
obviously a vector add.

-- 
Aaron Crane * GBdirect Ltd.
http://training.gbdirect.co.uk/courses/perl/

Re: Persistance of superpositions?

[Damian Conway]

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 C there, partner. You meant:

  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;


Damian

PS: Is anyone collecting these examples. It would make writing that perl.com
article much easier for me ;-)

Re: Perl6 Operator List, Damian's take

[Damian Conway]

Aaron Crane wrote:


Mmm, yummy.  I do have a question though (and apologies if I've merely
missed the answer).  We've got two productive operation-formation rules: one
saying "add a final = to operate-and-assign", and the other saying "wrap in
[] to vectorise".  But no-one's said which order they apply in.  That is,
which of these should I type:

  @x [+]= @y;
  @x [+=] @y;

Of course, the rule ordering didn't matter with the "add a leading ^ to
hype" rule.

I think I prefer the first one, by the way -- it strikes me as more
obviously a vector add.


Yep.

Damian

Re: Persistance of superpositions?

[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

Re: Persistance of superpositions?

[Brian Ingerson]

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 C 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

Generalising properties

[Paul Johnson]

OK, perl6-language is getting scary again ;-)  So here's something else
to think about.  Code coverage.

We don't have to worry about how to do it here.  That's a problem for
internals, and they seem to be solving it quite well without my
interference at the moment, even if they are not aware of that.

But it's often nice to be able to provide information to the coverage
tool which it may not be able to figure out on its own.  In most
coverage tools, this sort of information is bolted onto the language,
usually in the form of special comments.  It would be nice to be able to
design something useful into Perl 6 from the start.

So I would like to see able to tag arbitrary information onto just about
everything, including files, packages, classes, subroutines, blocks,
control structures, statements, lines, expressions, variables and
whatever else I've forgotten about.  Properties can be attached to some
of these.  Can we generalise this at all?

Of course, the applicability of this is not limited to code coverage, so
it would be nice to have something as general and multi purpose as
possible.

The sort of data I'm thinking about includes:

 - this statement should never be executed
 - this class is a singleton
 - these two conditional statements have the same condition
 - the values that this variable can take are constrained by that variable
 - these two subroutines are mutually exclusive - use one or the other

But I don't want language support for saying that, that seems to be a
problem for the applications that want the data, although I'd be glad to
be shown that I am wrong and that the language can support that in a
clean and concise way.  Instead, I just want somewhere to hang arbitrary
data.

Thoughts?

-- 
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net

Re: Perl6 Operator List, Damian's take

[Luke Palmer]

> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Date: Tue, 29 Oct 2002 21:37:32 +
> From: Aaron Crane <[EMAIL PROTECTED]>
> Content-Disposition: inline
> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
> 
> Damian Conway writes:
> > My personal favorite solution is to use square brackets (for their dual
> > array and indexing connotations, and because they highlight the operator
> > so nicely):
> > 
> > $count = @a + @b;
> > @sums  = @a [+] @b;
> 
> Mmm, yummy.  I do have a question though (and apologies if I've merely
> missed the answer).  We've got two productive operation-formation rules: one
> saying "add a final = to operate-and-assign", and the other saying "wrap in
> [] to vectorise".  But no-one's said which order they apply in.  That is,
> which of these should I type:
> 
>   @x [+]= @y;
>   @x [+=] @y;
> 
> Of course, the rule ordering didn't matter with the "add a leading ^ to
> hype" rule.

Hmm.  Well, they're different:

  @x [+]= @y;
  @x = @x [+] @y;

  @x [+=] @y;
  for @x | @y -> $x is rw | $y {
  $x += $y
  }

:)  Is there any advantage in differentiating that?  Or would the
former *always* optimize to the latter?

Luke

> I think I prefer the first one, by the way -- it strikes me as more
> obviously a vector add.
> 
> -- 
> Aaron Crane * GBdirect Ltd.
> http://training.gbdirect.co.uk/courses/perl/

Re: Perl6 Operator List, Damian's take

[Austin Hastings]

Interesting point, especially if operator:+= can be overloaded.

@a [+=] @b; 

implies iteratively invoking operator:+=, whereas 

@a [+]= @b;

implies assigning the result of iteratively invoking operator:+


It only matters when they're different. :-|

And, of course, if they ARE different then the implication is that
signature-matching may also be involved, such that the version of
operator:+ (or +=) that gets used can change...

Hell, we might as well throw in multiple dispatch.

Any of you OO guys know of a case where 

$a = $a + $b;   # @A [+]= @B; --> @A = @A [+] @B;

and

$a += $b;   # @A [+=] @B;

should be different? (Intuitively, I get the feeling that these cases
exist, especially in the weird cases kind of like the >> and <<
operators that C++ redefined for I/O. But I'm not sure if that's
paranoia causing me to accept lousy design, or what...)

Or should there be an overloadable operator:[op]= that takes arrays or
lists as its normal context? (Kind of like C++ differentiating between
new and new[])

=Austin


--- Luke Palmer <[EMAIL PROTECTED]> wrote:
> > Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> > Date: Tue, 29 Oct 2002 21:37:32 +
> > From: Aaron Crane <[EMAIL PROTECTED]>
> > Content-Disposition: inline
> > X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
> > 
> > Damian Conway writes:
> > > My personal favorite solution is to use square brackets (for
> their dual
> > > array and indexing connotations, and because they highlight the
> operator
> > > so nicely):
> > > 
> > >   $count = @a + @b;
> > >   @sums  = @a [+] @b;
> > 
> > Mmm, yummy.  I do have a question though (and apologies if I've
> merely
> > missed the answer).  We've got two productive operation-formation
> rules: one
> > saying "add a final = to operate-and-assign", and the other saying
> "wrap in
> > [] to vectorise".  But no-one's said which order they apply in. 
> That is,
> > which of these should I type:
> > 
> >   @x [+]= @y;
> >   @x [+=] @y;
> > 
> > Of course, the rule ordering didn't matter with the "add a leading
> ^ to
> > hype" rule.
> 
> Hmm.  Well, they're different:
> 
>   @x [+]= @y;
>   @x = @x [+] @y;
> 
>   @x [+=] @y;
>   for @x | @y -> $x is rw | $y {
> $x += $y
>   }
> 
> :)  Is there any advantage in differentiating that?  Or would the
> former *always* optimize to the latter?
> 
> Luke
> 
> > I think I prefer the first one, by the way -- it strikes me as more
> > obviously a vector add.
> > 
> > -- 
> > Aaron Crane * GBdirect Ltd.
> > http://training.gbdirect.co.uk/courses/perl/


__
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/

Re: Wh<[ie]>ther Infix Superposition ops

[Dan Sugalski]

At 1:34 PM -0800 10/29/02, Brian Ingerson wrote:

On 29/10/02 14:47 -0500, Dan Sugalski wrote:

 At 10:22 AM -0800 10/29/02, Michael Lazzaro wrote:
 >This is why I am nervous about introducing terms like eigenbunny, etc.

 Oh, I dunno, I kind of like it. Of course, now my kids want
 eigenbunny slippers... (Though the trouble with those is they may or
 may not be keeping your feet warm--you can never tell)


Oh! I just remembered the ultimate word for a container. It's "cozy", of
course!

Every eigenbunny needs a supercozy!


Absolutely. Eigenbunnies in supercozens. Sounds like we've found the 
mascot for Perl 6!
--
Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Generalising properties

[chromatic]

On Tue, 29 Oct 2002 14:19:59 -0800, Paul Johnson wrote:

> So I would like to see able to tag arbitrary information onto just about
> everything, including files, packages, classes, subroutines, blocks, control
> structures, statements, lines, expressions, variables and whatever else I've
> forgotten about.  Properties can be attached to some of these.  Can we
> generalise this at all?

> Of course, the applicability of this is not limited to code coverage, so it
> would be nice to have something as general and multi purpose as possible.

> But I don't want language support for saying that, that seems to be a problem
> for the applications that want the data, although I'd be glad to be shown that
> I am wrong and that the language can support that in a clean and concise way.
> Instead, I just want somewhere to hang arbitrary data.

Dan started a thread about bytecode in p6i:

http://archive.develooper.com/perl6-internals@;perl.org/msg13377.html

I jumped on the "arbitrary metadata" soapbox, and finally distilled my thoughts
down to this:

http://archive.develooper.com/perl6-internals@;perl.org/msg13443.html

It sounds like we're thinking along the same lines.  This would be very handy
for introspective tools (code coverage, refactoring browsers, IDEs...).

-- c

Re: Persistance of superpositions?

[Larry Wall]

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 C.

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

[RFC] Perl6 Operator List, Take 5

[Michael Lazzaro]

Okay, For those of you playing the home game, Take 5, with Damian & 
Larry's latest inputs.  ^ means xor again, and a few things have been 
removed.  Comments?

Note that I will next post a list of hyperoperators _separately_.

If the design team could take a look, esp. at the remaining questions, 
in order to [APPROVE] a "final" list, that'd be wonderful.  We'll then 
get to work on reconstructing the operator precedence table that 
started this monster thread and, hopefully, we can [APPROVE] that in 
short order as well, and be done with it.  (optimist optimist optimist 
optimist...)

hyperoperators:

  [op]  - as prefix to any unary/binary operator, "vectorizes" the 
operator

  (is whitespace allowed inside the brackets, e.g. [ + ] vs. [+] ?)


unary (prefix) operators:

  \ - reference to
  * - list flattening
  ? - force to bool context
  ! - force to bool context, negate
  not   - force to bool context, negate
  + - force to numeric context
  - - force to numeric context, negate
  +^- force to numeric context, complement
  ~ - force to string context
  ~^- force to string context, complement
  . - method call on current topic

  ++- preincrement
  --- predecrement

unary (postfix) operators:

  ++- postincrement
  --- postdecrement

  ...   - [maybe] same as ..Inf [Damian votes Yes]

other postfix operators:

  ()- (when operator is expected)
  []- array access
  {}- hash access

binary operators:

  (do more of these have possible +~? prefix modifiers,
   or only the boolean &|^ ops?)

   + - * / % ** x xx ~  - arithmetic
   +=-=*=/=%=**=x=xx=~=

  <  > <=>===!=<=>  - comparision
  lt gtlegeeqnecmp

   &&  ||  ^^  //  - boolean operations
   &&= ||= ^^= //=
   and or  xor err

   .&  .|  .^  <<  >>  - bitwise (integer) 
operations
   .&= .|= .^= <<= >>=

   ~&  ~|  ~^  - charwise (string) operations
   ~&= ~|= ~^=

   ?&  ?|  ?^  - [maybe] C-like bool operations
   ?&= ?|= ?^= - (result is always just 1 or 0)

   &   |   ^   - superpositional operations
   &=  |=  ^=  - conjunctive, disjunctive, exclusive
   all any one   none  - conj, disj, excl, dismissive
   sum prodcat   reduce- [maybe]

   ~~  !~  - smart match, smart non-match
  like   unlike- [maybe]  [Damian votes No]

  =>   - pair creator
  ,- list creator
  ;- "greater comma", list-of-lists creator
  :- adverbial
  .- method call

  ..   - range
  ...  - [maybe] range, exclusive of endpoint   [Damian votes No]

  =- assignment
  :=   - binding
  ::=  - binding, but more so

trinary operator:

  ?? ::- if/else

parens, misc, and quotelike operators

  ()
  []- [when term is expected]
  {}- [when term is expected]

  m//   - shorthand, "matches"
  s///  - shorthand, "substitute"
  tr/// - shorthand, "transliterate"

  '...'  "..."   `...`   /.../   << >>
q qq  qx  rx  qw [qm?]
   [+ qr ?]

  <...>- readline
  (heredocs)   - [exact format unknown]


named unary (prefix) operators, terms, and other important assorteds, 
identified
when possible:

  -X   [-X]   - [op] filetest operators

  ref  [ref]  - [op]
  exists   [exists]   - [op]
  delete   [delete]   - [op]
  defined  [defined]  - [op]
  undef[undef]- [op]
  undef   - [term]
  temp?   - [op]
  let ?   - [op]
  but ?   - [op] val properties

  ${ }- [deref] dereference scalarref
  @{ }- [deref]
  %{ }- [deref]
  &{ }- [deref]

  ... - [term] yada**3
  Inf - [term]
  Nan - [term]

  is  - [declar] var properties
  ->  - [declar] like 'sub'
  hash- [declar] force hash context


--- taken out, for now 

magical whitespace modifier
  _ - [maybe] remove whitespace/newline
  (briefly discussed, but not an operator?)

explicit radix specifications for integers:
  (we'll just handle this issue separately, OK?)

other uncategorized:
  (no decisions are implied about these, e.g. are they
   ops, listops, methods, whatever... decide later)

  my our - [declar]
  mapgrep
  sqrt   log   sin cos  tan  (etc...)   - math
  lc lcfirst   uc  ucfirst
  intord   oct hex   bin


MikeL

[RFC] Perl6 HyperOperator List

[Michael Lazzaro]

For this version of the operator list, (since I am unsure that _every_ 
unary/binary op has a meaningful hyper, and some tentatively have 
_two_) I have placed all of them in EXPLICITLY.  Please check that I 
didn't miss any, or put any in that are incorrect.

hyperoperators:

  [op]  - as prefix to any unary/binary operator, "vectorizes" the 
operator

unary (prefix) operators (with all hyper equivs):

  \ [\]- reference to
  * [*]- list flattening
  ? [?]- force to bool context
  ! [!]- force to bool context, negate
  not   [not]  - force to bool context, negate
  + [+]- force to numeric context
  - [-]- force to numeric context, negate
  +^[+^]   - force to numeric context, complement
  ~ [~]- force to string context
  ~^[~^]   - force to string context, complement
  . [.]- method call on current topic

  ++[++]   - preincrement
  --[--]   - predecrement

unary (postfix) operators:

  ++[++]   - postincrement
  --[--]   - postdecrement

  ...   [...]  - [maybe] same as ..Inf

other postfix operators:

  ()- (when operator is expected)
  []- array access
  {}- hash access

binary operators (with ALL hyper equivs!):

   + - * / % ** x xx ~  - arithmetic
   +=-=*=/=%=**=x=xx=~=
  [+]   [-]   [*]   [/]   [%]   [**]   [x]   [xx]   [~] - 
(hyperversions)
  [+]=  [-]=  [*]=  [/]=  [%]=  [**]=  [x]=  [xx]=  [~]=
  [+=]  [-=]  [*=]  [/=]  [%=]  [**=]  [x=]  [xx=]  [~=]

  <  > <=>===!=<=>  - comparision
  lt gtlegeeqnecmp
  [<]   [>]   [<=]  [>=]  [==]  [!=]  [<=>] - (hyperversions)
  [lt]  [gt]  [le]  [ge]  [eq]  [ne]  [cmp]

   &&  ||  ^^  //  - boolean operations
   &&= ||= ^^= //=
   and or  xor err
  [&&][||][^^][//] - (hyperversions)
  [&&]=   [||]=   [^^]=   [//]=
  [&&=]   [||=]   [^^=]   [//=]
  [and]   [or][xor]   [err]

   .&  .|  .^  <<  >>  - bitwise (integer) 
operations
   .&= .|= .^= <<= >>=
  [.&][.|][.^][<<][>>] - (hyperversions)
  [.&]=   [.|]=   [.^]=   [<<]=   [>>]=
  [.&=]   [.|=]   [.^=]   [<<=]   [>>=]

   ~&  ~|  ~^  - charwise (string) operations
   ~&= ~|= ~^=
  [~&][~|][~^] - (hyperversions)
  [~&]=   [~|]=   [~^]=
  [~&=]   [~|=]   [~^=]

   ?&  ?|  ?^  - [maybe] C-like bool operations
   ?&= ?|= ?^= - (result is always just 1 or 0)
  [?&][?|][?^] - (hyperversions)
  [?&]=   [?|]=   [?^]=
  [?&=]   [?|=]   [?^=]

   &   |   ^   - superpositional operations
   &=  |=  ^=  - conjunctive, disjunctive, exclusive
   all any one   none  - conj, disj, excl, dismissive
   sum prodcat   reduce- [maybe]
  [&] [|] [^]  - (hyperversions)
  [&]=[|]=[^]=
  [&=][|=][^=]
  [all]   [any]   [one]   [none]
  [sum]   [prod]  [cat]   [reduce]

   ~~  !~  - smart match, smart non-match
  [~~][!~] - smart match, smart non-match
  like   unlike- [maybe]
 [like] [unlike]   - [maybe]

  =>   [=>]- pair creator
  ,[,] - list creator
  ;[;] - "greater comma", list-of-lists creator
  :[:] - adverbial
  .[.] - method call

  ..   [..]- range
  ...  [...]   - [maybe] range, exclusive of endpoint

  =[=] - assignment
  :=   [:=]- binding
  ::=  [::=]   - binding, but more so

trinary operator:

  ?? ::- if/else

parens, misc, and quotelike operators

  ()
  []- [when term is expected]
  {}- [when term is expected]

  m//   - shorthand, "matches"
  s///  - shorthand, "substitute"
  tr/// - shorthand, "transliterate"

  '...'  "..."   `...`   /.../   << >>
q qq  qx  rx  qw [qm?]
   [+ qr ?]

  <...>- readline
  (heredocs)   - [exact format unknown]


named unary (prefix) operators, terms, and other important assorteds, 
identified
when possible:

  -X   [-X]   - [op] filetest operators

  ref  [ref]  - [op]
  exists   [exists]   - [op]
  delete   [delete]   - [op]
  defined  [defined]  - [op]
  undef[undef]- [op]
  undef   - [term]
  temp?   - [op]
  let ?   - [op]
  but ?   - [op] val properties

  ${ }- [deref] dereference scalarref
  @{ }- [deref]
  %{ }- [deref]
  &{ }- [deref]

  ... - [term] yada**3
  Inf - [term]
  Nan - [term]

  is  - [declar] var properties
  ->  - [declar] like 'sub'
  hash- [declar] force hash context


Mik

Re: Wh<[ie]>ther Infix Superposition ops

[Simon Cozens]

[EMAIL PROTECTED] (David Wheeler) writes:
> Well, I like "set operators," too, but what's the grammatical term for
> the above "logically entangled list of nouns"?

Conjunctions and disjunctions.

-- 
Wouldn't you love to fill out  that  report? "Company asset #423423
was lost while fighting the forces of evil."
-- Chris Adams in the scary.devil.monastery

Re: Perl6 Operator List, Damian's take

[Simon Cozens]

[EMAIL PROTECTED] (Dave Mitchell) writes:
> (I'm thinking utf8 here).

I'd strongly advise against that.

-- 
Ermine? NO thanks. I take MINE black.
- Henry Braun is Oxford Zippy

Re: [RFC] Perl6 Operator List, Take 5

[Larry Wall]

On Tue, 29 Oct 2002, Michael Lazzaro wrote:
:(is whitespace allowed inside the brackets, e.g. [ + ] vs. [+] ?)

I don't think so.

: unary (prefix) operators:
:. - method call on current topic

I think we have to have unary .= as well, if we're to do the

.=replace

trick on $_.

: unary (postfix) operators:
:...   - [maybe] same as ..Inf [Damian votes Yes]

I wonder if we can possibly get the Rubyesque leaving out of
endpoints by saying something like 1..!10.

: other postfix operators:
: 
:()- (when operator is expected)
:[]- array access
:{}- hash access

These now consistently require no space, and they're all
when an operator is expected, not just ().

: binary operators:
: 
:(do more of these have possible +~? prefix modifiers,
: or only the boolean &|^ ops?)

Well, things like < already imply numeric, and things like lt already
imply string.  The booleans are already officially polymorphic.

: + - * / % ** x xx ~  - arithmetic
: +=-=*=/=%=**=x=xx=~=

I don't think of x or ~ as arithmetic exactly...

: .&  .|  .^  <<  >>  - bitwise (integer) 
: operations
: .&= .|= .^= <<= >>=

These should be +& etc.

: sum prodcat   reduce- [maybe]

That's Apocalypse 29.  :-)

: ~~  !~  - smart match, smart non-match
:like   unlike- [maybe]  [Damian votes No]

Undecided.

:..   - range
:...  - [maybe] range, exclusive of endpoint   [Damian votes No]

Still thinking about ..! or ..^ or some such.  Could have ^..^ and ^..
too, for all that.

:::=  - binding, but more so

Cute, but nonexplanatory.  Binding at compile time.

: trinary operator:
: 
:?? ::- if/else
: 
: parens, misc, and quotelike operators
:()
:[]- [when term is expected]
:{}- [when term is expected]

Again, all of these are when a term is expected, not just the latter two.

:m//   - shorthand, "matches"
:s///  - shorthand, "substitute"
:tr/// - shorthand, "transliterate"
: 
:'...'  "..."   `...`   /.../   << >>
:  q qq  qx  rx  qw [qm?]
: [+ qr ?]

No, the qr is dead.  Long live the rx.

:<...>- readline

Iterate interator.

:(heredocs)   - [exact format unknown]

Probably still the same, at least until we start thinking about it...

: magical whitespace modifier
:_ - [maybe] remove whitespace/newline
:(briefly discussed, but not an operator?)

We need something here.  Underline is available.

: explicit radix specifications for integers:
:(we'll just handle this issue separately, OK?)

Fine.  I'm not sure we actually have to change anything here from Perl 5.
Syntactic mangling could easily work for anyone who wants base 42.

: other uncategorized:
:(no decisions are implied about these, e.g. are they
: ops, listops, methods, whatever... decide later)
: 
:my our - [declar]
:mapgrep
:sqrt   log   sin cos  tan  (etc...)   - math
:lc lcfirst   uc  ucfirst
:intord   oct hex   bin

oct and hex are arguably backwards, typewise.  They don't produce
octal or hex types, but rather consume them.

Larry

Re: [RFC] Perl6 HyperOperator List

[Larry Wall]

On Tue, 29 Oct 2002, Michael Lazzaro wrote:
: For this version of the operator list, (since I am unsure that _every_ 
: unary/binary op has a meaningful hyper, and some tentatively have 
: _two_) I have placed all of them in EXPLICITLY.  Please check that I 
: didn't miss any, or put any in that are incorrect.

The problem with cut-and-paste of the regular table is that all the
errors are copied too.

Maybe we should just say that you can put it anywhere that makes sense,
and let the perl parser sort out the sheep from the goats.  The basic
rule is that for any op, [op] is also expected in the same place.  So
if the user defines a postfix:! for factorial, they automatically get
_[!] for that as well.

I think we could also allow

@a [??] @b [::] @c

But it's not clear whether we can parse

@a = [undef][...]

Larry

Re: Perl6 Operator List, Damian's take

[Larry Wall]

On 30 Oct 2002, Simon Cozens wrote:
: [EMAIL PROTECTED] (Dave Mitchell) writes:
: > (I'm thinking utf8 here).
: 
: I'd strongly advise against that.

Actually, it works out rather well in practice, because the string
abstraction in Perl is that of a sequence of codepoints.  But at
least in Perl 5, as long as your codepoints don't get above 255,
it can still all be done with good old byte-ops.

Larry

Re: Perl6 Operator List, Damian's take

[Dan Sugalski]

At 1:20 AM + 10/30/02, Simon Cozens wrote:

[EMAIL PROTECTED] (Dave Mitchell) writes:

 (I'm thinking utf8 here).


I'd strongly advise against that.


I'd agree. Thinking UTF-8 is generally a bad idea.

If you think anything, think fixed-size code points, since that's 
what you're ultimately going to get. Probably 8 bit if you're ASCII, 
Latin1, or EBCDIC, 16 if you're Shift-JIS or Big5 (either one), and 
32 if you're dealing with Unicode.

It's possible you'll get UTF-8 (or UTF-16) but I think you'll be 
hard-pressed to get there, at least without explicit hoop-jumping. I 
certainly hope so, at least.
--
Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: [OT] linguistics and cultural bias?

[Larry Wall]

On Wed, 30 Oct 2002, Martin D Kealey wrote:
: Hmmm...
: 
: I've heard that this is a culturally driven thing: that whilst people can 
: all disambiguate it, people from different cultures may do so differently
: 
: In a "western" culture, exclusive-or is the assumed default unless context
: implies otherwise.  But in many Pacific island cultures (*), if one offers
: "kava or coffee" one would be expected to provide both if answered "yes".
: 
: -Martin
: 
: (* This from annecdotal memory of 20 years ago, so I don't vouch that it
: still applies in any particular culture, but the essential point remains
: that the disambiguation is not as universal or consistent as may seem to us
: sitting here in Australasia, USA or Europe, speaking English.)

Well, it's actually a little worse than that.  Not all languages do
noun disjunctions.  In Japanese you can't ask

Want tea or coffee?

as far as I know.  You have to ask

Want tea?  Want coffee?

So I'm actually being a bit culturally imperialistic in pushing for
noun disjunctions.  But I'm an American, and nobody expects better of
me.  :-)

Larry

RE: [OT] linguistics and cultural bias?

[Brent Dax]

Larry Wall:
# So I'm actually being a bit culturally imperialistic in 
# pushing for noun disjunctions.  But I'm an American, and 
# nobody expects better of me.  :-)

I would argue that you should draw on useful concepts from any language,
not paying any attention to their existence in other languages--so if a
useful concept is in Japanese but not English, you should use it anyway.
(I think that at one point you mentioned that 'it' is implicit in
Japanese--so does $_ qualify? :^) )  Of course, I might just be
rationalizing my own cultural imperialism...

--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)

Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)

RE: [RFC] Perl6 Operator List, Take 5

[David Whipp]

Larry Wall [mailto:larry@;wall.org] wrote:
> : unary (postfix) operators:
> :...   - [maybe] same as ..Inf [Damian votes Yes]
> 
> I wonder if we can possibly get the Rubyesque leaving out of
> endpoints by saying something like 1..!10.

Perhaps we could use the less-than symbol: 1 ..< 10

Similarly: 1 >..< 10  ==  2..9


Dave.

RE: Perl6 Operator List, Damian's take

[David Whipp]

Luke Palmer [mailto:fibonaci@;babylonia.flatirons.org] wrote:

>   for @x | @y -> $x is rw | $y {
> $x += $y
>   }

This superposition stuff is getting to me: I had a double-take,
wondering why we were iterating with superpositions (Bitops
never entered my mind). Did the C<;> ever officially change
to C<|> as the low-precidence list composer?


Dave.


ps. for readability, I think most situations require parenthesis
round these mega-lists.

RE: Perl6 Operator List, Damian's take

[Larry Wall]

On Tue, 29 Oct 2002, David Whipp wrote:
: Luke Palmer [mailto:fibonaci@;babylonia.flatirons.org] wrote:
: 
: >   for @x | @y -> $x is rw | $y {
: >   $x += $y
: >   }
: 
: This superposition stuff is getting to me: I had a double-take,
: wondering why we were iterating with superpositions (Bitops
: never entered my mind). Did the C<;> ever officially change
: to C<|> as the low-precidence list composer?

No.  It's still officially C<;>.

Larry

RE: [OT] linguistics and cultural bias?

[Larry Wall]

On Tue, 29 Oct 2002, Brent Dax wrote:
: (I think that at one point you mentioned that 'it' is implicit in
: Japanese--so does $_ qualify? :^) )

Only when you leave it out.  Kind of like the cat.

Larry

Re: Perl6 Operator List, Damian's take

[Dave Storrs]

On Tue, 29 Oct 2002, Austin Hastings wrote:

> Hell, we might as well throw in multiple dispatch.

Actually, I am really hoping we do.


> Any of you OO guys know of a case where
>
> $a = $a + $b;   # @A [+]= @B; --> @A = @A [+] @B;
>
> and
>
> $a += $b;   # @A [+=] @B;
>
> should be different?

Any time that evaluating $a produces a side effect--for example,
if $a is a tied variable implementing a counter and increments itself by
one every time its value is fetched.  If it started with a value of 5,
then $a += 3 leaves it with a value of 8, but $a = $a + 3 leaves it with a
value of 9.


Dave Storrs

Re: Wh<[ie]>ther Infix Superposition ops

[Dave Storrs]

On Tue, 29 Oct 2002, Dan Sugalski wrote:

> At 1:34 PM -0800 10/29/02, Brian Ingerson wrote:
> >Every eigenbunny needs a supercozy!
>
> Absolutely. Eigenbunnies in supercozens. Sounds like we've found the
> mascot for Perl 6!


I really want to work a "pear pimples for hairy fishnuts" reference in
here somewhere, but I can't quite make it work.


Dave Storrs

RE: [RFC] Perl6 Operator List, Take 5

[Larry Wall]

On Tue, 29 Oct 2002, David Whipp wrote:
: Larry Wall [mailto:larry@;wall.org] wrote:
: > : unary (postfix) operators:
: > :...   - [maybe] same as ..Inf [Damian votes Yes]
: > 
: > I wonder if we can possibly get the Rubyesque leaving out of
: > endpoints by saying something like 1..!10.
: 
: Perhaps we could use the less-than symbol: 1 ..< 10
: 
: Similarly: 1 >..< 10  ==  2..9

That front one is backwards--it would have to be 1 <..< 10.

But the biggest problem is that 1..<$iterator> is valid syntax.

Of course, ..! and ..^ have the same problem.  But it just seems like
it's really unlikely that someone would use a unary ! or ^ on the
endpoint term.  So with 1..!$x or 1..^$x it's likely to be right if
we guess (per the longest token rule) that the operator is ..! or ..^.
The same can't be said of ..<, alas.  But at least it might produce
a syntax error when it tries to parse the >.  Or no, it wouldn't
necessarily.  This parses:

1..<$iterator> + 1;

but wrongly as

1 ..< $iterator > +1;

Ick.

Of course, Real Mathematicians will want [1..10) and (1..10] instead.

Double ick.

I kind like ..^ the best because ^ is currently read "exclusive of"
anyway, sort of...

And the arrow can be read "up to", at least on that end of it.  I think
that ..^ is going to be much, much more common than ^.. will be.

There's also an issue of what (1..10) - 1 would or should mean, if anything.
Does it mean (1..9)?  Does 1 + (1..10) mean (2..10)?

And what would ('a' .. 'z') - 1 mean?

I think I'd better go to bed now...

Larry

Re: [RFC] Perl6 Operator List, Take 5

[Michael Lazzaro]

Larry Wall wrote:
> :...  - [maybe] range, exclusive of endpoint   [Damian votes No]
> 
> Could have ^..^ and ^..too, for all that.

OK, I just gotta say, that's _d*mn_ clever.  "Exclusive of endpoint" --
It looks like what it is, and vice versa.  I guess that's why you're our
fearless leader.  :-)

I'll revise according to the notes, do some cleanup, and repost the
single, re-condensed list.

I also want to say again, for the record, I'm *really* looking forward
to programming in this.  It's going to be FUN.  Bwah-ha-ha!

MikeL

Re: [RFC] Perl6 Operator List, Take 5

[Me]

> : > I wonder if we can possibly get the Rubyesque leaving out of
> : > endpoints by saying something like 1..!10.
> : 
> : Similarly: 1 >..< 10  ==  2..9

> There's also an issue of what (1..10) - 1 would or should
> mean, if anything. Does it mean (1..9)?  Does 1 + (1..10)
> mean (2..10)?
> 
> And what would ('a' .. 'z') - 1 mean?

1..10-1  # 1..9
1+1..--10# 2..9
'a'..'z'--   # a - y

?

--
ralph

PS. [op] is such a sweet improvement. the [op=] vs [op]=
trick that then became possible, the move of ^ back to its
previous meaning, is nice icing.

RE: [RFC] Perl6 Operator List, Take 5

[Brent Dax]

Larry Wall:
# Of course, Real Mathematicians will want [1..10) and (1..10] instead.
# 
# Double ick.

Reminds me of the number-line notation you learn about *before*
precalculus (or whatever the value of
$you.schooling.grade[12].class{math}.name is) confuses everything, with
open vs. closed circles on a number line.  How about:

1 oo 10   # (1, 10)
1 o. 10   # (1, 10]
1 .o 10   # [1, 10)
1 .. 10   # [1, 10]

(The scary part is that I'm not sure I'm joking any more...)

# There's also an issue of what (1..10) - 1 would or should 
# mean, if anything. Does it mean (1..9)?  Does 1 + (1..10) 
# mean (2..10)?
# 
# And what would ('a' .. 'z') - 1 mean?

Er, I would hope that it would be the same as scalar('a' .. 'z') - 1, or
['a' .. 'z'] - 1, or +['a' .. 'z'] - 1, or 26 - 1, or 25.  But that
wouldn't be weird enough, I suppose--it's looking like Perl 6 will be
the official language of *The Matrix*.  Free your mind!  :^)

--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)

Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)

Re: [RFC] Perl6 Operator List, Take 5

[Michael Lazzaro]

Brent Dax wrote:
> Larry Wall:
> # There's also an issue of what (1..10) - 1 would or should
> # mean, if anything. Does it mean (1..9)?  Does 1 + (1..10)

Actually, I would at first glance think, based on the parens, that:

(1..10)-1
means
((1-1)..(10-1))
means
(0..9)

 and if someone has been playing a lot with the superposition stuff,
that is probably what they would indeed expect.  That's also a valuable
interpretation, since it means you can say things like

(1..$n) * 10

And get a list (10,20,...) without having to change $n.

However, by the same logic,

@array * 10
means
@array [*] 10

which it doesn't.  So maybe the correct interpretation of the above is
indeed this:

(1..10)-1   # (1..10).length-1, e.g. 9  (oops!)

(1..10) [-] 1   # (0..9)   (correct, if that's WYM)

meaning that (1..10)-1 almost always does The Wrong Thing(!)

MikeL