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: for loop and streams
-- On Thu, 26 Sep 2002 14:06:50 John Williams wrote: We should respect default values if arrays can declare them. Perhaps there will be a modifier for operator declarations to declare what the default behavior should be. Otherwise I don't know how different behaviors for different operators would be possible, especially for user-defined operators. Having an operator force some very narrow kind of context to control what the list returns is very strange. The list should respond in some generalized way (undef or whatever the list is set to pretend is undef) and have the operator choose how to respond to that, and return whatever it deems to be the result of the operation. Under this mechanic the only tricky part is figuring out when the list is exhausted and when it is passing the autoviv value legitimately. Related note, if we can define default values for a list, is that a compile time or runtime property. I confess as to not knowing quite how to tell. I would hope it was runtime for the syntax alone: users but autovivs (Anonymous User); -Erik sub operator:foo is hyper_default(1) ... I agree with Blech, but we can procrasticate doing it at least until Damian makes it clear how operators will define their behavior. Otherwise, a contextualized undef (0 in numeric context, '' in string) would seem DWIM to me. I wouldn't want to throw tons of warnings from one operation, so maybe hyper-operating on unequal lengths gets a new warning, instead of throwing lots of 'undefined value' warnings. ~ John Williams Is your boss reading your email? Probably Keep your messages private by using Lycos Mail. Sign up today at http://mail.lycos.com
Re: for loop and streams
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) 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. 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. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: for loop and streams
On Thu, 26 Sep 2002, Sean O'Rourke wrote: 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. Maybe treating lazy and/or infinite data structures as infinitely short for this purpose would capture most of what we mean, so hype(A,B) would take the longer of two finite lengths, the more finite of a finite and an infinite length, and infiniti for two infinite operands. Sounds reasonable. Of course, this still doesn't account for what kind of extension makes most sense for a given operand/operator pair. It seems to me that anything more complex than undef (which is consistent with out-of-bounds array accesses) would be a nightmare to get right. We should respect default values if arrays can declare them. Perhaps there will be a modifier for operator declarations to declare what the default behavior should be. Otherwise I don't know how different behaviors for different operators would be possible, especially for user-defined operators. sub operator:foo is hyper_default(1) ... I agree with Blech, but we can procrasticate doing it at least until Damian makes it clear how operators will define their behavior. Otherwise, a contextualized undef (0 in numeric context, '' in string) would seem DWIM to me. I wouldn't want to throw tons of warnings from one operation, so maybe hyper-operating on unequal lengths gets a new warning, instead of throwing lots of 'undefined value' warnings. ~ John Williams
