1 view

Skip to first unread message

Mar 19, 2004, 8:48:30 PM3/19/04

to Perl6

I just read Synopsis 3, and I have several questions.

1) Synopsis 3 says that the difference between $x ?| $y and $x || $y

is that the later always returns a Boolean. Does this mean that $x ?| $y

short-circuits?

2) Do all of the xor variants have the property that chained calls

return true if exactly one input parameter is true?

3) Is there an ASCII digraph for the | operator?

4) Do "==" and "!=" participate in chained comparisons, so that $a ==

$b == $c evaluates to true if and only if all three are equal? Is $x > $y <

$z a legal chaining? Or $x < $y lt $z?

5) Would it be possible for me to create a user-defined operator that

does chaining?

Joe Gottman

Mar 19, 2004, 10:06:21 PM3/19/04

to Joe Gottman, Perl6

Joe Gottman writes:

> 2) Do all of the xor variants have the property that chained calls

> return true if exactly one input parameter is true?

> 2) Do all of the xor variants have the property that chained calls

> return true if exactly one input parameter is true?

I would imagine not. C<xor> is spelled out, and by definition XOR

returns parity. On the other hand, the junctive ^ (one()) is exactly

one.

>

> 3) Is there an ASCII digraph for the | operator?

No. Just use C<zip>.

> 4) Do "==" and "!=" participate in chained comparisons, so that $a ==

> $b == $c evaluates to true if and only if all three are equal?

Yes. But not really. It evaluates true if $a == $b and $b == $c (while

only evaluating $b once). This may not be the same as all three being

equal if $a, $b, and $c are objects whose equality isn't transitive.

> Is $x > $y < $z a legal chaining? Or $x < $y lt $z?

Sure. It (rather confusingly) asks whether $y is less than both $x and

$z. The latter is too, and it's equivalent to:

$x < +$y and ~$y lt $z

> 5) Would it be possible for me to create a user-defined operator that

> does chaining?

Yes. You just have to be clever about your return values. A comparison

operator could return its right argument C<but true> or C<but false>.

To get them to short circuit is exactly the same problem as getting

other user-defined operators to short circuit, something that's been

adressed but I don't remember the answer to.

Luke

Mar 20, 2004, 12:58:45 AM3/20/04

to Luke Palmer, Joe Gottman, Perl6

> -----Original Message-----

> From: Luke Palmer [mailto:lu...@luqui.org]

> Sent: Friday, 19 March, 2004 10:06 PM

> To: Joe Gottman

> Cc: Perl6

> Subject: Re: Some questions about operators.

>

>

> Joe Gottman writes:

> > 2) Do all of the xor variants have the property that

> > chained calls return true if exactly one input

> > parameter is true?

>

> I would imagine not. C<xor> is spelled out, and by

> definition XOR returns parity. On the other hand,

> the junctive ^ (one()) is exactly one.

Hmmm: If infix:xor returns Scalar.boolean, there might be hope. This would involve returning something like a.or.b but a.xor.b.

>

> > 3) Is there an ASCII digraph for the | operator?

> No. Just use C<zip>.

Re: | vs ¦

Boggle! Who let that slip in?

I kind of got the impression he was asking about e.g., ??! or some such, a la ANSI C. (In the same vein as << for «, etc.)

But no, it's far worse: every keyboard that is capable of generating '|' is labeled incorrectly. How's that for the principle of least surprise?

It's like the old Far Side cartoon showing "Ed's Dingoes" right next to "Martha's Day Care" -- trouble waiting to happen. Let's pray nobody uses ¦...

=Austin

PS:

S3 appears inconsistent WRT the . operator and hyperoperation. One example uses ("f","oo","bar")».«length,

while elsewhere you have @objects».run();

Comment?

Mar 20, 2004, 2:04:23 AM3/20/04

to Austin Hastings, Joe Gottman, Perl6

Austin Hastings writes:

> > -----Original Message-----

> > From: Luke Palmer [mailto:lu...@luqui.org]

> > Sent: Friday, 19 March, 2004 10:06 PM

> > To: Joe Gottman

> > Cc: Perl6

> > Subject: Re: Some questions about operators.

> >

> >

> > Joe Gottman writes:

> > > 2) Do all of the xor variants have the property that

> > > chained calls return true if exactly one input

> > > parameter is true?

> >

> > I would imagine not. C<xor> is spelled out, and by

