>>>>> "RA" == Rod Adams <[EMAIL PROTECTED]> writes:
RA> Here's my stab at a sort syntax, pulling syntax over from REs:
RA> @out
RA> <== sort key:ri($_->[2]), key:s($_->[4])
RA> <== @in;
RA> Basicly, you have a list of RE syntax like C<key> values, whilch take
RA> various modifiers to say how to play with that key, and then an expr
RA> on how to generate the key given element $_.
RA> Possible modifiers: (verbose versions welcome)
RA> :r reverse/descending
RA> :n force numeric comparisons
RA> :s force string comparisons (default)
RA> :u unicode (implies :s)
RA> :i case insensitive (implies :s)
RA> :l localized collation order
RA> :x call custom compare sub (a la P5)
i would support longer modifier names as aliases like rules do.
also numeric comparisons can be float or int. semantically they are the
same but it does affect internal stuff if you do a GRT implementation. i
hate to see this exposure of internals but if we want speed here it
needs to be shown.
RA> This allows:
RA> @out = sort keys %hash; # everything gets defaulted
RA> @out = sort key:x{myfunc($a) cmp myfunc($b)}(), @in; # handy for P5
RA> migration, but not much else
RA> @out = sort key(myfunc($_)), @in; # same as above, but much better.
RA> @out = sort key(%lookup{$_->{remotekey}}), key:ir($_->{priority}),
RA> @in; # complex in P5, easy here.
overall i like it.
RA> Advantages:
RA> - Uses syntax idioms used elsewhere in P6.
RA> - Common cases are easy
RA> - Decent huffman coding.
huffman isn't needed here IMO. sort isn't called so often so longer
modifier names are not a hinderance. rules will be called way more often
so short modifier aliases are useful huffman there. a good syntax that
handles multiple keys and is easy to remember and read is more important
than brevity. and you can spread keys out over multiple lines:
@out = sort
key( %lookup{ .{remotekey} } ),
key:insensitive:descending:locale( 'somewhere' )( .{priority} ),
key:float ( substr( 0, 10 ) ),
key:integer ( /foo(\d+)bar/ ),
key:compare( { ^$a <=> ^$b } )( /(\d+)$/ ),
key:compare( \&my_compare_sub ) ( /(\d+)$/ ),
@in ;
i think the . replaces $_->. in fact IIRC -> isn't used anymore for
deref.
do we need , between keys? sort basically will expect a list (without
commas?) of keys and then a list of data.
note that the code in key needs to be called in a list context so
grabbing (which i did perl5 style there. gotta get perl6::rules from
damian!) will work. maybe rules can deal with that in a better way than
i can think of.
note that i passed an argument to the locale modifier.
note that the custome compare callbacks can be a block or a sub
name/ref. the callback sub would be passed 2 args as usual.
do we need the ==> or <== stuff anywhere?
RA> Disadvantages:
RA> - Do we really want things that look like REs that are not REs?
other than the short names, it doesn't look like rule stuff.
RA> - If we do this, are we setting ourselves up to create other RE-like
RA> creatures for grep, for, etc, to the point
RA> where people will start wanting to roll their own in modules?
well, with the long names that isn't a problem.
RA> Thoughts?
drop the short names. but i like it. let's see if it passes larry's
muster.
uri
--
Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
