Re: Grammar ambiguities again (was: Perl 6 Summary for week ending
Sorry, I was being too terse in my original message, I guess some of the
meaning got lost.
When I said:
> > If %(...) makes a shallow copy of its innards, as Perl5's { ... } does,
> > then how do you impose hash context onto something without doing the
> > copy?
What I meant to say was:
> > Speaking hypothetically, for a moment, let's assume that what %(...)
> > does is it makes a shallow copy of its innards, as Perl5's { ... } does.
> > Then what syntax do you use to impose hash context onto something
> > without doing the copy?.
In other words, I was attempting a proof-by-contradiction. It didn't
come out too well, I gotta say.
I'm pretty sure that none of us is quite on the same wavelength here.
But since it's all speaking hypothetically, who cares?
Anyway, after all this, I went back to see Apocalypse 2, and this bit
stood out:
And the { foo => $bar } list composer will be required to use => (or be
in a hashlist context), or it will instead be interpreted as a closure
without a sub. (You can always use an explicit sub or hash to cast the
brackets to the proper interpretation.)
which I guess answered my original question.
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
"You can't take me up, you can't wind me down, There's no escape but I'll never
drown, no wires or strings, no rough and smooth, just like fire and stings,
watch me closely, watch my every move." - _Wine from the Water_, Alan Parsons
Re: Grammar ambiguities again (was: Perl 6 Summary for week ending
On Tuesday 16 July 2002 01:01 am, Deborah Ariel Pickett wrote:
> If %(...) makes a shallow copy of its innards, as Perl5's { ... } does,
> then how do you impose hash context onto something without doing the
> copy?
%{} forces hash context. What else could it do?
%{ foo() } calls foo() in hash context, asking it to return a HASH ref, does
it not?
%( foo() ) would call foo() in list context asking for a list of PAIRs. If
foo() returns a hash ref which you want a copy of, you would use %( *foo() )
which would flatten the returning hash ref into a PAIR list, then construct a
hash ref from those pairs.
My argument is that %{} already represents 'HASH' context, and we don't need
%() for that as well. Instead, we need a punctuation-happy hash constructor.
Ashley Winters
--
When you do the community's rewrite, try to remember most of us are idiots.
Re: Grammar ambiguities again (was: Perl 6 Summary for week ending
> > Using %(...) to create a hashref, as { ... } does in Perl5, would go
> > against all that, because the purpose of making a hashref is to
> > *reference* something. Now a unary % operator/sigil/prefix might mean
> > referencing, or it might mean dereferencing, depending on whether the
> > symbols following are (...) or {...}. Ouch.
> As with $(), I assume %() would force hash context. Nothing more. You'd
> just probably never need to force hash context, so we won't see it often.
If all it does is force hash context, then this:
$href = %( %somehash );
would simply mean the same as this:
$href = \%somehash; # reference existing hash.
and not this, which may have been what I wanted:
$href = hash { %somehash }; # reference clone of hash.
Or, in other words, context alone can't turn a simple reference into a
constructor. Something, somewhere, has to clone %somehash's contents.
If %(...) makes a shallow copy of its innards, as Perl5's { ... } does,
then how do you impose hash context onto something without doing the
copy? There'd need to be a different syntax to do that, since Perl
can't possibly always DWIM in this case. %(...), assuming it's valid
Perl6 (I don't remember seeing it or $(...) in any Apocalypse[1]),
means one or the other; it can't mean both.
[1] $(...) has been seen inside double-quoted strings to interpolate
expressions, but that's not the same thing.
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
"You can't take me up, you can't wind me down, There's no escape but I'll never
drown, no wires or strings, no rough and smooth, just like fire and stings,
watch me closely, watch my every move." - _Wine from the Water_, Alan Parsons
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 @foo, @bar; # Are the parens required in p6? > # or > my (@foo, @bar) is ; # Can you distribute properties? > <...> > @foo += @bar; > > where 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: Grammar ambiguities again (was: Perl 6 Summary for week ending
On Tue, 16 Jul 2002, Deborah Ariel Pickett wrote:
> > I still have my vote on %() as a hash constructor in addition to {}. :)
>
> The problem I see with that is that % as a prefix implies a
> *dereferencing*, though years of Perl5 conditioning like this:
> %{ $mumble } = return_a_hash();
> print_hash( %{ $mumble } );
>
> (Yes, the braces are optional; I'm assuming that they'll still be needed
> in Perl6, when $mumble is something complex.)
>
> Using %(...) to create a hashref, as { ... } does in Perl5, would go
> against all that, because the purpose of making a hashref is to
> *reference* something. Now a unary % operator/sigil/prefix might mean
> referencing, or it might mean dereferencing, depending on whether the
> symbols following are (...) or {...}. Ouch.
As with $(), I assume %() would force hash context. Nothing more. You'd
just probably never need to force hash context, so we won't see it often.
Luke
Re: Grammar ambiguities again (was: Perl 6 Summary for week ending
> I still have my vote on %() as a hash constructor in addition to {}. :)
The problem I see with that is that % as a prefix implies a
*dereferencing*, though years of Perl5 conditioning like this:
%{ $mumble } = return_a_hash();
print_hash( %{ $mumble } );
(Yes, the braces are optional; I'm assuming that they'll still be needed
in Perl6, when $mumble is something complex.)
Using %(...) to create a hashref, as { ... } does in Perl5, would go
against all that, because the purpose of making a hashref is to
*reference* something. Now a unary % operator/sigil/prefix might mean
referencing, or it might mean dereferencing, depending on whether the
symbols following are (...) or {...}. Ouch.
I suppose we're going to have that kind of thing already in Perl6,
though, with {...} meaning both ref and deref, just as it has in Perl5:
%foo{"abc"} # dereference-type op, extract member "abc".
hash { "abc" => 1 } # reference-type op, construct member "abc".
That's kind of ouchy too, come to think of it.
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
"You can't take me up, you can't wind me down, There's no escape but I'll never
drown, no wires or strings, no rough and smooth, just like fire and stings,
watch me closely, watch my every move." - _Wine from the Water_, Alan Parsons
RE: Grammar ambiguities again (was: Perl 6 Summary for week ending 20020714)
David Whipp:
# Brent Dax wrote:
# > $href = hash { %hash }; #B
#
# Why the curlies? if C is a function (ctor), then surely
# these should be parentheses. In this context, parentheses are
# optional, so this could be written
#
#$href = hash %hash;
C is not a function. It's a keyword, analogous to C.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
RE: Grammar ambiguities again (was: Perl 6 Summary for week ending 20020714)
Brent Dax wrote:
> $href = hash { %hash }; #B
Why the curlies? if C is a function (ctor), then surely these should
be parentheses. In this context, parentheses are optional, so this could be
written
$href = hash %hash;
Dave.
Re: Grammar ambiguities again (was: Perl 6 Summary for week ending 20020714)
On Monday 15 July 2002 11:22 pm, Deborah Ariel Pickett wrote:
> Besides, does
> $hashref = some_function_returning_a_hash()
> make $hashref simply refer to the result of the function, or does it
> make $hashref refer to a hash containing a *copy* of the result of the
> function? If Perl6 is going to do fancy things with functions returning
> lvalues, which looks like the case, those two things aren't necessarily
> the same thing.
I don't think scalar context can ever make copies of aggregate data. Here's a
little experiment.
sub func {
return a => 10; # returns a single pair; not a list or a hash
}
$foo = func(); # $foo is a PAIR ref, not a hash ref
$foo = { func() } # $foo is a CODE ref
$foo = { *func() } # $foo is still a CODE ref, I assume?
$foo = %{ func() } # die "Not a HASH reference"
$foo = hash func(); # This should work
> Or, saying the same thing another way, does this:
> $href = %hash;
> which I presume will be legal Perl6, mean the same as this Perl5:
> $href = \%hash;#A
It always means A according to some apocalypse.
my %hash = (key => "bar");
sub foo {
return %hash;
}
$ref = foo();# $ref = \%hash
%copy = foo(); # %copy = { %hash }
%alias := foo(); # \%alias == \%hash
%$ref = foo(); # ($ref = {}) = %hash
> or this Perl5:
> $href = { %hash }; #B
The ways I can think to do that are:
%$href = %hash; # autovivify $href = {}, then copy
$href = hash %hash; # Perhaps * flattening is required?
> and how would I say each of A and B in Perl6 unambiguously?
I don't much like the effects of using %$foo as an lvalue. Having a context
sigil clobber the value doesn't seem very perl5ish. Perhaps I have my
blinders on and don't see where Perl5 does that.
> Automatic referencing and dereferencing is all well and good, and it
> appears that it's here to stay in Perl6 (it's been in most Apocalypses),
> but I don't think anyone's actually sat down yet to thrash out exactly
> under what circumstances it happens.
I think the rule of auto-hashifying only when an explicit pair is found is
gonna be hard to swallow.
I still have my vote on %() as a hash constructor in addition to {}. :)
Ashley Winters
--
When you do the community's rewrite, try to remember most of us are idiots.
RE: Grammar ambiguities again (was: Perl 6 Summary for week ending 20020714)
Deborah Ariel Pickett:
# > > ..., and someone pointed out that it had a problem
# > > with code like "{ some_function_returning_a_hash()
# }". Should it give a
# > > closure? Or a hash ref? ...
# > Oh, well now that it's stated this way... (something went
# wrong in my
# > brain when I read the actual message) It returns a closure
# :(. A4 says
# > that as a term, { } define a closure, unless it contains a pair
# > constructor at the top level. But, thanks to Perl 6's
# smartness, that would
# > be excessive syntax anyway:
# > $hashref = some_function_returning_a_hash()
# > would do what you wanted.
#
# Would it always? What if I had two functions (or more), all returning
# part of the hash I want to package up? Can I do:
# $hashref = some_function_returning_a_hash(),
# some_other_function_returning_more_of_the_hash();
# and get the result of both functions into the anonymous hash?
Not directly--just use the hash {} constructor.
# Besides, does
# $hashref = some_function_returning_a_hash()
# make $hashref simply refer to the result of the function, or does it
# make $hashref refer to a hash containing a *copy* of the result of the
# function? If Perl6 is going to do fancy things with
# functions returning
# lvalues, which looks like the case, those two things aren't
# necessarily
# the same thing.
#
# Or, saying the same thing another way, does this:
# $href = %hash;
# which I presume will be legal Perl6, mean the same as this Perl5:
# $href = \%hash;#A
# or this Perl5:
# $href = { %hash }; #B
# and how would I say each of A and B in Perl6 unambiguously?
A. And unambiguously:
$href = \%hash; #A
$href = hash { %hash }; #B
# Automatic referencing and dereferencing is all well and good, and it
# appears that it's here to stay in Perl6 (it's been in most
# Apocalypses),
# but I don't think anyone's actually sat down yet to thrash out exactly
# under what circumstances it happens.
Autodereferencing happens whenever we have a scalar but we need an array
or hash; autoreferencing happens whenever we have an array or hash but
need a scalar (usually because of scalar assignment, but not
necessarily).
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
Grammar ambiguities again (was: Perl 6 Summary for week ending 20020714)
Back to this again . .
> > ..., and someone pointed out that it had a problem
> > with code like "{ some_function_returning_a_hash() }". Should it give a
> > closure? Or a hash ref? ...
> Oh, well now that it's stated this way... (something went wrong in my
> brain when I read the actual message) It returns a closure :(. A4 says
> that as a term, { } define a closure, unless it contains a pair
> constructor at the top level. But, thanks to Perl 6's smartness, that would
> be excessive syntax anyway:
> $hashref = some_function_returning_a_hash()
> would do what you wanted.
Would it always? What if I had two functions (or more), all returning
part of the hash I want to package up? Can I do:
$hashref = some_function_returning_a_hash(),
some_other_function_returning_more_of_the_hash();
and get the result of both functions into the anonymous hash?
Besides, does
$hashref = some_function_returning_a_hash()
make $hashref simply refer to the result of the function, or does it
make $hashref refer to a hash containing a *copy* of the result of the
function? If Perl6 is going to do fancy things with functions returning
lvalues, which looks like the case, those two things aren't necessarily
the same thing.
Or, saying the same thing another way, does this:
$href = %hash;
which I presume will be legal Perl6, mean the same as this Perl5:
$href = \%hash;#A
or this Perl5:
$href = { %hash }; #B
and how would I say each of A and B in Perl6 unambiguously?
Automatic referencing and dereferencing is all well and good, and it
appears that it's here to stay in Perl6 (it's been in most Apocalypses),
but I don't think anyone's actually sat down yet to thrash out exactly
under what circumstances it happens.
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
"It's no good believing in somebody else if you can't believe in yourself. You
give them the reason to take all the power and wealth." - _Turn it Up_, Alan
Parsons
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 @foo, @bar; # Are the parens required in p6? # or my (@foo, @bar) is ; # Can you distribute properties? <...> @foo += @bar; where 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
Karl Glazebrook: # On Monday, July 15, 2002, at 01:45 PM, Sean O'Rourke wrote: # # > On Mon, 15 Jul 2002, Luke Palmer wrote: # > # >> On Mon, 15 Jul 2002, Karl Glazebrook wrote: # >> # >>> @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, # # yeah the minus sign got lost in all the clutter. My point I think :) # # >> and clear way would be like this: # > # > Not necessarily true! The compiler can figure out that a # sequence of # > operators is hyped and avoid the temporary arrays (like your # > for-loop). It takes a little more work, but it's really not # all that # > hairy when the necessary information is right in the syntax. # > # > Furthermore, the beauty of the hyper-operators (or the # > implicitly-vector normal operators below) is they don't give the # > programmer a loop body in which to do wierd things to the arrays. # > Since # > # > @y = $a ^* @x ^+ @b # > # > is all a single operation from the user's perspective, the compiler # > can make it faster than a loop written in pure Perl. # # This is exactly what happens in PDL currently, but instead you say # # $y = $a * $x + $b # # where everything is an object # # > I actually find myself using @a in numeric context quite a bit, but # > would # > have no objections to changing it to @a.length, since the former is # > completely bizarre to someone not familiar with Perl. # # glad you agree. I want to hear what Larry says. # # > # >> 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 C (or now # just C) # >> loop. # > # > Maybe we could add a hyper-context to cut down on the line-noise # > without startling Perl 5 programmers: # > # > @solution = ^( -@b + sqrt(@b**2 + 4*@a*@c) ) / (2*@a) ) # # Still looking ugly! That statement looks ugly anyways. $solution = -$b + sqrt($b**2 + 4*$a*$c) / (2*$a); Ugly, ugly, ugly. It needs more spacing to make it pretty, not fewer carrots. Besides, mistakes like this are the alternative: #This should be $baz, not $foo... $foo=something_that_returns_an_infinite_array_ref(); ... #1654 lines later... $bar=$foo ** 2; #Anyone have a date for the heat death of the Universe? If the hyperoperization was implicit, the guy who wrote this would be sitting there twiddling his thumbs till he died. Now imagine that that error was in a CGI script running on Apache/NT. He *can't* kill the Perl process and make life better--he doesn't have the access. (I've learned this point the hard way. :^) ) 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. # > Or (this might break something): # > # > @solution ^= -@b + sqrt(@b**2 + 4*@a*@c) ) / (2*@a); # > # # But would not work if there was no = sign - e.g. foo(@x * @b +1) # # > (then watch as people have all their # inplace-array-bitwise-xors change # > meaning;) # # # > # > I agree that the ^op syntax is painful if you have to type # it a lot, # > but for the majority of people not using Perl for numerical code, # > hyper-operation is something out of the ordinary, and seems # to deserve # > syntactic markers. For example: # > # > my @things = @args || @defaults; # @args if it is true, # else @defaults # > # vs my @things = @args ^|| @defaults; # $args[$_] || $defaults[$_] # > for 0..X # > # > If infix operators are implicitly vector, the first's becoming the # > second # > could be a bit surprising. Even more so since, if we're handling # > infinite # > lists, hyper-operators should iterate over the number of # items in their # > shorter argument. # # I say the latter is more useful and it is time to break with the past I say we shouldn't decide for the user what's more useful. Personally, I think the first is more useful, but that's irrelevant. With implicit vectorization, they have to jump through hoops to get the first one. So many hoops, in fact, that I can't even think of a decent way to do it. (@args.length ?? @args :: @defaults would work, but that's horrible.) With explicit, one of the ways of doing it is one character longer, but at least the other one is *possible to do*. # > On Monday, July 15, 2002, at 01:03 PM, Erik Steven Harrison wrote: # > # > # > 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 # # @defaults = 1 Somehow, that seems wrong to me... # > 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 #
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
[several replies flattened into one] On Monday, July 15, 2002, at 01:45 PM, Sean O'Rourke wrote: > On Mon, 15 Jul 2002, Luke Palmer wrote: > >> On Mon, 15 Jul 2002, Karl Glazebrook wrote: >> >>> @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, yeah the minus sign got lost in all the clutter. My point I think :) >> and clear way would be like this: > > Not necessarily true! The compiler can figure out that a sequence of > operators is hyped and avoid the temporary arrays (like your for-loop). > It takes a little more work, but it's really not all that hairy when the > necessary information is right in the syntax. > > Furthermore, the beauty of the hyper-operators (or the implicitly-vector > normal operators below) is they don't give the programmer a loop body in > which to do wierd things to the arrays. Since > > @y = $a ^* @x ^+ @b > > is all a single operation from the user's perspective, the compiler can > make it faster than a loop written in pure Perl. This is exactly what happens in PDL currently, but instead you say $y = $a * $x + $b where everything is an object > I actually find myself using @a in numeric context quite a bit, but > would > have no objections to changing it to @a.length, since the former is > completely bizarre to someone not familiar with Perl. glad you agree. I want to hear what Larry says. > >> 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 C (or now just C) >> loop. > > Maybe we could add a hyper-context to cut down on the line-noise without > startling Perl 5 programmers: > > @solution = ^( -@b + sqrt(@b**2 + 4*@a*@c) ) / (2*@a) ) Still looking ugly! > Or (this might break something): > > @solution ^= -@b + sqrt(@b**2 + 4*@a*@c) ) / (2*@a); > But would not work if there was no = sign - e.g. foo(@x * @b +1) > (then watch as people have all their inplace-array-bitwise-xors change > meaning;) > > I agree that the ^op syntax is painful if you have to type it a lot, but > for the majority of people not using Perl for numerical code, > hyper-operation is something out of the ordinary, and seems to deserve > syntactic markers. For example: > > my @things = @args || @defaults; # @args if it is true, else @defaults > # vs > my @things = @args ^|| @defaults; # $args[$_] || $defaults[$_] for 0..X > > If infix operators are implicitly vector, the first's becoming the > second > could be a bit surprising. Even more so since, if we're handling > infinite > lists, hyper-operators should iterate over the number of items in their > shorter argument. I say the latter is more useful and it is time to break with the past > > On Monday, July 15, 2002, at 01:03 PM, Erik Steven Harrison wrote: > > > 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 @defaults = 1 > 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. Karl
Re: hyper operators - appalling proposal
On Mon, 2002-07-15 at 11:29, Karl Glazebrook wrote:
> complex formulae. Imagine:
>
> @solution = (^-@b + sqrt(@b^**2 ^+ 4^*@a^*@c) ) ^/ (2^*@a);
>
> (or would it be ^sqrt() ?) - This looks like sendmail :-)
I would imagine that non-binary operators would simply have a hyper-form
(which could be provided as a module) such as:
hypersqrt(@x)
or perhaps
@x.^{sqrt()}
or something like that.
> What is wrong with using @a * @b - the only reason I can think is to
There's nothing really *wrong* with it. In fact, I see no reason that
they can't co-exist:
@a = @b * @c if @d == 2;
since making hyper-operation context sensitive seems a reasonable thing
to me.
> Why do we need to preserve @x as array length when you are proposing
> @x.length ?
This is one of the most common operations performed on arrays. It seems
like Perl6 should be hospitable in that respect.
> 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
PDL does much more than that, but of course you know that :) I think a
Perl6 re-design of PDL will be much more streamlined, but still
essential.
> If I was forced to write vector code like this I *WILL* give up on perl,
> and resort to Numerical
> Python or IDL instead.
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.
Re: hyper operators - appalling proposal
On Mon, 15 Jul 2002, Luke Palmer wrote: > On Mon, 15 Jul 2002, Karl Glazebrook wrote: > > > @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: Not necessarily true! The compiler can figure out that a sequence of operators is hyped and avoid the temporary arrays (like your for-loop). It takes a little more work, but it's really not all that hairy when the necessary information is right in the syntax. Furthermore, the beauty of the hyper-operators (or the implicitly-vector normal operators below) is they don't give the programmer a loop body in which to do wierd things to the arrays. Since @y = $a ^* @x ^+ @b is all a single operation from the user's perspective, the compiler can make it faster than a loop written in pure Perl. > > 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 actually find myself using @a in numeric context quite a bit, but would have no objections to changing it to @a.length, since the former is completely bizarre to someone not familiar with Perl. > 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 C (or now just C) loop. Maybe we could add a hyper-context to cut down on the line-noise without startling Perl 5 programmers: @solution = ^( -@b + sqrt(@b**2 + 4*@a*@c) ) / (2*@a) ); Or (this might break something): @solution ^= -@b + sqrt(@b**2 + 4*@a*@c) ) / (2*@a); (then watch as people have all their inplace-array-bitwise-xors change meaning;) I agree that the ^op syntax is painful if you have to type it a lot, but for the majority of people not using Perl for numerical code, hyper-operation is something out of the ordinary, and seems to deserve syntactic markers. For example: my @things = @args || @defaults; # @args if it is true, else @defaults # vs my @things = @args ^|| @defaults; # $args[$_] || $defaults[$_] for 0..X If infix operators are implicitly vector, the first's becoming the second could be a bit surprising. Even more so since, if we're handling infinite lists, hyper-operators should iterate over the number of items in their shorter argument. /s
Re: Perl6 grammar (take V)
On Fri, 2002-07-12 at 13:22, Thomas A. Boyer wrote:
> Aaron Sherman wrote:
> > An example:
> >
> > $pid = fork() // -1;
> > if $pid < 0 {
> > # error ...
> > } else unless $pid {
> > # Parent
> > } else if $pid > 0 {
> > # Child
> > } else {
> > # Huh? Can't happen
> > }
>
> Of course, your indentation implies a different syntax than the parser actually sees.
I don't think so. What do you see when you look at that? Is there more
than one order? "if ... else unless ... else ..." is different from "if
elsif (!...) ... else ..." in what way?
I think you're confusing nested if statements (which is all you can do
in C, you don't have any other option) with this syntax for chaining
conditionals (which is more like a C switch). Granted you can do the
same thing in C in terms of effect, the language just doesn't give you a
handy syntax for it.
This syntax is actually much less ambiguous than "1 + 2 * 3 + 4", for
which you have to know precedence to resolve the ambiguity.
But, realistically I'm still doing it the Perl5 way. The "else if" vs
"elsif" distinction is only important to the "lexer" (not that there
will be a clear distinction in Perl6).
I'm still not 100% happy with dropping the ()s around the expr, but I
can see why it's appealing.
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
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.
>
> > 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 C (or now just C) 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
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. > 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: Perl 6 Summary for week ending 20020714
> ..., and someone pointed out that it had a problem
> with code like "{ some_function_returning_a_hash() }". Should it give a
> closure? Or a hash ref? ...
Oh, well now that it's stated this way... (something went wrong in my
brain when I read the actual message) It returns a closure :(. A4 says
that as a term, { } define a closure, unless it contains a pair
constructor at the top level. But, thanks to Perl 6's smartness, that would
be excessive syntax anyway:
$hashref = some_function_returning_a_hash()
would do what you wanted.
Luke
Re: Perl6 grammar (take V)
On Monday 15 July 2002 07:52 am, Brent Dax wrote:
> Ashley Winters:
> # > You've got a point. There's an easy way to say "I want a sub":
> # >
> # > my $sub = -> { ... }
> # >
> # > But I can't think of a similarly punctuation-intensive way
> # to say "I
> # > want a hash." (someone please step in and correct me).
> #
> # I nominate:
> #
> # $() == scalar()
> # %() == hash()
> # @() == array()
> #
> # For the above function:
> #
> # $hashref = %(function_returning_list_which_needs_to_be_hashified());
> #
> # That would make %() a hash constructor, just like {}.
>
> IIRC, $() and @() are already being used to denote scalar and array
> context. Of course, an array or hash in scalar context would probably
> referencify.
But we don't need @() for array context, we have @{} for that.
@{foo()} would pass foo() a 'want' value of 'ARRAY', would it not? In fact,
the block in @{} as a whole has a 'want' value of 'ARRAY', and that
wantedness propagates to whatever statements return a value from the block.
So, I still want to use @() as a smart array constructor. If you pass an array
reference to @(), it would dereference. If you passed a list, it would
construct a reference. Perhaps it could even copy an array if it's passed one
directly...
my @copy = [ *@orig ]; # before
my @copy = @( @orig ); # after
Or not. That's weird.
Ashley Winters
--
When you do the community's rewrite, try to remember most of us are idiots.
RE: Perl6 grammar (take V)
Ashley Winters:
# > You've got a point. There's an easy way to say "I want a sub":
# >
# > my $sub = -> { ... }
# >
# > But I can't think of a similarly punctuation-intensive way
# to say "I
# > want a hash." (someone please step in and correct me).
#
# I nominate:
#
# $() == scalar()
# %() == hash()
# @() == array()
#
# For the above function:
#
# $hashref = %(function_returning_list_which_needs_to_be_hashified());
#
# That would make %() a hash constructor, just like {}.
IIRC, $() and @() are already being used to denote scalar and array
context. Of course, an array or hash in scalar context would probably
referencify.
I'd suggest that $(), @(), and %() all be syntactic sugar for a
context() keyword:
$(foo) = context SCALAR : foo();
@(foo) = context ARRAY : foo();
%(foo) = context HASH: foo();
foo(); = context VOID: foo();
\foo() = context REF : foo();
foo()[0..5] = context ARRAY, 6: foo();
my MyClass $x=foo() = my MyClass $x=context MyClass : foo();
This context() keyword would be like the opposite of want(). Of course,
something like:
context $x: foo();
Might not work.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
