G'day all.
On Fri, Apr 26, 2002 at 09:45:24AM -0700, Larry Wall wrote:
> Gee, maybe I should patent this.
Actually, you're binary searching the Stern-Brocot tree representation
of rational numbers. In fact, if you have arbitrary precision integers,
you can convert these strings into rational n
> This is now extensible to any number of precedence levels, and you can
> now use simple string comparison to compare any two precedences. It even
> short circuits the comparison as soon as it finds a character that
> differs.
>
> Gee, maybe I should patent this.
Too late. Amazon has already p
Larry Wall <[EMAIL PROTECTED]> writes:
> : Why not use a 16 bit int and specify that languages should use
> : default precedence levels spread through the range but keeping the
> : bottom 8 bits all zero. That gives 255 levels between '3' and '4'.
> : Seems like enough to me!
> :
> : Floating po
Buddha Buck writes:
: So you'd have something like:
:
: sub operator:mult($a, $b) is looser('*') is inline {...}
: sub operator:add($a, $b) is tighter("+") is inline {...}
: sub operator:div($a,$b) is looser("/") is inline {...}
:
: assuming default Perl5 precedences for *, *, and / you would ha
At 09:45 AM 04-26-2002 -0700, Larry Wall wrote:
>Tim Bunce writes:
>: For perl at least I thought Larry has said that you'll be able to
>: create new ops but only give them the same precedence as any one
>: of the existing ops.
>
>Close, but not quite. What I think I said was that you can't speci
Tim Bunce writes:
: For perl at least I thought Larry has said that you'll be able to
: create new ops but only give them the same precedence as any one
: of the existing ops.
Close, but not quite. What I think I said was that you can't specify
a raw precedence--you can only specify a precedence
At 5:05 PM +0100 4/26/02, Tim Bunce wrote:
>On Fri, Apr 26, 2002 at 11:33:06AM -0400, Dan Sugalski wrote:
>> At 2:26 PM +0100 4/26/02, Nicholas Clark wrote:
>> >On Tue, Apr 23, 2002 at 01:25:15PM -0400, Dan Sugalski wrote:
>> >> At 12:36 PM -0400 4/23/02, Buddha Buck wrote:
>> >> >OK, but th
On Fri, Apr 26, 2002 at 11:33:06AM -0400, Dan Sugalski wrote:
> At 2:26 PM +0100 4/26/02, Nicholas Clark wrote:
> >On Tue, Apr 23, 2002 at 01:25:15PM -0400, Dan Sugalski wrote:
> >> At 12:36 PM -0400 4/23/02, Buddha Buck wrote:
> >> >OK, but that limits you to the, um, 24 standard levels of
> >>
At 2:26 PM +0100 4/26/02, Nicholas Clark wrote:
>On Tue, Apr 23, 2002 at 01:25:15PM -0400, Dan Sugalski wrote:
>> At 12:36 PM -0400 4/23/02, Buddha Buck wrote:
>> >OK, but that limits you to the, um, 24 standard levels of
>> >precedence. What do you do if you don't think that that's enough
>>
At 12:36 PM -0400 4/23/02, Buddha Buck wrote:
>At 08:58 AM 04-23-2002 -0700, Larry Wall wrote:
>>Precedence is set with the "like' property:
>>
>> my sub operator:now ($a,$b) is like("but") is inline { $a but $b }
>> sub operator:also ($a,$b) is like("and") is inline { $a and $b }
>
>OK, b
Buddha Buck writes:
: At 08:58 AM 04-23-2002 -0700, Larry Wall wrote:
: >Precedence is set with the "like' property:
: >
: > my sub operator:now ($a,$b) is like("but") is inline { $a but $b }
: > sub operator:also ($a,$b) is like("and") is inline { $a and $b }
:
: OK, but that limits you
At 01:12 PM 04-23-2002 -0400, [EMAIL PROTECTED] wrote:
>24 levels of precedence should be enough, else you can always resort to
>parens.
I would have agreed, except that I would have also said that the 14
precedence levels of C should be enough as well -- yet we seem to have
discovered uses f
In reply to Buddha Buck <[EMAIL PROTECTED]>:
> At 08:58 AM 04-23-2002 -0700, Larry Wall wrote:
> >Precedence is set with the "like' property:
> >
> > my sub operator:now ($a,$b) is like("but") is inline { $a but $b
> }
> > sub operator:also ($a,$b) is like("and") is inline { $a and $b }
>
At 08:58 AM 04-23-2002 -0700, Larry Wall wrote:
>Precedence is set with the "like' property:
>
> my sub operator:now ($a,$b) is like("but") is inline { $a but $b }
> sub operator:also ($a,$b) is like("and") is inline { $a and $b }
OK, but that limits you to the, um, 24 standard levels of
Aaron Sherman writes:
: On Mon, 2002-04-22 at 19:22, Larry Wall wrote:
:
: > Perl 6 will try to avoid synonyms but make it easy to declare them. At
: > worst it would be something like:
: >
: > my sub operator:now ($a,$b) is inline { $a but $b }
:
: I see your point, and it makes sense, bu
On Mon, 2002-04-22 at 19:22, Larry Wall wrote:
> Perl 6 will try to avoid synonyms but make it easy to declare them. At
> worst it would be something like:
>
> my sub operator:now ($a,$b) is inline { $a but $b }
I see your point, and it makes sense, but how will precedence work? What
would
Aaron Sherman writes:
: On Sun, 2002-04-21 at 10:59, Trey Harris wrote:
:
: > 0 has true
: >
: > my first reaction would be, "huh? Since when?"
:
: Dare I say... "now"? ;-)
:
: Sorry, someone had to say it.
:
: Personally, even though it sucks up namespace, I think what we're seeing
: here i
On Sun, 2002-04-21 at 10:59, Trey Harris wrote:
> 0 has true
>
> my first reaction would be, "huh? Since when?"
Dare I say... "now"? ;-)
Sorry, someone had to say it.
Personally, even though it sucks up namespace, I think what we're seeing
here is a need for more than one keyword that are s
In a message dated Sat, 20 Apr 2002, Daniel S. Wilkerson writes:
> It is one of the standard refactoring tricks to replace the second one
> with the first. The word "has" is in the positive, whereas "but" is a
> negative, but it assigns a positive, even more confusing.
"but" isn't a negative, no
On Sat, 20 Apr 2002, Daniel S. Wilkerson wrote:
> Everyone I've ever talked to about it agrees that defining things to be a
> negative is just a bad idea. Consider:
>
> if (gronk) do_this();
> else do_that();
>
> versus
>
> if (not_gronk) do_that();
> else do_this();
But look how well C read
On Fri, 19 Apr 2002, Daniel S. Wilkerson wrote:
> Please don't use 'but' to associate runtime properties to things.
> Please call it 'has'.
How about both?
Luke
Everyone I've ever talked to about it agrees that defining things to be a
negative is just a bad idea. Consider:
if (gronk) do_this();
else do_that();
versus
if (not_gronk) do_that();
else do_this();
It is one of the standard refactoring tricks to replace the second one
with the first. The w
On 4/20/02 3:02 PM, "Me" <[EMAIL PROTECTED]> claimed:
> banana now red;
> "foo" now false;
> banana now foo;
> banana now tainted;
>
> I read 'now' as somewhat suggestive of changing something.
I actually rather like this keyword. It not only suggests that something has
changed, but tha
I agree 'but' seems a tad odd, and I like the elegance of your
suggestion at first sight. However...
> First, but is just strange. I have a thing and I want to tell you it
is
> red, so I say 'but'. Huh?
banana but red;
"foo" but false;
According to Larry, run time properties will most
24 matches
Mail list logo
