RFC: new logical operator

2002-02-21 Thread Sam Vilain

I think Perl 6 should have a but keyword, as in:

if (defined $foo but $foo eq ) {

}

:-)



Re: RFC: new logical operator

2002-02-21 Thread hachi

On Thu, Feb 21, 2002 at 12:30:11PM +, Sam Vilain wrote:
 I think Perl 6 should have a but keyword, as in:
 
 if (defined $foo but $foo eq ) {

*scratches head*
so... it negates the left side, then ANDs it with the right?

also, it seems to be rather vague to me.

in order to sound clearer, I think it would need to be written as

if (not defined $foo but $foo eq '') {

but then, what does this give us besides another way to write 'and'?
I could be missing something basic here, ignore me if I am.
 
 }
 
 :-)

--hachi

P.S. The first 'revision' was mistakenly sent only to the author, not 
the list, sorry bout that Sam.



Re: RFC: new logical operator

2002-02-21 Thread Sam Vilain

On Thu, 21 Feb 2002 06:50:13 -0600
[EMAIL PROTECTED] wrote:

 On Thu, Feb 21, 2002 at 12:30:11PM +, Sam Vilain wrote:
  I think Perl 6 should have a but keyword, as in:
  if (defined $foo but $foo eq ) {
 *scratches head*
 so... it negates the left side, then ANDs it with the right?

No, but is syntactically equivalent to and in English.  It just
implies that the second condition is not generally what you'd expect if
the first was true.

Complete syntactic sugar :)

Sma.



Re: RFC: new logical operator

2002-02-21 Thread Randal L. Schwartz

 Sam == Sam Vilain [EMAIL PROTECTED] writes:

Sam No, but is syntactically equivalent to and in English.  It just
Sam implies that the second condition is not generally what you'd expect if
Sam the first was true.

Maybe in the interest of huffman encoding, we could make it even_though. :)

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!



Re: Re: RFC: new logical operator

2002-02-21 Thread jadams01

Randal L. Schwartz [EMAIL PROTECTED] wrote:

Sam No, but is syntactically equivalent to and in English.  It
Sam just implies that the second condition is not generally what
Sam you'd expect if the first was true.

Randal Maybe in the interest of huffman encoding, we could make
Randal it even_though. :)

Or we could compromise on despite.

But (sigh) when I first looked at this proposal, I thought, Now what the heck is he 
trying to say that 'and' doesn't cover?

Is it really syntactic sugar if it's confusing at first glance?

 John A



Re: Re: RFC: new logical operator

2002-02-21 Thread Austin Hastings

It can't be that confusing at first glance if English dedicates a slot
way up in the huffman table to the word, eh?

print ; 
 if ($need_eol but $current_column  21);

OTOH, this might become an and grep-not operator for (was it
Damian?)'s quantum operators:

 @y = all(@x) but { /^anti/ };

(Or however that was supposed to work...)

TFIC,

=Austin


--- [EMAIL PROTECTED] wrote:
 Randal L. Schwartz [EMAIL PROTECTED] wrote:
 
 Sam No, but is syntactically equivalent to and in English.  It
 Sam just implies that the second condition is not generally what
 Sam you'd expect if the first was true.
 
 Randal Maybe in the interest of huffman encoding, we could make
 Randal it even_though. :)
 
 Or we could compromise on despite.
 
 But (sigh) when I first looked at this proposal, I thought, Now what
 the heck is he trying to say that 'and' doesn't cover?
 
 Is it really syntactic sugar if it's confusing at first glance?
 
  John A


__
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com



Re: Re: RFC: new logical operator

2002-02-21 Thread Melvin Smith

At 09:47 AM 2/21/2002 -0500, [EMAIL PROTECTED] wrote:
Randal L. Schwartz [EMAIL PROTECTED] wrote:

Sam No, but is syntactically equivalent to and in English.  It
Sam just implies that the second condition is not generally what
Sam you'd expect if the first was true.

Randal Maybe in the interest of huffman encoding, we could make
Randal it even_though. :)

Or we could compromise on despite.

But (sigh) when I first looked at this proposal, I thought, Now what the 
heck is he trying to say that 'and' doesn't cover?

Is it really syntactic sugar if it's confusing at first glance?

Syntactic maple syrup?

-Melvin




Re: RFC: new logical operator

2002-02-21 Thread Aaron Sherman

On Thu, 2002-02-21 at 09:01, Sam Vilain wrote:
 On Thu, 21 Feb 2002 06:50:13 -0600
 [EMAIL PROTECTED] wrote:
 
  On Thu, Feb 21, 2002 at 12:30:11PM +, Sam Vilain wrote:
   I think Perl 6 should have a but keyword, as in:
   if (defined $foo but $foo eq ) {
  *scratches head*
  so... it negates the left side, then ANDs it with the right?
 
 No, but is syntactically equivalent to and in English.  It just
 implies that the second condition is not generally what you'd expect if
 the first was true.
 
 Complete syntactic sugar :)

