RE: Perl6 grammar (take V)
On Sun, 14 Jul 2002, Brent Dax wrote:
Deborah Ariel Pickett:
# My perl5 sensibilities tell me that that's likely to cause a
# problem when I want to do something like this:
#
# $hashref = { function_returning_hash() };
#
# because I won't get the function's return values put into a
# hash, because the stuff inside the { ... } isn't a list of
# pairs. Instead I'll get a (reference to) a closure, not at
# all the same thing.
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).
# that this is being phased out for perl6 (the grammar backs that up).
I wouldn't take the grammar too seriously -- it's more or less one
person's interpretation of the Apocalypses, Exegeses, and recent mailing
list traffic.
my HASH $hashref;
my CODE $subref;
So if I have the above two declarations, and do this later:
$hashref = { ... };
$subref = { ... };
It does the right thing? This could work up to a point, but Perl can do
crazy things like this:
$foo ?? $hashref :: $subref = { ... };
and propagate context differently to different branches of the ternary
(try doing $x ? y : $z = (2,3,4) sometime -- very cool!). And while we
could interpret the block differently on each branch, that seems a bit too
scary.
(Alternatively, always parse it as a closure and afterwards run through
the parse tree, checking all the closures and converting those that only
contain pairs.)
Or use context to try and figure it out. Unfortunately, from the outside
I think either would just look like a reference. Maybe if the compiler
could figure out that your function would return pairs, it could fix
things up so that turns into a hash-ref. But then you can get into
trouble with a function that returns pairs only in non-hash-ref
contexts...
/s
Re: Perl6 grammar (take V)
On Monday 15 July 2002 06:57 am, Sean O'Rourke wrote:
On Sun, 14 Jul 2002, Brent Dax wrote:
Deborah Ariel Pickett:
# My perl5 sensibilities tell me that that's likely to cause a
# problem when I want to do something like this:
#
# $hashref = { function_returning_hash() };
#
# because I won't get the function's return values put into a
# hash, because the stuff inside the { ... } isn't a list of
# pairs. Instead I'll get a (reference to) a closure, not at
# all the same thing.
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 {}.
Ashley Winters
--
When you do the community's rewrite, try to remember most of us are idiots.
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: 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
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
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: 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.
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)
Brent Dax wrote:
$href = hash { %hash }; #B
Why the curlies? if Chash 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)
David Whipp:
# Brent Dax wrote:
# $href = hash { %hash }; #B
#
# Why the curlies? if Chash is a function (ctor), then surely
# these should be parentheses. In this context, parentheses are
# optional, so this could be written
#
#$href = hash %hash;
Chash is not a function. It's a keyword, analogous to Csub.
--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
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: 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.
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: 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
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