> > definition XOR returns parity. On the other hand,

> > the junctive ^ (one()) is exactly one.

>

> Hmmm: If infix:xor returns Scalar.boolean, there might be hope. This

> would involve returning something like a.or.b but a.xor.b.

> > -----Original Message-----

> > From: Luke Palmer [mailto:lu...@luqui.org]

> > Sent: Friday, 19 March, 2004 10:06 PM

> > To: Joe Gottman

> > Cc: Perl6

> > Subject: Re: Some questions about operators.

> >

> >

> > Joe Gottman writes:

> > > 2) Do all of the xor variants have the property that

> > > chained calls return true if exactly one input

> > > parameter is true?

> >

> > I would imagine not. C<xor> is spelled out, and by

> > definition XOR returns parity. On the other hand,

> > the junctive ^ (one()) is exactly one.

>

> Hmmm: If infix:xor returns Scalar.boolean, there might be hope. This

> would involve returning something like a.or.b but a.xor.b.

I don't know what you're hoping for when you say 'hope.'

>

> >

> > > 3) Is there an ASCII digraph for the | operator?

> > No. Just use C<zip>.

>

> Re: | vs ¦

>

> Boggle! Who let that slip in?

>

> I kind of got the impression he was asking about e.g., ??! or some

> such, a la ANSI C. (In the same vein as << for «, etc.)

>

> But no, it's far worse: every keyboard that is capable of generating

> '|' is labeled incorrectly. How's that for the principle of least

> surprise?

I've never been too fond of the (lack of) visual distinction between |

and ¦ . They're just too similar. I'd much rather see something like

U+299A VERTICAL ZIGZAG LINE (⦚). But alas, not in latin-1 (not to

mention my terminal's inability to render that character, but that

wasn't a design constraint last time I checked ¦-).

But context serves us humans well here. Very infrequently will you see:

for @a | @b -> $a, $b {...}

My head hurts just thinking about what that actually does. Among other

things, it should probably issue a warning saying "did you mean ¦ ?"

> It's like the old Far Side cartoon showing "Ed's Dingoes" right next

> to "Martha's Day Care" -- trouble waiting to happen. Let's pray nobody

> uses ¦...

>

> =Austin

>

> PS:

>

> S3 appears inconsistent WRT the . operator and hyperoperation. One

> example uses ("f","oo","bar")».«length, while elsewhere you have

> @objects».run();

Oops. The latter is correct.

Luke

Mar 20, 2004, 3:09:15 PM3/20/04

to Perl6

> -----Original Message-----

> From: Luke Palmer [mailto:lu...@luqui.org]

> Austin Hastings writes:

> > > From: Luke Palmer [mailto:lu...@luqui.org]

> > > Joe Gottman writes:

> > > > 2) Do all of the xor variants have the property that

> > > > chained calls return true if exactly one input

> > > > parameter is true?

> > >

> > > I would imagine not. C<xor> is spelled out, and by

> > > definition XOR returns parity. On the other hand,

> > > the junctive ^ (one()) is exactly one.

> >

> > Hmmm: If infix:xor returns Scalar.boolean, there might be hope. This

> > would involve returning something like a.or.b but a.xor.b.

>

> I don't know what you're hoping for when you say 'hope.'

Let's look at boolean xor:

if ($a xor $b xor $c) {...}

should succeed only when exactly one of ($a, $b, $c) is true. This corresponds roughly to constructing and then collapsing a one() junction:

if one (?$a, ?$b, ?$c) {...}

If XOR is true, it should return 1/true. If XOR is false, it can either be "false, but not preclusive of later success", or "definitely false". (Remember a year ago when we talked about how many values should be present in a logical type?)

So "definitely false" xor "anything" is false.

But "tentatively false" is 0/false. It passes into another XOR just fine.

Thus:

tentatively false = 0

definitely false = 1/false. (or perhaps false/1 ?)

So

sub infix:xor(Scalar $a, Scalar $b) {

my $left = (?$a == ?($a.value)) ?? ?$a :: 1; # 0/true is true,

my $right = (?$b == ?($b.value)) ?? ?$b :: 1; # 1/false is 1

if ($left && $right) { return 1 but false; }

if ($left || $right) { return 1; }

else return 0;

}

means that:

0 xor 0 == 0

0 xor 1 == 1

1 xor 0 == 1

1 xor 1 == 1/false (!!)

so that:

