proposal: use \ as none junction delimeter
Thomas Sandlaß
it just occured to me that the lone single character reference
operator '\' is badly Huffman coded! These days references are
pretty much automagical. So my idea is to replace '\' with e.g.
'\*' which puts it in opposition to the flattening '*' and '**'
operators. And there should be a little bit more verbose form
'ref' which is much like a context enforcer like 'int' and '+',
'~' and '?'.
This gives:
my @x = (1,2,3);
my $x = [1,2,3];
my $x = ref (1,2,3); # also without ()?
my $x = \* (1,2,3); # also without ()?
Accepting the above completes the junction constructing operators:
my $x = 1|2|3; # any
my $x = 1^2^3; # one
my $x = 1&2&3; # all
my $x = 1\2\3; # none
The rational behind the none delimeter is that 'none(a,b,c)' is
'!a && !b && !c' which DeMorgan tells us is 'a \\ b \\ c' with
'\\' beeing the high precedence version of 'nor'. So we end up
having a third orish operator:
if $a && $b { ... } # and
if $a || $b { ... } # or
if $a ^^ $b { ... } # xor
if $a // $b { ... } # err
if $a \\ $b { ... } # nor
Well?
--
TSa (Thomas Sandlaß)
Aldo Calpini
> my $x = 1|2|3; # any
> my $x = 1^2^3; # one
> my $x = 1&2&3; # all
> my $x = 1\2\3; # none
>
>
> if $a && $b { ... } # and
> if $a || $b { ... } # or
> if $a ^^ $b { ... } # xor
> if $a // $b { ... } # err
> if $a \\ $b { ... } # nor
>
> Well?
that's all very Huffy (short for Huffmanish), and probably makes a lot
of visual sense to someone used to mathematical logic.
but to someone who's not, well, I'm afraid it just looks *weird*.
cheers,
Aldo
Autrijus Tang
> Accepting the above completes the junction constructing operators:
>
> my $x = 1|2|3; # any
> my $x = 1^2^3; # one
> my $x = 1&2&3; # all
> my $x = 1\2\3; # none
Pugs currently implements binary infix "!" as the "none" separator:
$ ./pugs -e "(none 1..3).perl"
((1 ! 2 ! 3))
as well as the non-short-circuitting "!!" logical operator, and the
lower-precedenced "nor".
I like the "!" notation because it agrees with "!" as not, hence easier
to remember for me, but if it is agreed that "\" and "\\" works better,
I can certainly adjust to the "\" notation.
Thanks,
/Autrijus/
Luke Palmer
> This gives:
>
> my @x = (1,2,3);
>
> my $x = [1,2,3];
> my $x = ref (1,2,3); # also without ()?
> my $x = \* (1,2,3); # also without ()?
>
> Accepting the above completes the junction constructing operators:
>
> my $x = 1|2|3; # any
> my $x = 1^2^3; # one
> my $x = 1&2&3; # all
> my $x = 1\2\3; # none
That's quite nice, but I've been kind of wanting to go the other way.
You know, not every operation in Perl 6 needs to have a punctuation
operator.
I think we should not use \, and also get rid of ^. I'm interested in
seeing an example where using ^ is readable enough over one() where its
conciseness is warranted. I haven't found that yet. [1]
Luke
[1] Arguably you'd want it in type signatues, since this is not very
readable:
sub foo( one(Dog, Cat, Horse) $x )
But I counter that arguability by saying that you really shouldn't be
putting one() in type signatures. If you want something to be an A or a
B, and you're not doing any checking later on in the code, then it's
fine if it's both A and B. If you are doing checking later on, then it
should either be in a multimethod or you should factor it out into an
abstract type. Perl's not so keen on what you "should" do, though, but
I offer this as solace for those who wish to break the guidelines:
sub foo ( one(Dog, Cat, Horse) $x )
:-)
Thomas Sandlaß
> as well as the non-short-circuitting "!!" logical operator, and the
> lower-precedenced "nor".
I'm not sure if '!' fits the heavy weight perl6 grammar. But why is
'nor' not short-circuitting? It only continues when the left side is
true --- like '||' and '//'. At least this is what the logic table
tells me:
a b a nor b == !a and !b
0 0 1
0 1 0
1 0 0
1 1 0
Regards,
P.S.: I've no clue what I meant with delimeter! Should be delimiter :)
--
TSa (Thomas Sandlaß)
Autrijus Tang
> Autrijus Tang wrote:
> >as well as the non-short-circuitting "!!" logical operator, and the
> >lower-precedenced "nor".
>
> I'm not sure if '!' fits the heavy weight perl6 grammar. But why is
> 'nor' not short-circuitting? It only continues when the left side is
> true --- like '||' and '//'. At least this is what the logic table
> tells me:
Right. I mean short-circuitting as in "returning a or b instead of
returning a Boolean". On the other hand, maybe you can live with it
returning either a, or b, or True, or False. I don't know... :)
Thanks,
/Autrijus/
Thomas Sandlaß
> That's quite nice, but I've been kind of wanting to go the other way.
> You know, not every operation in Perl 6 needs to have a punctuation
> operator.
>
> I think we should not use \, and also get rid of ^. I'm interested in
> seeing an example where using ^ is readable enough over one() where its
> conciseness is warranted. I haven't found that yet.
What I tried to provide is syntactic completeness---and beauty---in the
sense of the table given below. I've found a posting of Damian where he
opposes the usage of binary '!' and '!!' because it looks too negative.
Is there another grammar reason why there is no single character list op
for the none junction?
Another unanswered question is: how often is the ref operator needed
in Perl6?
eval | value | | bitwise ops
rhs if | returning | junction | num str bit
lhs is | low | high | | + ~ ?
-------+-----+------+----------+----------------
true | and | && | & all | +& ~& ?&
always | xor | ^^ | ^ one | +^ ~^ ?^
false | or | || | | any | +| ~| ?|
false | nor | \\ | \ none | +\ ~\ ?\
undef | err | // |
Regards,
--
TSa (Thomas Sandlaß)
Luke Palmer
> Luke Palmer wrote:
> >That's quite nice, but I've been kind of wanting to go the other way.
> >You know, not every operation in Perl 6 needs to have a punctuation
> >operator.
> >
> >I think we should not use \, and also get rid of ^. I'm interested in
> >seeing an example where using ^ is readable enough over one() where its
> >conciseness is warranted. I haven't found that yet.
>
> What I tried to provide is syntactic completeness---and beauty---in the
> sense of the table given below. I've found a posting of Damian where he
> opposes the usage of binary '!' and '!!' because it looks too negative.
> Is there another grammar reason why there is no single character list op
> for the none junction?
Yeah. Because it doesn't exist in English, the natural language that
Perl most closely follows (which isn't very closely).
if $a | $b == 3 {...}
If A or B is 3 ...
if $a & $b == 3 {...}
If A and B are 3 ...
if $a \ $b == 3 {...}
*If A nor B is 3 ...
In English it's more like:
if \ $a \ $b == 3 {...}
If neither A nor B is three ...
And that's one of the reasons that I don't want ^ either:
if $a ^ $b == 3 {...}
*If A oneof B == 3 ...
The most Englishish equivalent of this is the one we already have:
if one($a, $b) == 3 {...}
If one of $a, $b is three ...
I suppose.
> Another unanswered question is: how often is the ref operator needed
> in Perl6?
I don't know. There's not really a corpus of Perl 6 yet is there. And
Perl is TMTOWDI, right, so you never really *need* it. But how often
will it be wanted? I don't really know. I know I don't use it very
much at all in Perl 5.
> eval | value | | bitwise ops
> rhs if | returning | junction | num str bit
> lhs is | low | high | | + ~ ?
> -------+-----+------+----------+----------------
> true | and | && | & all | +& ~& ?&
> always | xor | ^^ | ^ one | +^ ~^ ?^
> false | or | || | | any | +| ~| ?|
> false | nor | \\ | \ none | +\ ~\ ?\
> undef | err | // |
I definitely like the symmetry. But we have to remember that the P in
Perl (can) stand for Practical. The advantages of having syntactic
symmetry are nice, and they aid learning. But they aren't nearly as
important as semantic symmetry/consistency. (Not to say that they
aren't important)
We have a surplus of semantic ideas, and a shortage of characters on the
keyboard. Adding seldom-used (and in this case, confusing) operators in
the face of consistency is a Maxwellian thing, but I don't think it's
hiding any deep truth behind it this time.
Compare:
say "nope" if $a \\ $b;
say "nope" unless $a && $b;
I find the latter actually reads well in our precious natural languages.
The former just seems like golfing.
Luke
Thomas Sandlaß
you wrote:
> if $a \ $b == 3 {...}
> *If A nor B is 3 ...
What does the * in front of the if mean? Not?
With "grammar reason" I meant the formal grammar of Perl6
not the one of natural english. Are you aware of such reasons?
> In English it's more like:
>
> if \ $a \ $b == 3 {...}
> If neither A nor B is three ...
I'm not a native english/american speaker but I think it's
pretty much the same as the German "weder ... noch ..." for
"neither ... nor ..." and "entweder ... oder ..." for the
"either ... or ..." of xor. Also the plural/singular usage
is the same. So I fully agree with you, that xor and nor have
the same feature/burden as infix ops.
But since xor, ^ and ^^ are in the language already, consistency
would at least allow nor, \ and \\. And nor is a proper english word,
xor isn't ;)
BTW, there also was a thread about ',' and 'then'. There people
complained about the missing 'and' in front of it.
> I definitely like the symmetry. But we have to remember that the P in
> Perl (can) stand for Practical. The advantages of having syntactic
> symmetry are nice, and they aid learning. But they aren't nearly as
> important as semantic symmetry/consistency. (Not to say that they
> aren't important)
The lack of infix ops to go with the none junction has worried others
before me. Unfortunately I don't find the thread were Larry rambles
about this. The only thing I found was Damian disliking ! and !!.
Of course I wouldn't ask for a nand infix op for two reasons:
1) there's no corresponding junction
2) what should be the high precedence version?
> We have a surplus of semantic ideas, and a shortage of characters on the
> keyboard. Adding seldom-used (and in this case, confusing) operators in
> the face of consistency is a Maxwellian thing, but I don't think it's
> hiding any deep truth behind it this time.
Well, not depth but notational convenience for small to medium sized junctions.
Do you see chances to get that through? Or is the design more or less finished?
> Compare:
>
> say "nope" if $a \\ $b;
>
> say "nope" unless $a && $b;
>
> I find the latter actually reads well in our precious natural languages.
> The former just seems like golfing.
I agree fully. The if/unless and while/until pairs are nice lunguistic
concessions of Perl. On the other hand, as a programmer it's not so far
out. Definitly not more than xor---but I repeat myself.
Good night!
--
TSa (Thomas Sandlaß)
Luke Palmer
> HaloO Luke,
>
> you wrote:
> > if $a \ $b == 3 {...}
> > *If A nor B is 3 ...
>
> What does the * in front of the if mean? Not?
"Ungrammatical"
> With "grammar reason" I meant the formal grammar of Perl6 not the one
> of natural english. Are you aware of such reasons?
Ahh. Using \ as an infix operator doesn't conflict with the grammar of
Perl 6. It's perfectly feasable in that regard.
> >In English it's more like:
> >
> > if \ $a \ $b == 3 {...}
> > If neither A nor B is three ...
>
> I'm not a native english/american speaker but I think it's pretty much
> the same as the German "weder ... noch ..." for "neither ... nor ..."
> and "entweder ... oder ..." for the "either ... or ..." of xor. Also
> the plural/singular usage is the same. So I fully agree with you, that
> xor and nor have the same feature/burden as infix ops.
>
> But since xor, ^ and ^^ are in the language already,
See, I'm trying to change that. The former and probably the latter can
stay, but I'm convinced that the operator form of ^ doesn't huffmanly
belong, even if it does mnemonically.
> BTW, there also was a thread about ',' and 'then'. There people
> complained about the missing 'and' in front of it.
Yeah, and it got rejected, too. People complain about a lot of things.
That's why I'm here: to comfort people out of their complaints, and to
replace them with my own. :-)
> >I definitely like the symmetry. But we have to remember that the P in
> >Perl (can) stand for Practical. The advantages of having syntactic
> >symmetry are nice, and they aid learning. But they aren't nearly as
> >important as semantic symmetry/consistency. (Not to say that they
> >aren't important)
>
> The lack of infix ops to go with the none junction has worried others
> before me. Unfortunately I don't find the thread were Larry rambles
> about this. The only thing I found was Damian disliking ! and !!.
>
> Of course I wouldn't ask for a nand infix op for two reasons:
> 1) there's no corresponding junction
> 2) what should be the high precedence version?
And 3) who the hell would use it?
>
>
> >We have a surplus of semantic ideas, and a shortage of characters on the
> >keyboard. Adding seldom-used (and in this case, confusing) operators in
> >the face of consistency is a Maxwellian thing, but I don't think it's
> >hiding any deep truth behind it this time.
>
> Well, not depth but notational convenience for small to medium sized
> junctions. Do you see chances to get that through? Or is the design
> more or less finished?
Well, the design is more or less finished in that we have enough
information that the language can be implemented completely. The design
is not finished because it keeps changing.
I never consider the design to be finished (even after it's
implemented). I just assign it an ever-thickening viscosity. If we
wish to make sweeping changes that will change the langauge for the
better, now is the time to do it, because it only gets harder as time
progresses.
Luke
Thomas Sandlaß
> But I counter that arguability by saying that you really shouldn't be
> putting one() in type signatures. If you want something to be an A or a
> B, and you're not doing any checking later on in the code, then it's
> fine if it's both A and B. If you are doing checking later on, then it
> should either be in a multimethod or you should factor it out into an
> abstract type. Perl's not so keen on what you "should" do, though, but
> I offer this as solace for those who wish to break the guidelines:
>
> sub foo ( one(Dog, Cat, Horse) $x )
I think there is a practical application of this. If the classes are
derived from the same base e.g. Mammal then &foo<Dog^Cat^Horse> cannot
be called with a Mammal instance but &foo<Dog|Cat|Horse> could. The former
also excludes junction types. In the latter case there are seven matching
types when superclasses are neglected: Dog, Cat, Horse, Dog|Cat, Dog|Horse,
Cat|Horse and Dog|Cat|Horse.
I also have another idea where the exclusivity of one() is usefull, but
I don't know how to write that in Perl6. I want a
method
Mammal::reproduce( Mammal[male^female] $self:
Mammal[$self.type ^ (male|female)] $partner )
returns Mammal[male^female];
Am I making sense?
--
TSa (Thomas Sandlaß)
Luke Palmer
> Luke Palmer wrote:
>
> >But I counter that arguability by saying that you really shouldn't be
> >putting one() in type signatures. If you want something to be an A or a
> >B, and you're not doing any checking later on in the code, then it's
> >fine if it's both A and B. If you are doing checking later on, then it
> >should either be in a multimethod or you should factor it out into an
> >abstract type. Perl's not so keen on what you "should" do, though, but
> >I offer this as solace for those who wish to break the guidelines:
> >
> > sub foo ( one(Dog, Cat, Horse) $x )
>
> I think there is a practical application of this. If the classes are
> derived from the same base e.g. Mammal then &foo<Dog^Cat^Horse> cannot
> be called with a Mammal instance but &foo<Dog|Cat|Horse> could.
Uhh, only if Perl could give a proof that there were no other mammals
than those three. I wish Perl could do that.
What you probably mean is that &foo<Horse^Bird> could not be called with
Pegasus, but &foo<Horse|Bird> could. Multiple inheritance restriction.
And now you've lost Liskov substitutability, among other things.
And I claim that such would not be a good programming practice, or used
very often in real life. But see above for a possible solution :-)
> I also have another idea where the exclusivity of one() is usefull, but
> I don't know how to write that in Perl6. I want a
>
> method
> Mammal::reproduce( Mammal[male^female] $self:
> Mammal[$self.type ^ (male|female)] $partner )
> returns Mammal[male^female];
I see where you're going with this. In this specfic case, I'd probably
do:
enum Gender { male, female } # Creates mutually-exclusive roles
multi sub reproduce( Mammal & male, Mammal & female )
is symmetric
returns Mammal
{ ... }
But the symmetric bit wouldn't work in the general case. There's also
this:
enum Charge { positive, negative }
multi sub force( Charge $x, Charge ^ ::($left.Charge) $y) {
"attract"
}
multi sub force( Charge $left, ::($left.Charge) $y) {
"repel"
}
Which would define semantics independent of the number of Charges there
actually were. And here we actually did use ^. But that really doesn't
change my argument at all.
Luke