Nice to have'it
Hi,
I have couple of ideas which may or may not worth it, so I didn't
wrote the RFC but will list them here in short.
Here are the nice to have'it.
1. There will be good to have some sort of "match and/or assign" operator
for structures i.e. HASHES. Can't still figure out the syntax but may be
it must borrow some ideas from "switch/case" and Pascal
"with" it should be also easy to say :
if ( %a match %b )
or
%a assign_diff %b - assign and/or add all key and/or values from %b which
are
not in %a OR diff ... :")
2. "in" operator i.e.
$a in (5,6,10,33,45)
$a in @b
3. min,max,avg !!!
$a = min(5,6,10,33,45)
if ( max(@b) 22 ) ...
4. op() - Prolog like operator/keywords precedence.
f - position of the op/keyword
x - if there are more operators in this operand they must be lower
precedence
y - if there are more operators in this operand they must be
equal or lower precedence.
yfx - left-associative evaluate from left to right
xfy - righ-associative evaluate from right to left
op(100,yfx,"*");
op(200,yfx,"+");
this mean that :
a+b*3 is (a+b)*c, but not a+(b*c)
More interesting will be redifining the keywords :")
5. Persistency and easy integration in other systems as example mod_perl,
deamons like stuff etc... THE CLUE
6. CPAN = module - bundle - distribution
Distriburion(many modules+many bundles) to be something that the OS vendors
will add to their OS's or other people do separately.
F.e..Perl Power Pack.
Primary task as small as possible interaction with the user...
many of the current CPAN modules can't install successfuly on the fly
'cause thay need some info for which they ask interactively.
In some extent this can be achieved for OS vendors 'cause they know
their Config better..
7. DBM f/locking support in standard Perl
8. The following syntax to be possible :
$hash{/re/} i.e. this is the same like
my @res;
foreach my $k (keys %hash)
{
if ($k =~ /re/) {push $hash{$k},@res}
};
OR
keys %hash{/re/}
values %hash{/re/}
each %hash{/re/}
This is very usefull for fast searching in DBM for example.
9. 64-bit aware Perl - Merced is comming !!!
10. I know this is very hard or some may argue against this, but I think
it should be possible to hack perl itself easy by every "seasoned" Perl
programmer i.e. some possibility to change language on the fly.
(And not only by the Perl-core-hackers).
A good steps toward that direction are Filter and Inline modules...
further it will be very good if we can Lex/Yacc-ing in Perl,
preprocesing source etc..
11. "Gobble" parameters from both sides i.e.
sub add(x,y){ }
may act like this :
x add y
add x,y
add(x,y)
This should be some play with Prototypes. I think also that it is good as
mantioned in one RFC that there should be the way that we can have several
subs with the same name and depending on their number of params executed is
that one that match..i.e
sub add(a,b) {}
sub add(a,b,c) {}
If I call add(4,5) the first one is executed, if I call add($c,12,45)
second one.
12. CONTEXT - there should be a way to define different and new types of
contexts. Let we think what is a context ?
Shortly it is - THE WAY WE PASS PARAMETERS and THE WAY WE RECIEVE THE
RESULT.
So the context can be SUB that accept a reference to all the params and
return
reference - may be .. i.e.
sub add(a,b) { return $a+$b };
this SUB is supposed to handle the scalars, but when we use it in
array context it shold do whatever is expected she to do w/o
explictly code this in the SUB or to be more clear DWIM.
(the description again can be handled to some extent by the prototypes)
then :
{
context array;
@c = add @a,@b; # or better @a add @b
}
sub array
{
$sub = shift;
@refs = @_;#not the same but just example, leave details for you
my @res;$i=0;
#I dont care about the number of arrays passed here i.e foreach $v (@refs)
# we should care
while ( $#{$refs[0]} $#{$refs[1]})
{
my $a = shift @{$refs[0]};
my $b = shift @{$refs[1]};
$res[$i++] = $sub($a,$b);
};
return \@res;# !??!
}
Some EXAMPLES of contexts : scalar,array,iterator,boolean,matrix
That is in short, thanx for your attention
PS.
Perl6 should stay Perl, but must be more than Perl.
Perl6 should be fast as mentioned in one RFC - but most importantly it must
be featurefull and must continue its tradition - "writing less, doing much"
=
iVAN
[EMAIL PROTECTED]
=
Re: Nice to have'it
Hey Raptor et al:
Wow you did some homework! Nice ideas, but the consensus seems to be "roll
your own". I've noted that opertors working on arrays are generally
discouraged in favor of scalar ops in these discussions, so for example your
(min,max) (ceiling, floor) are coded thousands of times by hundreds of
people each year since there is no primitive. I assume, but may be
incorrect, that this is an offshoot of people never having coded in a
language resplendent in array and matrix ops, but once you have, its hard to
go backwards..
My take is that the lack of array/matrix operators reduce the productivity
of the Perl community. The language should be rich in array (and matrix)
operators so we don't waste our time coding our personal favorite ceiling
operator (yes I know its simple, that's why I don't want to waste time on
it).
As Larry said in Monterey this year (I paraphrase),
"Difficult things should become easy, and the impossible should become
difficult."
Following that logic- shouldn't easy (ceiliing) become trivial (a primitive
op)?
my 2c
From: "raptor" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Nice to have'it
Date: Mon, 28 Aug 2000 14:10:26 +0100
Hi,
I have couple of ideas which may or may not worth it, so I didn't
wrote the RFC but will list them here in short.
Here are the nice to have'it.
1. There will be good to have some sort of "match and/or assign" operator
for structures i.e. HASHES. Can't still figure out the syntax but may be
it must borrow some ideas from "switch/case" and Pascal
"with" it should be also easy to say :
if ( %a match %b )
or
%a assign_diff %b - assign and/or add all key and/or values from %b which
are
not in %a OR diff ... :")
2. "in" operator i.e.
$a in (5,6,10,33,45)
$a in @b
3. min,max,avg !!!
$a = min(5,6,10,33,45)
if ( max(@b) 22 ) ...
4. op() - Prolog like operator/keywords precedence.
f - position of the op/keyword
x - if there are more operators in this operand they must be lower
precedence
y - if there are more operators in this operand they must be
equal or lower precedence.
yfx - left-associative evaluate from left to right
xfy - righ-associative evaluate from right to left
op(100,yfx,"*");
op(200,yfx,"+");
this mean that :
a+b*3 is (a+b)*c, but not a+(b*c)
More interesting will be redifining the keywords :")
5. Persistency and easy integration in other systems as example mod_perl,
deamons like stuff etc... THE CLUE
6. CPAN = module - bundle - distribution
Distriburion(many modules+many bundles) to be something that the OS
vendors
will add to their OS's or other people do separately.
F.e..Perl Power Pack.
Primary task as small as possible interaction with the user...
many of the current CPAN modules can't install successfuly on the fly
'cause thay need some info for which they ask interactively.
In some extent this can be achieved for OS vendors 'cause they know
their Config better..
7. DBM f/locking support in standard Perl
8. The following syntax to be possible :
$hash{/re/} i.e. this is the same like
my @res;
foreach my $k (keys %hash)
{
if ($k =~ /re/) {push $hash{$k},@res}
};
OR
keys %hash{/re/}
values %hash{/re/}
each %hash{/re/}
This is very usefull for fast searching in DBM for example.
9. 64-bit aware Perl - Merced is comming !!!
10. I know this is very hard or some may argue against this, but I think
it should be possible to hack perl itself easy by every "seasoned" Perl
programmer i.e. some possibility to change language on the fly.
(And not only by the Perl-core-hackers).
A good steps toward that direction are Filter and Inline modules...
further it will be very good if we can Lex/Yacc-ing in Perl,
preprocesing source etc..
11. "Gobble" parameters from both sides i.e.
sub add(x,y){ }
may act like this :
x add y
add x,y
add(x,y)
This should be some play with Prototypes. I think also that it is good as
mantioned in one RFC that there should be the way that we can have several
subs with the same name and depending on their number of params executed is
that one that match..i.e
sub add(a,b) {}
sub add(a,b,c) {}
If I call add(4,5) the first one is executed, if I call add($c,12,45)
second one.
12. CONTEXT - there should be a way to define different and new types of
contexts. Let we think what is a context ?
Shortly it is - THE WAY WE PASS PARAMETERS and THE WAY WE RECIEVE THE
RESULT.
So the context can be SUB that accept a reference to all the params and
return
reference - may be .. i.e.
sub add(a,b) { return $a+$b };
this SUB is supposed to handle the scalars, but when we use it in
array context it shold do whatever is expected she to do w/o
explictly code this in the SUB or to be more clear DWIM.
(the description again can be handled to some extent by the prototypes)
then :
{
context array;
@c = add @a,@b; # or
Re: Nice to have'it
David Corbin wrote:
raptor wrote:
$hash{/re/} i.e. this is the same like
my @res;
foreach my $k (keys %hash)
{
if ($k =~ /re/) {push $hash{$k},@res}
};
OR
keys %hash{/re/}
values %hash{/re/}
each %hash{/re/}
Way cool. I'd love this.
Well, $hash{/re/} would only evaluate to a single scalar.
More likely, you'd want @hash{/re/}, which would be
equivalent to @hash{ grep { /re/ } keys %hash }.
So values %hash{/re/} is unnecessary, since it would
be the same as @hash{/re/}.
And keys %hash{/re/} would be the same as
grep {/re/} keys %hash -- a very small gain, imho.
The proposed each %hash{/re/} wouldn't work, even given
hash slices like %hash{@keys}, since each needs an actual
hash object to attach to; and slices aren't.
--
John Porter
We're building the house of the future together.
Re: Nice to have'it
Damian Conway wrote: I have a draft RFC that proposes that the LIST argument of a grep be optional in a hash slice, and default to the key list of the sliced hash. So: That's a waste of RFC paper, Damian. But let's generalize it a bit, and say that Perl6 should have a standard intrinsic mechanism -- perhaps just an extension of Ccaller -- which allows any sub to get whatever details it wants on its calling context. "Was I called in list context as the index of a hash slice? What hash?" This would allow any user func (not to mention built-ins) to decide for itself what its default arguments should be. -- John Porter We're building the house of the future together.
