Re: Interfaces
On Wed, 02 Oct 2002 04:12:44 -0700, Michael G Schwern wrote: I like the class Vehicle is interface as a shorthand for declaring every method of a class to be an interface. Perhaps associating a property with a class can be shorthand for associating that property with every method of the class? -- c
Re: Interfaces
On Sun, Oct 06, 2002 at 06:17:37PM -0400, Daniel B. Boorstein wrote: I think there may be some confusion here. In java, there's no special syntax to declare a method an optional part of the interface. All concrete classes that implement the Collection interface still must define full-bodied Cadd(Object element) methods. It just so happens that by convention some classes simply throw an UnsupportedOperationException, perhaps like so: A! No wonder I couldn't find any syntax for it! Thanks for clearing that up. Still, the objections still hold, though now it's a stylistic objection rather than syntactic. It's disturbing that they'd put these optional methods into the core Java API, thereby encouraging their use (Sun did it, so I can to!). Cannonizing the idea weakens the whole concept of an interface and contract. It really ought to be one of those sure you can do this, but please don't things. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One You see, in this world there's two kinds of people. Those with loaded guns, and those who dig. Dig. -- Blondie, The Good, The Bad And The Ugly
Re: Interfaces
On Sun, Oct 06, 2002 at 11:57:51PM -0400, Noah White wrote: I wouldn't call it a dirty little secret as Michael put it :-). This is the right thing to do within the context of a contract. The contract does not guarantee that method functionality implemented by a concrete class does exactly a certain thing a certain way ( I'd like to see the language that does!). Oddly enough, JUnit (and in the Perl world Test::Class and Test::Unit) can do it with inherited tests. Subclasses must pass their parent's tests, so yes, you can guarantee method implementations, just not with an interface contract. Unfortunately, Java doesn't ship with JUnit nor do Java libraries usually ship with tests nor does a simple convention to run them nor an expectation that the user will run the tests before installing. Score one for Perl. :) -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Please Captain, not in front of the Klingons.
Re: Interfaces
In a message dated Tue, 8 Oct 2002, Michael G Schwern writes:
On Sun, Oct 06, 2002 at 06:17:37PM -0400, Daniel B. Boorstein wrote:
I think there may be some confusion here. In java, there's no special syntax
to declare a method an optional part of the interface. All concrete classes
that implement the Collection interface still must define full-bodied
Cadd(Object element) methods. It just so happens that by convention some
classes simply throw an UnsupportedOperationException, perhaps like so:
A! No wonder I couldn't find any syntax for it! Thanks for clearing
that up.
Still, the objections still hold, though now it's a stylistic objection
rather than syntactic. It's disturbing that they'd put these optional
methods into the core Java API, thereby encouraging their use (Sun did it,
so I can to!). Cannonizing the idea weakens the whole concept of an
interface and contract.
It really ought to be one of those sure you can do this, but please don't
things.
It's a RuntimeException. You can't require that all RuntimeExceptions be
declared if thrown; otherwise, every method would have to declare throws
OutOfMemoryException, CannotLoadClassException,
TheEndTimeIsUponUsException, ... for every single runtime error. You
can subclass RuntimeException. So if Sun hadn't provided an
UnsupportedOperationException, anyone else could easily have done so.
And they'll be able to in Perl, too, whatever you do. I often code
method foo {
die Abstract method foo not implemented in concrete class .
(ref $_[0] || $_[0]) . , died;
}
In my abstract superclasses, which is the very same thing.
Trey
Re: Interfaces
On Tue, Oct 08, 2002 at 05:03:26PM -0400, Trey Harris wrote: It really ought to be one of those sure you can do this, but please don't things. It's a RuntimeException. You can't require that all RuntimeExceptions be declared if thrown; snip You can subclass RuntimeException. So if Sun hadn't provided an UnsupportedOperationException, anyone else could easily have done so. I'm not objecting to the fact that it's a runtime exception [1] or that it's possible to do such a thing. I'm objecting to the fact that it's an exception at all since it adds uncertainty into what should otherwise be a guaranteed interface and that this uncertainty is put in the core library of the language. Because Sun did it it's now Officially OK, even if that's not what they ment. More so in the Java world than in Perl, things you do in the core API become canonized. Because that's how Sun does it carries a lot of weight. In Perl it's often that's how (C|Bourne Shell|$popular_module) does it. Programmers parroting the design of a popular API is common and can be used for Good or Evil. [1] It would be less worse [2] as a compile-time exception. [2] This is different than better. ;) -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One I don't get it. Must be art.
Re: RFC: [] as the solitary list constructor
On 6 Oct 2002, Smylers wrote: : Do parens still provide list context on the left side of an assignment? Er, kind of. More precisely, use of parens on the left provides a flattening list context on the right side, just as in Perl 5. I guess I did not make clear that a basic Perl 6 design decision was that = will appear to work exactly as it does in Perl 5, while all the new semantics get put into := instead. In fact, = doesn't work exactly the same, because it lazily evaluates things like ranges and other potentially infinite lists. But that should be more or less transparent. Larry
Re: RFC: [] as the solitary list constructor
On Sun, 6 Oct 2002, Trey Harris wrote: : In a message dated Sun, 6 Oct 2002, Noah White writes: : On Sunday, October 6, 2002, at 01:50 AM, Brent Dax wrote: : : Parens don't construct lists EVER! They only group elements : syntactically. One common use of parens is to surround a : comma-separated list, but the *commas* are creating the list, *not* the : parens! : : : Following this rule would mean that : :$a = (); # $a is a list reference with 0 elements : : should not be a list reference at all and would appear inconsistent. : : No, because there are zero commas. Squint and you can see them. :-) Actually, () has -1 commas, which is why it's not ambiguous. Rather, it's ($x) that has zero commas, so it's naturally ambiguous, and thus must depend on context to determine whether to produce a scalar or a list value. Seriously, () is just a special token. We could easily have used a special token like NULLLIST instead. What does INTERCAL use? Larry
Re: RFC: [] as the solitary list constructor
On Sat, 5 Oct 2002, Chip Salzenberg wrote:
: According to Larry Wall:
: I suppose we could make comma merely puke in scalar context rather
: than DWIM, at least optionally.
:
: I rather like Perl 5's scalar comma operator.
Most of the uses of which are actually in void context, where it
doesn't matter if we technically build a list and throw it away,
or throw away all but the last value, then throw that one away too.
Which is why it got decided the way it was. If you really want the
last value, you can always use
(LIST)[-1]
which could be construed as better documentation. Admittedly it's
not quite the same, since LIST is evaluated in list context.
Anyway, if we did outlaw comma in scalar context, it would not apply
to void context, or we couldn't write:
loop ($a=0, $b=1; $c; $a++, $b++) { ... }
: : $a = ();# $a is a list reference with 0 elements
: : $a = (10); # $a is the scalar 10
: : $a = (10, 20); # $a is a list reference with 2 elements
:
: I don't think that's an important inconsistency.
:
: What if $a and $b are both array refs, and maintenance programmer
: changes:
: for $a, $b { print }
: to:
: for $a { print }
: Will that end up iterating across $a? The equivalent of that gotcha
: was forever bugging me in Python (gack).
No, in list context reference scalars must still be explicitly
dereferenced. The $ on the front still means something occasionally.
It's only in scalar contexts that $ can be autodereffed as an array
now, so that someone can say
push $a, list;
But if you say
push $a, $a;
you get the ref in $a pushed onto $a, as it currently stands.
Larry
Re: for loop and streams
On Fri, 27 Sep 2002, Dan Sugalski wrote: : At 12:40 PM -0700 9/26/02, Sean O'Rourke wrote: : On Thu, 26 Sep 2002, Paul Johnson wrote: : Is that sufficiently vague? : : Not vague enough, because the current implementation manages to miss the : broad side of that semantic barn... : : The intention is to allow aggregates to have different default return : values, IIRC. Right now we return undef as the default, when : accessing elements that don't exist, but there are cases where you : might want something else. (Numeric-only arrays might want to return : 0, and string-only ones , for example) We can certainly have arrays that know how to return default values. But my apocalyptic remarks about dwimming were specifically with respect to hyperoperators that might have specific ideas about how to deal with differing arrays. That behavior should in turn be distinguished from what I said about parallel Cfor loops. Those run until all streams are exhausted, because otherwise there's no way for the code within the loop to tell the loop to run longer. If you assume you should run longer, it's always possible for the loop to terminate itself early. In the particular case where one or another stream is infinite, the loop will run forever unless terminated explicitly by either loop control or detonation of the warhead. : Different operators doing different things sounds awful to me, because it : makes it hard to predict what will happen, because new operators will have : to be able to control what they do with their operands, and because new : types of array-like operands will have to tell operators how to treat : them. Blech. : : Well... no, not really. : : I think this vagueness is my fault, as I badger Larry and Damian : about it on occasion. Well, I'm never vague, except when I am. : The reason it's vague is that the Right Thing depends on the types of : the variables on either side of an operator. Multiplying two matrices : should work differently than multiplying two multidimensional arrays, : or two vectors, or a vector by a matrix. : : We should get the default behaviour defined and in use so people get : a handle on how things work, but we do want to make sure people keep : in mind that it's the default behaviour, not the required behaviour. Right-o. A system is expert friendly if it has the right options. It's novice friendly if it has the right defaults. Larry
Re: perl6 operator precedence table
On Thu, 26 Sep 2002, Sean O'Rourke wrote:
: Thanks for taking the time to write this out.
:
: On Thu, 26 Sep 2002, John Williams wrote:
: perl6 operator precedence
:
: leftterms and list operators (leftward) [] {} () quotes
: left. and unary .
: nonassoc++ --
: leftis but
:
: This would lead to some scary things, I think:
:
: $a = 3 + 4 but false
: = (= $a (+ 3 (but 4 false)))
:
: Of course, so does having low precedence:
:
: $a = 3 but false + 4
: = (= $a (but 3 (+ false 4)))
:
: but I think the latter is unnatural enough that it deserves parens, so I'd
: put 'but' above comma (and probably '='), but below just about everything
: else.
Could perhaps unify with C... Wouldn't hurt for it to be non-associative like C...
: Larry mentions that other precedence unifications are possible. I can see
: the following as possibilites. Are there others?
: with
: | with ||
:
: It seems like a good idea to me to encourage people to think of bitwise
: ops as mathematical, not logical, so I'd rather see them with different
: precedences. Plus, anything that significantly goes against people's
: hard-wired C expectations will just lead to confusion and pain. Finally,
: having '|' below '' will probably lead to strange things, e.g.
:
: 1|2 3|4
: = 1 | (2 3) | 4
I'd be more inclined to unify and | with * and +, since that's
exactly what they are in Boolean algebra, where 1*1 == 1. I think
the argument that it breaks C compatibily is weak in this case,
since almost everyone admits that C is broken in this respect.
Alternately, we take | and away from bitwise ops and do something
more useful with them. I have been asked privately by a sight
impaired person to consider using | as the separator for parallel
streams rather than the almost invisible ; character, for instance.
Being a bit sight impaired myself at the moment, I have great empathy...
Larry
Re: perl6 operator precedence table
On Thu, 26 Sep 2002, John Williams wrote:
: I'm trying to write a revised operator precedence table for perl6,
: similar to the one in perlop.pod.
:
: This is what I have come up with based on Apocalypse 3 and Exegesis 3.
: Does anyone have comments? I'm not sure if the precedence
: for : (adverb) or 'is' and 'but' are quite right.
Me either.
: perl6 operator precedence
:
:leftterms and list operators (leftward) [] {} () quotes
:left. and unary .
Unary . can't be left associative. Perhaps unary . is nonassoc like ++.
:nonassoc++ --
:leftis but
Should probably be down about where .. is, maybe same as.
:right **
:right ! \ and unary ~ + - * _
Probably unary ? goes here too.
:left=~ !~
Probably should be the same as all the other comparison ops.
:left* / % x
And maybe.
:left+ - _
And | maybe.
:left
Can be argued these are really just multiplicative. Or even exponential.
:right named unary operators, -X
:left = = lt gt le ge == != = eq ne cmp
:left
:left| ~
Not sure what to do with ~ if we move and |. Probably just follows |.
:left
:left|| ~~ //
:nonassoc.. ...
Maybe but here. Maybe is too, though compile-time declarations
don't necessarily have the same syntactic constraints as ordinary
expressions.
:right ??::
:right = := **= += -= _= *= /= %= x= = |= ~=
: = = = ||= ~~= //=
:left, =
= is no longer a comma. I think it has to be tighter than , now,
or we can't say
a = a, b = b
Perhaps it goes in as another nonassoc .. operator.
:left;
:left:
While semicolon is definitely looser than comma, it's not clear where
colon should go yet.
:nonassoclist operators (rightward)
:right not
I've also considered unifying Cnot with the list operators, which are
actually right associative, or you couldn't say
print sort 1,2,3;
On the other hand, it would be strange for Cnot to give its right
side a list context.
:leftand
:leftor xor err
Those are fine. :-)
Larry
Re: RFC: [] as the solitary list constructor
According to Larry Wall:
On Sat, 5 Oct 2002, Chip Salzenberg wrote:
: I rather like Perl 5's scalar comma operator.
Most of the uses of which are actually in void context [...]
I didn't realize you were distinguishing scalar from void in this, uh,
context. I agree that scalar comma is expendable if void comma can be
rescued. However:
... where it doesn't matter if we technically build a list and throw
it away, or throw away all but the last value, then throw that one
away too.
Except that it would impose list context on the values; and if the
values to be thrown away are no longer in void context, unnecessary
work may be done to evaluate them fully. This is a bad thing.
(Or are you rescinding the rule that void context is a special kind of
scalar context?)
If you really want the last value, you can always use
(LIST)[-1]
If scalar comma goes away, I'd be inclined to replace it with
do { E1; E2; E3 }
which evaluates E1 and E2 in void context.
--
Chip Salzenberg - a.k.a. -[EMAIL PROTECTED]
It furthers one to have somewhere to go.
Re: Fw: perl6 operator precedence table
On Thu, 26 Sep 2002, Joe Gottman wrote:
: Apocalypse 4 mentions unary '?' . Since this is used to force boolean
: context, I would assume that it has the same precedence as unary '+' and
: '_' which force numeric and string context respectively. By the way, has
: anyone come up with a use for binary '?' yet?
More likely to be a postfix operator. Maybe it even means the same thing:
if ?foo() {...}
if foo()? {...}
I've always wondered what the ! postfix operator means. The mathematicians
think they know. :-)
There's this basic rule that says you can't have an operator for both binary
and postfix, since it's expecting an operator in either case, rather than a
term (which is how we recognize prefix operators). The one exception I can
think of is that we might allow .. as a postfix operator, but only if followed
by a right bracket. That would let us say
a[0..]
rather than
a[0..Inf]
But that's a special case.
Larry