(1 xor 1) xor 0 == 0

(1 xor 1) xor 1 == 1/false

Ad infinitum.

> > > > 3) Is there an ASCII digraph for the | operator?

> > > No. Just use C<zip>.

> >

> > Re: | vs ¦

> >

> > Boggle! Who let that slip in?

> >

> > I kind of got the impression he was asking about e.g., ??! or some

> > such, a la ANSI C. (In the same vein as << for «, etc.)

> >

> > But no, it's far worse: every keyboard that is capable of generating

> > '|' is labeled incorrectly. How's that for the principle of least

> > surprise?

>

> I've never been too fond of the (lack of) visual distinction between |

> and ¦ . They're just too similar. I'd much rather see something like

> U+299A VERTICAL ZIGZAG LINE (⦚). But alas, not in latin-1 (not to

> mention my terminal's inability to render that character, but that

> wasn't a design constraint last time I checked ¦-).

>

> But context serves us humans well here. Very infrequently will you see:

>

> for @a | @b -> $a, $b {...}

>

> My head hurts just thinking about what that actually does. Among other

> things, it should probably issue a warning saying "did you mean ¦ ?"

Granted. But some pitaph is going to come along and find a novel new use for zip outside of loops. And then it's going to be in an expression of some kind, where the parser won't know what to do...

Ah, well, that's what P6tidy will be for. That program's going to have a hella-long configuration setup...

> > PS:

> >

> > S3 appears inconsistent WRT the . operator and hyperoperation. One

> > example uses ("f","oo","bar")».«length, while elsewhere you have

> > @objects».run();

>

> Oops. The latter is correct.

I saw something a while back from $Larry talking about some consensus leaning towards always being balanced. Is that a misrecollection on my part, or was there some counterexample which actually provides value for » xor « xor »« ?

=Austin

Mar 20, 2004, 3:30:12 PM3/20/04

to perl6-l...@perl.org

I'm not sure that having quaternary logic in Perl 6 is necessarily a good

idea. Why stop only at four states?

--

... though the Japanese must be the most stupid people... I'm sure I

read somewhere that Tokyo has the densest population in the world...

- Gid Holyoake, sdm.

Mar 20, 2004, 4:03:02 PM3/20/04

to Perl6

Austin Hastings wrote:

> Granted. But some pitaph is going to come along and find a novel new use for

> zip outside of loops. And then it's going to be in an expression of some kind,

> where the parser won't know what to do...

%hash = @keys ¦ @values;

Oh, and it's "petaQ" not "pitaph".

Hey...wait a minute!

<tlhInganHol>

petaQ chopong?

bIQambogh DaqDaq qaHoH!!

</tlhInganHol>

{{;-)

Damian

Mar 20, 2004, 4:17:09 PM3/20/04

to perl6-l...@perl.org

> -----Original Message-----

> From: si...@alibi.simon-cozens.org

> [mailto:si...@alibi.simon-cozens.org]On Behalf Of Simon Cozens

>

> I'm not sure that having quaternary logic in Perl 6 is necessarily a good

> idea. Why stop only at four states?

Indeed:

undef, unset (disagreeable undef, a la NaN), nocare (always matches), true,

false. Plus "but tentative" and "but forcing" modifiers, and junction

support for 'none(true)'.

Total about twelve possible "states" plus junctions, of which eight or nine

would be 'useful', and only three would be knowingly used.

Most users would never see "nocare", and rarely see "unset." But NULL would

map directly to it (hello, DBI), the complex operators could use it, and

occasionally having the core logic code do the right thing would be a win,

like the xor example.

=Austin

Mar 20, 2004, 4:19:17 PM3/20/04

to perl6-l...@perl.org

Austin_...@Yahoo.com (Austin Hastings) writes:

> > I'm not sure that having quaternary logic in Perl 6 is necessarily a good

> > idea. Why stop only at four states?

>

> > I'm not sure that having quaternary logic in Perl 6 is necessarily a good

> > idea. Why stop only at four states?

>

> Total about twelve possible "states" plus junctions, of which eight or nine

> would be 'useful', and only three would be knowingly used.

> would be 'useful', and only three would be knowingly used.

Irony is wasted on perl6-language.

--

A year spent in artificial intelligence is enough to make one believe in God.

Mar 20, 2004, 4:21:17 PM3/20/04

to Damian Conway, Perl6

> -----Original Message-----

> From: Damian Conway [mailto:dam...@conway.org]

>

> Austin Hastings wrote:

>

> > Granted. But some pitaph is going to come along and find a

> > novel new use for zip outside of loops. And then it's going

> > to be in an expression of some kind, where the parser won't

> > know what to do...

>

> %hash = @keys ¦ @values;

>

> Oh, and it's "petaQ" not "pitaph".

Umm, no. It's "pitaph", vice "japh". (Better than "gdtsfhogwaph", certainly.)

But you make my point.

BTW, how did you generate that ¦, or did you mouse it?

=Austin

Mar 20, 2004, 4:50:37 PM3/20/04

to Perl6

Austin Hastings wrote:

>>Oh, and it's "petaQ" not "pitaph".

>

> Umm, no. It's "pitaph", vice "japh". (Better than "gdtsfhogwaph", certainly.)

Oh, then in that case:

<english>

You called me a "pain in the ass"?

I should kill you were you stand!!

</english>

;-)

> BTW, how did you generate that ¦, or did you mouse it?

I mapped one of my iBook's function keys to it.

Damian

Mar 20, 2004, 6:41:08 PM3/20/04

to perl6-l...@perl.org

Dear All,

I think that the broken bar is dangerous. Why:

It can be mixed up with the normal bar |. In some fonts it looks the same.

And to many people it is not 100% clear, which of the two bars is the broken

one and which not.

Off course it is possible to avoid this, but that is not solving the problem

of reading perl-code that someone else has written. The 姣 are not such a problem.

But I would think that it would still be worth considering to avoid the broken bar.

Sorry if this disscussion has been performend 1000 times already.

Best regards,

Karl

Mar 20, 2004, 6:40:26 PM3/20/04

to perl6-l...@perl.org

At 9:19 PM +0000 3/20/04, Simon Cozens wrote:

>Austin_...@Yahoo.com (Austin Hastings) writes:

>> > I'm not sure that having quaternary logic in Perl 6 is necessarily a good

>> > idea. Why stop only at four states?

>>

>> Total about twelve possible "states" plus junctions, of which eight or nine

>> would be 'useful', and only three would be knowingly used.

>

>Irony is wasted on perl6-language.

>Austin_...@Yahoo.com (Austin Hastings) writes:

>> > I'm not sure that having quaternary logic in Perl 6 is necessarily a good

>> > idea. Why stop only at four states?

>>

>> Total about twelve possible "states" plus junctions, of which eight or nine

>> would be 'useful', and only three would be knowingly used.

>

>Irony is wasted on perl6-language.

And this is a new revelation?

--

Dan

--------------------------------------"it's like this"-------------------

Dan Sugalski even samurai

d...@sidhe.org have teddy bears and even

teddy bears get drunk

Mar 20, 2004, 7:09:18 PM3/20/04

to perl6-l...@perl.org

Well, maybe we should use yen (･) instead. It even looks like a zipper.

(Of course, we'll leave out the little problem that half the people

in Japan would read it as a backslash wannabe...that's not really

a problem since a zipper would only be used where an operator is

expected, and backslash is illegal there (so far).)

Larry

Mar 20, 2004, 4:02:43 PM3/20/04

to Austin Hastings, Perl6

On Sat, Mar 20, 2004 at 03:09:15PM -0500, Austin Hastings wrote:

> Let's look at boolean xor:

>

> if ($a xor $b xor $c) {...}

>

> should succeed only when exactly one of ($a, $b, $c) is true. This corresponds roughly to constructing and then collapsing a one() junction:

> Let's look at boolean xor:

>

> if ($a xor $b xor $c) {...}

>

> should succeed only when exactly one of ($a, $b, $c) is true. This corresponds roughly to constructing and then collapsing a one() junction:

That's not the definition of xor that I learned in school.

It's taking a simplified form of the definition that works

for two arguments and then expanding it to multiple

arguments - but the result is different from the original

definition of xor.

The truth table for xor is:

x y | x xor y

------+--------

0 0 | 0

0 1 | 1

1 0 | 1

1 1 | 0

If you look at the first two rows, the result is equalt to y:

zero xor'ed with y is y. The last two rows shot that one

xor'ed with y is the complement of y. Every 1 in a list of

values being xor'ed together complements the result. So:

$a xor $b xor $c

is true when either one or three of ($a, $b, $c) are true,

and false when zero or two of them are true. This

characteristic of xor gets used in many places: cryptography

and secure hash computations, for example, or RAID parity

value for another.

Since the one function already exists, there is no need to

change the meaning of the xor function.

Mar 22, 2004, 6:05:42 AM3/22/04

to Austin Hastings, Perl6

Austin Hastings said:

> Let's look at boolean xor:

>

> if ($a xor $b xor $c) {...}

>

> should succeed only when exactly one of ($a, $b, $c) is true.

I think it is generally accepted that xor is true iff an odd nnumber of

its argumnets are true.

--

Paul Johnson - pa...@pjcj.net

http://www.pjcj.net

Mar 22, 2004, 3:35:39 PM3/22/04

to Perl6

John Macdonald wrote:

>> if ($a xor $b xor $c) {...}

>>

>>should succeed only when exactly one of ($a, $b, $c) is true.

> That's not the definition of xor that I learned in school.

> It's taking a simplified form of the definition that works

> for two arguments and then expanding it to multiple

> arguments - but the result is different from the original

> definition of xor.

To which Paul Johnson added:

> I think it is generally accepted that xor is true iff an odd nnumber of

> its argumnets are true.

There are *two* generally accepted extensions of xor as an n-adic operator:

the one John learned in school, and the one Austin was describing. *Both* are

consistent with the definition of the binary form -- depending, of course, on

how the binary form is defined. ;-)

