Re: Please rename 'but' to 'has'.
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 Internally precedence is going to be stored as a floating-point number. Dunno how it'll be exposed at the language level, but at least there'll be more than just 20 or so levels. Why store precedence as floating point rather than integer? [Or did I miss a design document} Because, while you may run into problems fitting something in between 1.001 and 1.002, it's not a problem to fit something between 3 and 4. Floating point precedence is a problem at the edge, but integer precedence makes things potentially difficult for user-added operators if you want to fit things between the standard operators. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Please rename 'but' to 'has'.
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 precedence. What do you do if you don't think that that's enough Internally precedence is going to be stored as a floating-point number. Dunno how it'll be exposed at the language level, but at least there'll be more than just 20 or so levels. Why store precedence as floating point rather than integer? [Or did I miss a design document} Because, while you may run into problems fitting something in between 1.001 and 1.002, it's not a problem to fit something between 3 and 4. Floating point precedence is a problem at the edge, but integer precedence makes things potentially difficult for user-added operators if you want to fit things between the standard operators. Is it worth it? 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. 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 point seems like over-egging the omelette. Tim. p.s. I missed the start of this thread so I'm not sure why this is a parrot issue rather than a language one. I also probably don't know what I'm talking about :)
Re: Please rename 'but' to 'has'.
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 patented the concept of string comparisons. Microsoft is in litigation over the number 2. -Miko
Re: Please rename 'but' to 'has'.
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 that limits you to the, um, 24 standard levels of precedence. What do you do if you don't think that that's enough Internally precedence is going to be stored as a floating-point number. Dunno how it'll be exposed at the language level, but at least there'll be more than just 20 or so levels. Why store precedence as floating point rather than integer? [Or did I miss a design document} Because, while you may run into problems fitting something in between 1.001 and 1.002, it's not a problem to fit something between 3 and 4. Floating point precedence is a problem at the edge, but integer precedence makes things potentially difficult for user-added operators if you want to fit things between the standard operators. Is it worth it? I think so, yes. 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. Don't recall that, though all decisions are subject to later revision. Still, it doesn't have to be exposed either. :) 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! If we're going that route, we've essentially edged over into reals of some sort, at which point we might as well just make it a float. p.s. I missed the start of this thread so I'm not sure why this is a parrot issue rather than a language one. It's a parrot issue in that it'll be welded into the parser part when the parser builds up its operator precedence table. I also probably don't know what I'm talking about :) I'll believe that the first time I see it actually happen... ;-P -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Please rename 'but' to 'has'.
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 relative to an existing operator. That way it doesn't matter what the initial precedence assignments are. We can always change them internally. : 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 point seems like over-egging the omelette. It's also under-egging the omelette, and not just because you eventually run out of bits. I don't think either integer or floating point is the best solution, because in either case you have to remember separately how many levels of derivation from the standard precedence levels you are, so you know which bit to flip, or which increment to add or subtract from the floater. In an approach vaguely reminscent of surreal numbers, I'd just use a string that does trinary ordering. Suppose you have 26 initial precedence levels. Call these A-Z. Subsequent characters can just be 0-2. Skip A for the moment, call the lowest precedence level B, the next lowest C, and so on. * To make a new operator at the same precedence, simply copy the base precedence string. * To make a new operator at a higher precedence level, copy the base precedence and append a 1 to it. * To make a new operator at a lower precedence level, copy the base precedence, decrement the last character (that's why we skipped A) and append a 2. 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. : p.s. I missed the start of this thread so I'm not sure why this is : a parrot issue rather than a language one. I also probably don't : know what I'm talking about :) It's a language issue insofar as the language specifies that the implementation should avoid arbitrary limits. Larry
Re: Please rename 'but' to 'has'.
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 specify
a raw precedence--you can only specify a precedence relative to an
existing operator. That way it doesn't matter what the initial
precedence assignments are. We can always change them internally.
: 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 point seems like over-egging the omelette.
It's also under-egging the omelette, and not just because you
eventually run out of bits. I don't think either integer or floating
point is the best solution, because in either case you have to remember
separately how many levels of derivation from the standard precedence
levels you are, so you know which bit to flip, or which increment to
add or subtract from the floater.
snip
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 have the
precedence strings for *, +, /, mult, add, and div to be S, R, S,
S2, S1, S2 respectively? So mult and div would have the same
precedences?
Hmmm What problems would be caused by:
sub operator:radd($a,$b) is tighter(+) is inline is rightassociative {...}
sub operator:ladd($a,$b) is tighter(+) is inline is leftassociative {...}
Right now, all the operator precedence levels in Perl5 have either right,
left, or no associativity, but they do not mix right and left associative
operators. Will that be allowed in Perl6?
Larry
Re: Please rename 'but' to 'has'.
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 have the
: precedence strings for *, +, /, mult, add, and div to be S, R, S,
: S2, S1, S2 respectively? So mult and div would have the same
: precedences?
Yes. This seems the most sensical approach to me. If you base two
operators on the same precedence level with the same pedigree, they
should have the the same precedence. One can always differentiate them
explicitly. I could even see people setting up a system of virtual
operators that are just there for deriving precedence from, so you
could have 20 standard levels of precedence between * and + if you
wanted.
sub operator:PREC1($a, $b) is tighter('+') {...}
sub operator:PREC2($a, $b) is tighter('PREC1') {...}
sub operator:PREC3($a, $b) is tighter('PREC2') {...}
...
sub operator:funky($a, $b) is like(PREC13) { ... }
: Hmmm What problems would be caused by:
:
: sub operator:radd($a,$b) is tighter(+) is inline is rightassociative {...}
: sub operator:ladd($a,$b) is tighter(+) is inline is leftassociative {...}
:
: Right now, all the operator precedence levels in Perl5 have either right,
: left, or no associativity, but they do not mix right and left associative
: operators. Will that be allowed in Perl6?
Well, associativity is mostly just a tie-breaking rule, so we'd just
want to refine the tie-breaking rule to say what happens in that case.
It's possible the right thing to do is to treat conflicting associativity
as non-associative, and force parentheses.
Larry
Re: Please rename 'but' to 'has'.
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 point seems like over-egging the omelette. It's also under-egging the omelette, and not just because you eventually run out of bits. I don't think either integer or floating point is the best solution, because in either case you have to remember separately how many levels of derivation from the standard precedence levels you are, so you know which bit to flip, or which increment to add or subtract from the floater. On this subject, has it been considered doing it the Cecil way? http://www.cs.washington.edu/research/projects/cecil/www/Release/doc-cecil-lang/cecil-spec-37.html (no numbered priorities, but a partial-order relation on operators) -- Pixel programming languages addict http://merd.net/pixel/language-study/
Re: Please rename 'but' to 'has'.
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 this do:
$i now foo but bar and 2;
or this:
$i but foo now bar and 2;
What if I want to define a synonym for and?
sub operator:also ($a,$b) is inline { $a and $b }
print $_ also die;
Scratching my head here in userville
Re: Please rename 'but' to 'has'.
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, but how will precedence work? What
: would this do:
:
: $i now foo but bar and 2;
:
: or this:
:
: $i but foo now bar and 2;
:
: What if I want to define a synonym for and?
:
: sub operator:also ($a,$b) is inline { $a and $b }
: print $_ also die;
:
: Scratching my head here in userville
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 }
Larry
Re: Please rename 'but' to 'has'.
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 precedence. What
do you do if you don't think that that's enough. Let's say you want to
define a nand operator:
my sub operator:nand ($a, $b) is inline { not ($a and $b) }
but you want nand to have a precedence lower than the existing 'and' but
higher than the existing 'or' (for some reason I can't imagine
offhand). It isn't like() anything, since there isn't anything currently
between 'and' and 'or'. Would that be something like:
my sub operator:nand ($a, $b) is below(and) is inline {not ($a and $b) }
Re: Please rename 'but' to 'has'.
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 }
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. Let's say you want to
define a nand operator:
my sub operator:nand ($a, $b) is inline { not ($a and $b) }
but you want nand to have a precedence lower than the existing 'and' but
higher than the existing 'or' (for some reason I can't imagine
offhand). It isn't like() anything, since there isn't anything
currently
between 'and' and 'or'. Would that be something like:
my sub operator:nand ($a, $b) is below(and) is inline {not ($a and $b)
}
24 levels of precedence should be enough, else you can always resort to parens.
Guillaume
Re: Please rename 'but' to 'has'.
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 for 10 more. Guillaume
Re: Please rename 'but' to 'has'.
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 to the, um, 24 standard levels of precedence. What
: do you do if you don't think that that's enough. Let's say you want to
: define a nand operator:
:
: my sub operator:nand ($a, $b) is inline { not ($a and $b) }
:
: but you want nand to have a precedence lower than the existing 'and' but
: higher than the existing 'or' (for some reason I can't imagine
: offhand). It isn't like() anything, since there isn't anything currently
: between 'and' and 'or'. Would that be something like:
:
: my sub operator:nand ($a, $b) is below(and) is inline {not ($a and $b) }
Yes, that's what I was thinking. And the dimensions shrink every time
you do that, so if something is above your Cnand, it doesn't go
back to being the same as Cand.
Though since people can't seem to keep up and down straight on their
precedence charts, I'd go for tighter and looser or some such. I
think I'm even on the record somewhere about that.
Larry
Re: Please rename 'but' to 'has'.
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, 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
Internally precedence is going to be stored as a floating-point
number. Dunno how it'll be exposed at the language level, but at
least there'll be more than just 20 or so levels.
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Please rename 'but' to 'has'.
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 synonyms. but and now seem to cover a good deal of ground. 0 now true Is misleading, IMHO, as 0 is not now true. 0, in this context is an expression, and we're saying that that expression is now true. but conveys this much more clearly. However, as many have pointed out, there are a number of cases where but is equally misleading. Is there any problem with allowing both but and now? It might even be elegant to use both at the same time: $x now integer but true which is clearer to my eye than $x now integer now true which seems to change the properties of $x twice without reconciling the changes with each other. In any other language this would be unthinkable, but I think it fits nicely with Perl's philosophy. Not TMTOWTDI, which I think is often used to excuse the inexcusable, but the idea that Perl reflects the ways in which humans use language. We want to convey shades of meaning that do not translate directly to action. So, have I just lost it, or would it make sense to have now and but? Apologies to the person who started this thread. I know you thought has was ideal, and I understand why. It's just that between but and now, I think you get more ground covered than you do with has and either one.
Re: Please rename 'but' to 'has'.
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 is a need for more than one keyword that are synonyms. but and
: now seem to cover a good deal of ground.
:
: 0 now true
:
: Is misleading, IMHO, as 0 is not now true. 0, in this context is an
: expression, and we're saying that that expression is now true. but
: conveys this much more clearly. However, as many have pointed out, there
: are a number of cases where but is equally misleading.
:
: Is there any problem with allowing both but and now? It might even be
: elegant to use both at the same time:
:
: $x now integer but true
:
: which is clearer to my eye than
:
: $x now integer now true
:
: which seems to change the properties of $x twice without reconciling the
: changes with each other.
:
: In any other language this would be unthinkable, but I think it fits
: nicely with Perl's philosophy. Not TMTOWTDI, which I think is often used
: to excuse the inexcusable, but the idea that Perl reflects the ways in
: which humans use language. We want to convey shades of meaning that do
: not translate directly to action.
:
: So, have I just lost it, or would it make sense to have now and but?
:
: Apologies to the person who started this thread. I know you thought
: has was ideal, and I understand why. It's just that between but and
: now, I think you get more ground covered than you do with has and
: either one.
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 }
Larry
Re: Please rename 'but' to 'has'.
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 word has is in the positive, whereas but is a
negative, but it assigns a positive, even more confusing.
The word now would be much nicer to indicate a change if you made it
orthogonal to the has. So, use it as follows.
To assign a compile time property:
$a is now red;
To test a compile time property:
if ($a is red) {...}
To assign a runtime property:
$a now has green;
Who cares if the order is reversed. Make it work both ways.
To test a runtime property:
if ($a has green) {...}
Me wrote:
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 often be used
to contradict a built-in or compile time property. If he is right
about the dominant case being a contradiction, 'but' works
better for me than anything else I can think of, including 'now'
(explained below).
Re: Please rename 'but' to 'has'.
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
Re: Please rename 'but' to 'has'.
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 Cunless reads :) IMO, Cunless is one of the best
readability decisions that Perl ever made.
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.
You wouldn't expect
$foobar but true
to actually be false, would you? So, I wouldn't say assigning a positive
is all that confusing.
To assign a compile time property:
$a is now red;
That uses too many of my precious keystrokes.
To test a runtime property:
if ($a has green) {...}
This brings up an interesting point.
if ($a but green) {...}
doesn't make a lot of sense. Would it be possible to make boolean Cis
test both runtime and compile-time properties? But I suppose that could
be confusing on the reader
Luke
Re: Please rename 'but' to 'has'.
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, not really. but can be read basically two ways in English, either as a synonym of and which happens to carry a tone of warning or things not being quite ordinary, or as a synonym for except that. 0 but true Means 0 *and also* true, even though this isn't the usual state of affairs. Makes perfect sense to me. has makes no sense at all in this context. Were I to read: 0 has true my first reaction would be, huh? Since when? Or imagine a Color class, where you wanted to state that this black, if it were only just a bit brighter, would be green: $foo = Color.black but green; I think that black has green just sounds plain weird. but is absolutely perfect, Larry. I say keep it. Trey -- Trey Harris Secretary and Executive SAGE -- The System Administrators Guild (www.sage.org) Opinions above are not necessarily those of SAGE.
Please rename 'but' to 'has'.
Larry, Please don't use 'but' to associate runtime properties to things. Please call it 'has'. First, but is just strange. I have a thing and I want to tell you it is red, so I say 'but'. Huh? Using 'has' makes a nice parallel with 'is' for compile time properties: What you are is determinted at compile time, what you have is determined at run time. Daniel
Re: Please rename 'but' to 'has'.
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 often be used to contradict a built-in or compile time property. If he is right about the dominant case being a contradiction, 'but' works better for me than anything else I can think of, including 'now' (explained below). - Even if usage to contradict a built-in or compile time property is not the most common form of usage, it is still arguably the case that if one keyword is to cover both cases (contradict or not), then having the keyword warn that contradiction may have occured is better than having the keyword indicate to a newbie that there is nothing to worry about, as would be the case with 'has'. Further, even if the warn notion is deemed unimportant, 'has' is still far from an ideal fit in many cases: banana has red; foo has false; Yet another issue is use of 'is' in a conditional: if ($foo is red) ... This would be nice, and would work nicely if one uses a different keyword for runtime properties, but works best if that other word is more consistent with the notion of 'is' than 'has' is. One plausible middle ground word off the top of my head that is odd in its own special way would be 'now': banana now red; foo now false; banana now foo; banana now tainted; I read 'now' as somewhat suggestive of changing something. -- ralph
Re: Please rename 'but' to 'has'.
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 that it has changed at a particular time -- runtime. Compile time properties just *are* (is), no matter what, unless and until you say, at runtime, that it is *now* something else. -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
