Re: hyper operators - appalling proposal
I still feel this adds yet another layer of inconsistency and confusion. I can't look at a piece of code and know what it does, without referring up N lines to the top of the scripts. How is the infinite loop problem any different from other Halting problems? Karl Christian Soeller wrote: Trey Harris wrote: Yes. This is my fear of hyperoperation being the default for normal aggregates. Loops--and large, multiply-nested, potentially-infinite ones--can spring out of code that doesn't look loopy at all. Erm... you know what I mean. :-) Karl, do you have any objection to marking aggregates for which hyperoperation is to be the default? Then you could say: my mumble foo, bar; # Are the parens required in p6? # or my (foo, bar) is mumble; # Can you distribute properties? ... foo += bar; where mumble is matrix, hyper, or something along those lines (choosing great names is Larry, Damian and Allison's jobs, not mine :-) If we simply made such hyperoperated aggregates builtins rather than requiring user-defined classes, this would offer a compromise, would it not? This is a good compromise. The numerics person might even be able to say: use default = hyperops; # somewhere at the top of your script res = foo * sqrt(bar); while brent and others can do their CGI scripts without having to wait for the end of the known Perl universe.
Re: hyper operators - appalling proposal
At 8:30 AM -0400 7/16/02, Karl Glazebrook wrote: I still feel this adds yet another layer of inconsistency and confusion. I can't look at a piece of code and know what it does, without referring up N lines to the top of the scripts. How is the infinite loop problem any different from other Halting problems? It's not, the issue's really with what's better for the common case, which probably won't be PDL stuff. (Unfortunately--I think it's a nifty realm to work in) However... If operator overloading on particular classes doesn't work for you, and you don't want to just redefine the behaviour of an operator for a particular block, there's always the APL route. You've got all of Unicode handy--there's no reason we can't have a pragma that enables alternate characters for the hyperoperators. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
hyper operators - appalling proposal
In Apocalypse 2 Larry Wall wrote: RFC 082: Arrays: Apply operators element-wise in a list context APL, here we come... :-) This is by far the most difficult of these RFCs to decide, so I'm going to be doing a lot of thinking out loud here. This is research--or at least, a search. Please bear with me. snip So the resolution of this is that the unmarked forms of operators will force scalar context as they do in Perl 5, and we'll need a special marker that says an operator is to be auto-iterated. That special marker turns out to be an uparrow, with a tip o' the hat to higher-order functions. That is, the hyper-operator: a ^* b Excuse me, but *bletch*, - this is as ugly as sin. Especially when we get into complex formulae. Imagine: solution = (^-@b + sqrt(b^**2 ^+ 4^*@a^*c) ) ^/ (2^*@a); (or would it be ^sqrt() ?) - This looks like sendmail :-) What is wrong with using a * b - the only reason I can think is to preserve a backward compatibility which is not needed? perl6 is supposed to prefer improvement over backward compatibility. The last thing we need is yet more line noise in perl6. This is a pity because in many ways perl6 changes all look rather attractive to me (e.g. consistent sigils, use of . vs -, no need to make PDL arrays any different from perl arrays). Why do we need to preserve x as array length when you are proposing x.length ? As instigator of PDL, I am very concerned. Clearly inbuilt vectorization and compact arrays in perl6 will make PDL obsolete. I have no problem with that. A sign of success to get in the core. :-) What I do have a problem with is replacing it with a construct this ugly. If I was forced to write vector code like this I *WILL* give up on perl, and resort to Numerical Python or IDL instead. appalled, Karl Glazebrook
Re: hyper operators - appalling proposal
On Mon, 15 Jul 2002, Karl Glazebrook wrote:
In Apocalypse 2 Larry Wall wrote:
RFC 082: Arrays: Apply operators element-wise in a list context
APL, here we come... :-)
This is by far the most difficult of these RFCs to decide, so I'm going
to be doing a lot of thinking out loud here. This is research--or at
least, a search. Please bear with me.
snip
So the resolution of this is that the unmarked forms of operators will
force scalar context as they do in Perl 5, and we'll need a special
marker that says an operator is to be auto-iterated. That special
marker turns out to be an uparrow, with a tip o' the hat to
higher-order functions. That is, the hyper-operator:
a ^* b
Excuse me, but *bletch*, - this is as ugly as sin. Especially when we
get into
complex formulae. Imagine:
solution = (^-@b + sqrt(b^**2 ^+ 4^*@a^*c) ) ^/ (2^*@a);
That would not be very pretty, indeed. It would also not be very
efficient. (BTW, its b**2 - 4ac, not + :)A more efficient, pretty,
and clear way would be like this:
for a; b; c; s is rw -
$a; $b; $c; $s {
$s = (-$b + sqrt($b**2 - 4*$a*$c)) / (2*$a)
}
What is wrong with using a * b - the only reason I can think is to
preserve
a backward compatibility which is not needed?
...
Why do we need to preserve x as array length when you are proposing
x.length ?
I see your point. I went through a couple of my larger perl programs, and
the only time I used arrays in numeric context was in the C-style for
loop.
I think the idea is the red flag. If you have a 1-element array, you
wouldn't think a line like:
$end = array - 1
is going to take a long time and stick a big reference into $end. And a
lot of Perl 5 programmers would do that. I guess this is back on
backwards-compatibility. But do you see my point?
I wouldn't mind if this proposal was accepted, but I also think the hyper
operator syntax is nice. At least for what I'm doing, in which it's
usually Yet Another shorthand for a Cforeach (or now just Cfor) loop.
If I was forced to write vector code like this I *WILL* give up on perl,
and resort to Numerical
Python or IDL instead.
Well, I guess that will be your loss... especially when Python is
assimilated by Perl. You will have nowhere to go :)
appalled,
Karl Glazebrook
attempting unappalment,
Luke
Re: hyper operators - appalling proposal
Karl Glazebrook [EMAIL PROTECTED] disgusted: @solution = (^-@b + sqrt(@b^**2 ^+ 4^*@a^*@c) ) ^/ (2^*@a); [Stuff] If I was forced to write vector code like this I *WILL* give up on perl, and resort to Numerical Python or IDL instead. You can always use the map and foreach like we've done all along. And, frankly, I find this (surprisingly) legible. It's no great shakes, but there are regexen which are signifigantly worse. Remember, your never forced to do much of anything in Perl. Where I see a big win for hyper operators is in places where the scafolding code ordinarly clutters the actual work. I like being able to write @defaults ^//= 1; don't you? -Erik Is your boss reading your email? Probably Keep your messages private by using Lycos Mail. Sign up today at http://mail.lycos.com
Re: hyper operators - appalling proposal
At 2:09 PM -0400 7/15/02, Karl Glazebrook wrote: On Monday, July 15, 2002, at 01:52 PM, Aaron Sherman wrote: Sure, that's always an option. I think Perl has a lot going for it other than the way vectorization happens, and with the ability to define your own array behavior, you can pretty much do this however you want anyway. Yes but it would be nuts to have PDL arrays do things one way and inbuilt compact arrays do things another way. Oh, I dunno. I don't think it's all that bizarre to have Arrays operate one way and Matrices operate another way. But, then, that's just me. If you don't want to, you won't have to hyperoperate on matrices, or any other user-defined class, if you don't want to, as you're going to have to be able to override * for both the single element and aggregate case. The only real issue then is the behaviour of core arrays and hashes when dealt with in aggregate. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: hyper operators - appalling proposal
In a message dated Mon, 15 Jul 2002, Brent Dax writes: With explicit, you just get the result of Inf ** 2 (which presumably is still Inf) in $bar. Perhaps neither is what you want, but at least it doesn't take forever to run. Yes. This is my fear of hyperoperation being the default for normal aggregates. Loops--and large, multiply-nested, potentially-infinite ones--can spring out of code that doesn't look loopy at all. Erm... you know what I mean. :-) Karl, do you have any objection to marking aggregates for which hyperoperation is to be the default? Then you could say: my mumble foo, bar; # Are the parens required in p6? # or my (foo, bar) is mumble; # Can you distribute properties? ... foo += bar; where mumble is matrix, hyper, or something along those lines (choosing great names is Larry, Damian and Allison's jobs, not mine :-) If we simply made such hyperoperated aggregates builtins rather than requiring user-defined classes, this would offer a compromise, would it not? Trey
Re: hyper operators - appalling proposal
Trey Harris wrote: Yes. This is my fear of hyperoperation being the default for normal aggregates. Loops--and large, multiply-nested, potentially-infinite ones--can spring out of code that doesn't look loopy at all. Erm... you know what I mean. :-) Karl, do you have any objection to marking aggregates for which hyperoperation is to be the default? Then you could say: my mumble foo, bar; # Are the parens required in p6? # or my (foo, bar) is mumble; # Can you distribute properties? ... foo += bar; where mumble is matrix, hyper, or something along those lines (choosing great names is Larry, Damian and Allison's jobs, not mine :-) If we simply made such hyperoperated aggregates builtins rather than requiring user-defined classes, this would offer a compromise, would it not? This is a good compromise. The numerics person might even be able to say: use default = hyperops; # somewhere at the top of your script res = foo * sqrt(bar); while brent and others can do their CGI scripts without having to wait for the end of the known Perl universe.