An off-the-wall thought... If this is not the expected condition,
should it have the extra meaning of an assertion? For example,

defined $foo but $foo eq 

could set $! to 'defined $foo but $foo eq ' and, if -w was in use,
issue 'warn Exceptional condition: $!'

Perhaps but introduces more information than you had thought

Is there a unary but? Or would that be never?

Alternatively, this could all be replaced by should:

defined $foo  $foo should ne 

$foo should == $bar

should $state

should not $state

It's not a hard assertion, just a debugging tool.

should, unlike but would probably always force the expression to be
true. So, 'defined $foo  $foo should ne ' would always be true if
$foo was defined (should should become false or die, under use
strict or the debugger?)

A stanalone should not would be useful for unexpected circumstances
that are not important enough to always issue a warning:

exec($prog);
should not;

This brings up the switch idea... (in C terminology because I don't have
time to look up the Perl version right now):

switch ($x) {
case 1: break;
case 2: break;
default: should not;
}

Ok, I think I'm rambling now... off to do more work.





Re: RFC: new logical operator

2002-02-21 Thread Sam Vilain

[EMAIL PROTECTED] (Randal L. Schwartz) wrote:

 Sam No, but is syntactically equivalent to and in English.  It just
 Sam implies that the second condition is not generally what you'd
 Sam expect if the first was true.
 Maybe in the interest of huffman encoding, we could make it
 even_though. :)

Hmm, to me that implies a binary and where the short circuit behaviour
is reversed.

if ($var eq  even_though defined $var) { }

Sam.



Re: RFC: new logical operator more syntactic maple syrup

2002-02-21 Thread Sam Vilain

Aaron Sherman [EMAIL PROTECTED] wrote:

 An off-the-wall thought... If this is not the expected condition,
 should it have the extra meaning of an assertion? For example,
 could set $! to 'defined $foo but $foo eq ' and, if -w was in use,
 issue 'warn Exceptional condition: $!'

Interesting idea; the problem with warn is that you always get a message
with -w, which is a pain.

I can't count the number of times I've had to do something like:

  if (defined $foo and $foo ne bar) { }

to avoid my program writing garbage to STDERR.

Messages should have priorities, somewhat like syslog priorities.  I tend
to find myself writing this sort of thing:

package Foo;
sub speak { print __PACKAGE__.: @_\n }
sub quiet { }
%SEV = map { $_ = $c++ }
@SEV = (debug,verbose, info,  notice, warning,
err,  crit,alert, emerg);
@FUNCS= [mutter,   mumble,  say,   remark, moan,
 complain, shout,   yell,  scream ]
$MESSAGE_LEVEL=2;
*{$FUNCS[$_]} = \quiet foreach (0..$MESSAGE_LEVEL-1);
*{$FUNCS[$_]} = \speak foreach ($MESSAGE_LEVEL..$#SEV);

mutter Connecting to database;
mumble Selecting some data;
say Your result is: empty;
remark An empty result is unusual; check your head;
complain can't open /etc/hosts;
shout Fix your permissions on /, too open!;
yell The disk is about to fill up!;
scream About to run out of virtual memory!;

In my actual module (http://sam.vilain.net/pm/Codeine.pm or
http://sam.vilain.net/Codeine-0.07.tar.gz, if you're interested), I also
define alternatives to die, such as barf, melt, and explode.

So then use warnings would simply make warning messages say level
rather than mutter.

And but would have an implied { mutter mmm, that's odd }

Sam.



Re: RFC: new logical operator more syntactic maple syrup

2002-02-21 Thread David M. Lloyd

On Thu, 21 Feb 2002, Sam Vilain wrote:

 I can't count the number of times I've had to do something like:

   if (defined $foo and $foo ne bar) { }

 to avoid my program writing garbage to STDERR.

Of course you will now be able to say:

if ($foo //  ne bar) { }

Right?

- D

[EMAIL PROTECTED]




Re: RFC: new logical operator more syntactic maple syrup

2002-02-21 Thread Larry Wall

David M. Lloyd writes:
: On Thu, 21 Feb 2002, Sam Vilain wrote:
: 
:  I can't count the number of times I've had to do something like:
: 
:if (defined $foo and $foo ne bar) { }
: 
:  to avoid my program writing garbage to STDERR.
: 
: Of course you will now be able to say:
: 
: if ($foo //  ne bar) { }
: 
: Right?

Not quite.  You'd have to say:

if ($foo // ) ne bar { }

That's presuming we leave // with the same precedence as ||.

Larry