The "parity" version John described is the obvious extension of the binary

logic of an xor (as illustrated in John's truth-table). But it's at least

arguable that n-ary operators should not always be generated from binary ones

in this manner.

One could equally well argue that the binary xor truth table is really just a

convenient encoding of the semantics: "exactly one of these operands is true".

And indeed many have done so, and thus generalized xor that way. For example,

this second definition is the basis of the "exists uniquely (a.k.a. "big-xor")

quantifier of predicate calculus.

And, indeed, that's how junctional xor (C<^>) is generalized in Perl 6 to

create the C<one> function.

In practice, the parity-checking version of n-ary xor has proved extremely

useful in a number of practical low-level domains (low-level, at least,

compared to predicate calculus ;-). And that utility has meant that the

parity-checking definition has come to predominate.

But that doesn't make it the One True Xor, or even the best choice for a

high-level programming language.

Of course, I'm not going to argue that the various Perl 6 *bit-wise* xors

ought to be anything other than parity-checking, but the case for logical xor

isn't nearly so clear-cut.

Nor is "exists uniquely" the only alternative semantics. At an even higher

level, one could argue that xor means "my operands all have different truth

values". Which implies that n-ary xor (for n>2) should always return

false...unless, of course, we decide to implement Simon's 12 distinct boolean

values.

However I do think that, now we have C<one> to carry the load of "exists

uniquely", Larry will probably decide that C<xor> is strictly binary, and

hence generalizes to the "parity" form in the n-ary case. I just don't want

people to think we neglected to consider the other valid alternatives.

Damian

Mar 22, 2004, 11:07:25 PM3/22/04

to Perl6

On Tue, Mar 23, 2004 at 07:35:39AM +1100, Damian Conway wrote:

: However I do think that, now we have C<one> to carry the load of "exists

: However I do think that, now we have C<one> to carry the load of "exists

: uniquely", Larry will probably decide that C<xor> is strictly binary, and

: hence generalizes to the "parity" form in the n-ary case.

: hence generalizes to the "parity" form in the n-ary case.

Hmm, I probably will. :-)

But I'd like to point out that there's also a view of xor as the negated

form of BASIC's "eqv", and that could be considered a comparison operator,

and as we all know, comparison operators in Perl 6 do chaining. We can

currently write "eqv" like this:

?$a == ?$b == ?$c

which implies that we can write chained "xor" as:

?$a != ?$b != ?$c

Of course, now someone's going to suggest that we should make ?^ a

comparison operator so that you can just say

$a ?^ $b ?^ $c

And then go on to suggest that we also allow chained

$a ?& $b ?& $c

and

$a ?| $b ?| $c

And then they'll say, hey, if ? makes a "true" operator, we should also

have the corresponding "not true" operators, giving us "nand" and "nor"

directly:

$a !& $b !& $c

$a !| $b !| $c

And then this person will point out that BASIC's eqv operator is just:

$a !^ $b !^ $c

And then, before this person can suggest anything else, he will be

taken out and shot. :-)

Larry

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu