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 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]
>=====
>
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Share information about yourself, create your own public profile at
http://profiles.msn.com.
